Re: Some thoughts on a new publication approach

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. It is possible that when 
history is rewritten, tags are preserved in such a way that if we had a 
special syntax to name tags with it could be maintained. But I don't 
like that because:

   • Only the W3C Team should be able to mark a release (otherwise 
people can go off and break the PP, even if they mean no harm). So a 
system based on tagging would have to be supported at the W3C end, 
probably with signed tags (which git does support).
   • This involves the ability to push changes back to the origin (if 
the tag is meant to be shared, which you seem to want). I'd rather keep 
the W3C side read-only. Having write-back ability complicates the 
auto-update code substantially.
   • It just strikes me as an awful lot simpler to have the Web 
interface to TR be able to export a tree.

Note that "exporting the whole repo for every release" is neither "an 
annoyance to setup" nor "an important feature loss". There can be as few 
as three releases for a spec, and I would expect the export to be 100% 
automated with something like git archive $branch_you_want | tar -x -C 
/path/to/FPWD/snapshot. And if you want to tag, tag!


* I categorically deny this being based on a real life scenario. Any 
resemblance to someone being very, very stupid on this account is purely 
incidental.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Monday, 21 October 2013 19:23:47 UTC