| 2006-10-22 16:37:08 |
John A Meinel |
bzr: statusexplanation |
|
This is simply because bzr does not version anything but the executable bit. And in the short term, there is no plans to version more than that.
It is *possible* to do more, but past experience with other systems (Arch) means that it usually causes more problems than not when versioning source code. (If your mask is not my mask, then commits tend to ping pong back and forth).
For versioning $HOME or /etc, it *is* useful to version strict permissions, and possibly even user and group. But for most source code, it is not useful.
So for now, bzr is focused on versioning source code. Versioning detailed file modes and user/group info should be possible without too much extra effort, and if someone wants to write a plugin to do so, we are willing to help a little bit, and give pointers as to what it would take. |
|
| 2007-06-25 11:28:14 |
Jonathan Knowles |
description |
In order to understand the problem, a little context may be neccessary: Yesterday, I decided to put my home directories on different workstations (ws2 and ws2 for simplicity) under version control to keep them in sync and [insert VCS merits here]. To start the repos off with a common ancestry, I first created an *empty* revision of my home directory.
ws1:~$ bzr init
ws1:~$ bzr commit --unchanged
The versioning information was then tarred, scp'ed to the remote ws2 and untarred. Getting curious of bzr's DVCS functionality, I tried merging my awfully diverging Gaim configurations on both machines:
ws1:~$ bzr add .gaim && bzr commit
ws2:~$ bzr add .gaim && bzr commit
ws1:~$ bzr merge --remember sftp://daniel@ws2:22/
Of course, the merge didn't go so well. bzr left me with both .gaim (the ws2 one) and a .gaim.moved (the ws1 one). Files that had existed in both working trees now lay in .gaim and .gaim.moved, respectively -- no .BASE, .THIS, etc. file quartet.
Now, to get to the point: What really struck me is that permissions of files in .gaim were not preserved, but set according to my ws1 umask (0022). A grave situation, considering that my conversation logs, buddy list, gaim-encryption private keys and so on were world-readable. The permissions in .gaim.moved, however, were not touched.
I'd consider this a security vulnerability, but am going to wait for feedback before tagging it as such. Versions used: Debian bzr-0.10-1 on ws1, Ubuntu bzr-0.8.2-1ubuntu3 on ws2. If you need further info, I'll do my best to provide it. |
In order to understand the problem, a little context may be neccessary: Yesterday, I decided to put my home directories on different workstations (ws1 and ws2 for simplicity) under version control to keep them in sync and [insert VCS merits here]. To start the repos off with a common ancestry, I first created an *empty* revision of my home directory.
ws1:~$ bzr init
ws1:~$ bzr commit --unchanged
The versioning information was then tarred, scp'ed to the remote ws2 and untarred. Getting curious of bzr's DVCS functionality, I tried merging my awfully diverging Gaim configurations on both machines:
ws1:~$ bzr add .gaim && bzr commit
ws2:~$ bzr add .gaim && bzr commit
ws1:~$ bzr merge --remember sftp://daniel@ws2:22/
Of course, the merge didn't go so well. bzr left me with both .gaim (the ws2 one) and a .gaim.moved (the ws1 one). Files that had existed in both working trees now lay in .gaim and .gaim.moved, respectively -- no .BASE, .THIS, etc. file quartet.
Now, to get to the point: What really struck me is that permissions of files in .gaim were not preserved, but set according to my ws1 umask (0022). A grave situation, considering that my conversation logs, buddy list, gaim-encryption private keys and so on were world-readable. The permissions in .gaim.moved, however, were not touched.
I'd consider this a security vulnerability, but am going to wait for feedback before tagging it as such. Versions used: Debian bzr-0.10-1 on ws1, Ubuntu bzr-0.8.2-1ubuntu3 on ws2. If you need further info, I'll do my best to provide it. |
|
