https://www.gentoo.org/downloads/signatures/ currently provides fingerprints and key IDs for the signing keys, which users are instructed to retrieve from a keyserver. However, GPG fingerprints are merely SHA1 hashes, making key verification the weakest link in the chain. The TLS certificate, image hashes and their signatures are already SHA256. SHA1 is fairly weak nowadays. Fingerprint checking is more of a stop-gap measure than best practice. That being said, I urge you to publish the full keys on that page. This ensures a trust chain at least as good as SHA256, which is very reasonable for 2016. Users should not rely on checking fingerprints for keys retrieved over insecure channels. Reproducible: Always
Signatures are mainly RelEng territory, www just has a copy of the current signatures. We'll stay on CC if anything from us is needed.
The full keys are available over HTTPS for a long time: https://qa-reports.gentoo.org/output/service-keys.gpg jstein: Add a link to them?
great, that sounds good to me.
(In reply to Eduard - Gabriel Munteanu from comment #0) > https://www.gentoo.org/downloads/signatures/ currently provides fingerprints > and > key IDs for the signing keys, which users are instructed to retrieve from a > keyserver. However, GPG fingerprints are merely SHA1 hashes, making > key verification the weakest link in the chain. The TLS certificate, > Just to have it mentioned int he discussion; a 2nd preimage attack on SHA1 is a very different story than a collission attack.
They are also available as a full keyring in the tree with a manifest confirming the validiy of the download in app-crypt/gentoo-keys
(In reply to Brian Dolbec from comment #5) > They are also available as a full keyring in the tree with a manifest > confirming the validiy of the download in app-crypt/gentoo-keys The primary usecase is to allow all users, including new users or those who don't already have a Gentoo installed close by, to verify downloads easily.
> The primary usecase is to allow all users, including new users or those who don't already have a Gentoo installed close by, to verify downloads easily. As one such user, I found it ridiculous to be presented both a stage 3 tarball and its accompanying PGP signature over unsecured HTTP. Here is the offending page, linked from <https://gentoo.org/downloads/>: http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3-amd64/ Is this considered a separate issue?
(In reply to B.D. from comment #7) > > The primary usecase is to allow all users, including new users or those who don't already have a Gentoo installed close by, to verify downloads easily. > > As one such user, I found it ridiculous to be presented both a stage 3 > tarball and its accompanying PGP signature over unsecured HTTP. Here is the > offending page, linked from <https://gentoo.org/downloads/>: > > http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3-amd64/ > > Is this considered a separate issue? I'm not sure I understand your concerns around the http content, can you provide more detail? -A
(In reply to B.D. from comment #7) > > The primary usecase is to allow all users, including new users or those who don't already have a Gentoo installed close by, to verify downloads easily. > > As one such user, I found it ridiculous to be presented both a stage 3 > tarball and its accompanying PGP signature over unsecured HTTP. Here is the > offending page, linked from <https://gentoo.org/downloads/>: > > http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3-amd64/ > > Is this considered a separate issue? Yes, it is separate but no, it is not an issue. The files are provided via third-party mirrors, so TLS certificates do not provide any advantage towards verifying the authenticity of the contents.
The keys are now also published via WKD on https://www.gentoo.org/ , so I guess we can close this.
