Re: Some thoughts on a new publication approach

On Monday, October 21, 2013 at 8:23 PM, Robin Berjon wrote:

> On 21/10/2013 18:30 , Tobie Langel wrote:
> > On Monday, October 21, 2013 at 4:26 PM, Robin Berjon wrote:
> > > At FPWD, a static snapshot is also made. I say static because I'm
> > > assuming that systems like ReSpec that generate things on the
> > > client side become accepted in TR, for non-snapshots. Basically,
> > > FPWD (and the other snapshot points) are *not* git SHAs. History
> > > can be rewritten in git, which can be defended against but would be
> > > annoying. Instead they really are snapshot exports of the repo.
> > > This also makes generating static versions easier.
> > 
> > 
> > 
> > I'm not sure I understand the attack vector you're describing here,
> > nor why it wouldn't be easy to defend against it. Exporting the whole
> > repo for every release seems to be both an annoyance to setup and an
> > important feature loss (I'd love to have tags of each different
> > maturity level bundled together when cloning the repo.
> 
> 
> 
> Well, it's not necessarily an attack vector in that it may not be 
> malicious. But unless I've misunderstood some part of git (which is 
> certainly possible), what I'd like to avoid is the following:
> 
> 1) User edits spec in git, does all sorts of things.
> 2) Group likes it, pushes it to FPWD.
> 3) FPWD is recorded as being SHA deadb33f.
> 4) User realises that in one of the earlier commits, she added her 
> password to a file in the repository. The file can't just be changed, it 
> needs to be fully expunged. Ooops!*
> 5) User runs git filter-branch --tree-filter 'rm -f passwords.txt' HEAD
> 6) Every single commit has now changed. There is no longer any deadb33f 
> for FPWD to point to. We've broken the PP.
> 
> At least, I'm pretty sure that that's possible.
This seems like an extreme, and pretty far fetched, case - IMO.

Received on Monday, 21 October 2013 19:32:18 UTC