[Haskell-cafe] Unmaintained packages and hackage upload rights

Carter Schonwald carter.schonwald at gmail.com
Fri Jan 31 18:14:45 UTC 2014


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.

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.

On Friday, January 31, 2014, Daniil Frumin <difrumin at gmail.com> wrote:

> On Fri, Jan 31, 2014 at 10:05 PM, Clark Gaebel <cgaebel at uwaterloo.ca<javascript:;>>
> wrote:
> > The automation could just be "new package version + new maintainer added
> in
> > 30 days if no one manually stops it".
> >
> > Takeovers should be easy to stop for both existing library maintainers
> and
> > any core "trusted" members of the community.
>
> Rights, that's why we have hackage trustees. They can easily
> overwrite/update any package (if I understand the process correctly).
> Complete takeover of a package should *not* be easy, we must give the
> maintainers a good sense of ownership.
>
> >
> >
> > On Fri, Jan 31, 2014 at 1:03 PM, Carter Schonwald
> > <carter.schonwald at gmail.com> wrote:
> >>
> >> How would the automation work?  Automation in trust models is very very
> >> fiddly to get right.  Like really hard.  Like a research problem with
> >> reality consequences hard.
> >>
> >> At the end of the day, it's a people problem.  The best we can do is
> come
> >> up with a very audit able, publicly visible process that makes
> everything
> >> easy for 3rd partiies to audit.  And prevents / catches any abuse
> before it
> >> does something like break vector or ByteString.
> >>
> >>
> >>
> >> On Friday, January 31, 2014, 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
> >>> >> pag--
> Sincerely yours,
> -- Daniil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140131/a49d5c98/attachment-0001.html>


More information about the Haskell-Cafe mailing list