| 1 |
On Friday 18 January 2008, Robin H. Johnson wrote: |
| 2 |
> On Sat, Jan 19, 2008 at 12:26:44AM +0200, Alon Bar-Lev wrote: |
| 3 |
> > On 1/18/08, Mike Frysinger <vapier@g.o> wrote: |
| 4 |
> > > On Thursday 17 January 2008, Robin H. Johnson wrote: |
| 5 |
> > > > anonvcs.gentoo.org: anoncvs, anonsvn, anongit |
| 6 |
> > > > - Anonymous SVN is changing from http:// to svn:// [1] |
| 7 |
> > > > overlays.gentoo.org [3]: |
| 8 |
> > > > - Anonymous SVN is changing from http:// to svn:// |
| 9 |
> > > |
| 10 |
> > > i'd point out that http:// syncing is usable from behind firewalls |
| 11 |
> > > while svn:// is not ... while this does not affect me personally, it's |
| 12 |
> > > something to keep in mind. |
| 13 |
> > > -mike |
| 14 |
> > |
| 15 |
> > Just wanted to note this too... I am one of the affected ones... |
| 16 |
> > I think that it is very important to have http, and even https for |
| 17 |
> > formal resources. |
| 18 |
> > git://, svn://, rsync:// or ssh+X:// are inaccessible for a large |
| 19 |
> > group of users. |
| 20 |
> |
| 21 |
> My core concern with the SVN http://, was the crappy performance it |
| 22 |
> provided compared to svn://. The main rsync tree has never been |
| 23 |
> available for iterative syncing via http://, just had tarball snapshots |
| 24 |
> and deltas instead. |
| 25 |
|
| 26 |
i'm not suggesting you *not* provide the proper svn:// and git:// ones. i'd |
| 27 |
always use those myself when possible (as performance is a ton better as ive |
| 28 |
seen many times). i'm suggesting we provide both and tell people to use |
| 29 |
svn:// and git://, but if you're behind a stupid firewall, there is also |
| 30 |
http:// available. |
| 31 |
|
| 32 |
> > Also using none secured protocols, exposes users to man-in-the-middle |
| 33 |
> > attacks. |
| 34 |
> |
| 35 |
> The existing http:// had this problem already, it's not a new one. |
| 36 |
> git:// and svn:// do both have patches around adding support for adding |
| 37 |
> TLS. This however just adds overhead, I really need to finish the |
| 38 |
> tree-signing work I was doing, as that protects the content better (MITM |
| 39 |
> is still possible on SSL without it, just a lot harder as an attacker |
| 40 |
> has to deal with the SSL stream first). |
| 41 |
|
| 42 |
using https:// to secure your data here is the wrong way to go. if you have a |
| 43 |
man-in-the-middle attacking you, they can do a lot more than inject crap into |
| 44 |
your syncs, some of which you wouldnt even notice. for the topic at hand, |
| 45 |
this topic does not matter i think. |
| 46 |
-mike |
Archives