Uploaded image for project: 'Daffodil'
  1. Daffodil
  2. DAFFODIL-2727

KEYS file contains deprecated digest algorithm, RPM key import failures

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Minor
    • Resolution: Fixed
    • None
    • 3.6.0
    • Infrastructure
    • None

    Description

      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:

      $ gpg --list-packets KEYS  | grep -E '(user ID|digest algo)'
      :user ID packet: "Steve Lawrence <slawrence@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 <olabusayo@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 <shanedell@apache.org>"
          digest algo 10, begin of digest 11 4d
          digest algo 10, begin of digest 09 57
      

      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?

      Attachments

        Activity

          People

            olabusayo Olabusayo Kilo
            slawrence Steve Lawrence
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: