On Thu, Aug 30, 2012 at 8:11 PM, Antoine Latter <aslat...@gmail.com> wrote: > 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. >
After digging a bit, the code that does this is a part of converting the legacy data into the new-style backup tarball. I'm too behind on how things work to know if that's still a thing that happens or is at all useful :-) > maint = BulkImport.mergeMaintainers pkgsInfo and later: > getGroups = return [maintToExport maint, csvToBackup ["trustees.csv"] > adminFile] Then later 'getGroups' gets packed into the output tarball. Antoine > Antoine _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
