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

[Daniel Kahn Gillmor]

Hi Werner and Andre--

thanks for your fast responses.

On Fri 2016-07-15 11:43:59 +0200, Werner Koch <wk at gnupg.org> wrote:
> For com-certs.pem.  We don't want to decide which root CAs are good (if
> there are any at all).  In the pas ca-cert was distributed to give it a
> push but cacert never took off except for geeks.  Well, there is one
> exception: the certifciate for sks-keyservers.net.
>
> The qualified.txt had only expired certificates and was thus useless.
> Also the rules for qualified signatures changes a a couple of years ago.
> It is not anymore possible to have a definitive list of root
> certificates to indicate a certificate used for qualified signatures.
> That whole qualified signature system is FUBAR.

ok, this makes sense.  Would it also make sense, then, to look for
com-certs.pem and qualified.txt (if gpgsm looks for them at all) in
/etc/gnupg/ instead of /usr/share/gnupg/ ?  /etc is typically under
control of the local system administrator, while /usr/share/gnupg is
expected to be maintained by the package.

If the theory is that the package has no business shipping generic
certificate authorities (with a special carve-out for the SKS pool) then
/etc/ seems like the better place.

>> authority's certificate instead?  If not, how will users know how to
>> validate LE-signed sites?
>
> dirmngr uses the system provided certificates.

hm, i'm not actually seeing this behavior, but that's probably a
separate thread.

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

great, thanks!

>>  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"
>
> Isn't this a task for Debian's voliatile repo?

it's been called "stable-updates" since squeeze -- but sure, we can make
a separate package to handle standard certs if someone has a proposal
for what they should be.  Until that point, we can let the local system
administrator hand the situation, i guess.

              --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/f6ea1c99/attachment.sig>