On Thu, Aug 30, 2012 at 7:57 PM, Ian Lynagh <i...@well-typed.com> wrote: > > [moving to cabal-dev@] > > On Thu, Aug 30, 2012 at 08:13:01PM -0400, Leon Smith wrote: >> Ok, I tried to upload the most recent version of postgresql-simple, and I >> couldn't because I'm not the maintainer for that package. >> >> Has anybody ever uploaded a package that they shouldn't have on the old >> Hackage? Is this security really necessary at this stage in the game? >> >> I'm very much of the philosophy that, given that we must approve >> accounts, that we rely on social processes instead of technical solutions >> for these types of access control issues until (and unless) experience >> proves that we do need some kind of technical solution. But by then, >> hopefully we'll have a better idea of what we need. > > I wasn't involved in the design of that, so I wonder if someone who was > could comment? > > The most analogous large system I'm familiar with is Debian, which AFAIK > has no technical measures to stop any developer uploading any package, > but is careful about who it allows to become a developer. > > Perhaps it is redundant to have both the "uploaders" group and the > "per-package uploaders" functionality enabled, and even if the software > continues to support both, we should only enable one or the other on the > central Hackage site? In which case, which do we want? > > > If we do stay with the "per-package uploaders" feature, then I wonder > whether we should have a special case for packages with an empty access > list (i.e. all currently existing packages), such that anyone can upload > a new version of them, and anyone doing so becomes the sole uploader for > that package? That would avoid the admins having to get involved for > every package, as well as every person. >
At one point I think we tried to populate the per-package uploaders group as a part of the import with everyone who had historically uploaded the package - this relies on the historic user names lining up with the current user accounts as imported. I guess that also relies on order-of-operations of the import getting users first. We get by with social conventions now, so it wouldn't be terrible to get by with them on Hackage 2. Antoine _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
