-
-
Notifications
You must be signed in to change notification settings - Fork 20
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
Are public key revocations checked/respected? #235
Comments
Currently public key was download once and store in cache directory. When key exist in cache it will not be downloaded once again. We can introduce feature to evict keys from cache by download date, last usage etc ... for it we should create new issue. Public key contains all data available from key server also revocation signature. All signature is checked https://github.com/s4u/pgpverify-maven-plugin/blob/master/src/main/java/org/simplify4u/plugins/utils/PublicKeyUtils.java#L181 |
key can be revoked after signature was created, and in this case signature was made by valid key, even now key is revoked. |
reference #284 |
javax.inject is and should be optional (used only when Guice and/or Sisu is being used), but in case SL is being used no javax.inject should be needed. This rule was violated in 1.9.0 commit 5566bd5 where `javax.inject.Provider` was used in conjuction with SL as well. This fix introduces `NameMappers` helper static class that constructs name mappers, and javax.inject.Provider classes are used ONLY when in Guice/Sisu, are NOT used with conjunction of SL. --- https://issues.apache.org/jira/browse/MRESOLVER-298
Possibly just a question: are public key revocations respected if present on the keyserver?
Is your feature request related to a problem? Please describe.
Download not only the public key for a certain artifact, but also its revocation signature if present and if so respect it and mark the public key as invalid, and consequently warn about the artifact.
Describe the solution you'd like
pgpverify plug-in to take into account possible public key revocations that are present and known on the keyserver.
Describe alternatives you've considered
The alternative of leaving the public key out of the keysmap is insufficient as we would need to know that the public key has been revoked at creation time of the keysmap.
Additional context
The text was updated successfully, but these errors were encountered: