Policy regarding taking over Hackage packages

1

Hi folks,

I just recently dusted off my Hackage admin hat in response to a request for help, which led me to consider this broader policy issue.

The existing policy regarding taking over a Hackage package is here: Taking over a package - HaskellWiki

It gives instructions for what to do if:

  • the maintainer can be contacted, and consents to the takeover,
  • the maintainer can’t be contacted

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.

With the cryptonite family of packages in particular, the original author has taken the position that:

  • people may have used the package because they trusted the author,
  • the author, being no longer involved, can’t evaluate any new maintainer to be a suitable recipient of that trust,
  • therefore, no ownership transfer maintains / deserves the trust that the package may have originally carried.

I’m sympathetic to this line of argument, perhaps especially for cryptography libraries. But I think the thing that really matters is what community expectations are here.

Granting that hackage-admins are not always going to be qualified to assess trustworthiness of a new contributor, is it appropriate that we are willing to hand over unmaintained packages to any volunteer? Here are a few possible stances one might take:

  • 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.
  • Having packages unmaintained on Hackage is a greater evil, ultimately, than having them transfer ownership between different maintainers. We should let anyone who is willing step up in most cases, even when we aren’t able to meaningfully “vet” them. After all, existing packages aren’t meaningfully vetted.

Any of these stances can also be combined with being in favour or against package owners being able to explicitly opt in or opt out of being replaced in this way.

My default inclination is to fall on the second case above, where ownership transfers should generally only be done by consent of the original owner or by consensus of the community (and the original owner, if available). In the cryptonite case, this policy endorses the current painful transfer process from existing libraries to differently-named forks. I understand that process causes a lot of work for a lot of people (I’ve been annoyed by it myself), but I think the trustworthiness we’d be giving up in the other direction is also a nasty cost, and I hope we can usually avoid it with better succession planning and perhaps better tooling over post-hoc mechanisms like this.

(I wonder if we could make changes to cabal to make it willing to use a new package with a different name as a substitute for an existing one?)

Some previous discussion: Deciding whether to create a new package or take over an abandoned one - #14 by gcox

6 Likes
2

If the original maintainer explicitly said he doesn’t want anyone to take over?

No, that would be disrespectful and set a precedence that hackage can’t be trusted.

Regarding cryptonite… I’m not sure why anyone would use completely unaudited stuff. Especially since we have no idea how resistant GHC is to side channel attacks etc.

At any rate, there already is a fork: crypton: Cryptography Primitives sink

5 Likes
3

Interesting policy decision.

I for sure would expect the admins to intervene when transferring maintainership (or doing maintainer work) is both important and urgent (e.g. a vulnerability that will quickly cause damages if not immediatly fixed).

Otherwise, when the matter is important but not urgent — and this seems to be the case — I would expect the community to deal with it, be it with a transfer of ownership or a fork.

It is a very unfortunate situation, bound to leave some users not happy with any of the possible decisions.
I don’t agree with the original maintainer’s claim: if people depending on a cryptography libraries cannot be bothered to read a changelog between releases (which would prominently announce a change of maintainership), “supply-chain security potential issue” is the least of our problems.

2 Likes
4

(Deleting my post, it wasn’t in good faith)

5

Not really.

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.

That’s purely a communication/tooling issue. We can’t force maintainers to fix bugs, whether security related or not.

The other issue is what happens if someone purposefully added an exploit (given that we actually know). I’m pretty sure hackage admins can revoke upload access in such cases.

After such an incident, I don’t believe anyone will trust the package name ever again.

3 Likes
6

Unfortunately the “cryptonite universe” is a lot of packages. The latest one to come up here is memory: memory and related abstraction stuff of which I am not aware of any fork (yet).

To be clear, I expect the community “dealing with it” would necessitate the involvement of Hackage admins to implement the consensus change.

I think if you trust the author of the package you don’t need to read the changelog for every minor version upgrade, and it may in fact be risk-reducing to allow such upgrades to happen without waiting for manual approval. For major version upgrades you need to read it, sure, but typically you’ll ensure that by setting your version bounds appropriately. But when a new maintainer takes over they are able to upload new minor versions (and often will, if they took over maintainership to fix a bug or bump version bounds).

4 Likes
7

I think we could take another lesson from this, which is: important packages should have more than one maintainer. Of course, that’s no help if they’re also unavailable (I see that cryptonite and memory both have a second listed mantainer other than Vincent…), but it should significantly reduce the risk of this happening.

Of course that’s a big “should”- my best guess for how we might encourage that might be some Haskell BOM analysis tool that identifies packages with few maintainers, which might lead to some pressure to add more.

4 Likes
8

Yeah, AIUI Vincent actually did reasonable things here, but they just didn’t work out in the end. I agree that whatever takeover policy we have, we should also aim for packages, particularly widely-used packages, to have enough succession planning to (as an ideal) never need it.

1 Like
9

I did not follow what was the current situation. What do Hackage admins actually currently seek to do with an unmaintained package where the recorded mantainer cannot be contacted, where:

  1. one person has volunteered to maintain it;
  2. that person has stated that intention in a public forum, and waited a while; and
  3. no other person has subsequently volunteered to maintain it instead, but
  4. some third person has objected to the first person’s intention being implemented on some grounds which appear to the Hackage admins to be reasonable.

That is, what is the relationship between what Hackage admins actually seek to do and the question that you pose - “Is it appropriate that [Hackage admins] are willing to hand over unmaintained packages to any volunteer?”

10

On the question of what happens if an existing recorded mantainer of a package does not want maintainer status to be granted to any other person, it seems to me that the existing policy deals with that implicitly (emphasis added):

If someone has their package taken over because they did not respond, then, for the following year, should they request it, the admins will unconditionally return it to them.

If the Hackage admins will unconditionally return a package to a past maintainer on request (in these circumstances), it is hard to see why they would, normally, take a package from an existing maintainer against the maintainer’s express wishes.

6 Likes
11

I like the idea of being able to opt in to something in the range between bullet points two and three. It might be considered a selling point for a package that its author has agreed that Hackage admins can rescue it from the author if at a later date they become unresponsive or even uncooperative, under conditions in which Hackage administration believes that would be best for the community. Without opt-in, I largely agree with @mpilgrem’s take above.

12

Maybe not the same thing, but there’s already Haskell GitHub Trust · GitHub

That said, I would never use any crypto packages that are “community maintained”. That’s a recipe for disaster for incorrect drive-by commits.

1 Like
13

Yeah, the Trust isn’t what I had in mind for exactly that reason. More like an, I don’t know, foster care system—orphaned packages are found homes, not raised by the community, and if the authorities find that the homes are bad maybe they’re given to new homes. (I hesitate somewhat to use this comparison; hopefully any real-world negative impressions of your locale’s foster care system don’t bleed across the analogy boundary.)

Still not as ideal from a trust perspective as having a small, well-known team of maintainers own the library for life, but in an imperfect world, might be a preferable thing to the uncertainty of a fork-fest.

14

I actually agree with Vincent here. Crypto libraries are special. I vet my dependencies often based on maintainers.

I wouldn’t trust anyone but the original maintainer to decide whether the successor is competent enough to carry on the work in the same fashion.

That’s why a fork is better.

1 Like
15

I think current written policy doesn’t unambiguously cover this case but:

  • I personally would not implement a takeover that I thought was a bad idea, regardless of what the policy says. So if the objection is not only reasonable but persuasive, then I don’t do the takeover.
  • I’d also tend to default to not acting in ambiguous cases, so even if I wasn’t fully persuaded, I might still not implement the takeover.
16

For myself, when I depend on a package I almost always have no idea who the current owner/maintainer is. I’m trusting “the ecosystem” far more than I’m trusting any individual. Certainly I couldn’t have told you who maintained cryptonite before reading this thread; and I still can’t tell you who now maintains crypton.

(Sorry, whoever-you-are. I appreciate your work even if I can’t credit you for it.)

Maybe I’m wrong here, but I’d expect most people work the same? Even for crypto libraries. In an ideal world I should vet those carefully, but frankly I’m not capable of doing that. If there’s a showstopper bug in one of those, I’m relying on the community-at-large to notice and propagate that information to somewhere I’ll see it.

So as a user, I don’t consider it a violation of my trust if hackage admins hand over maintainership of a package, against the current maintainer’s will. It may well be a violation of the current maintainer’s trust, and that’s not something to do lightly.

I assume this would take some time, but it seems like a good direction to go in.

I guess it’s already possible with a bunch of manual effort. If I decide that every package depending on cryptonite should have that dependency satisfied by crypton, I can

  • Fork crypton.
  • Rename it to cryptonite, which I think will be straightforward.
  • Tell cabal that cryptonite comes from my fork.

But it would be more convenient if I could just tell cabal “the package cryptonite is actually supplied by crypton”.

Edge case: if I do it manually, then data types cryptonite:Crypto.Hash.Digest and crypton:Crypto.Hash.Digest are different. If I tell cabal to use crypton for cryptonite, could we get them to be the same? Would we want that?

2 Likes
17

As a package maintainer, if adding a package to Hackage ran the risk of hostile takeover, even with only good intentions, I would be a lot more hesitant to do it. A package is not just its license and source code. It’s also the maintainer’s vision for it. For this reason, I support maintainers’ right to retain ownership, regardless of whether I disagree with the maintainer’s plans for the package.

As a user taking on a dependency, I do so with whatever knowledge of the package I have or am willing to research, including its maintainers. However, I also do so with a lot of trust in whatever decisions Hackage admins make. We have to trust both the nominal package maintainers and the community behind the supply chain, who for some purposes are implicit maintainers. If I trust the Hackage admins, I am trusting that they will uphold the written policies, which I think clearly prohibit takeover in this case, and that they will uphold the spirit of the written policies, if it turns out there is an important ambiguity, which I do not think is not what’s going on here. What this meandering paragraph is trying to say is that I agreed to the policy when I took on the dependency, and especially for something like a cryptographic library, there should not be surprises. Maybe the maintainers end up surprising me, but Hackage admins’ do not have a responsibility to anticipate and mitigate that surprise, as that would run the risk of even greater surprise.

At the end of the day, though, we should still expect admins to care for the safety of Hackage users. Perhaps, instead of changing or disobeying the package takeover policy, there could be ways to loudly signal to users when a package has forks and, in cases where a package is found to have a vulnerability, ways to warn users and require them to explicitly acknowledge it in order to download affected versions of it? I would consider this a much lighterweight version of an admin simply deleting the package entirely, which I would be surprised to learn is not allowed for dealing with malicious or rule-violating packages. I would hope that maintainers unwilling to give up exclusive control over what the package actually is would at least have to accept whatever social and technical pushback results from their decisions, as long as they are still allowed to pursue their own vision for the package itself.

4 Likes
18

I wholeheartedly agree.

And I think it is not possible to change the policy retroactively, because it is not what maintainers, who already uploaded a package prior to the change, agreed to.

And in that sense, even if we did change the policy… already uploaded packages (like cryptonite) would likely remain unaffected/unchanged.

(I mean, legally… hackage can do that anyway, because it is open source licenses and hackage is just a “namespace” so to speak… but I’d quit using hackage if that would ever happen too)

19

That makes sense. If I find out that admins are violating written policy, that does cost my trust - even if I didn’t know the policy in advance, and even if I’d prefer the policy say they do the thing they’re actually doing. (How much trust depends on details, of course, and there are times when breaking trust is the right thing to do. I don’t expect this is one such.)

20

This is not a policy, it’s a specific procedure. It describes one of the ways how packages are reassigned, but it nowhere claims to be an exhaustive list of such processes. A few other ways are:

  • Core Libraries Commitee can install maintainers for core libraries without following the timeline or limitations of the usual takeover procedure.
  • Hackage Trustees can perform Non-Maintainers Uploads for pretty much any neglected package.

Imagine listed Hackage maintainers of base package going rogue and following the stance of cryptonite, blocking any new releases and forbidding takeovers. Does anyone believe that Hackage admins should not forcefully reassign maintainership in such case? While I would strongly expect them to wield such powers with great restraint, it seems unwise to put formal restrictions.

This might be a sound position to take when talking about an audited and verified code base, but absolutely ridiculous with regards to cryptonite, a self-declared “kitchen sink” to be polite.

10 Likes