aslatter at gmail.com
Fri Aug 31 03:42:34 CEST 2012
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
> getGroups = return [maintToExport maint, csvToBackup ["trustees.csv"] adminFile]
Then later 'getGroups' gets packed into the output tarball.
More information about the cabal-devel