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

On Aug 31, 2012 11:56 AM, "Ian Lynagh" wrote:

On Thu, Aug 30, 2012 at 08:42:34PM -0500, Antoine Latter wrote:

...

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 :-)

I don't think the current mirror script makes any attempt to copy across user accounts, if that's what you mean.

Yep, that's what I meant. So we would need to already have users in the destination instance, and then also call into the functionality that tries to create an uploaders group based on user name.

Thanks Ian

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

On Sat, Sep 1, 2012 at 5:10 PM, Ian Lynagh wrote:

On Fri, Aug 31, 2012 at 01:57:55AM +0100, Ian Lynagh wrote:

...

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.

I wasn't involved in the design of that, so I wonder if someone who was could comment?

I've just disabled the per-package-uploader test, for now at least. Hackage 1 didn't have it, so this leaves us no worse off than we were before, and we can always re-enable it later if we decide that that's what we want.

I think that the eventual situation should have per-package uploaders. It just seems to dangerous for anyone to be able to upload any package, especially heavily-used ones. On the other hand, I see little use for the global uploaders group. So I'd propose to eventually switch from the current situation, and have only per-package uploaders, and no global uploaders. This also means that the maintenance burden per person is constant as the community grows, since the package maintainers can manage their own packages uploaders, whereas a global uploaders list has to managed by centralized admins. This does imply that there has to be some initial import where the old accounts/uploaders are connected with new accounts, which would need to be imported from the old hackage. I don't think that is the plan now, is it? Erik

On Tue, Sep 4, 2012 at 1:35 AM, Leon Smith wrote:

On Mon, Sep 3, 2012 at 4:20 AM, Erik Hesselink wrote:

...

I think that the eventual situation should have per-package uploaders. It just seems to dangerous for anyone to be able to upload any package, especially heavily-used ones.

I think you underestimate the power of non-technical security measures. It's not been a problem in the past, and Debian allows any committer to upload any package.

The thing is, since we have an account approval process and that we have a full, public log of everything that everybody's uploaded, people are going to notice when somebody uploads something they shouldn't. We have accountability, unlike a typical FTP site or other mutable filesystem.

Yes, I think you are right that people will notice -- eventually. It might take an hour, it might take a day, it might take a week. But say that a malicious version of mtl was uploaded, that, say, copied some private keys or password files at compile time using template haskell. If you notice after a week, how many people and companies will have been hit?

Also, remember Linus Torvald's justification for not having any commit bits in git; I think our situation is different but similar. If somebody does upload something they shouldn't, to what degree is it really a problem? Again, data is not lost, and we have accountability.

Linus has some peculiar views on some subjects that work well for the linux kernel, but not necessarily for everybody. Note that github, which really popularized git, does have per repository permissions, given to the creator by default.

...

On the other hand, I see little use for the global uploaders group. So I'd propose to eventually switch from the current situation, and have only per-package uploaders, and no global uploaders.

As a LtU admin (something more of a nightclub bouncer, really), I dislike the current Hackage 2 user account process in a lot of respects. But the approval process has worked remarkably well for LtU, we haven't had a single spam message since requiring account approval before posting. (I hope I haven't failed to approve too many legitimate requests... but at the same time, if somebody really wants an account they can try again or contact Ehud.)

But the problem being solved at LtU is spam. What problem is the hackage uploaders group solving? I don't think spammers are going to upload spammy, well-formed Haskell packages. It might become more of a problem in case we add commenting. But even then, wouldn't a captcha or email confirmation work equally well? I feel that right now, we're wasting an admittedly small amount of your and my time, and delaying people who want to upload a package to hackage, for no good reason.

Also, we haven't had a single problem that I'm aware of on Ross Paterson's watch as bouncer for Hackage 1. The point I'm trying to make is that a technical solution imposes additional administrative and technical overhead whereas social processes can also be very effective while also handling corner cases more gracefully.

I don't see how a technical solution (which is already implemented, by the way) introduces *more* overhead than a manual solution. Also, the fact that we haven't had any problems doesn't mean we won't in the future. We don't have to wait before something goes wrong to fix it. Erik

On Thu, Sep 6, 2012 at 10:28 AM, Duncan Coutts

wrote:

On 5 September 2012 20:22, Erik Hesselink wrote:

...

...

Also, we haven't had a single problem that I'm aware of on Ross Paterson's watch as bouncer for Hackage 1. The point I'm trying to make is that a technical solution imposes additional administrative and technical overhead whereas social processes can also be very effective while also handling corner cases more gracefully.

I don't see how a technical solution (which is already implemented, by the way) introduces *more* overhead than a manual solution. Also, the fact that we haven't had any problems doesn't mean we won't in the future. We don't have to wait before something goes wrong to fix it.

As I think you know, I'm definately in favour of the per-package maintainer group stuff.

Let me make one more argument: even if we don't in practice have problems with people uploading packages they shoudn't, it'll make everyone *feel* better (that is, package maintainers and users). We do get a bit of stick for the current lack of security (not just this issue but about the lack of tamper profing / detecting).

Additionally, if you decide that you would prefer to allow anyone to upload without having to get manual approval to be in the uploader group, then the per-package maintainer group becomes very useful. You could have more or less a free for all in uploading new names, but nobody can subvert existing names.

(We would still have the problem of people taking all the good package names for crappy packages, but that's another issue)

I understand we're not planning on importing the accounts from the old server. Could someone explain the issue there? I'd assumed we'd do that for a smoother changeover (and to set up the initial maintainer groups).

Duncan

I'm a little bit confused on the exact set up. The uploaders group seems to be roughly the same thing as the trustees group. (Except uploaders has an AND relationship with per-package groups as far as membership requirements for upload, and trustees has an OR relationship). To my knowledge, It's technically possible to import the old accounts. Matt

On Thu, Sep 06, 2012 at 06:49:36PM +0100, Matthew Gruen wrote:

To my knowledge, It's technically possible to import the old accounts.

Why is that? I think that's worth exploring, as you'd be losing associations between 1150 users and 24456 uploads of 4442 packages. (Not entirely, because the old names would be there as text, but they wouldn't be connected to user-ids.)

On Thu, Sep 6, 2012 at 11:53 AM, Ian Lynagh wrote:

But if that's not the case then I can look into importing them.

I think that making the effort to import that data would be well worthwhile. Thanks for looking into it.

On Thu, Sep 06, 2012 at 08:32:38PM +0100, Duncan Coutts wrote:

...

From the point of view of an existing user, they will go to the new site, go to a special page, enter their username and their old password and a new password (which can be the same if they like). This is a one off. After that they use the site as normal with their new password.

Does the H1 server have an e-mail address for the user? If so, we can just implement a "Reset my password" feature that e-mails you a URL with which you can reset your password. That seems like something we ought to implement anyway. Thanks Ian

On Mon, Sep 3, 2012 at 4:35 PM, Leon Smith wrote:

The thing is, since we have an account approval process and that we have a full, public log of everything that everybody's uploaded, people are going to notice when somebody uploads something they shouldn't.

No, it has already happened that people have *not* noticed when someone else has uploaded or otherwise modified packages that they shouldn't have. I only know about the incidents that involved me personally, but I am certain there have been many more. I don't have a huge investment in how this is managed, but the decision process should not be based on wishful thinking.