-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RPM distrusts signatures done by previous versions of prolonged keys #50
Comments
This comment was marked as outdated.
This comment was marked as outdated.
Yep, see #46 |
This is of course basically a duplicate of #46, but... This issue keeps popping up from many directions. As long as the predominant life-form in this field (gpg, to be clear) is stripping the old key when postponing expiry, in what appears to be the documented way of doing so, I don't think we can really swipe it under the "legacy" carpet. |
#46 was due to the use of SHA1, right? But the linter doesn't report anything wrong in this case. |
Oh, there was an SHA1 somewhere in there as well, but the key expiry thing was the big deal there too. But this ticket with the reproducer steps makes it nice and clear. |
So would you mind summarizing what's wrong with the prolonging of this key? Is this not allowed anymore? What should Copr do? It's not clear to me what's the expiry thing from reading #46, sorry. |
Basically it's GPG and Sequoia disagreeing over RFC-4880 interpretation. And as I already said here and in #46 (comment), I do think rpm-sequoia really just needs to accept the result as an OK (rather than legacy untrusted). Not because one interpretation is right and the other wrong, but because real-world usage requires it (not entirely unlike the situation with v3 signatures). It's not like accepting such signatures introduces some gigantic risk in the rpm context. |
Then, if this was fixed in rpm-sequoia 1.4.1, and this version is present in f38, why do we still get this issue? |
It's there in the ticket & PR details, but basically 1.4.1 changed the behavior to consider such packages "untrusted" rather than simply fail. It helps upgrading away from such packages which is enough for legacy packages, but this is not such a case really. |
|
I can see this output from gpg |
No, this doesn't help. Maybe I saw that the error messages were missing but didn't see the |
You might be confused by having the older pubkey imported, as discussed here fedora-copr/copr#2878. Aka "importing the older pubkey" (not prolonged, but still valid, expires next year):
This is though a bit unexpected. That RPM has been signed off by the updated/prolonged keypair, and RPM accepts it even with the old key installed:
|
Another problem we might have is that |
@Jakuje there was a relevant discussion in #46, but I don't think GPG maintainers were involved. @mlschroe how do you eventually handle this in SUSE, considering you depend on rpm-sequoia and you probably prolong keys/signatures the way we do? Have you relaxed some policies in the distro? |
I was only vacation the previous few weeks and I'm only now catching up.
When canonicalizing an OpenPGP certificate, GnuPG considers the newest self signature. This means that the validity of a data signature may change when a new self signature is introduced. Image Alice sends a signed message to Bob saying: "I owe you 100 Euro". She could create a new self signature that says that the signing key does not have the signing capability, which would invalidate the signature. Sequoia uses the self signature that was live at the time that the signature was generated. This makes the above harder (although not impossible). The point is less about security and more about consistency and robustness; users find it surprising when a signature that was once valid is suddenly considered invalid. Given the practical problems, I'll change rpm-sequoia to accept self-signatures created after the data signature was generated. |
Sounds good. Hope you enjoyed your vacation! |
- When we verify a data signature, we canonicalize the signer's certificate to look as it did at the time of the data signature. - When exporting a certificate, GnuPG strips old self signatures. - This means that when a certificate's expiration time is extended, say, we are no longer able to verify old data signatures, because the certificate is not considered to be valid as of the data signature's creation time! - Relax this requirement. Also allow a certificate, if it can be canonicalized as of the current time. - Fixes #50.
It was great, thanks! 2 of 4 of us came back with corona, though :D. |
From what I can tell, patch from #52 doesn't help (applied the patch on top of Fedora Rawhide package) in
|
Yeah, but I may be doing something wrong. Is the one-liner from #52 supposed to just work on top of v1.4.1? |
My theory was that #52 is enough to fix the issue. There's only one other commit since 1.4.1 and that has to do with CI, so it is not relevant here. The
You can see that the lint is returned even if
I think It would be helpful if you could provide the certificate as it is on your system and ideally a link to a package that I can use to recreate the issue. Thanks for helping to debug this, @praiskup! |
I believe the original reproducer helps here:
Throws |
@praiskup, thanks for investigating this and reposting the reproducer. I updated the PR. Here's what I see on Fedora 38:
Can you please test that this fixes the issue. Thanks! |
I rebuilt the updated package in
The situation with
But I believe this is a short-term solution, though. We should find a way to "extend" keys without stripping. Should we track this somewhere? |
Thanks for confirming that the fix now works. I should have tested my initial suggestion with your reproducer, but I didn't. I'm sorry about that.
The warnings are indeed a bit annoying and they are not really actionable. Perhaps it would be better to turn them off. @pmatilai, what do you think?
Good question. The problem isn't how certificates are extended, but that |
Yeah, drowning the user in warnings they can't do anything about is not particularly useful. Let's just silence it for the time being. As for gnupg, I think we should at least file a bug on that behavior there. Who knows how intentional (or not) that particular behavior is, gnupg is a pretty old piece of software too. |
Thank you for fixing this. In the meantime I filled a gnupg bug against Red Hat Bugzilla, I'm not sure where to fill an upstream RFE. https://bugzilla.redhat.com/show_bug.cgi?id=2235323 |
Upstream bug tracker is supposedly at https://dev.gnupg.org/ |
I suppressed the lint in #54 . |
I filled the upstream issue at least do see if this is intentional or not: https://dev.gnupg.org/T6689
Does the sequoia's gpg replacement or the sequoia-sop already supports this use case? Would copr support this as an alternative to use gnupg for start? |
These fixes are included in the 1.5.0 release. |
@decathorpe ☝️🙏 |
Thank you for forwarding the issue!
I don't know.
Copr just uses obs-signd, @mlschroe could comment on this, but it would be nice to have an upstream issue filled by someone who better understands the benefits/motivation. |
Can you publish 1.5.0 to crates.io too? |
Fixed. It seems I forgot to remove the |
Thanks! Will push the update to Fedora later today. |
Thanks @nwalfield and @decathorpe ! It occurred to me that a possible to way to both eat and keep the cake might be only issuing the lints if there are more than one self-signature, ie assume that in that case it hasn't been stripped a'la gpg. I don't know if it's possible/meaningful in practise though. |
@pmatilai, that's a pretty clever idea! That said, my feeling is that the case is pretty rare in practice, and detecting it would add more than a bit of implementation complexity. So, for now, I think I'll just leave it disabled. |
In Copr, we "prolong" the expiration time of GPG keys with
gpg --edit-key
, withexpire
=>5y
=>save
commands. See the Copr issue for more info. After this action, RPM stops trusting all the signatures done before the time ofgpg --edit-key
action, if checked with the updated pub key.Steps to reproduce with prebuilt packages in Fedora Copr:
Import the key, note the validity seems to be from 2019-08-15 to 2028-08-12:
Verify the key:
It is not quite obvous what to do about this. This seems like a too pedantic
policy requirement, or is the key prolonged a wrong way?
Reproducible both with Rawhide and 38. But the RPM package versions on Rawhide are here:
The files related to this bugreport.
The text was updated successfully, but these errors were encountered: