vfs accessible branches can have content subverted by users with write access - not possible to restrict to append_only + push/pull verbs only
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Triaged
|
Medium
|
Unassigned |
Bug Description
Hi,
while trying to get https:/
Any member of the revu-team can delete the bzr-files directly via sftp://<launchpad-
As an example, I've overwritten https:/
While this may not be problematic for locked teams with known/trusted members, it's quite problematic for our spec, since the revu-team should be open to any contributor.
Ideally it would only be possible to commit a new revision to the hosted branch. Any other solution that would give us at least the possibility to restore the package data in case an attacker overwrites it would also do. Any suggestions?
P.S.: I hope I've filed the bug against the right product.
Thanks in advance,
Stefan.
description: | updated |
Changed in bzr: | |
status: | New → Incomplete |
tags: | added: check-for-breezy |
I'm not sure what you are asking for.
Leaving aside the current SFTP protocol attacks, once we have a smart server members of your group can still do 'bzr checkout --lightweight URL; bzr uncommit -r 0' and remove all the commits. In current formats that is relatively easy to recover from, but thats due to a lack of garbage collection more than deliberate intent.
There seem to be two concerns: data loss, and injection of bad data. On the bad data side, use gpg signed commits - thats what they are there for,
On the data loss side, well its a distributed system :). I realise that doesn't help a lot - but let me ask, why are you letting folk you dont know *at all* into the team? Is it so that they can commit to these branches? or so they can read them? If you dont know them at all, why not encourage them to put up their own branches, branched off the MOTU ones?