Update bootstrap root keys

[david-christiansen]

Johan Tibell is not part of the signing process anymore, so his key is removed.

I've also annotated the keys with their owners and public keys, because every time we consult this, I end up spending a bunch of time in a scratch buffer correlating key IDs, public key values, and ownership attestations. Might as well save the work for next time, with appropriate disclaimers added.

---

Please include the following checklist in your PR:

• 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.

Please also shortly describe how you tested your change. Bonus points for added tests!

I was unable to test the changes, as I can't build the contents of the repo right now:

$ cabal update
Downloading the latest package list from hackage.haskell.org
Updated package list of hackage.haskell.org to the index-state 2023-01-13T05:15:22Z
To revert to previous state run:
    cabal v2-update 'hackage.haskell.org,2022-11-14T10:09:26Z'
$ cabal v2-build Cabal
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: cabal-testsuite-3 (user goal)
[__1] next goal: cabal-testsuite:setup.Cabal (dependency of cabal-testsuite)
[__1] rejecting: cabal-testsuite:setup.Cabal-3.9.0.0,
cabal-testsuite:setup.Cabal-3.8.1.0 (constraint from maximum version of Cabal
used by Setup.hs requires <3.8)
[__1] rejecting: cabal-testsuite:setup.Cabal-3.6.3.0/installed-3.6.3.0
(conflict: cabal-testsuite => cabal-testsuite:setup.Cabal>=3.8 && <3.9)
[__1] skipping: cabal-testsuite:setup.Cabal-3.6.3.0,
cabal-testsuite:setup.Cabal-3.6.2.0, cabal-testsuite:setup.Cabal-3.6.1.0,
cabal-testsuite:setup.Cabal-3.6.0.0, cabal-testsuite:setup.Cabal-3.4.1.0,
cabal-testsuite:setup.Cabal-3.4.0.0, cabal-testsuite:setup.Cabal-3.2.1.0,
cabal-testsuite:setup.Cabal-3.2.0.0, cabal-testsuite:setup.Cabal-3.0.2.0,
cabal-testsuite:setup.Cabal-3.0.1.0, cabal-testsuite:setup.Cabal-3.0.0.0,
cabal-testsuite:setup.Cabal-2.4.1.0, cabal-testsuite:setup.Cabal-2.4.0.1,
cabal-testsuite:setup.Cabal-2.4.0.0, cabal-testsuite:setup.Cabal-2.2.0.1,
cabal-testsuite:setup.Cabal-2.2.0.0, cabal-testsuite:setup.Cabal-2.0.1.1,
cabal-testsuite:setup.Cabal-2.0.1.0, cabal-testsuite:setup.Cabal-2.0.0.2,
cabal-testsuite:setup.Cabal-1.24.2.0, cabal-testsuite:setup.Cabal-1.24.0.0,
cabal-testsuite:setup.Cabal-1.22.8.0, cabal-testsuite:setup.Cabal-1.22.7.0,
cabal-testsuite:setup.Cabal-1.22.6.0, cabal-testsuite:setup.Cabal-1.22.5.0,
cabal-testsuite:setup.Cabal-1.22.4.0, cabal-testsuite:setup.Cabal-1.22.3.0,
cabal-testsuite:setup.Cabal-1.22.2.0, cabal-testsuite:setup.Cabal-1.22.1.1,
cabal-testsuite:setup.Cabal-1.22.1.0, cabal-testsuite:setup.Cabal-1.22.0.0,
cabal-testsuite:setup.Cabal-1.20.0.4, cabal-testsuite:setup.Cabal-1.20.0.3,
cabal-testsuite:setup.Cabal-1.20.0.2, cabal-testsuite:setup.Cabal-1.20.0.1,
cabal-testsuite:setup.Cabal-1.20.0.0, cabal-testsuite:setup.Cabal-1.18.1.7,
cabal-testsuite:setup.Cabal-1.18.1.6, cabal-testsuite:setup.Cabal-1.18.1.5,
cabal-testsuite:setup.Cabal-1.18.1.4, cabal-testsuite:setup.Cabal-1.18.1.3,
cabal-testsuite:setup.Cabal-1.18.1.2, cabal-testsuite:setup.Cabal-1.18.1.1,
cabal-testsuite:setup.Cabal-1.18.1, cabal-testsuite:setup.Cabal-1.18.0,
cabal-testsuite:setup.Cabal-1.16.0.3, cabal-testsuite:setup.Cabal-1.16.0.2,
cabal-testsuite:setup.Cabal-1.16.0.1, cabal-testsuite:setup.Cabal-1.16.0,
cabal-testsuite:setup.Cabal-1.14.0, cabal-testsuite:setup.Cabal-1.12.0,
cabal-testsuite:setup.Cabal-1.10.2.0, cabal-testsuite:setup.Cabal-1.10.1.0,
cabal-testsuite:setup.Cabal-1.10.0.0, cabal-testsuite:setup.Cabal-1.8.0.6,
cabal-testsuite:setup.Cabal-1.8.0.4, cabal-testsuite:setup.Cabal-1.8.0.2,
cabal-testsuite:setup.Cabal-1.6.0.3, cabal-testsuite:setup.Cabal-1.6.0.2,
cabal-testsuite:setup.Cabal-1.6.0.1, cabal-testsuite:setup.Cabal-1.4.0.2,
cabal-testsuite:setup.Cabal-1.4.0.1, cabal-testsuite:setup.Cabal-1.4.0.0,
cabal-testsuite:setup.Cabal-1.2.4.0, cabal-testsuite:setup.Cabal-1.2.3.0,
cabal-testsuite:setup.Cabal-1.2.2.0, cabal-testsuite:setup.Cabal-1.2.1,
cabal-testsuite:setup.Cabal-1.1.6, cabal-testsuite:setup.Cabal-1.24.1.0 (has
the same characteristics that caused the previous version to fail: excluded by
constraint '>=3.8 && <3.9' from 'cabal-testsuite')
[__1] fail (backjumping, conflict set: cabal-testsuite,
cabal-testsuite:setup.Cabal)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: cabal-testsuite,
cabal-testsuite:setup.Cabal

$ cabal --version
cabal-install version 3.6.2.0
compiled using version 3.6.2.0 of the Cabal library 

So I'll rely on CI.

[Mikolaj]

The failure is a known problem due to custom setup, etc.:

cabal/cabal-testsuite/cabal-testsuite.cabal

Lines 113 to 118 in bcfc79c

	custom-setup
	-- we only depend on even stable releases of lib:Cabal
	-- and due to Custom complexity and ConstraintSetupCabalMaxVersion
	-- it has to be the latest release version plus
	-- you have to use the latest cabal-install release
	setup-depends: Cabal == 3.8.*,

and due to the default cabal.project being designed for devs trying to test the whole repo.

Perhaps it'd work using this commandline bit from README (not tested): --project-file=cabal.project.release

[david-christiansen]

This worked: cabal v2-build cabal-install --project-file=cabal.project.release

Perhaps it should be added to CONTRIBUTING.md?

[david-christiansen]

I also can't see where to put that option in hie.yaml to get HLS working.

[Mikolaj]

This worked: cabal v2-build cabal-install --project-file=cabal.project.release

Does cabal v2-build Cabal --project-file=cabal.project.release work as well?

Perhaps it should be added to CONTRIBUTING.md?

Sure. In what context? In which chapter? In what usecase?

[Mikolaj]

I also can't see where to put that option in hie.yaml to get HLS working.

No clue about HLS. In the worst case overwrite cabal.project and add to your global .gitignore or something?

[david-christiansen]

Does cabal v2-build Cabal --project-file=cabal.project.release work as well?

Yes, that works fine.

Sure. In what context? In which chapter? In what usecase?

I'd stick it up high, perhaps right in the first section, as an option that might need to be added. That's where most documentation of build commands is, so that's where I looked and didn't find the answer.

[david-christiansen]

RE HLS, it should be possible to run it on projects that need custom Cabal arguments to build. I'll check in with them, and contribute some docs if something can be done other than mutating the repo :-)

[Mikolaj]

If mutating the repo is unavoidable, perhaps our cabal.project should be empty and the options moved to cabal.project.local, because this the file for local mutation and customarily in .gitignore. However, this predates me (as almost everything), so I'd need to ask around and then I'd be told I'm silly and not to touch anything at my peril. ;D

[david-christiansen]

Having multiple project files is common, really. It would be good if it were easier with HLS!

I opened haskell/haskell-language-server#3451 to hopefully work this out.

Thanks!

[gbaz]

Shouldn't we add tom and lennart?

[david-christiansen]

Shouldn't we add tom and lennart?

They seem to not be active, and their key IDs haven't been in the root.json as far back as I can see, so I think that they should not be included in the bootstrap set.

[ulysses4ever]

@gbaz just a gentle ping here

[ulysses4ever]

Thanks!

@david-christiansen do you want to put the merge-me label on this to hand it over to the merge bot?

[david-christiansen]

I'm not particularly familiar with Cabal development procedures, but if that's the next step, then I can do it. As a drive-by contributor, it does surprise me a bit that I put the label on, rather than a maintainer doing so.

Should I?

[ulysses4ever]

@david-christiansen yes, as per https://github.com/haskell/cabal/blob/master/CONTRIBUTING.md#github-pull-request-conventions

[david-christiansen]

All right then! Thanks!

[mergify]

⚠️ This pull request got rebased on behalf of a random user of the organization.
This behavior will change on the 1st February 2023, Mergify will pick the author of the pull request instead.

To get the future behavior now, you can configure bot_account options (e.g.: bot_account: { author } or update_bot_account: { author }.

Or you can create a dedicated github account for squash and rebase operations, and use it in different bot_account options.

[Mikolaj]

Does it need to be in cabal 3.10? If so, we should backport. @david-christiansen, @gbaz

[david-christiansen]

I don't think it needs a backport. This is an improvement in documentation, and a removal of an unused key that we have no reason to think was compromised (and even if it were, two others would need to be compromised for an attack).

We'll hopefully get new signing keys instituted soon, which will be more important, but we're not there yet.