Binpkg update ignored for signed package: file removed

[inf1nity]

Hi,

I've been using signed binary packages for a few months now and everything was working just fine.

Last update on my binary package server was 8th of January.

At that time (end of the updates) there were 1251 signed binary packages in /var/cache/binpkgs, with extension .gpkg.tar .

I just ran eix-sync and in the course of approx. 15 minutes it informed me, that:

[Hu]

You had signed packages, which needed to be updated, probably for a pkgmove. The move would invalidate the signatures, rendering the package unusable. The following options exist to handle this:

• Delete the package. This is easy, and was what the Portage developers chose.
• Update the contents, and leave the signature invalid. Portage should refuse to handle a package with an invalid signature, so this seems like a bad choice.
• Update the contents, and remove the signature. If the user is signing packages, the user is probably validating the signatures, so this would again make the package unusable.
• Update the contents, and rebuild the signature. As discussed in the linked commit, this was judged to be a lot of trouble, so it was not done.
• Ignore the update, and leave the old metadata. This would probably cause problems later.

I saw quite a few pkgmove events come through recently as packages migrated into the dev-debug/ category.

It would be nice if the signature could have been regenerated. This seems like an area for a Portage improvement, if someone were to volunteer to write it.

[sam_]

Just to be explicit: before that commit, Portage would crash.

It's also complicated by the fact that even if we have signing capabilities locally, they may not match the keyring used to verify too.

Maybe if we implement Zac's suggestion in bug 921431 to verify on fetch and then not again for getbinpkg, that'd work, but I'm hesistant to mess with that for now.

As a workaround, you may be able to use some Portage options on your builder so it refreshes the binpkgs (if there isn't a suitable one, we might be able to then add one).

[inf1nity]

Thank you both for the explanations.

As far as I'm concerned, please correct me if I'm wrong, there should be two gpg homedirs, one where the binary package server signing key is stored and the /etc/portage/gnupg directory where the public keys are stored for verification.

Both are set up correctly on the binary package host and /etc/portage/gnupg on all clients.

Everything is working there.

What I found was that I had to add the following gpg-agent.conf file in the gpg homedir where the signing key is stored

[inf1nity]

So getting the fingerprint out of the archive seems to involve doing this:

tar -C /tmp/tempdir -xf libreoffice-7.5.9.2.gpkg.tar libreoffice-7.5.9.2/metadata.tar.zst.sig
gpg --list-packets /tmp/tempdir/libreoffice-7.5.9.2/metadata.tar.zst.sig | grep 'issuer fpr'

I'm sure there is also a python method for that.

Getting the private key fingerprints of those in the binary package key gpg homedir should be relatively easy and then one could just compare them and if a match is found invoke the gpg unlock class so that the user is asked for the password to the signing key.

After that the whole archive would have to be extracted, both .sig files removed, new signatures generated and repacked.

[inf1nity]

The --list-packets gnupg option seems to be for debug purposes only and shouldn't be relied on.

This works and is based on the signature verification code:

[sam_]

[inf1nity]

Maybe my point of view is truly limited because I'm having a hard time thinking of cases where I would want them to be resigned and I can only come up with one that is sane enought for portage to automatically perform the action. It was not my intention to offend.

If the user has set BINPKG_GPG_SIGNING_GPG_HOME, BINPKG_GPG_SIGNING_KEY and FEATURE binpkg-signing, then they intend to sign packages. If not, just remove the package, as is currently implemented. For my use case this would already filter out all client systems, because they have neither of them set. But to be sure:

If a package that is signed is encountered, get the fingerprint of the signature inside the package. Compare it against the private keys - you can't sign without it - in BINPKG_GPG_SIGNING_GPG_HOME. If no match is found, just remove it as is.

If a match is found, then the user not only intends to sign packages on that host but also has the private key that was used to create the signature on that package, meaning the user has the power to resign it with the exact same key. Only the owner of the binary package host should match here.

I would not assume that a user ever gets access to the Gentoo private signing key, otherwise this whole security concept would fall apart, correct? So that issue is removed.

Should the intention be to support key-migration, then portage would need to support something like

BINPKG_GPG_SIGNING_KEY_MIGRATION["old-id/fingerprint"]="new-id/fingerprint"

for every old key that could be encountered. It should be possible to filter out expired private keys, via either gpg or python-gnupg, and the keys of the BINPKG_GPG_SIGNING_KEY_MIGRATION array, although they should have been set to expired. If no match for the fingerprint encountered in the signed package is found via this logic fallback to package removal.

Which edge cases would remain? I mean the moment you require that the exact same private key that created the packages signature or its configured migration key is present and valid and force the resigning to be with that key, it should either succeed or fail, correct?


Regarding another issue I had, because I want to manage the contents myself:

Should whoever intends to merge getuto into portage read this, please keep

PORTAGE_TRUST_HELPER=true

so that it doesn't import the Gentoo signing keys into /etc/portage/gnupg. I would like that to be another security mechanism and only have my own signing keys (public) imported on clients, so that no other binpkgs are accidentally installed. Them I manage via my own update script similarly to how getuto does it.

[inf1nity]

This seems to work for listing secret subkeys and their expiration date (date +%s format), if it exists, otherwise it will probably be an empty string, but I'd have to look at it again to be sure: