<div dir="ltr"><span class="gmail-im" style="color:rgb(80,0,80)">> > I don't think there is any need for a public announcment if a package creator hands over maintainership to another developer.<br><br></span>> Well, there have been some rather unfortunate transfers of control of widely used packages (in other ecosystems than hackage) to shady operators<div>> who made malicious changes.  This is more directly a concern for browser plugins, or "apps", but also<br>> applies to Python, Ruby, Node and ultimately even Haskell.<br></div><div><br></div><div>Viktor makes some great points, but we do not have any such checks in place at the moment.</div><div><br></div><div>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.</div><div><br></div><div>At this stage, I think we should stop piling in on Tom -- it does not seem right, at all.</div><div><br></div><div>Chris</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 12 Mar 2021 at 16:59, Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org">ietf-dane@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On Mar 12, 2021, at 2:42 PM, Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>> wrote:<br>
> <br>
> I don't think there is any need for a public announcment if a package creator hands over maintainership to another developer.<br>
<br>
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<br>
applies to Python, Ruby, Node and ultimately even Haskell.<br>
<br>
Supply chain security is a hard problem, and any transparency in changes<br>
of control would be great.<br>
<br>
If release tarballs are digitally signed, and contributors can be<br>
expected to not hand over their own keys when transferring control,<br>
but rather to arrange for new keys to be authorised to continue to<br>
make releases, then such changes of control could be noted on hackage<br>
as a change in which key signed a new release.<br>
<br>
Cautious users might pin the release keys trusted to sign a given<br>
dependency, and could then review and approve imports of these<br>
if signed by not yet trusted keys.  There could even be a role<br>
for trusted reviewers (and ideally a means to compensate them<br>
for their work).  I did mention this is a hard problem...<br>
<br>
-- <br>
        Viktor.<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>