path: root/44/0efac5a8c95d85f7d230bea079b5c0d2c02a05

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <drak@zikula.org>) id 1VthzK-0008EZ-3W
	for bitcoin-development@lists.sourceforge.net;
	Thu, 19 Dec 2013 18:06:22 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of zikula.org
	designates 74.125.82.44 as permitted sender)
	client-ip=74.125.82.44; envelope-from=drak@zikula.org;
	helo=mail-wg0-f44.google.com; 
Received: from mail-wg0-f44.google.com ([74.125.82.44])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1VthzG-0004n4-Et
	for bitcoin-development@lists.sourceforge.net;
	Thu, 19 Dec 2013 18:06:22 +0000
Received: by mail-wg0-f44.google.com with SMTP id a1so1451326wgh.35
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 19 Dec 2013 10:06:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=fSj1c0U8z7m0oL5ZEZ0nhj8tpVW5GWX2RpX1nb7pZSQ=;
	b=kHdLPQrP0hASyYBC1vH78YlZP70GZvXgRDnCwtPhytSaFN50W/WIZCbnBKlnl8oKR/
	kFJ79KHXBf+OJCBaDOLJ2Ar1mds4dKtFFghC8ZWhw4fPPYcAsqChywwevpdkJXSJ91x8
	SBRyiBPLDwDZHQXkc1QM9+/oHBqaSnXYzWH68QSzjakf8Qbw1MxKE1uhFyWi2L1kznHh
	QEpV5oAWrimfsyhoKhXCYg0sRT7hy07aFDzfYctKABfYPSL10QuYQe67CXQYc5R0UEVG
	WALzaBwR4Ra8VrhjhWaQn1f5UFxQoJ2+XvBoeHzRitPSBT76OL7xyQLWmhU25Vu9oeCi
	6taw==
X-Gm-Message-State: ALoCoQm0nOmwb962LvMeLad0Lbo4uM9Tmt8iC6apVgB4k/+vfMO623k5AgYghMpJwa7w3pETg6IY
X-Received: by 10.194.80.137 with SMTP id r9mr176500wjx.88.1387476372081; Thu,
	19 Dec 2013 10:06:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.93.105 with HTTP; Thu, 19 Dec 2013 10:05:51 -0800 (PST)
In-Reply-To: <20131219174406.GA12740@petertodd.org>
References: <20131219131706.GA21179@savin>
	<dde469d7ce77a748fb4c279334deb643.squirrel@fruiteater.riseup.net>
	<538d3c4677a4332ae8341e37d1a77d5e.squirrel@fruiteater.riseup.net>
	<20131219174406.GA12740@petertodd.org>
From: Drak <drak@zikula.org>
Date: Thu, 19 Dec 2013 18:05:51 +0000
Message-ID: <CANAnSg0e5vRQk9+wG5cxpOPnciBoDfm1AtYRZofJRF49pCsdgQ@mail.gmail.com>
To: System undo crew <unsystem@lists.dyne.org>
Content-Type: multipart/alternative; boundary=047d7bdc8e864ae68504ede704bb
X-Spam-Score: 0.8 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
	See
	http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
	for more information. [URIs: nabble.com]
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.3 URI_HEX URI: URI hostname has long hexadecimal sequence
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1VthzG-0004n4-Et
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Amir Taaki <genjix@riseup.net>
Subject: Re: [Bitcoin-development] [unSYSTEM] DarkWallet Best Practices
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2013 18:06:22 -0000

--047d7bdc8e864ae68504ede704bb
Content-Type: text/plain; charset=UTF-8

How does signing the commit message itself help at all since it just signs
the commit message, not the content of the commit. You could commit some
code then I. Then I squash my commits into yours and use your commit
message. You could also include the previous commit hash in your commit
message.

But correct me if I am wrong, but that would be difficult (if not
impossible) to verify once you get into merging code since the patch can be
merged in at another point in history entirely.. and still doesn't work
because I can still squash commits into yours. I don't see how it can work
at all unless I am missing something obvious (which I fear I may be?).

I also don't believe Linus is talking just from the perspective of how the
kernel project works. The integrity of a git repository is maintained by
the hash chaining and by the distributed nature of the repository. If
someone hacked github and changed the history of the tree, the next time
you tried to push his code up it would fail because the history had changed
- tampering is immediately obvious in git.

Regards,

Drak


On 19 December 2013 17:44, Peter Todd <pete@petertodd.org> wrote:

> On Thu, Dec 19, 2013 at 04:04:17PM -0000, Amir Taaki wrote:
>
> Looks like for this to actually go to the email lists they need to be in
> the To: field.
>
> > About signing each commit, Linus advises against it:
> >
> >
> http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html
> >
> > "Btw, there's a final reason, and probably the really real one. Signing
> > each commit is totally stupid. It just means that you automate it, and
> you
> > make the signature worth less. It also doesn't add any real value, since
> > the way the git DAG-chain of SHA1's work, you only ever need _one_
> > signature to make all the commits reachable from that one be effectively
> > covered by that one. So signing each commit is simply missing the point."
> >
> > What do you reckon?
>
> His point is valid, but it's valid in the context of how Linux
> development is done, not Bitcoin. The key difference being that Linus
> and other kernel developers have a model where code is passed around on
> mailing lists and between developers rather than stored on untrustworthy
> third-parties like github.
>
> For instance typically someone will submit a patch to the kernel
> development mailing list, example:
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg558841.html
> That patch isn't signed, and the email itself doesn't have to be PGP
> signed either. However a trusted maintainer of the relevant subsystem
> will (in theory) look over the patch carefully and commit it to their
> personal tree on a secure computer. (in theory)
>
> At some point the maintainer will create a *signed* tag on a commit with
> one or more patches, often many patches, another another maintainer
> higher in the hierarchy (maybe even Linus) will *merge* that tag into
> their tree, hopefully checking the signature first! Modern versions of
> git actually include the tag signature in the merge commit, so the
> result is signed by the original maintainer; note how this contradicts
> Linus's email with regard to the idea of separable signatures.
> Eventually multiple such groups of patches build up and the result is
> tagged as a release, and that release tag is signed.
>
> Accountability in this model rests with maintainers, and source-code
> stays on a multitude of personal, secure, locations. (in theory)
>
>
> However since we like to use github and tend to get code directly from
> it our main risk is github (or similar) being compromised. Given that I
> think we're much better off using per-commit signatures, and in effect
> continually making the statement "Yes, this commit/merge was really
> produced by me on my machine, although I may have made a mistake and
> might not have looked at the code as thoroughly as I maybe should have."
> The statement *is* weaker than Linus's model of "This signature is
> Really Official and Stuff and I've carefully checked everything." but I
> think we're much more interested in getting a strong guarantee on who
> made the commit than some strong statement about its actual contents -
> humans are fallible anyway.
>
> > Also do you approve of the other link I sent you?
> >
> > https://wiki.unsystem.net/index.php/DarkWallet/Negotiation
>
> I think you're conflating identities with the messaging layer; focus on
> the latter and use off-the-shelf identity systems like OpenPGP and SSL
> certificate authorities. Remember that every new identity system that
> gets involved is another way for an attacker to MITM attack you; you're
> better off using whatever the user is using already.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000016a442255c6d15cd6e085991c1efffc9caeff5fc6da14368a
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
>

--047d7bdc8e864ae68504ede704bb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">How does signing the commit message itself help at all sin=
ce it just signs the commit message, not the content of the commit. You cou=
ld commit some code then I. Then I squash my commits into yours and use you=
r commit message. You could also include the previous commit hash in your c=
ommit message.<div>

<br><div>But correct me if I am wrong, but that would be difficult (if not =
impossible) to verify once you get into merging code since the patch can be=
 merged in at another point in history entirely.. and still doesn&#39;t wor=
k because I can still squash commits into yours. I don&#39;t see how it can=
 work at all unless I am missing something obvious (which I fear I may be?)=
.</div>

<div><br></div><div>I also don&#39;t believe Linus is talking just from the=
 perspective of how the kernel project works. The integrity of a git reposi=
tory is maintained by the hash chaining and by the distributed nature of th=
e repository. If someone hacked github and changed the history of the tree,=
 the next time you tried to push his code up it would fail because the hist=
ory had changed - tampering is immediately obvious in git.</div>

<div><br></div><div>Regards,</div><div><br></div><div>Drak</div></div></div=
><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 19 Decemb=
er 2013 17:44, Peter Todd <span dir=3D"ltr">&lt;<a href=3D"mailto:pete@pete=
rtodd.org" target=3D"_blank">pete@petertodd.org</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Thu, Dec 19, 2013 at 04:04:17PM -0000, Am=
ir Taaki wrote:<br>
<br>
Looks like for this to actually go to the email lists they need to be in<br=
>
the To: field.<br>
<div class=3D"im"><br>
&gt; About signing each commit, Linus advises against it:<br>
&gt;<br>
&gt; <a href=3D"http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-=
td2582986.html" target=3D"_blank">http://git.661346.n2.nabble.com/GPG-signi=
ng-for-git-commit-td2582986.html</a><br>
&gt;<br>
&gt; &quot;Btw, there&#39;s a final reason, and probably the really real on=
e. Signing<br>
&gt; each commit is totally stupid. It just means that you automate it, and=
 you<br>
&gt; make the signature worth less. It also doesn&#39;t add any real value,=
 since<br>
&gt; the way the git DAG-chain of SHA1&#39;s work, you only ever need _one_=
<br>
&gt; signature to make all the commits reachable from that one be effective=
ly<br>
&gt; covered by that one. So signing each commit is simply missing the poin=
t.&quot;<br>
&gt;<br>
&gt; What do you reckon?<br>
<br>
</div>His point is valid, but it&#39;s valid in the context of how Linux<br=
>
development is done, not Bitcoin. The key difference being that Linus<br>
and other kernel developers have a model where code is passed around on<br>
mailing lists and between developers rather than stored on untrustworthy<br=
>
third-parties like github.<br>
<br>
For instance typically someone will submit a patch to the kernel<br>
development mailing list, example:<br>
<a href=3D"http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg5588=
41.html" target=3D"_blank">http://www.mail-archive.com/linux-kernel@vger.ke=
rnel.org/msg558841.html</a><br>
That patch isn&#39;t signed, and the email itself doesn&#39;t have to be PG=
P<br>
signed either. However a trusted maintainer of the relevant subsystem<br>
will (in theory) look over the patch carefully and commit it to their<br>
personal tree on a secure computer. (in theory)<br>
<br>
At some point the maintainer will create a *signed* tag on a commit with<br=
>
one or more patches, often many patches, another another maintainer<br>
higher in the hierarchy (maybe even Linus) will *merge* that tag into<br>
their tree, hopefully checking the signature first! Modern versions of<br>
git actually include the tag signature in the merge commit, so the<br>
result is signed by the original maintainer; note how this contradicts<br>
Linus&#39;s email with regard to the idea of separable signatures.<br>
Eventually multiple such groups of patches build up and the result is<br>
tagged as a release, and that release tag is signed.<br>
<br>
Accountability in this model rests with maintainers, and source-code<br>
stays on a multitude of personal, secure, locations. (in theory)<br>
<br>
<br>
However since we like to use github and tend to get code directly from<br>
it our main risk is github (or similar) being compromised. Given that I<br>
think we&#39;re much better off using per-commit signatures, and in effect<=
br>
continually making the statement &quot;Yes, this commit/merge was really<br=
>
produced by me on my machine, although I may have made a mistake and<br>
might not have looked at the code as thoroughly as I maybe should have.&quo=
t;<br>
The statement *is* weaker than Linus&#39;s model of &quot;This signature is=
<br>
Really Official and Stuff and I&#39;ve carefully checked everything.&quot; =
but I<br>
think we&#39;re much more interested in getting a strong guarantee on who<b=
r>
made the commit than some strong statement about its actual contents -<br>
humans are fallible anyway.<br>
<div class=3D"im"><br>
&gt; Also do you approve of the other link I sent you?<br>
&gt;<br>
&gt; <a href=3D"https://wiki.unsystem.net/index.php/DarkWallet/Negotiation"=
 target=3D"_blank">https://wiki.unsystem.net/index.php/DarkWallet/Negotiati=
on</a><br>
<br>
</div>I think you&#39;re conflating identities with the messaging layer; fo=
cus on<br>
the latter and use off-the-shelf identity systems like OpenPGP and SSL<br>
certificate authorities. Remember that every new identity system that<br>
gets involved is another way for an attacker to MITM attack you; you&#39;re=
<br>
better off using whatever the user is using already.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
&#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet=
ertodd.org</a><br>
00000000000000016a442255c6d15cd6e085991c1efffc9caeff5fc6da14368a<br>
</font></span><br>_______________________________________________<br>
unSYSTEM mailing list: <a href=3D"http://unsystem.net" target=3D"_blank">ht=
tp://unsystem.net</a><br>
<a href=3D"https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem"=
 target=3D"_blank">https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/u=
nsystem</a><br>
<br></blockquote></div><br></div>

--047d7bdc8e864ae68504ede704bb--