Fetching file portage-20160101.tar.xz.md5sum ... Fetching file portage-20160101.tar.xz.gpgsig ... Fetching file portage-20160101.tar.xz ... Checking digest ... Checking signature ... gpg: Signature made Sat Jan 2 02:58:06 2016 EET using RSA key ID C9189250 gpg: Good signature from "Gentoo Portage Snapshot Signing Key (Automated Signing Key)" [expired] gpg: Note: This key has expired! Primary key fingerprint: DCD0 5B71 EAB9 4199 527F 44AC DB6B 8C1F 96D8 BF6D Subkey fingerprint: E1D6 ABB6 3BFC FB4B A02F DF1C EC59 0EEA C918 9250 Getting snapshot timestamp ... Syncing local tree ... As far as I can tell, this key expired in November. It seems that my automated update scripts have run `emerge --sync` without the latter ever failing on this. Why does portage webrsync accept snapshots signed like this?! Imho this has serious security implications. I was told by Alex Legler that the expiration date of that key was extended and the key was republished. Apparently I've somehow missed the information about the correct procedures for updating these keys?
The key you are referring to is only expired on your system. Openpgp (gpg) keys have a reset-able expiry. That is for security issues. Because of that, periodically hte gpg key's expiry is extended to keep it a valid active key. When that is done, the gpg key is re-uploaded to the keyservers. That data is then available to all. You need to periodically update your keyring from the keyservers for it to be up-to-date. adjust the actual path to the keyring to suit your install: gpg --home-dir /etc/portage/gnupg --refresh-keys
Ok, please let me try to get this straight... (In reply to Brian Dolbec from comment #1) > The key you are referring to is only expired on your system. > > Openpgp (gpg) keys have a reset-able expiry. That is for security issues. Exactly which "security" issues do you have in mind? https://security.stackexchange.com/questions/14718/does-gpg-key-expiration-add-to-security > Because of that, periodically hte gpg key's expiry is extended to keep it a > valid active key. When that is done, the gpg key is re-uploaded to the > keyservers. What is the point of setting an expiration date at all, if you plan to virtually extend it forever? Why not instead properly generate new keys, sign them with the old one and use revocation for if needed? At minimum, I find the practice of changing the expiration date of the snapshot signing key questionable and the (non-fatal!) error message confusing. If webrsync trusts expired GPG keys, then this is still a security issue. What if the old key leaks, is cracked or if you really want it to expire? Emerge --sync MUST NEVER ALLOW the portage tree to be synced from an untrusted source!!! Unfortunately the exact opposite happens. At bare minimum this should fail for the purpose of notifying the sysadmin to update the keys. Reopening. So does Gentoo expect that each time before doing an webrsync users should first update (from which secure keyserver?) the GPG keys so that 1) The expiration dates are updated 2) All revocations take effect? Afaik OpenPGP keyservers are HKP which run over plain HTTP and a MiTM in possession of the expired keypair could easily tell the client that "expiration for (a 20 year old) key extended" and "no revocation issued"! Therefore I do hope it is Gentoo's practice to revoke its old keys soon after expiry. > That data is then available to all. You need to periodically update your > keyring from the keyservers for it to be up-to-date. > > adjust the actual path to the keyring to suit your install: > > gpg --home-dir /etc/portage/gnupg --refresh-keys Last time I checked the webrsync/gpg related online documentation for Gentoo, it had no information about the need to update the keys, neither does portage do so itself.
If you really want, you can configure it to use the app-crypt/gentoo-keys keyring. It will be maintained up to date. Also there is code being worked on (however slowly, I'm too busy to do a lot now) to integrate the gkeys project into portage to control the various keyrings for gpg to do verification, updates to the keyrings, etc.. I just don't have the time right now to figure out all the details and change all the docs for that option,... I'd much rather spend the time on actual coding for the project. After all it will replace the existing system when complete. Perhaps you can assist in updating the relevant wiki pages. The webrsync module is old and needs porting to python and the new sync system. Currently it just has a glue interface which runs the old bash script. It does not provide much flexibility to control all aspects of the sync and verification. Also, yes, there is plans and some actions underway to make and use rotating signing subkeys with the primary keys air-gapped for ultimate security. But in the meantime the infra team extended the expiry of the existing key. There are also still issues to deal with after the git tree migration. Which is why some things are missing in the rsync tree still. As for debating the intricacies, etc of extending expiry,... That is for a different discussion arena. Also the http vs https source urls, that is also in transition to being https exclusively. The target url is from api.gentoo.org which is https only. Some data is already exclusively serverd from there, some is duplicated in the old system still, some still only in the old system. The dev-python/ssl-fetch project I started is slowly being introduced into various tools. It does ssl certificate authentication as well as downloading gpg signatures, handling timestamps for bandwidth savings, etc.. So far layman, mirrorselect and gkeys are using it. I plan on migrating some areas of portage code to it soon too. If you have some time to devote to documentation updates, thank you. We can help you with getting them committed to teh pages you don't have authorization to edit.
Although I tend to agree expired cert should result in failure (possibly after asking for and attempting to update the cert from a known source), getting OpenPGP into portage takes precedence. If not taking expirations into account generally, though, it opens for downgrade attacks on the package (for signature expirations) and for the key, you can use an expired but revoked key, remove the revocation self-sig and present it to a user after the fact, so it is generally bad to rely on (this possibility to remove data if controlling the source is also why a certificate can reasonably only be extended in expiry, never shortened) But it isn't a major blocker... so normalizing bug severity.
It appears that the issue of trusting expired keys is now fixed. On the other hand, sys-apps/portage-2.3.40-r1 now seems to be unable to download&verify any recent snapshots signed with a valid key, leading sync to fail: >>> Syncing repository 'gentoo' into '/var/portage'... Fetching most recent snapshot ... Trying to retrieve 20180703 snapshot from http://distfiles.gentoo.org ... Fetching file portage-20180703.tar.xz.md5sum ... Fetching file portage-20180703.tar.xz.gpgsig ... Fetching file portage-20180703.tar.xz ... Checking digest ... Checking signature ... gpg: WARNING: unsafe permissions on homedir '/var/lib/gentoo/gkeys/keyrings/gentoo/release' gpg: Signature made Wed Jul 4 03:51:28 2018 EEST gpg: using RSA key E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250 gpg: Good signature from "Gentoo Portage Snapshot Signing Key (Automated Signing Key)" [expired] gpg: Note: This key has expired! Primary key fingerprint: DCD0 5B71 EAB9 4199 527F 44AC DB6B 8C1F 96D8 BF6D Subkey fingerprint: E1D6 ABB6 3BFC FB4B A02F DF1C EC59 0EEA C918 9250 Fetching file portage-20180703.tar.bz2.md5sum ... /.../ Fetching file portage-20180701.tar.gz.md5sum ... 20180701 snapshot was not found * Latest snapshot date: 20180630 * * Approximate snapshot timestamp: 1530405900 * Current local timestamp: 1530405301 * * The current local timestamp is possibly identical to the * timestamp of the latest snapshot. In order to force sync, use * the --revert option or remove the timestamp file located at * '/var/portage/metadata/timestamp.x'.
It seems that for stable users this can be worked around by the following steps: 1) Upgrading the keyring manually by using: GNUPGHOME=/var/lib/gentoo/gkeys/keyrings/gentoo/release gpg --refresh-keys 2) syncing as usual 3) Adding "=app-crypt/gentoo-keys-201807020151 ~amd64" to package.accept-keywords (since there no longer seems to be a stable version of gentoo-keys in the tree). 4) Upgrading gentoo-keys. Apparently the new keys (with postponed expiration dates) were not timely included in the (stable) keyring, causing this failure which requires manual intervention.
Looks like it indeed does not accept snapshots signed with expired keys. But now it enters a seemingly infinite download loop.
Created attachment 540540 [details] emerge-webrsync stdout&stderr From .xz to .bz2 and .gz. Rinse&repeat with another mirror.
(In reply to Jaak Ristioja from comment #6) > Apparently the new keys (with postponed expiration dates) were not timely > included in the (stable) keyring, causing this failure which requires manual > intervention. See bug 661838. (In reply to Fedja Beader from comment #7) > Looks like it indeed does not accept snapshots signed with expired keys. But > now it enters a seemingly infinite download loop. Noted in bug 661838. *** This bug has been marked as a duplicate of bug 646212 ***
