vfs accessible branches can have content subverted by users with write access - not possible to restrict to append_only + push/pull verbs only

[StefanPotyra]

Hi,

while trying to get https://wiki.ubuntu.com/MOTU/Processes/REVU into shape, we came up with a security problem for this process:
Any member of the revu-team can delete the bzr-files directly via sftp://<launchpad-id>@bazaar.launchpad.net/~revu/<product>/ubuntu and can then inject an entirely different branch (also via sftp), clearing out past revisions.

As an example, I've overwritten https://code.launchpad.net/~revu/+branch/tasks/ubuntu (storing the initial branch at http://tiber.tauware.de/~sistpoty/tasks_ubuntu/ubuntu). (please tell me if you don't need this reference attack any longer, as I'll then restore the original version).

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.

[Robert Collins (lifeless)]

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?

[Martin Pool (mbp)]

He seems to be asking for a way to set the append-only flag on the branch, in a way that can't be subverted or reset by people who're allowed to commit to the branch. Aside from the mechanics of implementing that (which is mostly on the Launchpad side), it seems to require a new concept of a branch administrator with more power than the branch owner.

[Jelmer Vernooij (jelmer)]

Reassigning to Launchpad, as it seems the bulk of work would need to happen there in combination with killing VFS requests over bzr+ssh in Bazaar.

[Robert Collins (lifeless)]

Putting back to bzr: this is asking for bzr facilities that don't exist; if/when they exist opening a launchpad task would be reasonable, but the initial changes certainly have to happen in bzr.