2.1.14 -- dropping qualified.txt and com-certs.pem

[Daniel Kahn Gillmor]

hi GnuPG folks--

in 2.1.14, c19b2061274cd50838e62a2acbdc7e7d24888e7e says:

   sm: Do not install cacert and other root certificates.
    
    * doc/Makefile.am (dist_pkgdata_DATA): Move qualified.txt and
    com-certs.pem to ...
    (EXTRA_DIST): here.
    --
    
    With Let's Encrypt there is no more need to push CA Cert.
    
    Signed-off-by: Werner Koch <wk at gnupg.org>

The result is that a "make install" ends up not shipping either
/usr/share/gnupg/com-certs.pem or /usr/share/gnupg/qualified.txt

The justification about Let's Encrypt covers CA Cert, but moving these
files to not be installed by "make install" seems like it also has an
effect on the STEED "nonthority" and on the list of qualified German
network authorities -- do you envision Let's Encrypt taking over both of
those roles as well?  Also, should GnuPG ship the Let's Encrypt
authority's certificate instead?  If not, how will users know how to
validate LE-signed sites?

Moreover, the info for gpgsm in 2.1.14 still implies that GnuPG ships
both files.

As a distributor, i'd like to ship documentation that matches what's
installed.  I see four options for the debian packaging:

 0) clean up the info/man pages to not claim that any of these files will
    be installed.

 1) go ahead and keep shipping the files from the source repo (they're
    still present) even though they aren't installed by "make install"

 2) decide on some new CAs to trust, write our own qualified.txt file,
    and install them both.

 3) point to other CA lists already installed by the OS, and generate
    qualified.txt from the same sort of system-level defaults (i don't
    know how to do this right now)

What do you think distros should do with this situation?

Thanks for the update and the new release!

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20160715/30b23c13/attachment.sig>