To conclude, neither revocation or expiry is particularly meaningful in the rpm
context, only a very limited subset of OpenPGP spec is relevant to rpm.
Revoking has been discussed at length here already, and while expiry is far
simpler on the outset, tick of the clock will not remove expired
Closed #1598.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1598#event-5304296943___
Rpm-maint mailing list
> There is another issue that is not covered by revocation at all. A software
> package is obsolete as soon as a new version of the package is signed,
> especially if there is a known vulnerability in the old version. However, the
> signature of the vulnerable version obviously stays valid. If
There is another issue that is not covered by revocation at all. A software
package is obsolete as soon as a new version of the package is signed,
especially if there is a known vulnerability in the old version. However, the
signature of the vulnerable version obviously stays valid. If the
> But the risk is not completely eliminated, since the usage of the HSM itself
> may have become compromised. An attacker may have gained access to a system
> with HSM access and issued malicious signatures. If this should happen, a key
> replacement is most probably warranted.
Absolutely!
> Perhaps the best solution is to ensure (by appropriate use of HSMs) that the
> key cannot be leaked.
Yes, that comes a long way to mitigating the problem and is hopefully already
used by the major distributions.
But the risk is not completely eliminated, since the usage of the HSM itself
> I agree with @ffesti about key revokation being more complex than what it
> seems like. When you revoke, you don't want to invalidate the signatures
> created _before_ the revokation. That would require every existing package to
> be re-signed with the new key, which would be very disruptive.
I agree with @ffesti about key revokation being more complex than what it seems
like. When you revoke, you don't want to invalidate the signatures created
_before_ the revokation. That would require every existing package to be
re-signed with the new key, which would be very disruptive.
But
> @dmantipov Is there a CVE associated with this vulnerability?
> I'm asking so that I can keep an eye out for the fix.
>
> Also, on a different note, any idea if package managers that reply on rpm are
> vulnerable as well? Yum and Zypper for instance.
OK, as there is some confusion here: There
> An additional thing, once a key is revoked by a distro (for whatever reason),
> they usually sign new rpms with the new key. However it does not mean that
> the older rpms signed by the old key are no longer secure to use. Unless
> of-course the old key has been compromised by the attacker
An additional thing, once a key is revoked by a distro (for whatever reason),
they usually sign new rpms with the new key. However it does not mean that the
older rpms signed by the old key are no longer secure to use. Unless of-course
the old key has been compromised by the attacker and they
@dmantipov Is there a CVE associated with this vulnerability?
I'm asking so that I can keep track of the fix.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> I don't think it makes sense to have a revoked key in the database at all,
> you might as well just delete the key from the database. So we could state
> that it's up to the layer above rpm that manages the keys to handle this
> (libzypp does handle key updates, I don't know about dnf).
I don't think we need to support key revokation in rpm. My understanding is
that the revokation handling in gpg is done that way because gpg can only merge
new key material and never deletes existing data. But that's not the way rpm
works, as it does not merge key material.
I don't think it
Related discussion of this over here
https://github.com/ostreedev/ostree/pull/2260
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Revocation checking requires a proper keystore, which RPM does not have.
Expiration checking “merely” requires checking the expiration date of the
self-signature.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Note the following text from the gpgv manpage:
```
gpgv2 assumes that all keys in the keyring are trustworthy. That does also
mean that it does not check for expired or revoked keys.
```
So we're in good company ;-)
--
You are receiving this because you are subscribed to this thread.
Reply
> this still needs a cryptographic signature check
Is it enough to get zero from `pgpVerifySignature()`?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> I'll investigate how to dig for fingerprints; here is the version with key
> IDs.
Thanks! In addition to the fingerprint vs key ID issue, this still needs a
cryptographic signature check.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
I'll investigate how to dig for fingerprints; here is the version with key IDs.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Well, it seems it would be helpful to have some advice here. In my local
> setup, packets analysis code detects the following,
> in that order:
>
> ```
>PGPTAG_PUBLIC_KEY; [1] public key id saved
>
>PGPTAG_SIGNATURE
>
> PGPSUBTYPE_SIG_CREATE_TIME
>
Well, it seems it would be helpful to have some advice here. In my local setup,
packets analysis code detects the following,
in that order:
`
PGPTAG_PUBLIC_KEY; [1] public key id saved
PGPTAG_SIGNATURE
PGPSUBTYPE_SIG_CREATE_TIME
PGPSUBTYPE_REVOKE_REASON
> Could someone please briefly review two patches above? Thanks.
Revocation signatures are only valid if they are a valid signature of the key
being revoked, and are made by either the key being revoked or a key that it
has designated as valid for revocation.
--
You are receiving this because
> (that stuff really needs proper docs, sigh...)
Is it intended to describe mechanism or policy? It seems that these two are
mixed through the whole code base in an obfuscating and weird way. For example,
what's expected to happen if someone try --nosignature install of a package
build with
See
https://github.com/rpm-software-management/rpm/blob/375bac6ffbc02d96aea0aaa1a8d39a3e53135430/macros.in#L672
(that stuff really needs proper docs, sigh...)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> There's already an enforcing mode for signature checking at install time
Is it controlled by the command-line option? I've found only --nodigest and
--nosignature, both meaning an opposite to what we're talking about here.
--
You are receiving this because you are subscribed to this
There's already an enforcing mode for signature checking at install time, and
that's a point where revocation and expiry checks would seem fairly obvious.
The open questions come after that.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
> actual interaction with the rest of rpm
What about adding configure-time option, say, --enable-enforced-signatures? If
configured and compiled with this one, RPM should refuse to install the package
if no signature at all or (sub)key(s) has been revoked or expired. This may be
useful for the
28 matches
Mail list logo
