
We need some security on uploads to hackage, because Cabal packages can run arbitrary code during the build process (and when in use). I think that Apache authentication (as used in Trac, for example) would be sufficient, but that the initial registration of submitters needs to be done manually by a small group of people. We need to know who we're dealing with, and we need at least an email address to contact them. Personally, I'd prefer that user names were real names in camel case, but maybe I'm too old-fashioned. Any views?

Hello Ross, Wednesday, January 3, 2007, 9:03:03 PM, you wrote:
We need some security on uploads to hackage, because Cabal packages
interesting question, although i think it is more appropriate for cafe maillist i think we can look at it from another side. how your committee van decide who is "good hacker" and who isn't? what is your criteria? for example, how you can decide is me good enough or not? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Thu, Jan 04, 2007 at 12:52:36AM +0300, Bulat Ziganshin wrote:
i think we can look at it from another side. how your committee van decide who is "good hacker" and who isn't? what is your criteria? for example, how you can decide is me good enough or not?
We just need to record names and email addresses for people who are producing or maintaining Haskell code. The recording needs to be done manually to ensure the consistency and quality of the information, not the individuals. We can leave reputation judgements to the users of libraries (and the build daemons), once it's clear who uploaded each package. (Reputation is transitive in this case.) We need a group of people to do this recording, not to have votes or discussions, but because a single person would be a chokepoint.

Hi
We need some security on uploads to hackage, because Cabal packages can run arbitrary code during the build process
I think this should be strongly discouraged by Cabal, almost to the point where Setup files with custom code are disallowed by Hackage. Doing an attack on an in-use module is a lot more work than putting it in the configure script.
I think that Apache authentication (as used in Trac, for example) would be sufficient, but that the initial registration of submitters needs to be done manually by a small group of people. We need to know who we're dealing with, and we need at least an email address to contact them. Personally, I'd prefer that user names were real names in camel case, but maybe I'm too old-fashioned.
There is also a list of people with access to the darcs repo's on Haskell.org - these things probably want managing in much the same way. Currently the policy is that Yhc hackers get their key added to my authorised_keys file, and just log in using my username - I'm not terribly comfortable with that. I would demand at the very least a real name, email address - but really, in an online world those things are nearly useless. I guess the only thing to do is to trust that people who have learnt enough about monads and IO to hijack Haskell things probably realise how cool Haskell is... Thanks Neil

Am Mittwoch, 3. Januar 2007 23:46 schrieb Neil Mitchell:
We need some security on uploads to hackage, because Cabal packages can run arbitrary code during the build process
I think this should be strongly discouraged by Cabal, almost to the point where Setup files with custom code are disallowed by Hackage. Doing an attack on an in-use module is a lot more work than putting it in the configure script. [...]
There are already quite a few open build systems for "normal" (RPM, etc.) packages out there, and the usual technology is to run everything in a chroot cage. Would this be an option here, too? I have to admit that I currently do not fully understand who will run which code when, etc. when we talk about hackage. Cheers, S.

On 03/01/07, Ross Paterson
I think that Apache authentication (as used in Trac, for example) ...
Just to point out that Trac's authentication is probably the most annoying I've ever used. It would never remember that I was logged in and every time I wanted to make a change to the Trac I'd have to hunt for the 'Log in' button and enter my username and password. If this is tied to HTTP auth, consider this a strong vote _against_ the proposed system from someone who's had experience working with the system in practise. -- -David House, dmhouse@gmail.com

On Thu, Jan 04, 2007 at 10:37:35AM +0000, David House wrote:
On 03/01/07, Ross Paterson
wrote: I think that Apache authentication (as used in Trac, for example) ...
Just to point out that Trac's authentication is probably the most annoying I've ever used. It would never remember that I was logged in and every time I wanted to make a change to the Trac I'd have to hunt for the 'Log in' button and enter my username and password. If this is tied to HTTP auth, consider this a strong vote _against_ the proposed system from someone who's had experience working with the system in practise.
Authentication would only happen when you upload a package. Do you have an alternative suggestion?

On 04/01/07, Ross Paterson
Authentication would only happen when you upload a package. Do you have an alternative suggestion?
The normal authentication methods for web applications. Store a database of (username, password) pairs. A user becomes logged in by setting two cookies, one to indicate their username and one to indicate their password (or often the MD5 hash of their password). To authenticate a user, you check that these cookies are present, that the value of the username cookie appears in the database and that the password cookie matches the corresponding password pulled from the database. I'm not actually that familiar with HTTP Auth itself, just with Trac. But if you want to save frequent contributors tearing their hear out, at least consider this. :) -- -David House, dmhouse@gmail.com
participants (5)
-
Bulat Ziganshin
-
David House
-
Neil Mitchell
-
Ross Paterson
-
Sven Panne