Secure cabal-install installation method

[AlistairB]

👋 Haskell docker is exploring some alternative installation methods as https://downloads.haskell.org/debian/ is increasingly slow to be updated. This includes cabal-install which is currently installed via the debian package.

The direction we are thinking of going is directly installing ghc / cabal based on the releases on haskell.org. For example, we can download and GPG verify ghc releases.

Cabal on the other hand do not include GPG sig files that we can use for verification - https://downloads.haskell.org/~cabal/cabal-install-3.6.0.0/

May relate to #6616

Options

1. Cabal to provide GPG signature files

This would be ideal and is the simplest for us and the most secure. GHC has some doco about how this is done - https://gitlab.haskell.org/ghc/ghc/-/wikis/making-releases#sign-and-hash-the-release-artifacts . Perhaps Cabal releases can include a step like this?

2. Verify SHA256SUMS.sig

Cabal does include SHA256SUMS.sig + SHA256SUMS. The process would be something like:

1. GPG verify SHA256SUMS.sig
2. Fetch SHA from SHA256SUMS.
3. Verify SHA256 of the release tar.

The current issue with this is I don't know what GPG key I need to verify SHA256SUMS.sig - https://downloads.haskell.org/~cabal/cabal-install-3.6.0.0/SHA256SUMS.sig.

$ gpg -vv SHA256SUMS.sig
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
# off=0 ctb=89 tag=2 hlen=3 plen=435
:signature packet: algo 1, keyid B3D9F94B8DCAE210
	version 4, created 1631239102, md5len 0, sigclass 0x00
	digest algo 10, begin of digest 39 ed
	hashed subpkt 33 len 21 (issuer fpr v4 A970DF3AC3B9709706D74544B3D9F94B8DCAE210)
	hashed subpkt 2 len 4 (sig created 2021-09-10)
	subpkt 16 len 8 (issuer key ID B3D9F94B8DCAE210)
	data: [3071 bits]
gpg: assuming signed data in 'SHA256SUMS'
gpg: Signature made Fri 10 Sep 2021 11:58:22 AEST
gpg:                using RSA key A970DF3AC3B9709706D74544B3D9F94B8DCAE210
gpg: Can't check signature: No public key

I cannot find key B3D9F94B8DCAE210 anywhere. If this is the preferred option, can details of the key be given and can it be uploaded to some keysevers?

[Mikolaj]

@hasufell: doesn't ghcup provide that by chance?

[hasufell]

I think the docker images maintainer has no interest in using ghcup.

GPG signing in ghcup has been discussed years ago, but no one really came up with a good proposal on how to integrate it:

1. GPG verification is useless if you haven't verified the key
2. Not all tarballs provide valid signatures
3. Many outstanding questions wrt usability: do we invoke gpg via cli? What if it doesn't exist? What do we do on windows? How do we educate the user about it? Etc etc

And lastly: you can already verify ghcup metadata (which contains the hashes of all tarballs) through hoops:

1. All commits in the ghcup repository are gpg signed
2. So if you verify the latest commits gpg sig, you also verified https://gitlab.haskell.org/haskell/ghcup-hs/-/blob/master/data/metadata/ghcup-0.0.6.yaml
3. Now you can check that your local yaml matches that remote files hash or you simply instruct ghcup to use an already verified metadata yaml via ghcup -s <file/http>://<uri> list

It's basically all there if you know what you're doing.

[Mikolaj]

Oh, that's interesting. Let's brainstorm.

[AlistairB]

As @hasufell notes ghcup does not do GPG verification. As noted Not all tarballs provide valid signatures, cabal does not provide signatures for the release tars, which if resolved would allow for option 1 I have listed. My understanding of ghcup is that it checks the sha256 hash of the releases.

Ideally we want to do the GPG (PGP) verification as official docker images are recommended to do PGP based verification. My understand is that this is stronger as it ties the verification to the user that publishes the artefacts and signature files. You can then choose to trust that user's key. (I've just learnt about all of this recently.. so don't have a deep understanding 😅)

Stack does provide GPG signature files and the current ghc / cabal debian packages also provides this. Which is why we don't want lose it if possible with a new installation approach.

I think the docker images maintainer has no interest in using ghcup.

Can we please assume that everyone is just aiming for the best technical solution? I was directly pushing for a ghcup based solution until @psftw highlighted the shortcomings around the GPG verification. I have no bias other than the best result for the official haskell docker users.

If you really want ghcup to be used in the images I would suggest looking into lack of GPG verification support. (FWIW I think ghcup is AWESOME and I use it :) )

[Mikolaj]

Uhoh, I apparently made a faux pas. Apologies.

I, too, think that ghcup (and docker-haskell) is AWESOME. :)

[hasufell]

If you really want ghcup to be used in the images I would suggest looking into lack of GPG verification support.

Well, GPG is widely misunderstood and I think this misunderstanding is present here as well.

Again: GPG is useless if you don't verify the key. In the sense that it has similar guarantees as SSL, which you're already using successfully. It makes only sense if you trust the person and can manually verify that the key belongs to that person. For all other intents and purposes, GPG is in fact useless. Verifying that a key belongs to a person requires effort (e.g. calling them, sharing secrets, meeting in person, also see https://en.wikipedia.org/wiki/Key_signing_party).

Also, I've already described how you can use gpg today:

1. have a conversation with me and figure out if you trust me
2. meet me in person and get my gpg key
3. clone the ghcup repository and verify the latest commit signature via git log --show-signature
4. copy data/metadata/ghcup-0.0.6.yaml to your Dockerfile repo and then have the Dockerfil copy it into the docker image
5. optionally sign it with your own gpg key and do whatever verification you intend
6. use ghcup -s file:///path/to/ghcup-0.0.6.yaml install ghc ... to only use the previously verified metadata file
7. Since the metadata file contains sha256 hashes, which are collision resistant, there's no reason to also gpg-verify the tarballs. The chain of trust is met.

But... I mean... what's the point? How does the user know the image they download correspond to the Dockerfile that does the gpg verification? How does the user even know the gpg signature in the Dockerfile is correct/good? You have to sign the Dockerfile as well (or every git commit in your repo). And... does the user even trust you? How are they gonna establish trust with you and verify your key?

So you see... automatic verification isn't really possible.

[emilypi]

@AlistairB just to update, I uploaded my key to OpenPGP (https://keys.openpgp.org/vks/v1/by-fingerprint/A970DF3AC3B9709706D74544B3D9F94B8DCAE210) and ubuntu's keyservers. I hope that helps

[AlistairB]

Thanks @emilypi !

I can confirm this is working and I can do:

$ gpg --batch --keyserver keyserver.ubuntu.com --recv-keys b3d9f94b8dcae210
$ curl -O https://downloads.haskell.org/~cabal/cabal-install-3.6.0.0/SHA256SUMS.sig
$ curl -O https://downloads.haskell.org/~cabal/cabal-install-3.6.0.0/SHA256SUMS
$ gpg --verify SHA256SUMS.sig

And it will successfully verify. Which means we can do option 2.

Although, options 1 is ideal as it is simpler (ahem for haskell docker, or others who care) and I think more secure as the final cabal-install binary is being gpg verified, not something in a chain.

Is it possible for you to execute these steps which is what ghc releases are doing?

I would be happy to help in any way that I can ie. add this info to the release checklist or making a release?

---

@hasufell you may be right, but the point is somewhat moot as the official docker images are recommended to gpg verify any downloaded artefacts as part of the docker build process. There is a review process when updating official images where they will call out stuff like this. Ideally we want to follow their best practice standards unless we have a good reason.

[hasufell]

you may be right, but the point is somewhat moot as the official docker images are recommended to gpg verify any downloaded artefacts as part of the docker build process.

Yeah, I read it and it clearly states that sha256 sums are valid as well.

[AlistairB]

Yeah, I read it and it clearly states that sha256 sums are valid as well.

True, they are considered acceptable but as a "Less Secure Alternate" option. I don't want to downgrade the security from the "Preferred" option if possible. The more secure, the more considered best practice by the official images the better I think.