Hi Markus,
thanks for all your advices.
Your thoughts are convincing me in my own analysis, that SVN for this
approach is not the best idea.
Our situation is not critical and this discussion was very useful.
Thanks,
Rado
On Tue, May 24, 2011 at 13:47, Markus Schaber <m.schaber_at_3s-software.com> wrote:
> Hi, Rado,
>
> Ah, now I see. The file is actually encrypted with a password, and you want to prevent older versions of the file to leak whenever the password is compromised.
>
> In this case, I really think that svn is not the right tool for the job, as the whole purpose of existence of version control is to keep old versions available.
>
> To clean up, you can use "svnadmin" dump, "svndumpfilter" and "svnadmin load" to recreate the repository without the file in question.
>
> But be aware that the same problem also exists for all other locations where this file is or was ever stored, e. G. the Server where the repository (and its mirrors) stored, all existing working copies of your svn repository which were not yet updated to the current version, all temp directories where the repository (or dumps of the repo) or working copies were stored or processed, old backup tapes or disks, copies on USB sticks which are lingering around in some drawer in the desk, and in the not-yet overwritten sectors of your disk even after the file was deleted.
>
> In some file systems, even overwriting the file does not destroy the contents reliably when data journaling is on. The same is true on a lower level for flash based devices which utilize wear leveling - the data may be inaccessible using the controller interface, but can still be recovered by raw access to the flash chip.
>
> Not to mention the spool folders of all involved mail servers or web proxies, when this file was ever transferred via Web or HTTP, or malicious persons which intentionally keep old versions of the file available just for the case the password ever leaks...
>
> This is definitely NOT a complete security analysis, I just wanted to show that the old versions in the SVN repository are not the only hole you may have to plumb.
>
> HTH,
> Markus
>
>> -----Ursprüngliche Nachricht-----
>> Von: [radoo] [mailto:ondas.radovan_at_gmail.com]
>> Gesendet: Dienstag, 24. Mai 2011 13:27
>> An: Markus Schaber
>> Cc: users_at_subversion.apache.org
>> Betreff: Re: SVN - restriction to checkout only the latest version
>>
>> Hi Markus,
>>
>> >> I have a question whether subversion has possibility to allow
>> >> checkout only the latest version of the repository.
>> >
>> > No.
>>
>> OK, then my research is confirmed. it would be against basic design and
>> idea of repositories in general.
>>
>> >> My idea is (due to security) to allow only access only to the latest
>> >> revision of the file stored in subversion repository.
>> >
>> > My gut feeling is that if you try to base security on an assumption
>> > like this, something in your security design is fundamentally broken.
>> >
>> >> Or is there an option to set which would tell to keep only the latest
>> >> version or last 10 versions?
>> >
>> > You can either dump the repository from that revision, and then build
>> > a new repository from the dump. Maybe svndumpfilter can also help.
>> >
>> > If your problem is that you accidentally committed some files into the
>> > repository which should not be seen by anyone, that your problem could
>> > be solved by an action like that.
>> >
>> > Maybe you try to describe us the problem you want to solve, and then
>> > we can help you to find a (better) solution?
>>
>> Right, I fully understand.
>> To explain the reason for my strange questions.
>> There was a need to store file with main password set for the file.
>> SVN was chosen because there was no need to setup another tool and also
>> all person who need to access the file has already access to SVN.
>> Therefore to create a simple repository was a matter of a few minutes.
>> So far so good. But later a question came up what will happen if the main
>> password will be compromised. You will change the password and commit new
>> version. But SVN has 'nice' option to checkout also older versions of the
>> file, where the old main password would be still valid and your content is
>> not protected.
>>
>> So, in the end it looks like not a good idea to store such files in SVN
>> unless there are other possibilities. Sure I'm aware of users and
>> permissions for SVN, but this would bring another layer of complexity to
>> the design of the environment. The user is asked for the password already
>> once before.
>>
>> We will also think of better tool to store the file with better way to
>> setup security. :)
>>
>> Thanks,
>>
>> Rado
> [> ]
>
>
> Best regards
>
> Markus Schaber
>
> ___________________________
> We software Automation.
>
> 3S-Smart Software Solutions GmbH
> Markus Schaber | Developer
> Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
>
> Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
> CoDeSys internet forum: http://forum.3s-software.com
> Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
>
> Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
>
Received on 2011-05-24 14:35:31 CEST