Re: [jira] [Created] (DAFFODIL-2727) KEYS file contains deprecated digest algorithm, RPM key import failures

[Mike Beckerle <mb...@apache.org>]

I support just modernizing the current KEYS file, not worrying about people
getting a failure when validating older releases using a newer KEYS file.

Instructions on how to validate could point this out, i.e., that KEYS
technology has changed so older releases require older KEYS files
corresponding to the tags of those releases.

On Fri, Sep 9, 2022 at 9:04 AM Steve Lawrence (Jira) <ji...@apache.org>
wrote:

> Steve Lawrence created DAFFODIL-2727:
> ----------------------------------------
>
>              Summary: KEYS file contains deprecated digest algorithm, RPM
> key import failures
>                  Key: DAFFODIL-2727
>                  URL: https://issues.apache.org/jira/browse/DAFFODIL-2727
>              Project: Daffodil
>           Issue Type: Bug
>           Components: Infrastructure
>             Reporter: Steve Lawrence
>
>
> RHEL9 has disabled support for SHA-1 gpg keys for verifying RPM packages.
> This is planned to be deprecated in Fedora 39:
>
>
> https://www.redhat.com/en/blog/rhel-security-sha-1-package-signatures-distrusted-rhel-9
>
> Unfortunately, our KEYS file contains a key that uses the SHA-1 algorithm.
> When installing daffodil via DNF, it imports all the keys and errors when
> importing that key.
>
> Here's filtered output of our keys and their digest algorithms:
>
> {code}
> $ gpg --list-packets KEYS  | grep -E '(user ID|digest algo)'
> :user ID packet: "Steve Lawrence <sl...@apache.org>"
>     digest algo 10, begin of digest 28 8e
>     digest algo 10, begin of digest 6c ff
> :user ID packet: "Michael J. Beckerle (Code Signing Key) <
> mbeckerle@apache.org>"
>     digest algo 2, begin of digest 5d ac
>     digest algo 2, begin of digest 30 08
> :user ID packet: "Olabusayo Kilo <ol...@apache.org>"
>     digest algo 8, begin of digest 48 eb
>     digest algo 8, begin of digest 48 1d
> :user ID packet: "John Interrante (Code Signing Key) <
> jinterrante@apache.org>"
>     digest algo 10, begin of digest d5 29
>     digest algo 10, begin of digest a4 20
> :user ID packet: "Shane Dell <sh...@apache.org>"
>     digest algo 10, begin of digest 11 4d
>     digest algo 10, begin of digest 09 57
> {code}
>
> Algorithm 2 is SHA-1, algorithm 8 is SHA-256, and algorithm 10 is SHA-512.
> So only Mike's KEY uses the deprecated algorithm and causes issues on RHEL
> 9. Though Lola's key is SHA-256, which is not the ASF preferred SHA-512.
>
> The question is how to deal with this. It's easy enough for Mike and Lola
> to generate new KEYS (our KEYS file has improved instructions on how to
> generate a SHA-512 key). If we replace the current KEYS it means old
> releases can no longer be verified. But if we do not remove the old KEYS,
> we get errors trying to import the file into RPM.
>
> It looks like Mike signed versions 2.2.0, 2.7.0, 3.2.0, and 3.2.1, and
> Lola signed 2.6.0, so it is a handful of somewhat recent versions that
> wouldn't be able to be verified.
>
> Maybe since SHA-1 is deprecated, not being able to verify those releases
> is acceptable, and if someone wants to verify then they need to import an
> older KEYS file? Maybe this way it's more clear to the user and so they
> would be  more aware of the consequences? And there are still the SHA-512
> sums as an alternative form of release verification.
>
> Thoughts?
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.20.10#820010)
>