Re: Hackage 2

On Thu, Aug 30, 2012 at 8:11 PM, Antoine Latter wrote:

On Thu, Aug 30, 2012 at 7:57 PM, Ian Lynagh 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