2.1.14 -- dropping qualified.txt and com-certs.pem
wk at gnupg.org
Fri Jul 15 11:43:59 CEST 2016
On Fri, 15 Jul 2016 03:39, dkg at fifthhorseman.net said:
> The result is that a "make install" ends up not shipping either
> /usr/share/gnupg/com-certs.pem or /usr/share/gnupg/qualified.txt
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.
> authority's certificate instead? If not, how will users know how to
> validate LE-signed sites?
dirmngr uses the system provided certificates.
> 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.
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?
> 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)
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
/* Join us at OpenPGP.conf <https://openpgp-conf.org> */
More information about the Gnupg-devel