Forbid uncommits over the network (redux)

Lasse Kliemann lasse-list-bazaar-2009 at mail.plastictree.net
Sun Mar 21 20:30:02 GMT 2010


* Message by -John Arbash Meinel- from Fri 2009-05-08:
> Lasse Kliemann wrote:
> > * Message by -John Arbash Meinel- from Fri 2009-05-08:
> > 
> >> So it would appear that I was wrong. I just checked the code, and
> >> 'append_revisions_only' supersedes '--overwrite'.
> >>
> >> append_revisions_only is actually checked at the time of
> >> 'set_last_revision_info', which is just about as low-level as you can get.
> > 
> > This sounds good so far. However...
> > 
> >> So with the existing bzr clients, you can't override that setting.
> >> (There are ways someone with write access to that file could write a
> >> specific value there, but it would have to be pretty much malicious, and
> >> not accidental in any way.)
> > 
> > Well, I am considering the case of a malicious person gaining 
> > access to the credentials of a committer.
> > 
> > Do I understand correctly that we have a kind of client-side 
> > "security" here, i.e., a setting that should protect the server 
> > and is set on the server (namely 'append_revisions_only') can be 
> > overwritten by an appropriately programmed client?
> 
> 'set_last_revision_info' validates append_revisions_only on the server
> side. However 'bzr+ssh://' currently has what we call "VFS" operations
> (Virtual FileSystem), which means you can effectively 'write' to any
> file that are underneath .bzr/ that you have OS level write access to.
> 
> We have an environment variable BZR_NO_SMART_VFS that can be set to
> disable all VFS access. However ATM there are still a fairly large
> number of simple 'read' accesses that are done via VFS. I'm not sure how
> many write operations remain, though I'm sure that number is dwindling.

Greetings everyone,

it's been almost a year since this discussion. I was pleased to 
notice that Bazaar development reached version 2.1.0, whereas we 
were talking about the 1.x.x series back then.

Have these things changed?

Is it now possible to have a shared repository in which existing 
revisions become immutable once they are committed (provided the 
server is set up properly)?

Thank you!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20100321/1b65d85e/attachment-0001.pgp 


More information about the bazaar mailing list