Hackage 2

[Antoine Latter]

On Thu, Aug 30, 2012 at 8:11 PM, Antoine Latter <aslatter at gmail.com> wrote:
> On Thu, Aug 30, 2012 at 7:57 PM, Ian Lynagh <ian at 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