http access to svn repos?
Hi All, Would anyone be averse to making anonymous http checkouts possible from zope.org? Some of us are behind annoying proxies that won't let svn through :-/ cheers, Chris PS: https write access would be nice, but I guess that's out of the question? -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Withers wrote:
Would anyone be averse to making anonymous http checkouts possible from zope.org?
Some of us are behind annoying proxies that won't let svn through :-/
At one point, enabling the 'http:' checkout gateway was a sure-fire recipe for getting SVN's knickers in a twist, which is why we disabled it. Or maybe that was ViewCSV. In any case, I would guess that you might persuade folks to allow DAV-based checkout (which is what svn-over-http is), but you are likely to have to write it up as a proposal, including specific information about the Apache / SVN configuration changes required.
PS: https write access would be nice, but I guess that's out of the question?
Yes, definitely. The answer is the same as when you asked for it two years ago (: the WebDAV stuff is slow (which may be a reason not to allow annonymous http: checkouts, too), and the credentials mechanism is built entirely around the contributor's SSH key.. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEDFIO+gerLs4ltQ4RAkwfAKCYaDo9lObM0Ye3+2T7x4NPdF7ntwCgnVvO GOYCPxQvM2C7+UZEtMvyHcg= =UJXD -----END PGP SIGNATURE-----
Tres Seaver wrote:
At one point, enabling the 'http:' checkout gateway was a sure-fire recipe for getting SVN's knickers in a twist, which is why we disabled it. Or maybe that was ViewCSV.
It was ViewCSV, in particular, the tarball download...
In any case, I would guess that you might persuade folks to allow DAV-based checkout (which is what svn-over-http is), but you are likely to have to write it up as a proposal, including specific information about the Apache / SVN configuration changes required.
Where should I write the proposal? Who is going to review it? I'm all for just doing it and reverting it if there are problems...
Yes, definitely. The answer is the same as when you asked for it two years ago (: the WebDAV stuff is slow (which may be a reason not to allow annonymous http: checkouts, too),
I'm fairly sure SourceForge uses https for it's writeable svn service. I might be mistaken on that, but if I'm not, I doubt there are issues...
and the credentials mechanism is built entirely around the contributor's SSH key..
yes, this sucks :-/ Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Withers wrote:
Tres Seaver wrote:
At one point, enabling the 'http:' checkout gateway was a sure-fire recipe for getting SVN's knickers in a twist, which is why we disabled it. Or maybe that was ViewCSV.
It was ViewCSV, in particular, the tarball download...
In any case, I would guess that you might persuade folks to allow DAV-based checkout (which is what svn-over-http is), but you are likely to have to write it up as a proposal, including specific information about the Apache / SVN configuration changes required.
Where should I write the proposal? Who is going to review it?
http://www.zope.org/Wikis/DevSite/Proposals ; post here and zope3-dev for review.
I'm all for just doing it and reverting it if there are problems...
You need to identify potential issues, document any changes needed to the Apache config (to enable the DAV verbs, for instance), and spell out how to revert it; then get the rest of the community to accept it, at least tacitly.
Yes, definitely. The answer is the same as when you asked for it two years ago (: the WebDAV stuff is slow (which may be a reason not to allow annonymous http: checkouts, too),
I'm fairly sure SourceForge uses https for it's writeable svn service. I might be mistaken on that, but if I'm not, I doubt there are issues...
- -1 on using https for writable checkouts. The issues aren't so much technical feasibility as social / legal: a checkin done using somebody's private key is way less deniable than one done with a password. Unless you plan to set up a system for issuing client certificates to contributors, I don't think https is superior to svn+ssh at all.
and the credentials mechanism is built entirely around the contributor's SSH key..
yes, this sucks :-/
It's *by design*. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEDMc9+gerLs4ltQ4RAnGXAKDQFNkxsqRV+W82SZh5yLlbeJIYdgCglCV5 7rizxM8sF3bXk0P+9yDNnIU= =9yuP -----END PGP SIGNATURE-----
Tres Seaver schrieb:
Chris Withers wrote:
...
Where should I write the proposal? Who is going to review it?
http://www.zope.org/Wikis/DevSite/Proposals ; post here and zope3-dev for review.
+1 for http anon checkouts at least :-)
...
-1 on using https for writable checkouts.
The issues aren't so much technical feasibility as social / legal: a checkin done using somebody's private key is way less deniable than one done with a password. Unless you plan to set up a system for issuing client certificates to contributors, I don't think https is superior to svn+ssh at all.
I think a possible solution would be client certificate on request and downloadable with ssh from users account - maybe even automatically generation of client cert via ssh for acredited contributors. At least this would be equaly secure/insecure as current ssh-pubkey only. Otoh, if you want to make it right [tm] you need a fairly complicated CA-setup. Including isolated box, sneakers-net or at least some solution with serial interface... really a lot of work. (But this would be more secure then we have now with the simple publickey) Regards Tino
Tres Seaver wrote:
Where should I write the proposal? Who is going to review it?
http://www.zope.org/Wikis/DevSite/Proposals ; post here and zope3-dev for review.
yay! a wiki... oh the joy...
You need to identify potential issues, document any changes needed to the Apache config (to enable the DAV verbs, for instance), and spell out how to revert it; then get the rest of the community to accept it, at least tacitly.
*sigh* red tape wins again. It's much easier to just do nothing, and just not be able to contribute from behind a firewall...
The issues aren't so much technical feasibility as social / legal: a checkin done using somebody's private key is way less deniable than one done with a password. Unless you plan to set up a system for issuing client certificates to contributors, I don't think https is superior to svn+ssh at all.
Hmmm, I'm tempted to call BS on this. How much of this has actually been tested in a court? Really, all this crap gets caught up on pseudo legal BS which ultimately just makes it more difficult for people to contribute :-( I really don't get the whole paranoia about passwords anyway... yes, client certs and public key are "more secure", but really, why are we setting the bar so high? It's not like we're dealing with top secret national security stuff...
yes, this sucks :-/
It's *by design*.
OK, as a concrete example, the guys at my current big project have effectively donated a full MSDN license so I can pick up doing the Windows builds and give Tim a break. But, because they're a bank, they care about security and so don't let any old protocol through their firewalls... http and https are fine, I can check into or out of my own repository, and any other repo running a "standard" protocol. However, zope.org insists on using the esoteric svn+ssh protocol for write access (which you have to jump through all sorts of hoops to get working on Windows anyway :-/) and the getting-used-less-and-less svn protocol which is just flat blocked by large and immovable firewalls... For trying to get people to help out, this sucks ass. Come on, we're an open source project, we _want_ people to help out, not keep on pushing them away with higher and higher bars :-( Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Tue, 2006-07-03 at 09:35 +0000, Chris Withers wrote:
*sigh* red tape wins again. It's much easier to just do nothing, and just not be able to contribute from behind a firewall...
Yeah, this is always unfortunate.
The issues aren't so much technical feasibility as social / legal: a checkin done using somebody's private key is way less deniable than one done with a password. Unless you plan to set up a system for issuing client certificates to contributors, I don't think https is superior to svn+ssh at all.
Hmmm, I'm tempted to call BS on this. How much of this has actually been tested in a court? Really, all this crap gets caught up on pseudo legal BS which ultimately just makes it more difficult for people to contribute :-( I really don't get the whole paranoia about passwords anyway... yes, client certs and public key are "more secure", but really, why are we setting the bar so high? It's not like we're dealing with top secret national security stuff...
+1 on Chris' comments
For trying to get people to help out, this sucks ass. Come on, we're an open source project, we _want_ people to help out, not keep on pushing them away with higher and higher bars :-(
+1 once more For my own contribution I could really care less what protocols we use, since I"m in a situation where I can use whatever. But out of the 20 or so public SVN repos i have write access to, zope.org is the only one that requires this whole ssh thing (most do writing over https, a few do writing over regular http). Its certainly not the norm. I realize changing it at this point would probably be a major pain for all existing contributors, but lowering the bar for new contributors is definitely worth it IMHO. Anyhow, just my 2 cents. - Rocky -- Rocky Burt AdaptiveWave - Content Management as a Service http://www.adaptivewave.com Content Management Made Simple
Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Chris Withers wrote:
Would anyone be averse to making anonymous http checkouts possible from zope.org?
Some of us are behind annoying proxies that won't let svn through :-/
At one point, enabling the 'http:' checkout gateway was a sure-fire recipe for getting SVN's knickers in a twist, which is why we disabled it. Or maybe that was ViewCSV.
Actually, it was BekeleyDB. :) The main obstical was that it required apache 2 and, at the time we were running apache 1 and I didn't want to spend the time figuring out the apache access.
In any case, I would guess that you might persuade folks to allow DAV-based checkout (which is what svn-over-http is), but you are likely to have to write it up as a proposal, including specific information about the Apache / SVN configuration changes required.
PS: https write access would be nice, but I guess that's out of the question?
Yes, definitely. The answer is the same as when you asked for it two years ago (: the WebDAV stuff is slow (which may be a reason not to allow annonymous http: checkouts, too), and the credentials mechanism is built entirely around the contributor's SSH key..
I would support HTTP anonymous checkouts. I'm really against writable HTTP checkouts because I consider the credentials mechanism for HTTP access to be extremely lame. Despite out lame program for uploading keys, I find the ssh-based access mechanism to be far more usable and secure. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
At one point, enabling the 'http:' checkout gateway was a sure-fire recipe for getting SVN's knickers in a twist, which is why we disabled it. Or maybe that was ViewCSV.
Actually, it was BekeleyDB. :)
And Jens has fixed that now, iirc?
The main obstical was that it required apache 2 and, at the time we were running apache 1 and I didn't want to spend the time figuring out the apache access.
Is cvs.zope.org still running Apache 1?
I would support HTTP anonymous checkouts. I'm really against writable HTTP checkouts because I consider the credentials mechanism for HTTP access to be extremely lame.
Can you elaborate a little? I'm guessing you may mean that the subversion client has a propensity for storing cleartext passwords but is there anything else?
lame program for uploading keys, I find the ssh-based access mechanism to be far more usable and secure.
Secure, maybe, but is it really worth it? Usable? Don't agree, especially if you're trying to develop on Windows... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris quoting Jim:
lame program for uploading keys, I find the ssh-based access mechanism to be far more usable and secure.
Secure, maybe, but is it really worth it?
Usable? Don't agree, especially if you're trying to develop on Windows...
As a data-point, for the last year or 2, I've had good success with putty's ssh2 keys on Windows. And quoting out-of-order, Jim wrote:
I would support HTTP anonymous checkouts. I'm really against writable HTTP checkouts because I consider the credentials mechanism for HTTP access to be extremely lame.
whether SVN or not, I'm guessing any use of HTTP basic authentication mechanism qualifies as "extremely lame"! I've no idea if this is what Jim meant though :) Cheers, Mark
Mark Hammond schrieb:
Chris quoting Jim:
...
I would support HTTP anonymous checkouts. I'm really against writable HTTP checkouts because I consider the credentials mechanism for HTTP access to be extremely lame.
whether SVN or not, I'm guessing any use of HTTP basic authentication mechanism qualifies as "extremely lame"! I've no idea if this is what Jim meant though :)
Well, I hope ;) he meant client certificates. This is doable but a bit of work for the certificate people to issue one to the user in addition to the ssh-pubkey stuff. Not actually quite in line w/ what you should do as a CA but possible and not more insecure then current ssh-pubkey auth would be a script which can be run with the ssh-useraccount and produces/registeres a given client certificate for that user. Something like: ssh cert.zope.org generate >mycert.csr when your ssh-pubkey is set up. And likewise ssh cert.zope.org retract <mycurrentcert.csr to disable a given client certificate. Just some mad ideas... Regards Tino PS: there is no need to have an official CA, any private setup would do.
Tino Wildenhain wrote:
I would support HTTP anonymous checkouts. I'm really against writable HTTP checkouts because I consider the credentials mechanism for HTTP access to be extremely lame.
whether SVN or not, I'm guessing any use of HTTP basic authentication mechanism qualifies as "extremely lame"! I've no idea if this is what Jim meant though :)
Well, I hope ;)
Why? The password are never sent over the wire unencrypted? Yes, caching them locally in cleartext blows a lot, especially since the files and directories that contain them are world readable, but this is a bug we should raise with the svn guys. That said, I'll ask again, why are we so paranoid about security? WE're working on a piece of open source software here... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Mark Hammond wrote:
Chris quoting Jim:
...
whether SVN or not, I'm guessing any use of HTTP basic authentication mechanism qualifies as "extremely lame"! I've no idea if this is what Jim meant though :)
OK, for those not familiar with svn/HTTP authentication, as I understand it you have to authenticate for each session and your credentials are cached in clear text in your home directory. The storage of clear-text credentials is obviously lame, as is the necessity to provide then for each svn session. With the current ssh-based mechanism, I authenicate once when I log into my machine and don't have to authenticate again for the remainder of that OS session, during which I can log into many remote machines and access many different Subversion and CVS repositories without having to reenter credentials. I find this to be a major convenience. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
OK, for those not familiar with svn/HTTP authentication, as I understand it you have to authenticate for each session and your credentials are cached in clear text in your home directory.
Well, you _either_ have to authenticate once per session _or_ your credentials are cached in clear text in .subversion/auth/basic/xxx.
The storage of clear-text credentials is obviously lame,
Yeah, I wonder if anyone has reported this as a bug to the svn people?
as is the necessity to provide then for each svn session.
Well, if you accept one lame-ness then you never have to provide credentials again ;-)
With the current ssh-based mechanism, I authenicate once when I log into my machine and don't have to authenticate again for the remainder of that OS session, during which I can log into many remote machines and access many different Subversion and CVS repositories without having to reenter credentials. I find this to be a major convenience.
...outweighed by getting public keys onto the right servers, getting the damn putty session to find the keys and getting Tortoise and the command line client to use the right putty session :-/ Chris :'( -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 3/8/06, Jim Fulton <jim@zope.com> wrote:
OK, for those not familiar with svn/HTTP authentication, as I understand it you have to authenticate for each session and your credentials are cached in clear text in your home directory. The storage of clear-text credentials is obviously lame, as is the necessity to provide then for each svn session.
Client certificates are the SSL equivalent of ssh keys and can, like keys, be protected by a passphrase. Without some form of passphrase-caching agent, you'd have to re-enter your passphrase every time too though, or (*shudder*) put your passphrase into the .subversion/servers config file, and you are back to square one. -- Martijn Pieters
Chris Withers wrote:
Hi All,
Would anyone be averse to making anonymous http checkouts possible from zope.org?
Not in principle. In fact, I would find it convenient for a particular project. I doubt that anyone with access to that machine has time, \ although I can only speak for myself. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Not in principle. In fact, I would find it convenient for a particular project. I doubt that anyone with access to that machine has time, \ although I can only speak for myself.
If I could get access, I'd make time ;-) I think I used to have it, and I may well still do, but I've forgotten what user I should "sudo su -" to in order to be able to do stuff with Apache... What should I be trying? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (7)
-
Chris Withers -
Jim Fulton -
Mark Hammond -
Martijn Pieters -
Rocky Burt -
Tino Wildenhain -
Tres Seaver