2.1.14 -- dropping qualified.txt and com-certs.pem
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Fri Jul 15 12:38:25 CEST 2016
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
>> 0) clean up the info/man pages to not claim that any of these files will
>> be installed.
> Okay, will do.
>> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 948 bytes
Desc: not available
More information about the Gnupg-devel