You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Bryce Schober <br...@dpzone.com> on 2003/09/18 00:19:58 UTC
Revisions graph?
I've been snooping around here a while, I'm a current cvsnt user/admin.
I like the looks of subversion, and I haven't actually tried the gui
clients yet, but one of our favorite features of wincvs around here is
the history graph. Do any of the subversion clients have or plan to add
such a feature in the near future? Which subversion clients offer the
most macro / customization support?
Thanks,
- Bryce Schober
---
[This E-mail scanned for viruses by digiposs.com]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Revisions graph?
Posted by cm...@collab.net.
Kirby Bohling <kb...@birddog.com> writes:
> > Should be much, *much* easier to write than cvs2svn script we have
> > now. No need to "deduce" changesets or branches or tags at all.
>
> That's not really what I meant; however, it's not a bad idea,
> especially as it's a two birds for one stone deal in the short term. I
> meant how hard would it be to write a tool that creates the data
> structures that make the problem easy (which you answered: not nearly as
> hard as cvs2svn).
Well, I'll tell you when I'm finished writing it (I've had code in
progress to do this for quite some time now, but life is busy, ya know?)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Revisions graph?
Posted by Kirby Bohling <kb...@birddog.com>.
On Wed, 2003-09-17 at 23:28, Ben Collins-Sussman wrote:
> Kirby Bohling <kb...@birddog.com> writes:
>
> > To state the obvious: how hard would it be to write a program that reads
> > the svn dump files and build the indexes "the RCS way"? That would seem
> > the obvious approach to do this.
>
> Well, um... you're describing a svn2svn script. Convert an SVN
> dumpfile into a genuine CVS repository. Then let WinCVS display RCS
> history all it wants!
>
> Should be much, *much* easier to write than cvs2svn script we have
> now. No need to "deduce" changesets or branches or tags at all.
That's not really what I meant; however, it's not a bad idea,
especially as it's a two birds for one stone deal in the short term. I
meant how hard would it be to write a tool that creates the data
structures that make the problem easy (which you answered: not nearly as
hard as cvs2svn).
When I said "RCS Way", organizing the data so it is like this
node: { set of revisions the node changes in },
....
node: { set of revisions the node changes in }
instead of the "SVN Way"
revision: { set of nodes changed in a given revision },
...
revision: { set of nodes changed in a given revision }
Sorry for the rough analogy, and crappy "diagram", I know the
subversion diagram should be more complex. To the best of my
understanding that is the crux of the problem.
My concern about running svn2cvs, then WinCVS would be simple stuff
like, file moves being lost, directory moves being lost. The meta-data
that svn captures that would be lost in the conversion to back cvs.
However, from your description, if you had the svn2cvs and the WinCVS
display history code, you might be able to jigger them together so the
meta-data svn has isn't lost.
Of course, displaying the history could be tricky, because do you
display the history by following the node history, or the history by
following the path history. I hate that complexity about SCM problems,
it makes everything more so much harder. Oh well, I get well ahead of
myself thinking further then I'm ever going to code.
Kirby
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Revisions graph?
Posted by Ben Collins-Sussman <su...@collab.net>.
Kirby Bohling <kb...@birddog.com> writes:
> To state the obvious: how hard would it be to write a program that reads
> the svn dump files and build the indexes "the RCS way"? That would seem
> the obvious approach to do this.
Well, um... you're describing a svn2svn script. Convert an SVN
dumpfile into a genuine CVS repository. Then let WinCVS display RCS
history all it wants!
Should be much, *much* easier to write than cvs2svn script we have
now. No need to "deduce" changesets or branches or tags at all.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Revisions graph?
Posted by Kirby Bohling <kb...@birddog.com>.
On Wed, 2003-09-17 at 19:28, Ben Collins-Sussman wrote:
> Bryce Schober <br...@dpzone.com> writes:
>
> > I've been snooping around here a while, I'm a current cvsnt
> > user/admin. I like the looks of subversion, and I haven't actually
> > tried the gui clients yet, but one of our favorite features of wincvs
> > around here is the history graph.
>
> This graph would be nearly impossible to produce in Subversion. The
> WinCVS graph, IIRC, shows every version of a file, and a list of every
> tag or branch that each version is part of. It's basically a visual
> representation of the RCS file format.
>
> Subversion indexes data "the other way". The only way to discover all
> the tags/branches that a specific version of a file lives in ... is by
> brute-force searching. This is a side effect of global revisions and
> all the node-sharing between revision trees. The trade-off, of
> course, is constant-time creation of tags and branches.
To state the obvious: how hard would it be to write a program that reads
the svn dump files and build the indexes "the RCS way"? That would seem
the obvious approach to do this.
Thanks,
Kirby
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Revisions graph?
Posted by Daniel Patterson <da...@adaptiveinternational.com>.
On Thu, 2003-09-18 at 10:28, Ben Collins-Sussman wrote:
> This graph would be nearly impossible to produce in Subversion. The
> WinCVS graph, IIRC, shows every version of a file, and a list of every
> tag or branch that each version is part of. It's basically a visual
> representation of the RCS file format.
Attached are a couple of python scripts that I wrote a while back
but never ended up using for anything.
These scripts browse a repository that is in the standard layout
(actually, they barf if these dirs don't exist):
/tags
/branches
/trunk
They build up the copy history of each branch/tag and spit out
some "heirachical" data. The XML script spits out an xml document
that looks somewhat like:
<branch name="trunk">
<start>2001-01-01</start>
<tag name="0.1.0" rev="84"/>
<tag name="0.2.0" rev="93"/>
<tag name="0.3.0" rev="104"/>
<tag name="0.4.0" rev="125"/>
<branch name="0.4_maint"
<tag name="0.4.1" rev="129"/>
</branch>
<tag name="0.5.0"/>
</branch>
It's not ideal, and it's missing some information (such as
branch source, i.e., I wanted it to do:
<tag name="0.1.0" rev="84">
<branch name="0.1_maint" startrev="87" endrev="99">
<tag name="0.1.1" rev="93"/>
<tag name="0.1.2" rev="98"/>
</branch>
</tag>
but I never had enough time.
The "branchtograph.py" script is a copy of the above, but instead,
it spits out GraphViz "dot" files that can be passed to "dot" to
produce a graphical representation of the branches.
I stopped working on it quite some time ago, I don't think the
python API that it worked against exists any more, but it
only took a couple of hours, so probably wouldn't be too hard
for someone who knew the API well to reproduce.
daniel
Re: Revisions graph?
Posted by Ben Collins-Sussman <su...@collab.net>.
Bryce Schober <br...@dpzone.com> writes:
> I've been snooping around here a while, I'm a current cvsnt
> user/admin. I like the looks of subversion, and I haven't actually
> tried the gui clients yet, but one of our favorite features of wincvs
> around here is the history graph.
This graph would be nearly impossible to produce in Subversion. The
WinCVS graph, IIRC, shows every version of a file, and a list of every
tag or branch that each version is part of. It's basically a visual
representation of the RCS file format.
Subversion indexes data "the other way". The only way to discover all
the tags/branches that a specific version of a file lives in ... is by
brute-force searching. This is a side effect of global revisions and
all the node-sharing between revision trees. The trade-off, of
course, is constant-time creation of tags and branches.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Authentication - storing of passwords in ~/.subversion/auth/svn.simple
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
Hi.
On Fri 2003-09-19 at 11:26:37 +0200, you wrote
> Hi David and List....
>
> > Which mechanism of 'encryption' would you suggest? rot13? base64
> encoding?
> Well an encryption which at its best can only be read by svn client to
> decode it back in clear to send it to apache. I know that someone capable
> enough to program can extract the algorithm out of the sources and decrypt
> the password by then.
David already addressed this, but maybe it came not over clear enough.
No need to be very capable, extract any algorithms or such: If you can
compile subversion, everything needed is one printf statement after
the part when the password has been decoded and a recompile. Even most
non-programmers are able to do this.
> The 'encryption' should be strong enough to hide the real password
> from human eyes by just opening a file in the editor, especially
> when your authentication mechanism you use in apache reads users
> data from a global authentification mechanism where you only have
> one unique password for everything. If it is detectable by just
> knowing where to find a single file the whole security is gone.
Well, even if the file was encrypted, there never was any real
security. Just some easy-to-be-broken obscurity.
How strong the encryption is, doesn't change the work for the
attacker, because he doesn't attack the encrypted file, but simply
decrypts it with the readily available algorithm and key from the
subversion source. Any security measure is only as strong as it's
weakest link. And in this case it's the accessibility of the file.
So, encryption doesn't help at all, except for one thing: it has do be
an intentional attack. Someone just glancing over the file, wouldn't
see the password. And that can be as easily be archieved by some
simple encoding mechanism, like base64, as David explained.
That was also why he went on to suggest to rely on filesystem
security. It is a lot safer, because it requires an attacker to obtain
at least root privileges, instead of just recompiling a program.
> > My suggestion is to rely on filesystem-level security to protect
> > the password files. If you want to defend against really stupid
> > attackers who don't know how to do google searches, promote base64
> > [...] If you cannot rely on filesystem-level security, don't
> > store passwords to disk.
>
> In my eyes you cannot rely on that...
Well, then the answer is clear: don't store passwords on disk.
This is not a new kind of problem. Security experts have discussed for
years how to protect data, that is meant to be processed without user
interaction, and there is no holy grail in sight[1]. Usual advice is
what David said: use the permission system of your OS.
[1] Another typical application of this are scripts for web sites
which shall access a database with sensitive information. Anybody
getting control of the scripts, also obtains the means to access the
sensitive database.
[...]
> But even you imagine the fs level security is working, this will not
> "defend" a user who has root-access to the machine.
If you cannot trust the root user on the machine to leave your files
alone, you should not store/process *any* sensitive data on that
machine.
> He can read the file regardlessly of the permissions and so can get
> the cleartext password, which is elsewise completely hidden to
> him.
Completely hidden is a bit of a overstatement. As I said, just a
one-line change and a recompile... Yes, it protects against the casual
bystander, as mentioned above.
> When it is encrpyted in some way the burden to him to get it
> cleartext is much higher. I still suggest to encrypt the stored
> passwords, even I can understand your (David) points.
If you meant someone "getting" root: Well, that usually requires a
more effort than recompiling some program. Also, I only need a one
time access to the file, to copy it away, and then have as much time
as I want to crack it (although adding the printf can be done quickly,
the compile may take a while ;-).
> > (Sorry if this came off as a rant, this same thread has come up three
> > times now this week on different mailing lists I subscribe to. Believe
> > it or not, I edited this post down... twice.)
> Ooops.. I just browsed very fast over the subversion users mailinglist and
> couldn't find an appropriate thread. Didn't want to hit a wound point.
I think he didn't meant the Subversion list, but other lists.
> Roland, who is not wanting to start an ideologic war here, just
> noticing a (in my eyes) security design flaw.
Well, this is a thing that may often perceived as flaw, but isn't one.
Having the password stored on disk brings a certain risk. But it only
would be a flaw, if storing the password as plaintext would cause the
risk to be (significantly) larger.
Another one of that kind (perceived flaws) is a world-readable file
within a protected directory. There is absolutely no more risk as with
an protected file, it only got changed finally, because the develit got
reported often.
In fact, I would even like to veto against introducing such an
(effectively pseudo-) encryption, because it provides a false sense of
security. The current behaviour had the right effect for you: you
realized that safing the file on disk is a risk which you are
seemingly not willing to take.
Would you have noticed that, too, if the file had used some simple
encoding?[2]
Regards,
Benjamin.
[2] I hope I could convince you that in this case encryption does not
has any merit over some encoding, as long as the encoding cannot
easily deciphered by humans without tools (that's why I didn't
suggest rot13, which is too easy to read).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Authentication - storing of passwords in ~/.subversion/auth/svn.simple
Posted by Jan Evert van Grootheest <j....@euronext.nl>.
Roland,
In unix land it is not so uncommon to rely on the filesystem. For
example, fetchmail uses a .fetchmailrc file in the users' home directory
and contains the usernames and matching passwords for all mail (s)he
wants to retrieve. Fetchmail actually refuses to work if this file has
the wrong permissions.
In your situation I also don't understand the problem.
If samba exports the homes, then the user logged into windows can access
only his own home directory. If it is different, I'd say samba can be
reconfigured to provide the proper protection.
Something like this should do the trick in smb.conf (from the example
configuration):
[homes]
comment = Home Directories
browseable = no
writable = yes
valid users = %S
create mode = 0664
directory mode = 0775
-- Jan Evert
Roland Schwingel wrote:
>
>
>
> Hi David and List....
>
>
>>Which mechanism of 'encryption' would you suggest? rot13? base64
>
> encoding?
> Well an encryption which at its best can only be read by svn client to
> decode it back in clear to send it to apache. I know that someone capable
> enough to program can extract the algorithm out of the sources and decrypt
> the password by then. The 'encryption' should be strong enough to hide the
> real password from human eyes by just opening a file in the editor,
> especially when your authentication mechanism you use in apache reads users
> data from a global authentification mechanism where you only have one
> unique password for everything. If it is detectable by just knowing where
> to find a single file the whole security is gone.
>
>
>>My suggestion is to rely on filesystem-level security to protect the
>>password files. If you want to defend against really stupid attackers
>>who don't know how to do google searches, promote base64 - this is what
>>the vast majority of 'encrypted' passwords for network-enabled apps are,
>>because they still have to 'decrypt' to plaintext. If you cannot rely on
>>filesystem-level security, don't store passwords to disk.
>
> In my eyes you cannot rely on that... Eg (like here) you have a linux box
> with the users homeaccounts and samba to share the filesystem to the
> clients and you use subversion on cygwin you are running very fast in
> exactly this situation. The auth and/or .subversion folder and their
> contents created by svn have 755 permissions on the linux box, so everyone
> can read them (This is a cygwin<->samba problem). You need to chmod at
> least the auth folder from the linux machine to protect the password.
> But even you imagine the fs level security is working, this will not
> "defend" a user who has root-access to the machine. He can read the file
> regardlessly of the permissions and so can get the cleartext password,
> which is elsewise completely hidden to him. When it is encrpyted in some
> way the burden to him to get it cleartext is much higher. I still suggest
> to encrypt the stored passwords, even I can understand your (David) points.
>
>
>>(Sorry if this came off as a rant, this same thread has come up three
>>times now this week on different mailing lists I subscribe to. Believe
>>it or not, I edited this post down... twice.)
>
> Ooops.. I just browsed very fast over the subversion users mailinglist and
> couldn't find an appropriate thread. Didn't want to hit a wound point.
>
> Roland, who is not wanting to start an ideologic war here, just noticing a
> (in my eyes) security design flaw.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Authentication - storing of passwords in ~/.subversion/auth/svn.simple
Posted by Ben Collins-Sussman <su...@collab.net>.
Roland Schwingel <Ro...@onevision.de> writes:
> Roland, who is not wanting to start an ideologic war here, just noticing a
> (in my eyes) security design flaw.
There's no security flaw here; this has been discussed many times in
the past. ~/.subversion/auth/ is set to chmod 700. That means no
spying eyes can look at your cached cleartext passwords.
If you don't want the caching to happen at all, just set
[auth]
store-password = no
...in your ~/.subversion/config file. End of story.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Authentication - storing of passwords in ~/.subversion/auth/svn.simple
Posted by Roland Schwingel <Ro...@onevision.de>.
Hi David and List....
> Which mechanism of 'encryption' would you suggest? rot13? base64
encoding?
Well an encryption which at its best can only be read by svn client to
decode it back in clear to send it to apache. I know that someone capable
enough to program can extract the algorithm out of the sources and decrypt
the password by then. The 'encryption' should be strong enough to hide the
real password from human eyes by just opening a file in the editor,
especially when your authentication mechanism you use in apache reads users
data from a global authentification mechanism where you only have one
unique password for everything. If it is detectable by just knowing where
to find a single file the whole security is gone.
> My suggestion is to rely on filesystem-level security to protect the
> password files. If you want to defend against really stupid attackers
> who don't know how to do google searches, promote base64 - this is what
> the vast majority of 'encrypted' passwords for network-enabled apps are,
> because they still have to 'decrypt' to plaintext. If you cannot rely on
> filesystem-level security, don't store passwords to disk.
In my eyes you cannot rely on that... Eg (like here) you have a linux box
with the users homeaccounts and samba to share the filesystem to the
clients and you use subversion on cygwin you are running very fast in
exactly this situation. The auth and/or .subversion folder and their
contents created by svn have 755 permissions on the linux box, so everyone
can read them (This is a cygwin<->samba problem). You need to chmod at
least the auth folder from the linux machine to protect the password.
But even you imagine the fs level security is working, this will not
"defend" a user who has root-access to the machine. He can read the file
regardlessly of the permissions and so can get the cleartext password,
which is elsewise completely hidden to him. When it is encrpyted in some
way the burden to him to get it cleartext is much higher. I still suggest
to encrypt the stored passwords, even I can understand your (David) points.
> (Sorry if this came off as a rant, this same thread has come up three
> times now this week on different mailing lists I subscribe to. Believe
> it or not, I edited this post down... twice.)
Ooops.. I just browsed very fast over the subversion users mailinglist and
couldn't find an appropriate thread. Didn't want to hit a wound point.
Roland, who is not wanting to start an ideologic war here, just noticing a
(in my eyes) security design flaw.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Authentication - storing of passwords in ~/.subversion/auth/svn.simple
Posted by David Waite <ma...@akuma.org>.
Roland Schwingel wrote:
>
>
>Hi....
>
>As of the fact being back from honeymoon, I started out again to migrate my
>CVS to SVN. I updated to 0.29 and added authentication to httpd for svn.
>This works very well...
>
>BUT: I encountered that subversion client stores my passwords in
>*CLEARTEXT* in ~/.subversion/auth/svn.simple/<some_file>. This is IMHO not
>so nice. Storing of passwords is ok, so that it can remember it for
>subsequent use, but it should encrypt the stored password in someway that
>only subversion can use it again...
>
>
Which mechanism of 'encryption' would you suggest? rot13? base64 encoding?
The password can be 'disguised', but anything the subversion program can
do to undesguise the password, someone with access to the .subversion
directory and subversion binary can do as well. The cleartext password
is required for plain authentication.
The only feasable 'secure' mechanism would be to require HTTP digest
authentication, and to store the A1 digest instead of plaintext
password. Even then, someone with access to your .subversion directory
could use that digest to log onto servers listed in your password cache.
My suggestion is to rely on filesystem-level security to protect the
password files. If you want to defend against really stupid attackers
who don't know how to do google searches, promote base64 - this is what
the vast majority of 'encrypted' passwords for network-enabled apps are,
because they still have to 'decrypt' to plaintext. If you cannot rely on
filesystem-level security, don't store passwords to disk.
(Sorry if this came off as a rant, this same thread has come up three
times now this week on different mailing lists I subscribe to. Believe
it or not, I edited this post down... twice.)
-David Waite
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Authentication - storing of passwords in ~/.subversion/auth/svn.simple
Posted by Roland Schwingel <Ro...@onevision.de>.
Hi....
As of the fact being back from honeymoon, I started out again to migrate my
CVS to SVN. I updated to 0.29 and added authentication to httpd for svn.
This works very well...
BUT: I encountered that subversion client stores my passwords in
*CLEARTEXT* in ~/.subversion/auth/svn.simple/<some_file>. This is IMHO not
so nice. Storing of passwords is ok, so that it can remember it for
subsequent use, but it should encrypt the stored password in someway that
only subversion can use it again...
Have I overseen something in config or is it missing??? It it is missing it
should IMHO be added...
What can I do to prevent storing my password in cleartext? (except
disabling storing it) in ~/.subversion/config?
Thanks for your help...
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org