Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
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 software from the system so checking for it at the door would only make things weirder, *security* would not be improved in the slightest. -- 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#issuecomment-919811790___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> 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 security of > updates were just based on package signatures, an attacker could just give > you an old package version with a known vulnerability. > Signing on the package level is a nice extra feature, but it is only a piece > in a working security concept. It is not even covering the update process. > Even if key revocation worked (which in general it does not, Google does not > even use it for TLS any more), a valid signature on the package level is no > guarantee that the update is correct. > This is of course solved by signing of update lists in short intervals, which > makes signatures on the package level unnecessary in the first place. The signature on an RPM by a vendor/distributor implies that the package has indeed been provided by the vendor and an MITM attacker has not tampered with it. It does not prove that the binaries in the package are non-malicious or free from known/unknown security defects, those are different security problems. Most likely someone who trusts his vendors signing keys would also trust that the vendor is providing him with known good binaries. -- 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#issuecomment-874388985___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
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 security of updates were just based on package signatures, an attacker could just give you an old package version with a known vulnerability. Signing on the package level is a nice extra feature, but it is only a piece in a working security concept. It is not even covering the update process. Even if key revocation worked (which in general it does not, Google does not even use it for TLS any more), a valid signature on the package level is no guarantee that the update is correct. This is of course solved by signing of update lists in short intervals, which makes signatures on the package level unnecessary in the first place. -- 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#issuecomment-874332436___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> 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! That said, I imagine any decent HSM can perform internal time-stamping, in which case only signatures before a certain point need to be invalidated. -- 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#issuecomment-873998097___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> 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 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. -- 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#issuecomment-873946795___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> 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 how can you trust the signature date? An attacker could create a new > signature with a forged date. Therefore you need to add support for trusted > third-party timestamping to the signatures. Unless I am mistaken, there is no > such support in GPG: > https://dev.gnupg.org/T4108 > https://dev.gnupg.org/T4537 > > The problem is not specific to RPM and package signatures. Git signatures, > for example, also have the same issue: > https://petertodd.org/2016/opentimestamps-git-integration > > Short term, the simplest way to deal with a compromised key, is to remove it > from the RPM DB, just as @ffesti suggested. There should be a tested and > planned process for how to do this, for example by sending an emergency > update, perhaps signed with the disaster recovery key (in Red Hat case). It > would also require all packages are re-signed with a new key, since the old > ones will be invalidated after the key removal. > > Long term, adding support for trusted timestamps would make key revokation > much easier. Perhaps the best solution is to ensure (by appropriate use of HSMs) that the key cannot be leaked, and therefore does not need to be revoked. -- 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#issuecomment-873937456___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
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 how can you trust the signature date? An attacker could create a new signature with a forged date. Therefore you need to add support for trusted third-party timestamping to the signatures. Unless I am mistaken, there is no such support in GPG: https://dev.gnupg.org/T4108 https://dev.gnupg.org/T4537 The problem is not specific to RPM and package signatures. Git signatures, for example, also have the same issue: https://petertodd.org/2016/opentimestamps-git-integration Short term, the simplest way to deal with a compromised key, is to remove it from the RPM DB, just as @ffesti suggested. There should be a tested and planned process for how to do this, for example by sending an emergency update, perhaps signed with the disaster recovery key (in Red Hat case). It would also require all packages are re-signed with a new key, since the old ones will be invalidated after the key removal. Long term, adding support for trusted timestamps would make key revokation much easier. -- 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#issuecomment-873935952___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> @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 is no CVE (AFAIK) and there should not be a CVE. This is not a vulnerability. This is a basic misunderstanding on how rpm works. RPM by design works on the local system only and does not look things up on the internet. It does not make decisions on its own but relies the user or other tools to be told what needs to be done - including adding or removing key. The RPM way of no longer trusting a key is to remove it from the RPM DB. This works just fine. This does not mean that the current situation does not leave things to be desired as withdrawing a key requires quite some effort like issuing an updated that removes the key or using some sort of automation for local setups. But the topic is much more complicated than just adding support for GPG revocation keys to RPM. First the actual key look up and check needs to go into the updater level (e.g. dnf and zypper) as they are dealing with things on the network. More important than removing a key is probably a way to add a new one when the current one is no longer trusted. Just breaking (automatic) updates for everyone is not a great solution. And there are probably more things to consider. Some are already mentioned above. -- 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#issuecomment-873881324___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> 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 sign > malicious rpms with that. > I mean the rpms signed before the key was revoked. > So if revokation makes all the installed rpms, seem to be signed with the > wrong key, than that could be a problem. > > Therefore there is some amount of onus on the administrator/user as well. -- 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#issuecomment-873505143___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
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 sign malicious rpms with that. So if revokation makes all the installed rpms, seem to be signed with the wrong key, than that could be a problem. Therefore there is some amount of onus on the administrator/user as well. -- 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#issuecomment-873505065___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
@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: https://github.com/rpm-software-management/rpm/issues/1598#issuecomment-873431438___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> 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). Perhaps a better option would be to replace the revoked key with an invalid stub entry, so future attempts to re-add the key fail. This also lets us provide better error messages to the user. > But I do think rpm should check the expiry date of a key. We could make it > configurable how rpm deals with an expired key. Agreed. -- 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#issuecomment-872999190___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
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 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). But I do think rpm should check the expiry date of a key. We could make it configurable how rpm deals with an expired key. -- 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#issuecomment-872834036___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
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: https://github.com/rpm-software-management/rpm/issues/1598#issuecomment-872509233___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
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: https://github.com/rpm-software-management/rpm/issues/1598#issuecomment-872300623___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
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 to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1598#issuecomment-872255504___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> 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: https://github.com/rpm-software-management/rpm/issues/1598#issuecomment-814171434___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> 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 view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1598#issuecomment-811848010___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
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: https://github.com/rpm-software-management/rpm/issues/1598#issuecomment-811769055___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> 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 ; [2] revoke reason > PGPSUBTYPE_ISSUER_KEYID; [3] key id match saved at [1] > >PGPTAG_USER_ID > >PGPTAG_SIGNATURE > > PGPSUBTYPE_SIG_CREATE_TIME > PGPSUBTYPE_KEY_FLAGS > PGPSUBTYPE_KEY_EXPIRE_TIME > PGPSUBTYPE_PREFER_SYMKEY > PGPSUBTYPE_PREFER_HASH > PGPSUBTYPE_PREFER_COMPRESS > PGPSUBTYPE_FEATURES > PGPSUBTYPE_KEYSERVER_PREFERS > PGPSUBTYPE_ISSUER_KEYID; key id match saved at [1] > >PGPTAG_USER_ID > >PGPTAG_SIGNATURE > > PGPSUBTYPE_SIG_CREATE_TIME > PGPSUBTYPE_KEY_FLAGS > PGPSUBTYPE_KEY_EXPIRE_TIME > PGPSUBTYPE_PREFER_SYMKEY > PGPSUBTYPE_PREFER_HASH > PGPSUBTYPE_PREFER_COMPRESS > PGPSUBTYPE_FEATURES > PGPSUBTYPE_KEYSERVER_PREFERS > PGPSUBTYPE_ISSUER_KEYID; key id match saved at [1] > >PGPTAG_PUBLIC_SUBKEY ; subkey saved for later analysis > >PGPTAG_SIGNATURE > > PGPSUBTYPE_SIG_CREATE_TIME > PGPSUBTYPE_KEY_FLAGS > PGPSUBTYPE_KEY_EXPIRE_TIME > PGPSUBTYPE_ISSUER_KEYID; key id match saved at [1] > PGPSUBTYPE_EMBEDDED_SIG > >PGPTAG_SIGNATURE > > PGPSUBTYPE_SIG_CREATE_TIME > PGPSUBTYPE_SIGNER_USERID > PGPSUBTYPE_ISSUER_KEYID; key id match saved at [1] > ``` > > So, if [2] is detected and key id at [3] matches key id saved at [1], can I > assume that the key (and so all subkeys) is revoked? Only if [2] is a valid signature of [1]. -- 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#issuecomment-811300496___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
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 ; [2] revoke reason PGPSUBTYPE_ISSUER_KEYID; [3] key id match saved at [1] PGPTAG_USER_ID PGPTAG_SIGNATURE PGPSUBTYPE_SIG_CREATE_TIME PGPSUBTYPE_KEY_FLAGS PGPSUBTYPE_KEY_EXPIRE_TIME PGPSUBTYPE_PREFER_SYMKEY PGPSUBTYPE_PREFER_HASH PGPSUBTYPE_PREFER_COMPRESS PGPSUBTYPE_FEATURES PGPSUBTYPE_KEYSERVER_PREFERS PGPSUBTYPE_ISSUER_KEYID; key id match saved at [1] PGPTAG_USER_ID PGPTAG_SIGNATURE PGPSUBTYPE_SIG_CREATE_TIME PGPSUBTYPE_KEY_FLAGS PGPSUBTYPE_KEY_EXPIRE_TIME PGPSUBTYPE_PREFER_SYMKEY PGPSUBTYPE_PREFER_HASH PGPSUBTYPE_PREFER_COMPRESS PGPSUBTYPE_FEATURES PGPSUBTYPE_KEYSERVER_PREFERS PGPSUBTYPE_ISSUER_KEYID; key id match saved at [1] PGPTAG_PUBLIC_SUBKEY ; subkey saved for later analysis PGPTAG_SIGNATURE PGPSUBTYPE_SIG_CREATE_TIME PGPSUBTYPE_KEY_FLAGS PGPSUBTYPE_KEY_EXPIRE_TIME PGPSUBTYPE_ISSUER_KEYID; key id match saved at [1] PGPSUBTYPE_EMBEDDED_SIG PGPTAG_SIGNATURE PGPSUBTYPE_SIG_CREATE_TIME PGPSUBTYPE_SIGNER_USERID PGPSUBTYPE_ISSUER_KEYID; key id match saved at [1] ` So, if [2] is detected and key id at [3] matches key id saved at [1], can I assume that the key (and so all subkeys) is revoked? -- 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#issuecomment-811146766___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> 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 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#issuecomment-810536776___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> (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 `%_pkgverify_level all`? -- 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#issuecomment-809403100___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
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: https://github.com/rpm-software-management/rpm/issues/1598#issuecomment-809275912___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> 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 thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1598#issuecomment-809262449___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
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 view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1598#issuecomment-809197164___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> 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 distributions where paranoid security checks are essential. -- 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#issuecomment-808720083___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
