Support authentication tokens for uploading to Hackage

[SebTee]

Adds support for authenticating uploads using authentication tokens, as discussed in issue #6738.

A new flag --token (-t) has been created. Token authentication takes precedence over username and password meaning that, if a token is set, the username and password flags are ignored.

The token is included in a HTTP header as follows: Authorization: X-ApiKey [token].

QA Notes

These tests must be run using http-transport: curl, wget, powershell, and plain-http.

• Calling cabal upload -t [valid-token] [./path/to/package.tar.gz] should successfully upload the package to Hackage.

  • The user shouldn't be prompted to enter a username and password.

• Calling cabal upload -t [invalid-token] [./path/to/package.tar.gz] should fail to upload the package to Hackage.

  • A HTTP 401 error should be returned with the message "Bad auth token".
  • The user shouldn't be prompted to enter a username and password.

• Calling cabal upload -t [invalid-token] -u [username] -p [password] [./path/to/package.tar.gz] should fail to upload the package to Hackage.

  • Authentication token takes precedence over username and password.
  • A HTTP 401 error should be returned with the message "Bad auth token".

• Calling cabal upload -t should output a cabal error message reading Error: cabal: option `-t' requires an argument TOKEN.

• Calling cabal upload [./path/to/package.tar.gz] should default to username and password authentication.

  • If username and password are not set in the config file, prompt the user for a username and password.
  • If username and password are set in the config file, cabal will attempt to upload the package using the username and password for authentication.

---

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.
• Include manual QA notes if your PR relates to cabal-install.

Bonus points for added automated tests!

[SebTee]

Token authentication is working for cabal upload. I'm currently working on getting token authentication working for cabal report.

[SebTee]

I've been having a couple issues with cabal report. It doesn't read the token, username or password from the config, you have to set them in the command line. This is also the case for username and password in the cabal-install version 3.10.1.0 release. I've not been able to find an issue for this, does one exist?

The other issue I'm encountering is that I can't seem to work out how to create a build report that cabal report can parse and upload to Hackage. My changes so far allow you to set a token that will be passed to the postHttp function if a build report is found and parsed. But, since I don't have a parsable build report to upload, I've not been able to fully test this.

[andreabedini]

IIRC there's a hidden and undocumented remote-build-reporting field. You can find it in the code: https://github.com/search?q=repo%3Ahaskell%2Fcabal%20remote-build-reporting&type=code

[gbaz]

I think its fine to not worry about testing the report feature. It was sort of stillborn if I recall. I double checked and the hackage builders generates reports as part of the build, but uses its own custom upload machinery.

[ffaf1]

One way to meaningfully test this would be to have an monad abstracting over IO, which is not the case.

QA notes are very good, but is there any test hackage server we can use instead of having QA people having to upload something to Hackage.

[ffaf1]

Good AFAICS

[Mikolaj]

@gbaz: could (one of the) Hackage maintainers review this PR as well? BTW, I understand that Hackage is immutable, so the QA tests need to upload real sensible packages, not test packages, do they? Or is it fine, because no --publish is used and so these would be candidates? But if so, does it test enough? Are more errors likely get exposed with --publish?

[gbaz]

Its fine to test this without --publish, and just upload candidates.

[Mikolaj]

OK, fine.

I'm re-running the failed CI jobs, since the failure is probably due to the unix package breakage.

[Mikolaj]

CI passed. @SebTee: once you are satisfied with the state of the PR, please kindly add label squash+merge_me and in 2 days of inactivity the PR is going to be merged.