Update Hackage root keys

[jmct]

Hackage Security has one new key and one key needing removal. The new root.json should go live on hackage in the next week.

The new root.json is here: haskell-infra/hackage-root-keys#23 is you want to compare the key signatures.

See #9068 for a prior MR in this series.

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.
• [N/A] Manual QA notes have been included.
• [N/A] Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[geekosaur]

This sounds like it should be backported to 3.14 and may warrant a point release in short order. I wonder if we should arrange for a point release containing only the key change for 3.12 as well?

[jmct]

While Tikhon's key was added, it was not used to sign this year's root.json.

Does that affect what's necessary here?

[geekosaur]

When does this become relevant, then? I still suspect we need to update versions of cabal that are in use at that point. (Arguably 3.10.3 is also in use, or at least I still hear of people using it, but I'm not sure that's in a releaseable state.)

Do we also need to tell people how to update their cabal config files since they have Hackage root keys in them?

[geekosaur]

(I should go look at the other PR but I'm on a call now so it'll have to wait a bit.)

[jmct]

I did not think it needed any action from the users, the previous PRs don't seem to mention that.

[jmct]

David C. (my predecessor and last person to do this) wrote the following for the Pantry/Stack part of it when new keys were added:

The new root key is authorized by the existing keyholders, so existing clients should give them the proper authority. However, new clients should have the current set of keyholders in the bootstrap set, which makes the system more robust against people leaving the process.

Unless cabal is doing something very different, I think this holds? So it is worth backporting for robustness but is not super urgent?

[geekosaur]

Okay, that sounds like it should be enough then. I was worried that the new key would cause rejections by the hackage-security framework, but if it takes cross-signing into account then it sounds like things are fine.

[juhp]

(Arguably 3.10.3 is also in use, or at least I still hear of people using it, but I'm not sure that's in a releaseable state.)

I think this is an understatement, I would say cabal-install-3.10 is still is in wide-spread use in many (really most) Linux distros. (Anyway 3.10.3 is still working.)

However yesterday I discovered that all versions of cabal-install < 3.10 stopped working. :-(

<repo>/root.json does not have enough signatures signed with the appropriate keys

Most obvious example is current Ubuntu 24.04 LTS which still ships 3.8.
Fortunately all current Fedora releases are already on 3.10.3, but EPEL 9 is on a much older version.

Is there documentation how to mitigate this? (without upgrading cabal-install)

[andreasabel]

However yesterday I discovered that all versions of cabal-install < 3.10 stopped working. :-(

More precisely, even 3.10.1.0 stopped working, so all < 3.10.2.

This means that in the past new keys were not backported to old versions of cabal-install. Was that deliberate?
In effect, cabal-install <= 3.10.1 has come to a violent end now, rather than a scheduled and announced slumber into after-life...

[jmct]

Yes, to be clear, this is not an issue with this pull-request.

I purposefully ensured that the signers for this year were all key-holders from the last time the set of root keys were updated (> 2 years ago).

This is actually an issue relating to the following PRs:

• Add new root keys #9068
• Update bootstrap root keys #8669

We think there might be a mitigation in this case, but it does bring up the more general question: what is the backport strategy for security patches like these?

To be ultra-clear here, part of the security strategy here is that it's going to be hard to rely on the same set of people acting as key signers for arbitrarily long periods of time, we need to be able to rotate people in/out. This issue demonstrates that even a 2 year lead time was insufficient. While we think there is a mitigation in this instance, we can't guarantee a mitigation next time. I'm happy for the HF to take on work that will help avoid this in the future. The patch I made for Debian (unclear if they're going to use it) was pretty easy to make, so maybe there needs to be a quick way to do a small key-holder-update release?

[Bodigrim]

I think this is an understatement, I would say cabal-install-3.10 is still is in wide-spread use in many (really most) Linux distros. (Anyway 3.10.3 is still working.)

https://hackage.haskell.org/package/cabal-install under "Distribution" section lists "Arch:3.8.1.0, Debian:3.0.0.0, Fedora:3.10.3.0, FreeBSD:1.22.6.0, LTSHaskell:3.12.1.0, NixOS:3.14.1.0, Stackage:3.14.1.1, openSUSE:3.10.3.0".

Here is a more complete list:

All in all I believe it's imperative we restore old Cabal releases back to the working order.

[gbaz]

for the record, new root.json deployed so that means we're in, i believe, good shape for now.