Comment 0 for bug 67589

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.