> > I don't think there is any need for a public announcment if a package creator hands over maintainership to another developer.

> Well, there have been some rather unfortunate transfers of control of widely used packages (in other ecosystems than hackage) to shady operators
> who made malicious changes.  This is more directly a concern for browser plugins, or "apps", but also
> applies to Python, Ruby, Node and ultimately even Haskell.

Viktor makes some great points, but we do not have any such checks in place at the moment.

Currently it is accepted that a package maintainer can get help maintaining a package through whatever means. The original package maintainer can step off at a later time, leaving the new maintainers in charge.

At this stage, I think we should stop piling in on Tom -- it does not seem right, at all.

Chris

On Fri, 12 Mar 2021 at 16:59, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> On Mar 12, 2021, at 2:42 PM, Henning Thielemann <lemming@henning-thielemann.de> wrote:
>
> I don't think there is any need for a public announcment if a package creator hands over maintainership to another developer.

Well, there have been some rather unfortunate transfers of control of widely used packages (in other ecosystems than hackage) to shady operators who made malicious changes.  This is more directly a concern for browser plugins, or "apps", but also
applies to Python, Ruby, Node and ultimately even Haskell.

Supply chain security is a hard problem, and any transparency in changes
of control would be great.

If release tarballs are digitally signed, and contributors can be
expected to not hand over their own keys when transferring control,
but rather to arrange for new keys to be authorised to continue to
make releases, then such changes of control could be noted on hackage
as a change in which key signed a new release.

Cautious users might pin the release keys trusted to sign a given
dependency, and could then review and approve imports of these
if signed by not yet trusted keys.  There could even be a role
for trusted reviewers (and ideally a means to compensate them
for their work).  I did mention this is a hard problem...

--
        Viktor.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.