Yes. It should be perhaps even require two trustees / admins / whatever if we are actually serious about making things proof against social engineering. Or something. <div><br></div><div>Nb: hackage admins have the super powers. I'm just a trustee. Which just means I can delete bad doc builds to force em to rebuild. <span></span><br>
<br>On Friday, January 31, 2014, Daniil Frumin <<a href="mailto:difrumin@gmail.com">difrumin@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Jan 31, 2014 at 10:05 PM, Clark Gaebel <<a href="javascript:;" onclick="_e(event, 'cvml', 'cgaebel@uwaterloo.ca')">cgaebel@uwaterloo.ca</a>> wrote:<br>
> The automation could just be "new package version + new maintainer added in<br>
> 30 days if no one manually stops it".<br>
><br>
> Takeovers should be easy to stop for both existing library maintainers and<br>
> any core "trusted" members of the community.<br>
<br>
Rights, that's why we have hackage trustees. They can easily<br>
overwrite/update any package (if I understand the process correctly).<br>
Complete takeover of a package should *not* be easy, we must give the<br>
maintainers a good sense of ownership.<br>
<br>
><br>
><br>
> On Fri, Jan 31, 2014 at 1:03 PM, Carter Schonwald<br>
> <<a>carter.schonwald@gmail.com</a>> wrote:<br>
>><br>
>> How would the automation work? Automation in trust models is very very<br>
>> fiddly to get right. Like really hard. Like a research problem with<br>
>> reality consequences hard.<br>
>><br>
>> At the end of the day, it's a people problem. The best we can do is come<br>
>> up with a very audit able, publicly visible process that makes everything<br>
>> easy for 3rd partiies to audit. And prevents / catches any abuse before it<br>
>> does something like break vector or ByteString.<br>
>><br>
>><br>
>><br>
>> On Friday, January 31, 2014, Clark Gaebel <<a>cgaebel@uwaterloo.ca</a>> wrote:<br>
>>><br>
>>> There could be an email made to the relevant mailing lists during a<br>
>>> takeover attempt. That way we get human visibility, human "veto power" if<br>
>>> the email goes to libraries@, and automation when there are no objections.<br>
>>><br>
>>><br>
>>> On Fri, Jan 31, 2014 at 12:09 PM, Carter Schonwald<br>
>>> <<a>carter.schonwald@gmail.com</a>> wrote:<br>
>>><br>
>>> Agreed. It should not be automatic. There should be lots of human<br>
>>> visible interaction publicly going on.<br>
>>><br>
>>><br>
>>> On Friday, January 31, 2014, Daniil Frumin <<a>difrumin@gmail.com</a>> wrote:<br>
>>><br>
>>> I have a problem with the 4th step. What if maintainer is unreachable,<br>
>>> but the updated version of the package is broken/breaking ever<br>
>>> dependency? What if there are several replacements awaiting?<br>
>>><br>
>>> I personally think that problem we are facing is not technical, but a<br>
>>> social one. Call me old fashioned, but I prefer trustees to the<br>
>>> automatic mechanism.<br>
>>><br>
>>> I understand that Roman may have been really irritated by the whole<br>
>>> process - but on the other hand, do we really need/want the process of<br>
>>> overtaking packages to be easy? I strongly align with Gershom's<br>
>>> position. We should make the process more transparent and visible. In<br>
>>> order to put my money where my mouth is, I created a wiki page that<br>
>>> (hopefully) describes the process of taking over a package:<br>
>>> <a href="http://www.haskell.org/haskellwiki/Taking_over_a_package" target="_blank">http://www.haskell.org/haskellwiki/Taking_over_a_package</a><br>
>>> You are strongly encouraged to edit that page and give more details<br>
>>> (especially given my far from perfect English)<br>
>>><br>
>>> Maybe it is a good idea to have links to that wiki article on every<br>
>>> package page on Hackage?<br>
>>><br>
>>> On Fri, Jan 31, 2014 at 8:44 PM, Carter Schonwald<br>
>>> <<a>carter.schonwald@gmail.com</a>> wrote:<br>
>>> > Problem: no one is really actively working on hackage-server. Are you<br>
>>> > volunteering? :-)<br>
>>> ><br>
>>> ><br>
>>> > On Friday, January 31, 2014, Clark Gaebel <<a>cgaebel@uwaterloo.ca</a>> wrote:<br>
>>> >><br>
>>> >> We could actually partially automate this:<br>
>>> >><br>
>>> >> 1) Package maintainership switch is submitted online, with a new<br>
>>> >> replacement package, and perhaps a message.<br>
>>> >> 2) An email is sent to the maintainer with a link to either:<br>
>>> >> - delete the replacement package<br>
>>> >> - allow one-time upload<br>
>>> >> - permanently add the uploader as a maintainer<br>
>>> >> - permanently switch maintaners to the uploader<br>
>>> >> 3) While the package is in this limbo state waiting for a response<br>
>>> >> from<br>
>>> >> the maintainer, put a link to the package at the bottom of the hackage<br>
>>> >> pag--<br>
Sincerely yours,<br>
-- Daniil<br>
</blockquote></div>