Relax "No binding signature" #46
Comments
|
You can use $ sq-keyring-linter /tmp/cert.asc
Certificate B88B2FD43DBDC284 is not valid under the standard policy: No binding signature at time 2023-05-02T15:41:54Z
Certificate B88B2FD43DBDC284 contains a User ID ("openSUSE Project Signing Key <[email protected]>") protected by SHA-1
Examined 1 certificate.
0 certificates are invalid and were not linted. (GOOD)
1 certificate was linted.
1 of the 1 certificates (100%) has at least one issue. (BAD)
0 of the linted certificates were revoked.
0 of the 0 certificates has revocation certificates that are weaker than the certificate and should be recreated. (GOOD)
0 of the linted certificates were expired.
1 of the non-revoked linted certificate has at least one non-revoked User ID:
1 has at least one User ID protected by SHA-1. (BAD)
1 has all User IDs protected by SHA-1. (BAD)
0 of the non-revoked linted certificates have at least one non-revoked, live subkey:
0 have at least one non-revoked, live subkey with a binding signature that uses SHA-1. (GOOD)
0 of the non-revoked linted certificates have at least one non-revoked, live, signing-capable subkey:
0 certificates have at least one non-revoked, live, signing-capable subkey with a strong binding signature, but a backsig that uses SHA-1. (GOOD)
So the user ids binding signatures rely on SHA-1. RPM's policy is controlled by |
|
I do have a policy file installed: |
|
Is that from your host or your chroot? (I don't use mock personally, but I think it runs rpm in a chroot, right?) |
|
That is from the host. It's an interesting thought though that DNF/RPM would be using the policies in the chroot rather than on the host where it was executed. I will see what I can do with that idea. |
|
It's definitely on the F38 host. The file does not exist in the chroot and every Moreover, it doesn't seem that |
|
So would this mean then that the crypto-policy is not actually being abided? |
|
@nwalfield? Where do I go from here? I thought this was going to be an issue that needed to be resolved by SUSE (well, ultimately it does) but you seem to be indicating that the DEFAULT crypto-policy on F38 should in fact allow this key to be used. I just want to get a confirmation before I go opening a ticket with RedHat. |
|
I think the current default policy should allow the certificate to be used. You can run by running |
|
Hrm. I suspect you meant It does seem to have imported. I am guessing your assertion is that if the crypto-policy were actually not allowing it, Given that and indeed, So the question/issue seems to be with the rpm library operating in it's chroot mode and how it applies (or doesn't) the crypto policies? It does open it successfully: And is operating in the chroot without actually using
|
|
Should I open a new issue in https://github.com/rpm-software-management/rpm given the above? |
|
I did confirm that changing |
IIRC, it would be rejected at import time. But, as you observed,
I don't know much about
I do know a bit about My sense is that this is a |
|
But I have demonstrated above that I am reproducing this issue without the So given that, is this the appropriate project to followup on the issue that RPM doesn't seem to be honouring the crypo-policies when used with the Or maybe open a ticket in the RH Bugzilla under the rpm component perhaps? |
I have no idea. I don't work for Red Hat. They are not paying me to work on this. Try asking them and see what they say. |
|
I guess what is unclear from my perspective is where this process of applying the crypto-policy (when the rpm library is operating in a [ch]root) lives. Is this a part of this rpm-sequoia [sub-]project or does it belong in the https://github.com/rpm-software-management/rpm project proper? |
|
The crypto policy is read here: https://github.com/rpm-software-management/rpm-sequoia/blob/main/src/lib.rs#L225-L269 |
|
This is one of the many gray areas with chroot operations. When doing a chroot install, the chroot is typically empty at first so the only place to pull policies like this is the host (same goes for selinux). Except for that initial install case, one could argue that it should use policies from the chroot, BUT there's zero guarantee that a policy for something inside the root is valid for the rpm running outside the root, and vice versa. Also, rpm needs to initialize all the libraries it uses outside any chroot to avoid using some arbitrary and very potentially incompatible version from the chroot. I don't think there's anything to change in rpm-sequoia behavior for this. |
|
Thanks for jumping in here panu. The explanation is helpful for me. |
|
Actually chroot has nothing to do with any of this, see https://bugzilla.redhat.com/show_bug.cgi?id=2192975#c1 for a simple reproducer. Looking at this specimen: https://ftp.funet.fi/pub/mirrors/download.opensuse.org/distribution/leap/15.4/repo/oss/x86_64/libzio1-1.06-2.20.x86_64.rpm I don't know what to make of that. |
|
Ah, that's annoying. Sequoia checks that the key that made the signature was actually able to make the signature at the time the signature was made ( |
|
Why is this a problem? Sequoia is trying to create a view of the certificate as it was when the signature was made at |
|
Makes sense to me. I guess the big question here is, is there a tweak-button for this particular behavior to allow for legacy compatibility? |
|
Currently there isn't. Let's say we were to add that functionality, should |
- If a certificate is not valid when a packet signature is made, but
is valid now, detect this and return `NotTrusted`. This happens
when old self signatures are stripped.
- Fixes #46
|
The above change should implement the semantics that I described. |
|
NOTTRUSTED will still cause installation to fail so it's not much of an improvement for those needing to install such content, such as here (trying to build packages for that distro). I don't know, might want to sleep on this a bit. |
|
I think it would be good to have a |
|
Note that the tool actually being used and affected here is |
|
To clarify I'm certainly not thinking this should be allowed by default. I'm pondering more about the big picture - who knows how many of these quirks we may still encounter? NOTTRUSTED is how we mapped the other legacy stuff (I nearly forgot that already) so it makes sense to follow suit here. And having a tunable for NOTTRUSTED in rpm makes sense too, regardless of this particular case. From the point of user though, they'd probably prefer a one-stop shop for tunables they can tweak until it runs. Which is why was initially thinking of something to put into the crypto policy file for this specific case, but that gets unwieldly pretty fast too. |
- If a certificate is not valid when a packet signature is made, but
is valid now, detect this and return `NotTrusted`. This happens
when old self signatures are stripped.
- Fixes #46
|
Even with 642e913 (above), a knob (somewhere, whether it's in crypto-policies or somewhere else) is still needed to be able to allow As an aside, what else might generate a |
|
I don't get how the public key should look like if the expiration data of the key is changed. Isn't that a common operation? Does Sequoia not support extending a key expiry? |
|
@mlschroe : As a first approximation, a certificate is an append-only data structure. To change a value, you add a new object, which overrides the older object. So, to extend a component's expiration time (in this case the primary key's expiration time), you create a new self signature, which has a newer creation time and a longer validity period. Normally old self signatures aren't stripped. For instance, when you get a certificate from a key server, all known self signatures are included. With So yes, Sequoia support changing the expiration time. |
|
If I do a |
|
Interesting. I just checked and it seems you are right. I wonder if that is a new behavior. |
|
I don't think so. I've never seen a public key with multiple self-sigs for a user id packet. |
|
How does this revelation of |
|
Any updates here on how this issue is going to get resolved? |
|
If 'gpg --edit-key' strips the old self-signature then I think the only practical solution to this is to just OK these in rpm-sequoia for the time being. And file a bug on gpg to stop doing that I guess. |
That sounds fine to me. Can we put this in action then?
I will leave that to you folks as you clearly have much better understanding of the details of GPG than I do and could surely compose a much more coherent bug report on that than I would be able to. |
|
@brianjmurrell: You are way too demanding. I just checked and your employer (Intel) does not appear to be sponsoring any of rpm-sequoia's development costs. When that happens, you can start making demands. Until then, no. |
|
I don't think this is a bug in gpg. All the rpc4480 language speaks of just one self signature. For example: I.e. it talks about rewriting the signature instead of adding a new one. I.e. it says that this is an ambiguity and not the standard case. |
How's that? My question ended with a question mark. That makes it a question. If it had ended in an exclamation mark it would have been a demand. I am simply trying to prevent this issue from being forgotten about and stagnating. |
This is not correct. See Section 12.1 of RFC4880, Key Structures: Here, (I am one of the co-authors of the revision of RFC4880.) |
- If a certificate is not valid when a package signature is made,
but is valid now, detect this and return `NotTrusted`.
- This happens when old self signatures have been stripped.
Consider a certificate `C` that expires `te`. It is used to sign
a package `P` at `t0`, where `t0 < te`. At `t1`, where `t1 > t0`,
`C`'s expiration is extended. It now has two self signatures.
When `C` is exported using `gpg --export`, `gpg` strips old self
signatures, which results in the certificate `Ce`. When rpm tries
to verify the package's signature using `Ce`, the certificate
cannot be canonicalized at `t0`, because the self signature that
was valid at time `t0` was stripped.
- See #46
|
Having a similar issue when trying to build packages for third-party distros like oraclelinux-9-x86_64 using mock. Seems as if this particular resolution works for systems already bootstrapped/installed, but not fresh chroots. Or maybe I am not understanding what this patch resolves :) System information (fedora:38 container): This command returns the Let me know how I can assist with testing a resolution or point me in the correct direction and I can attempt a resolution and submit a PR. Thanks for the help, |
|
@pmatilai I thought we wanted to allow "legacy" stuff like this using a command line option. I don't see it here. Did you add something like that? |
|
Oh, right. The idea was tossed around yes, but nothing came out of it so far. The idea seems clear enough but how and where exactly in rpm to plant it is trickier. Disables fit into the API/cli better than enablers, but the case here is to allow installing packages classified untrusted. Which I don't know how to fit into a --nosomething name 😄 (both the cli and the API, probably rpmVSFlags bit) Ideas welcome. (almost missed this due to long vacation, sorry) |
|
And has to be done in a way that |
I filed a ticket on this now to make sure it doesn't get forgotten: rpm-software-management/rpm#2630 (getting buried in the pile of tickets is a risk too, but a different one...) |
Thanks for working on this one |
While it's great that all of this additional PGP signature/key checking is being done on F38 (and of course Fedora has completely valid keys to work with all of this additional checking) other distros are not there yet and other distros have policy-violating keys (that indeed, need to be updated). I.e. https://bugzilla.suse.com/show_bug.cgi?id=1211022
But we still need to be able to work with those distros and their insecure keys while we wait for them to get up-to-date. One case where this fails is trying to use mock on F38 to build on distros that have insecure keys.
We need to be able to continue to use such distros with mock on F38.
Is there a crypto-policy setting that can be relaxed to allow keys with No binding signature, in the meanwhile for these such cases?
The text was updated successfully, but these errors were encountered: