[FFmpeg-devel] [RFC] libswscale into the FFmpeg SVN repo

[Christian Iversen]

M?ns Rullg?rd wrote:
> Diego Biurrun <diego at biurrun.de> writes:
> 
>> On Sat, Apr 04, 2009 at 10:00:09PM +0100, M?ns Rullg?rd wrote:
>>> Diego Biurrun <diego at biurrun.de> writes:
>>>
>>>> On Sat, Apr 04, 2009 at 10:25:22PM +0200, Michael Niedermayer wrote:
>>>>> On Sat, Apr 04, 2009 at 09:04:57PM +0200, Diego Biurrun wrote:
>>>>>> On Sat, Apr 04, 2009 at 06:18:14PM +0200, Michael Niedermayer wrote:
>>>>>>> On Sat, Apr 04, 2009 at 05:41:13PM +0200, Christian Iversen wrote:
>>>>>>>> Michael Niedermayer wrote:
>>>>>>>>> i think the way CVS did versioning was more flexible and
>>>>>>>>> powerfull, and no iam not saying the cvs implementation was
>>>>>>>>> good, with its non atomic changes, lack of move&copy
>>>>>>>>> tracking per directory commit mails ...  Fixing the CVS
>>>>>>>>> implementation and storing the file path in the RCS files
>>>>>>>>> instead of storing the RCS files in the path would have made
>>>>>>>>> cvs more powerfull than svn is today. (that is instead of a
>>>>>>>>> tree with the rcs files as leafs, there could be a flat list
>>>>>>>>> of rcs files where each stores where in the tree it is under
>>>>>>>>> which name for each revission or if that revission existed
>>>>>>>>> rather outside of the tree in a difeferent repo) And with a
>>>>>>>>> RCS file upload/download (aka push/pull) cvs could have been
>>>>>>>>> used offline and distributed ...  i never understood why
>>>>>>>>> people droped cvs and started to work on svn that is in
>>>>>>>>> several ways inferrior (less secure, no moving between
>>>>>>>>> repos, database shit, ...)
>>>>>>>> I'm interested, how is it less secure?
>>>>>>> IIRC it is vulnerable to simple off line password bruteforcing if one
>>>>>>> can listen to any svn traffic, and it is vulnerable to man in the
>>>>>>> middle attacks.
>>>>>> How so?
>>>>> no authetication of trafic just cram-md5 password check IIRC
>>>>> did i miss something?
>>>> How would this enable MITM attacks?
>>> The server will not notice if an attacker intercepts the connection
>>> and alters some data after the authentication has succeeded.
>> All you need is an encrypted connection.
> 
> Which the usual svn protocol doesn't provide.

I would argue that the "usual" SVN protocol is https://. And that 
certainly provides it. If you don't want to use that, use svn+ssh://. I 
mean, svn:// is something like a replacement for :pserver: in cvs.

-- 
Med venlig hilsen
Christian Iversen