Skip to content

convert to crypton#1510

Open
frasertweedale wants to merge 1 commit into
haskell:masterfrom
frasertweedale:refactor/crypton
Open

convert to crypton#1510
frasertweedale wants to merge 1 commit into
haskell:masterfrom
frasertweedale:refactor/crypton

Conversation

@frasertweedale

@frasertweedale frasertweedale commented Jun 7, 2026

Copy link
Copy Markdown
Contributor

crypton is today the dominant cryptographic primitives "kitchen
sink" library. There is a need and want of additional cryptographic
primitives in hackage-server, including HMAC (various use cases)
and, later, additional public key signature algorithms to support
OpenID Connect (for trusted publishing) and Passkeys/webauthn login.

This change migrates hackage-server to crypton. The changes are
kept to a minimum without any refactoring.

Dependencies on cryptohash-md5 and cryptohash-sha256 have been
dropped. It would have been nice to drop ed25519, but without it
we would be depending on internal implementation details to define
the MemSize instance for the hackage-security Key type.

NOTE: not tested yet. Made PR for early review and for others to
start building upon.

@gbaz

gbaz commented Jun 7, 2026 via email

Copy link
Copy Markdown
Contributor

@frasertweedale

frasertweedale commented Jun 8, 2026

Copy link
Copy Markdown
Contributor Author

memsize is i believe an approximate heuristic and its fine to give an instance thats a crude estimate

@gbaz I'd prefer to leave it alone. The ed25519 package doesn't interfere with anything else, and we only use the data constructors. If you insist, I will replace the existing calculations with a "magic number" and try not to lose sleep over it 😅

Never mind all that. I see that it is used for memory usage monitoring and am satisfied that estimates are indeed fine. I removed the dependency and replaced it with a magic number.

*crypton* is today the dominant cryptographic primitives "kitchen
sink" library.  There is a need and want of additional cryptographic
primitives in *hackage-server*, including HMAC (various use cases)
and, later, additional public key signature algorithms to support
OpenID Connect (for trusted publishing) and Passkeys/webauthn login.

This change migrates *hackage-server* to *crypton*.  The changes are
kept to a minimum without any refactoring.

Dependencies on *cryptohash-md5* and *cryptohash-sha256* have been
dropped.  It would have been nice to drop *ed25519*, but without it
we would be depending on internal implementation details to define
the `MemSize` instance for the *hackage-security* `Key` type.
@mergify

mergify Bot commented Jun 19, 2026

Copy link
Copy Markdown

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

  • Queue this pull request

@ysangkok

Copy link
Copy Markdown
Member

seems like this is blocked on

it seems like it isn't an issue on master since it was building with tls-1.9.0: https://github.com/haskell/hackage-server/actions/runs/27108585879/job/80002069176 , which does not need serialise

Comment thread hackage-server.cabal
-- Note: 0.2.2 added footnoteSpec to gfmExtensions
, cryptohash-md5 ^>= 0.11.100
, cryptohash-sha256 ^>= 0.11.100
, crypton >= 1.1.4 && < 1.2

@phadej phadej Jun 22, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is an improvement, cryptohash-md5 and cryptohash-sha256 are super simple and stable packages doing one thing well, i.e. providing corresponding hash primitive. crypton OTOH is a kitchen sink.

hackage-security already depends on ed25519 and cryptohash-sha256 so this patch doesn't remove dependencies, it adds them.

If there is need for more crypto stuff, it can be added. I don't think this improves the existing stuff though.

Comment thread hackage-server.cabal
, hslogger ^>= 1.3.1
, lifted-base ^>= 0.2.1
, mime-mail ^>= 0.5
, ram >= 0.19

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No upper bound.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants