Changesets feature complete

[John Arbash Meinel]

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>>> There is another thing that signing the whole changeset gets you. You
>>> can run one pass over it, and verify that the changeset itself is valid
>>> before you do any more work.
> 
> Using the signature as a checksum in other words?  Well, yes, but we
> could use a checksum for that, and we wouldn't need to type our PGP
> passphrases...

Well, (practically) every email I send is wrapped in a GPG signature. So
it is part checksum, and part a small verification that I'm the one
sending the changeset.

> 
>>>> I suppose one thing that signing the changeset would provide would be
>>>> evidence that the changeset itself is not maliciously written (as with
>>>> ActiveX browser plugins).  But changesets aren't supposed to be
>>>> dangerous anyway - it's not like they're an executable format - so
>>>> that's a very limited advantage.
>>> It also makes it easier if you wanted to do the darcs thing of
>>> writing a line in your .procmailrc to automatically apply changesets
>>> that are sent to a particular email address.
> 
> So this is where I say "sign the message, not just the changeset".  Just
> because I signed a changeset, doesn't mean I think *you* should merge it
> into *that* branch.  This is something I think PQM really gets right.

Except right now you can only tell the pqm to 'merge this branch', so if
you add extra commits (or uncommit) before it gets there, the message is
incorrect. :)
So if someone had access to your public branch location, they could
sneak in some extra commits when they notice you make a pqm request.
But that is something we need to fix with the pqm. (Part of the desired
fixes to the pqm and pqm-submit that I started were to submit the
testament sha signatures and revision id of the requested merge)

> 
>>> It also handles the case where I have merged Aaron, but he didn't sign
>>> any of his changes. I don't want to sign each one individually, but
>>> because they are part of history, they need to be included in the changeset.
> 
> But what are you asserting about my revisions?  That they're authentic?
>  How can you be sure?  You know that *your* revisions are authentic, and
> that you trust them, and you're asking someone to merge *your*
> revisions, not mine.

I am asserting that I want the PQM to grab the revisions that I have. I
can't guarantee that they are from Aaron, or that they are perfect, but
I can tell the pqm that they are what I have.

> 
>>> The biggest thing in my mind is that you can do one pass over everything
>>> and just make sure that the text you are about to parse was sent by
>>> somebody who has access to keys that you trust.
> 
> Unless you require the message to be signed, you don't have that
> guarantee.  Having the changeset be signed means that it was *created*
> by someone who has access to keys that you trust, not that they *sent*
> the message or that they think it's a good idea for you to apply it.
> 
> Aaron

I do see your point. And I'm not arguing that
'ChangesetSerializer.write()' should be doing the signing. I think that
'send-changeset' should be the one doing the signing.
Changesets aren't inherently signed, it should done at a higher level.
And like you mention, possibly along with a message saying what should
be done with the changeset (like by pqm-submit).

I realize I was mixing a couple things here. And it might mean that we
should put some sort of checksum at the end of a changeset. So that we
don't go to the expense of parsing it, if it has been munged in transit.
Though I know there is stuff which allows whitespace to be stripped from
the end of lines, so I'm not sure what should be part of the checksum. I
would like something, though.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060526/dfc43b69/attachment.pgp