shim 15.8 for Oracle Solaris 11.4

[daveminer1]

Confirm the following are included in your repo, checking each box:

• completed README.md file with the necessary information
• shim.efi to be signed
• public portion of your certificate(s) embedded in shim (the file passed to VENDOR_CERT_FILE)
• binaries, for which hashes are added to vendor_db ( if you use vendor_db and have hashes allow-listed )
• any extra patches to shim via your own git tree or as files
• any extra patches to grub via your own git tree or as files
• build logs
• a Dockerfile to reproduce the build of the provided shim EFI binaries

---

What is the link to your tag in a repo cloned from rhboot/shim-review?

---

https://github.com/daveminer1/shim-review/tree/oraclesolaris-shim-x86_64-20241010

---

What is the SHA256 hash of your final SHIM binary?

---

b098fb90bff86509aacff0e5bc197583e7e77968cc64da4d41d310fb4eab3087 shimx64.efi

---

What is the link to your previous shim review request (if any, otherwise N/A)?

---

N/A

---

If no security contacts have changed since verification, what is the link to your request, where they've been verified (if any, otherwise N/A)?

---

N/A

[es-fabricemarie]

• build reproduces fine with dockerfile and docker build .

  b098fb90bff86509aacff0e5bc197583e7e77968cc64da4d41d310fb4eab3087  /usr/share/shim/15.8-1.0.3.el9/x64/shimx64.efi
  

• shim built from 15.8 official tarball, unpatched
• NX bit is not set
• SBAT entries look alright
• OpenPGP keys:
  • Alan Coopersmith's key found on Ubuntu OpenPGP key server:
    • https://keyserver.ubuntu.com/pks/lookup?search=4A193C06D35E7C670FA4EF0BA2FB9E081F2D130E&fingerprint=on&op=index
    • expires: 2028-04-19, key is cross-signed
  • Dave Miner's key not found on Ubuntu/MIT OpenPGP key servers, no key expiry. Key is cross-signed.
• EV Code Signing cert used:
  • RSA 3072 bit
  • Issuer: C=US, O=DigiCert, Inc., CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
  • Subject: jurisdictionC=US, jurisdictionST=Delaware, businessCategory=Private Organization, serialNumber=2101822, C=US, ST=California, L=Redwood City, O=Oracle America, Inc., CN=Oracle America, Inc.
  • Expires in April next year: Not After : Apr 2 23:59:59 2025 GMT

Issues:

• DISABLE_EBS_PROTECTION is set so official reviewer will have to take a deeper look.
• grub2 is patched (build glue and zfs among others). More scrutiny by core team member is advised.

[jsetje]

Since I work for the same company as the submitters, I don't count as a reviewer in this case. However, I looked this over in some detail before it was submitted.

DISABLE_EBS_PROTECTION is expected, since with the custom ELF validation code nothing will call back into shim lock protocol to have shim validate anything additional.

[daveminer1]

My key is present on pgp.mit.edu:

Search results for 'oracle miner dave com'

Type bits/keyID Date User ID

pub 256E/8C450938 2024-07-23 Dave Miner dave.miner@oracle.com

[steve-mcintyre]

Mail sent to @daveminer1 for verification.

Alan's key is an ancient 1024-bit DSA key. We can't use that - it's way past time he generated something newer that's less readily broken.

[daveminer1]

Confirming identity

leaders drearier picker sequins oatmeal torrential Portsmouth revert Lindsay strait

[alanc]

Mail sent to @daveminer1 for verification.

Alan's key is an ancient 1024-bit DSA key. We can't use that - it's way past time he generated something newer that's less readily broken.

Is not the RSA4096 key shown on https://keyserver.ubuntu.com/pks/lookup?search=0xCFDF148828C642A7&fingerprint=on&op=index sufficient?

[jsetje]

The old DSA one shows up first, presumably because it's your oldest key endorsing the others? I don't think we should use it anymore, but removing it from the server doesn't seem right either.

[julian-klode]

Mail sent to @daveminer1 for verification.
Alan's key is an ancient 1024-bit DSA key. We can't use that - it's way past time he generated something newer that's less readily broken.

Is not the RSA4096 key shown on https://keyserver.ubuntu.com/pks/lookup?search=0xCFDF148828C642A7&fingerprint=on&op=index sufficient?

That is a subkey of a dsa1024 key, and as such the binding signature (the signature the primary key makes to certify the subkey as bound to it) is not strong enough, you need to properly rotate to a strong primary key.

As the primary key is the root of trust, when someone goes fetch the key it will fetch and trust all it's subkeys and encrypt to the latest encryption subkey.

An attacker with enough compute could be able to fake signatures binding arbitrary new suvkeys to the primary keys as dsa1024 is particularly weak.

[steve-mcintyre]

@julian-klode has described this exactly - just adding new stronger subkeys isn't sufficient

[alanc]

Sorry, I thought what I had done years ago was doing that, but I guess I did not. Unfortunately that description, no matter how exact, does not help me understand what I need to do now to satisfy you while not breaking the verification of the hundreds of X.Org package releases I've signed with that key which distros use to verify. Can you point to instructions for what gpg commands you want me to use here?

[steve-mcintyre]

Hi Alan!

No worries! You don't have to kill the old key, you can just create another new key for this new purpose.

The guide we typically point people to in the Debian community is https://keyring.debian.org/creating-key.html ; the defaults in gpg tend to be reasonable out of the box these days, but it dosn't hurt to check things look sane.