[Haskell-cafe] Unmaintained packages and hackage upload rights

[Clark Gaebel]

Fair enough. I'm also not sure the Haskell community has a resident
security expert, so it would likely be bad security at best.

  - Clark


On Fri, Jan 31, 2014 at 2:04 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> automation ... isn't flexible. the moment theres an automatic path, a lot
> of non social engineering approaches to break any hackage trust model
>
>
> On Fri, Jan 31, 2014 at 12:45 PM, Clark Gaebel <cgaebel at uwaterloo.ca>wrote:
>
>> There could be an email made to the relevant mailing lists during a
>> takeover attempt. That way we get human visibility, human "veto power" if
>> the email goes to libraries@, and automation when there are no
>> objections.
>>
>>
>> On Fri, Jan 31, 2014 at 12:09 PM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> Agreed.  It should not be automatic.  There should be lots of human
>>> visible interaction publicly going on.
>>>
>>>
>>> On Friday, January 31, 2014, Daniil Frumin <difrumin at gmail.com> wrote:
>>>
>>>> I have a problem with the 4th step. What if maintainer is unreachable,
>>>> but the updated version of the package is broken/breaking ever
>>>> dependency? What if there are several replacements awaiting?
>>>>
>>>> I personally think that problem we are facing is not technical, but a
>>>> social one. Call me old fashioned, but I prefer trustees to the
>>>> automatic mechanism.
>>>>
>>>> I understand that Roman may have been really irritated by the whole
>>>> process - but on the other hand, do we really need/want the process of
>>>> overtaking packages to be easy? I strongly align with Gershom's
>>>> position. We should make the process more transparent and visible. In
>>>> order to put my money where my mouth is,  I created a wiki page that
>>>> (hopefully) describes the process of taking over a package:
>>>> http://www.haskell.org/haskellwiki/Taking_over_a_package
>>>> You are strongly encouraged to edit that page and give more details
>>>> (especially given my far from perfect English)
>>>>
>>>> Maybe it is a good idea to have links to that wiki article on every
>>>> package page on Hackage?
>>>>
>>>> On Fri, Jan 31, 2014 at 8:44 PM, Carter Schonwald
>>>> <carter.schonwald at gmail.com> wrote:
>>>> > Problem: no one is really actively working on hackage-server.  Are you
>>>> > volunteering? :-)
>>>> >
>>>> >
>>>> > On Friday, January 31, 2014, Clark Gaebel <cgaebel at uwaterloo.ca>
>>>> wrote:
>>>> >>
>>>> >> We could actually partially automate this:
>>>> >>
>>>> >> 1) Package maintainership switch is submitted online, with a new
>>>> >> replacement package, and perhaps a message.
>>>> >> 2) An email is sent to the maintainer with a link to either:
>>>> >>        - delete the replacement package
>>>> >>        - allow one-time upload
>>>> >>        - permanently add the uploader as a maintainer
>>>> >>        - permanently switch maintaners to the uploader
>>>> >> 3) While the package is in this limbo state waiting for a response
>>>> from
>>>> >> the maintainer, put a link to the package at the bottom of the
>>>> hackage page
>>>> >> in a new "suggested replacements" section. In this section, each
>>>> candidate
>>>> >> replacement package is listed, along with its message and how long
>>>> it's been
>>>> >> waiting.
>>>> >> 4) After a bikeshed-long amount of time with no response from the
>>>> >> maintainer (I'll suggest 1 month), the package is automatically
>>>> updated to
>>>> >> the suggested version and the package uploader is added as a
>>>> maintainer.
>>>> >>
>>>> >>
>>>> >> On Fri, Jan 31, 2014 at 11:34 AM, Daniil Frumin <difrumin at gmail.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> I think the proposed approach is only reasonable. However, I would
>>>> >>> like to stress that in any case it would be better to make sure that
>>>> >>> we give the maintainer enough time to respond, e.g.: if the
>>>> maintainer
>>>> >>> is unreachable for a couple of weeks at least
>>>> >>>
>>>> >>> On Fri, Jan 31, 2014 at 1:04 PM, Erik Hesselink <
>>>> hesselink at gmail.com>
>>>> >>> wrote:
>>>> >>> > On Fri, Jan 31, 2014 at 3:15 AM, Roman Cheplyaka <
>>>> roma at ro-che.info>
>>>> >>> > wrote:
>>>> >>> >> * Erik de Castro Lopo <mle+hs at mega-nerd.com> [2014-01-31
>>>> >>> >> 09:22:36+1100]
>>>> >>> >>> I really can understand why you did this; I am frustrated by
>>>> some of
>>>> >>> >>> the same issues. However, I think if any significant number of
>>>> people
>>>> >>> >>> did this, the results could easily be disasterous.
>>>> >>> >>
>>>> >>> >> Agreed. Maybe we need those disasterous results to realize that
>>>> the
>>>> >>> >> current process is bad and come up with a better one. Or maybe
>>>> it's
>>>> >>> >> just
>>>> >>> >> me, and everyone else is happy (enough) with the process, so
>>>> nothing
>>>> >>> >> will happen.
>>>> >>> >
>>>> >>> > That's a rather fatalist attitude, and also one that is not
>>>> warranted
>>>> >>> > given the replies in this thread. Let me try to be more
>>>> constructive
>>>> >>> > instead:
>>>> >>> >
>>>> >>> > I propose to make the trustees group able to upload any package,
>>>> with
>>>> >>> > the understanding that they only do so to make packages where the
>>>> >>> > maintainer is unreachable compile on more compilers or with more
>>>> >>> > versions of dependencies. The newly uploaded version should have a
>>>> >>> > public repository of the forked source available and listed in the
>>>> >>> > cabal file. The process would then be:
>>>> >>> >
>>>> >>> > * User fixes a package, emails the maintainer.
>>>> >>> > * No response: User emails trustees.
>>>> >>> > * Trustees check the above conditions, and upload the new version.
>>>> >>> >
>>>> >>> > This is more lightweight that the process to take over
>>>> maintainership,
>>>> >>> > and it can be, because we're not trusting a random user with a
>>>> random
>>>> >>> > package. Instead, we're only trusting a fixed set of maintainers
>>>> and a
>>>> >>> > small, publicly visible change. Because of this, the waiting
>>>> times for
>>>> >>> > non-respo
>>>
>>>
>>
>>
>> --
>> Clark.
>>
>> Key ID     : 0x78099922
>> Fingerprint: B292 493C 51AE F3AB D016  DD04 E5E3 C36F 5534 F907
>>
>
>


-- 
Clark.

Key ID     : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016  DD04 E5E3 C36F 5534 F907
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140131/9cb6a265/attachment.html>