Policy regarding taking over Hackage packages

[therivercass]

I very much appreciate that this discussion is happening transparently, in discussion with the community. there are a few concerning elements of this situation, in my view. I think the facts that:

• the package is still in use
• it’s a cryptography package with real, unresolved bugs

weigh rather heavily in this. if it were a random library, “fork and let the ecosystem move to the new package” makes a lot of sense. but a widely used cryptography package (especially before people started moving to the fork) is in a position to do a lot of damage to the broader community.

I appreciate that people want to respect the wishes of the original author but there are real damages threatened by this situation. unmaintained cryptographic code will eventually surface vulnerabilities. it’s a matter of when not if. if someone discovers a vulnerability tomorrow, who do they report it to? the fork? does Hackage track CVEs so an unwitting user can’t have a known vulnerable package pulled in by a stale dependency that’s yet to update to the fork? i.e. how much damage can be mitigated if no action is taken?

minimally, versions of this package that are discovered to have problems in the future need to be pulled from Hackage. it’s disruptive but, barring active maintainership, that will at least prevent the propagation of harm. is that a step the admins are willing to take?

therefore, no ownership transfer maintains / deserves the trust that the package may have originally carried.

this is a bit weird to me. an unmaintained cryptography package will eventually break trust – especially one that wasn’t audited to begin with. arguably, it already has. it’s a question of how to break trust in a way that causes the least harm. personally, when I’ve had to rely on unaudited cryptography tools, trust for the author rarely factors into it for me – I’m trusting the community to get a warning in front of my face if the tool is eventually discovered to have problems. lack of maintenance of bitrotting code is absolutely one such problem.

consequently, one thing that would help, if the admins decide to leave things as they are, is if the tooling could warn users loudly that their transitive dependencies included this package. it’s a security risk and we should err on the side of making too much noise about it rather than too little. a deprecation notice is a bit too soft, in my view – it doesn’t communicate the danger effectively. users have a right to know what risks they’re signing up for.

it doesn’t sound like such a thing is possible, from the discussion in this thread. if so, my vote is that some maintainer gets chosen for this package, minimally to handle disclosures.

[hasufell]

@therivercass

if it were a random library

Well, it is.

The fact that the Haskell community has adopted it with little to no concern about its correctness and no thought about the implications of using GHC for cryptography is what is concerning.

[chreekat]

(post deleted by author)

[f-a]

The discussion is though and there is no way around it: different concerns will lead to different choices; inevitably someone — many — will be upset.

The debate has been frank and respectful, I am sure and I ask everyone to keep it this way.

Decision makers will have a clearer picture where (parts of) the community stand, they will appreciate.

[jackdk]

I don’t want to get too far into the details of a particular set of packages (although cryptonite, memory, etc., were the trigger for this discussion), but what’s the latest news on the botan bindings? That would solve the question about what to really do about cryptonite (and related libraries like memory).

In terms of package safety, though, I think the cryptonite angle is almost a red herring. Any admin-assisted package takeovers open the risk of a “Jia Tan”-style attack, like what happened to xz, and the most attractive packages for this would not be the cryptography libraries but rather the “boring” libraries for things like compression or data structure wrangling. These packages tend to have high numbers of reverse dependencies and few maintainers. Taking over a cryptographic package will invite much more aggressive scrutiny.

If individual package authors want to opt into more aggressive cross-package maintenance, there are initiatives for that, like the Haskell GitHub Trust.

[frasertweedale]

@hasufell

For security issues, we just need a way to mark a package on hackage as “known vulnerable” (similar to how deprecated versions work). We currently only have security-advisories and cabal-audit to check your project. There’s no direct integration with hackage afaik.

(Not quite on the main topic, but for what it’s worth…) no direct integration yet. Exposing advisory data in the Hackage UI is something the Security Response Team explicitly wants to see happen. We (currently) do not have capacity to implement this ourselves, but we will certainly support and collaborate with anyone who is able to make progress toward this high-impact goal.

[chreekat]

Julian, you’ve quoted a bit of @therivercass’s argument, but rather than meaningfully engage with it, you’ve simply ignored their evidence and asserted that it is wrong. This comes off as antagonistic.

Plus I’m not sure it’s productive to blame the community for potential flaws in a widely-used library. A system’s security is only as good as its least-informed, most-hurried user. The cryptonite and crypton family of libraries have thousands of indirect reverse dependencies. Even if there were sound theoretical arguments against using them (either because they’re abandoned, pure Haskell, unaudited, …), simply stating that all those other packages’ contributors were thoughtless or careless is a bad tactic.

Anyway, I think the stuff about putting advisory data directly in Hackage is actually a positive, practical step. In fact, I noticed that searching for cryptonite on Hackage turns up nothing: It’s already marked deprecated, and Hackage search hides deprecated packages by default! So that’s a good action that has already happened.

[hasufell]

@chreekat

Plus I’m not sure it’s productive to blame the community for potential flaws in a widely-used library. A system’s security is only as good as its least-informed, most-hurried user. The cryptonite and crypton family of libraries have thousands of indirect reverse dependencies. Even if there were sound theoretical arguments against using them (either because they’re abandoned, pure Haskell, unaudited, …), simply stating that all those other packages’ contributors were thoughtless or careless is a bad tactic.

There have been many threads about this over the years, but I don’t want to pull out all the “evidence”.

Security does not happen by accident. The most prominent example is here: Is hs-tls affected by CVE-2013-0169 · Issue #117 · haskell-tls/hs-tls · GitHub

That type of response from a maintainer of a cryptographic stack immediately moves them to my personal blocklist. And I’m afraid there’s no way to say this more diplomatically.

We do not have enough research and knowledge about how feasible cryptographic primitives are on GHC. GHC was, after all, not designed with that in mind. The type system does not make our code side-channel resistant. I’m not aware of anyone seriously exploring this. Any other serious effort of a proper TLS stack (like the everest project) does not use Haskell, but something like F* and then compile to C, so they can prove that the implementation is secure, constant time, etc.

I’m confused this has to be explained over and over again. Maybe the security team needs to make a stance on this topic, but it may be well outside of their responsibilities.

[frasertweedale]

@bmillwood

• When I depend on a package, I trust the current owner / maintainer, I trust them (alone) to decide a suitable successor for that trust, and I trust the Hackage admins to stay out of that process in all cases.
• The above policy, except that the Hackage admins can exceptionally intervene in cases where transferring maintainership is important to the community as a whole, there’s transparency about the process, the new maintainer is a known and respected community member, etc. etc.
• Hackage admins should have broad discretion to approve or deny maintainership transfers based on their own understanding of the situation and the stakes involved, and can routinely make these calls without it being a big deal.

My position is a mix of these. In case of unresponsive maintainer who has not set out any succession plan, and per the current policies, Hackage admins/trustees have implied authority to transfer ownership to a willing maintainer. I think that’s fine.

Wherever a maintainer expresses (actively in response to inquiry or e.g. in the project README) that ownership should not be transferred, or they specify rules of succession, those wishes should be respected. Hard forks are inconvenient but, IMO, preferable to a situation where community administrators violate the express wishes of community members (past or present) who have published packages in good faith (and without warranty).

The situation where current owner rejects takeover or co-maintainers, though not without precedent, is uncommon. In my experience, inactive maintainers are usually happy to transfer ownership or accept co-maintainers (I have been on both sides of that transaction).

As a side note, a transparency log of all package ownership transfers would be a nice thing, if it doesn’t exist already, and should include notes about whether the transfer was endorsed by previous owner, or due to unresponsive maintainer, or records the reasons for a “hostile takeover”, and so on.

[Bodigrim]

@frasertweedale

As a side note, a transparency log of all package ownership transfers would be a nice thing, if it doesn’t exist already

It exists already: adminstrator actions log | Hackage

[yaitskov]

@bmillwood

It does not give instructions for what to do if the maintainer can be contacted, doesn’t want to maintain the package, but also doesn’t want anyone to take it over.

A hackage package should show the problem on the package page. An admin could maintain a list of fork candidates claimed by their authors or hackage user could claim himself. New origin release clears fork list. This way transition is more smooth. It would help to concentrate new maintainers on a single fork. Count likes/dislikes per candidate. GitHub has a feature to list repo forks, but the list can be long and it is hard choose the most up-to-date fork.

I see some stats about issues resolved in a fork vs origin and last commit. Majority of packages are on GitHub which has API to automate such stats.

[sclv]

Package can be marked deprecated in favor of other packages by their owners, and typically this occurs. The packages triggering this dispute are a special case, because of the intransigence of the ownership.

Without getting into the technical disputes surrounding this suite of crypto-packages, it was well known that the owner of these packages did not play well with or collaborate well with others. I hope there’s a lesson for the future here that everyone takes away from this – which is that reliance on a package also means assessing its maintainer, and maybe its not a good idea to put a package at the bottom of everyone’s dep-tree when the person who controls it, no matter how productive, is not a good collaborator on a shared ecosystem.

[philderbeast]

An example of deprecated versions is ki where only the latest version is not deprecated. Can you point to a package deprecating in favour of another package? I’m keen to see what hackage would show for that situation.

[hasufell]

tar-bytestring

[therivercass]

this is completely fair. I wasn’t addressing whether one /should/ use the library but rather the fact that it is presently in use and the implications of that.

[mpilgrem]

This topic has become a mix of the abstract (policy and practice) and the concrete (cryptonite).

In the case of the latter package, on Hackage, it is clearly marked as deprecated in favour of crypton.

For its part, the change log of crypton on Hackage clearly states that crypton-0.31 was forked from cryptonite with the original author’s permission.

The change in the status of cryptonite was also discussed on this site in September 2023.

The maintainer of crypton, Kazu Yamamoto, has a public profile, both within and outside of the Haskell community. (By which I mean, the question “Who is the maintainer of this package, and what do I know about them?” does not hit the wall of anonymity.)

On Hackage, both cryptonite and crypton warn in their opening sentences:

Evaluate the security related to your requirements before using.

and people, including @hasufell (who has had a consistent public message on this topic for as long as I can remember), have warned that when it comes to Haskell’s ‘cryptographic’ packages, users do need to take great care when using them for certain purposes.

[jackdk]

It is also strange to me that most of the concrete discussion has focused on cryptonite when the crypton fork has been done and been rolled out through the ecosystem.

The instigating event for this round of takeover discussions was a different package from the Vincent/cryptonite universe — memory.

[sclv]

The issue arises from the fact that crypton still depends on memory, and memory is still unmaintained – in fact, despite its name, memory really should be seen as part of the cryptographic universe, since that’s where the bulk of its rev-deps arise from.

[yaitskov]

Every package maintainer should mention their email in cabal.
Eg. Hlist package has an extinguished email.
I was able to google contact just one of two maintainers.

Hackage maintainer page doesn’t have link to developer’s contact nor a button to notify developer.