Summary: | cannot merge packages with "verify-sig", as there are no valid keys | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | tsattler |
Component: | Eclasses | Assignee: | Michał Górny <mgorny> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | bertrand, feinorgh, gentoo, matoro_gentoo, sam, tom_gentoo, toralf |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=873211 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
tsattler
2023-02-13 11:51:38 UTC
net-dns/libidn2 is also affected. I think the recent changes to verify-sig/gemato make it fatal. I don't think it makes sense overall for us to worry about expiry for existing packages as there's no way to distinguish between a bump someone is doing (where we want a non expired key) and something which just expired since committing. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=014a26bb2e7e746cbd4a474a3d84075132b6c916 commit 014a26bb2e7e746cbd4a474a3d84075132b6c916 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2023-02-13 19:26:19 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2023-02-13 19:27:35 +0000 verify-sig.eclass: Revert "Use gemato openpgp-verify-detached" This is causing verification failures when verifying old signatures made with now-expired keys. Reverts: 75ea89a43b8d3efb6b264296f819d04d3c18c3af Bug: https://bugs.gentoo.org/894164 Signed-off-by: Michał Górny <mgorny@gentoo.org> eclass/verify-sig.eclass | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) Thanks for the report. I've reverted the changes for now. The problem is that gemato was originally meant to be used to verify the ::gentoo repository, so there was no real need to verify old signatures. I need to think how to handle this best. *** Bug 894236 has been marked as a duplicate of this bug. *** *** Bug 894224 has been marked as a duplicate of this bug. *** *** Bug 894218 has been marked as a duplicate of this bug. *** *** Bug 894202 has been marked as a duplicate of this bug. *** Ok, it's harder than I anticipated. The problem is that GnuPG doesn't emit "trust" for expired keys — probably simply because expired keys aren't trusted in the first place. This technically isn't a problem in this scenario because we're using a known set of keys. I suppose I'll need to explicitly track keys that gemato imported with trust=True, and assume trusted if one of these keys is used. This is now fixed in gemato 19.0. I've tested that signify-keys-signify passes after reapplying the verify-sig.eclass patches. However, I'm going to wait for the new version to become stable before reapplying them. Thanks to all people who reported this and I'm sorry for the problem. (In reply to Michał Górny from comment #10) > This is now fixed in gemato 19.0. I've tested that signify-keys-signify > passes after reapplying the verify-sig.eclass patches. However, I'm going > to wait for the new version to become stable before reapplying them. > > Thanks to all people who reported this and I'm sorry for the problem. ftr we ended up doing commit 519f14fe6f74814196996da2d45c077003144db0 Author: Michał Górny <mgorny@gentoo.org> Date: Mon Jan 23 09:22:12 2023 +0100 verify-sig.eclass: Use gemato openpgp-verify-detached w/ 20.0+ Use openpgp-verify-detached when app-portage/gemato-20.0 is installed. This lets us test the new code paths on ~arch with minimal risk of breakage on stable. Signed-off-by: Michał Górny <mgorny@gentoo.org> |