[
https://issues.apache.org/jira/browse/DAFFODIL-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olabusayo Kilo resolved DAFFODIL-2727.
--------------------------------------
Resolution: Fixed
Also pushed to daffodil-dist. All that's left is to add to id.apache, which I'm
working on.
> 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
> Assignee: Olabusayo Kilo
> Priority: Minor
>
> 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 <[email protected]>"
> 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)
> <[email protected]>"
> digest algo 2, begin of digest 5d ac
> digest algo 2, begin of digest 30 08
> :user ID packet: "Olabusayo Kilo <[email protected]>"
> digest algo 8, begin of digest 48 eb
> digest algo 8, begin of digest 48 1d
> :user ID packet: "John Interrante (Code Signing Key) <[email protected]>"
> digest algo 10, begin of digest d5 29
> digest algo 10, begin of digest a4 20
> :user ID packet: "Shane Dell <[email protected]>"
> 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)
