[darcs-users] Re: signing of patches

[Karel Gardas]

 Mon, 6 Dec 2004, David Roundy wrote:

> On Sat, Dec 04, 2004 at 10:08:27PM +0100, Karel Gardas wrote:
> > On Sat, 4 Dec 2004, David Roundy wrote:
> > > In fact, separately signing the inventory and patch files gives us no
> > > security whatsoever, since someone could then craft a repository out of
> > > combinations of the signed (by me) patches and inventories of the darcs and
> > > darcs-unstable repositories and thus create a corrupt repo.  It would be a
> > > pain to do this in a way that introduces a security hole, but it would be
> > > possible.  And it would be very easy to simply introduce corruption into
> > > the system, which would be enough to be very annoying.
> >
> > Sorry, I completelly do not understand how is it possible? How is it
> > possible to "combine" various patches from various repositories with
> > various inventories all files signed by their authors? my thinking about
> > it is that every commit to any repo is just "verification/consistent
> > point", so basically you have a lot of those verification points, but I
> > don't see _any_ way how to create another verification points in the way
> > that you don't need to sign anything (especially inventory).
>
> The problem is that patch contents are changed even in the absence of
> conflicts.  The line numbers a patch applies to depend on what patches have
> been previously applied--that is, the context.

Ah, yes, now I see. OK, in my proposal this will require to re-sign
changed patch contents by merge person.

> I have two repositories darcs-stable, and darcs-unstable.  Say they both
> have the patch:
>
> Sat Dec  4 10:01:12 EST 2004  David Roundy <droundy at abridgegame.org>
>   * add critical security check
>
> In darcs-stable the contents of this (leaving out patch identity headers)
> might be:
>
> hunk ./Apply.lhs 40
> +                    when (nasty situation) $
> +                        fail "This would be a security hole."
>
> In darcs-unstable, it might be:
>
> hunk ./Apply.lhs 70
> +                    when (nasty situation) $
> +                        fail "This would be a security hole."
>
> because perhaps there were 30 lines of documentation added to the beginning
> of this file in darcs-unstable before this security fix was introduced.
>
> If only the contents of the patches were signed, an attacker could use the
> signed patch from darcs-unstable along with everything else from
> darcs-stable to create a signed (by me) repository that has the security
> fix (perhaps) embedded in the documentation, where it won't do much good.
> Or even worse, it might be embedded in code in a place where it'll
> compile.

Interesting attack indeed! To prevent this kind of attack we will just
need to change inventory format to also include SHA1 of patches or perhaps
better to invent some kind of security context file and sign this.

> > > But if we modify your idea only be making the signatures of the patches be
> > > "patch bundle signatures", we could create the patch bundles on the fly and
> > > then verify the signature.
> >
> > I'm afraid I don't understand. Could you please be so kind and explain me
> > it a bit more? The best would be some example what would you sign, what
> > not and how will we check consistency.
>
> Okay.  Here's an example patch file
>
> BEGIN
> [Update copyright notice
> Ian Lynagh <igloo at earth.li>**20040314015321] {
> hunk ./SHA1.lhs 1
> -Copyright (C) 2001 Ian Lynagh <igloo at earth.li>
> +Copyright (C) 2001, 2004 Ian Lynagh <igloo at earth.li>
> }
> END
>
> This is insufficient for purposes of signing, since it doesn't tell us what
> the context of this patch is.  Although I don't see how a replay attack
> could be used to turn *this* patch into a security hole...
>
> The corresponding "patch bundle" would be
>
> BEGIN
> New patches:
>
> [Update copyright notice
> Ian Lynagh <igloo at earth.li>**20040314015321] {
> hunk ./SHA1.lhs 1
> - -Copyright (C) 2001 Ian Lynagh <igloo at earth.li>
> +Copyright (C) 2001, 2004 Ian Lynagh <igloo at earth.li>
> }
>
> Context:
>
> [add mention of darcs working on windows to web page.
> David Roundy <droundy at abridgegame.org>**20040314130320]
> [win32 fix: retrieve exit code of the gzip thread
> trivee at noir.crocodile.org**20040313003946]
>
>
> (cut about four hundred lines...)
>
>
> [remove unnecesary fixregex function from RepoPrefs.
> David Roundy <droundy at abridgegame.org>**20040221172930]
> [TAG 0.9.17
> David Roundy <droundy at abridgegame.org>**20040221160549]
> Patch bundle hash:
> 97cec2581274e10980cd6c484d132d6e7f51e7a1
> END
>
> Probably I'd just sign the patch bundle hash.

OK, as I understand it now, you would need to create _original_ patch
bundle from perhaps modified patch contents and then verify it by
using patch's signature. Is it ever possible to construct original
patch bundle from patch itself? Also from algorithm complexity point
of view, this looks like O(e^N) complexity, which is IMHO quite high
price for having repository signed, even if we use tags to limit N
size...

If I'm wrong please correct me.

Thanks,
Karel
--
Karel Gardas                  kgardas at objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com