From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UMa4s-000195-42 for bitcoin-development@lists.sourceforge.net; Mon, 01 Apr 2013 08:26:54 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.180 as permitted sender) client-ip=209.85.217.180; envelope-from=melvincarvalho@gmail.com; helo=mail-lb0-f180.google.com; Received: from mail-lb0-f180.google.com ([209.85.217.180]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UMa4m-0007Jq-Fu for bitcoin-development@lists.sourceforge.net; Mon, 01 Apr 2013 08:26:54 +0000 Received: by mail-lb0-f180.google.com with SMTP id t11so1721512lbi.39 for ; Mon, 01 Apr 2013 01:26:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.87.243 with SMTP id bb19mr5222330lab.12.1364804801665; Mon, 01 Apr 2013 01:26:41 -0700 (PDT) Received: by 10.112.143.38 with HTTP; Mon, 1 Apr 2013 01:26:41 -0700 (PDT) Date: Mon, 1 Apr 2013 10:26:41 +0200 Message-ID: From: Melvin Carvalho To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11c3537a641fec04d94861ac X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (melvincarvalho[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UMa4m-0007Jq-Fu Subject: [Bitcoin-development] bitcoin pull requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 08:26:54 -0000 --001a11c3537a641fec04d94861ac Content-Type: text/plain; charset=ISO-8859-1 I was just looking at: https://bitcointalk.org/index.php?topic=4571.0 I'm just curious if there is a possible attack vector here based on the fact that git uses the relatively week SHA1 Could a seemingly innocuous pull request generate another file with a backdoor/nonce combination that slips under the radar? Apologies if this has come up before ... --001a11c3537a641fec04d94861ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm just curious if there is a p= ossible attack vector here based on the fact that git uses the relatively w= eek SHA1

Could a seemingly innocuous pull request generate another file wi= th a backdoor/nonce combination that slips under the radar?

Ap= ologies if this has come up before ...
--001a11c3537a641fec04d94861ac-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UMkWs-0005sM-3V for bitcoin-development@lists.sourceforge.net; Mon, 01 Apr 2013 19:36:30 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of praus.net designates 209.85.215.42 as permitted sender) client-ip=209.85.215.42; envelope-from=petr@praus.net; helo=mail-la0-f42.google.com; Received: from mail-la0-f42.google.com ([209.85.215.42]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UMkWp-00038t-Jt for bitcoin-development@lists.sourceforge.net; Mon, 01 Apr 2013 19:36:30 +0000 Received: by mail-la0-f42.google.com with SMTP id fe20so2431151lab.29 for ; Mon, 01 Apr 2013 12:36:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=sR0SBDTZptBiS7LVp2F842T0+wbHvs2+uryHQF4eYbg=; b=g1JqmCZYkemcKVfDwWY+5dnOGsL6gPjQwwDhF2ISJgFYXUeayErNVRvDOrsM0U5VIn fNfsRPtK0QD5ITllSZfnPkx0jJ0dVndOcFXHcn9KSJQE2DfvyhVjHoyDjYDuAF8u484E EegczJCQ4Cx71P0rVjtC6xkpGetcGboNc2rvQxoJUZR7ipK1cwnTtSSFMB824QACvx8v w+xS3QtMX9rjpdRn9lWtTICpbbZCypeLJ0tpWSLVPQ5tHXsnZxGp/oaYlBdcp7xpCdU/ WFPr7lW8T7V6lgB+EltbNPbAUchXIrhSc96Ar3hdaR+5x/0UvbLf5pQzpHL6UhpRzEtK dGkA== X-Received: by 10.112.137.135 with SMTP id qi7mr6173958lbb.117.1364840928259; Mon, 01 Apr 2013 11:28:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.35.107 with HTTP; Mon, 1 Apr 2013 11:28:28 -0700 (PDT) X-Originating-IP: [129.62.151.28] In-Reply-To: References: From: Petr Praus Date: Mon, 1 Apr 2013 13:28:28 -0500 Message-ID: To: Melvin Carvalho Content-Type: multipart/alternative; boundary=089e012292fab445c404d950ca84 X-Gm-Message-State: ALoCoQkfesYoec5eDmoJszr+gKLm1CcSeoesvz7Dx35uLe0cuApOAGpWeVKoGsNsXf8ItdzZTaKw X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -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.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UMkWp-00038t-Jt Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] bitcoin pull requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 19:36:30 -0000 --089e012292fab445c404d950ca84 Content-Type: text/plain; charset=UTF-8 An attacker would have to find a collision between two specific pieces of code - his malicious code and a useful innoculous code that would be accepted as pull request. This is the second, much harder case in the birthday problem. When people talk about SHA-1 being broken they actually mean the first case in the birthday problem - find any two arbitrary values that hash to the same value. So, no I don't think it's a feasible attack vector any time soon. Besides, with that kind of hashing power, it might be more feasible to cause problems in the chain by e.g. constantly splitting it. On 1 April 2013 03:26, Melvin Carvalho wrote: > I was just looking at: > > https://bitcointalk.org/index.php?topic=4571.0 > > I'm just curious if there is a possible attack vector here based on the > fact that git uses the relatively week SHA1 > > Could a seemingly innocuous pull request generate another file with a > backdoor/nonce combination that slips under the radar? > > Apologies if this has come up before ... > > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --089e012292fab445c404d950ca84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
An attacker would have to find a collision between two spe= cific pieces of code - his malicious code and a useful innoculous code that= would be accepted as pull request. This is the second, much harder case in= the birthday problem. When people talk about SHA-1 being broken they actua= lly mean the first case in the birthday problem - find any two arbitrary va= lues that hash to the same value. So, no I don't think it's a feasi= ble attack vector any time soon.

Besides, with that kind of hashing power, it might be = more feasible to cause problems in the chain by e.g. constantly splitting i= t.


On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
I'm just curio= us if there is a possible attack vector here based on the fact that git use= s the relatively week SHA1

Could a seemingly innocuous pull request generate another file wi= th a backdoor/nonce combination that slips under the radar?

Ap= ologies if this has come up before ...

-----------------------------------------------------------------------= -------
Own the Future-Intel&reg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___________= ____________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--089e012292fab445c404d950ca84-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UMmeK-00053I-3j for bitcoin-development@lists.sourceforge.net; Mon, 01 Apr 2013 21:52:20 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.181 as permitted sender) client-ip=209.85.217.181; envelope-from=melvincarvalho@gmail.com; helo=mail-lb0-f181.google.com; Received: from mail-lb0-f181.google.com ([209.85.217.181]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UMmeI-0005VA-HC for bitcoin-development@lists.sourceforge.net; Mon, 01 Apr 2013 21:52:20 +0000 Received: by mail-lb0-f181.google.com with SMTP id r11so2371205lbv.12 for ; Mon, 01 Apr 2013 14:52:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.43.232 with SMTP id z8mr6506515lbl.135.1364853131793; Mon, 01 Apr 2013 14:52:11 -0700 (PDT) Received: by 10.112.143.38 with HTTP; Mon, 1 Apr 2013 14:52:11 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Apr 2013 23:52:11 +0200 Message-ID: From: Melvin Carvalho To: Petr Praus Content-Type: multipart/alternative; boundary=e0cb4efe34001760f404d953a2c9 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (melvincarvalho[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UMmeI-0005VA-HC Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] bitcoin pull requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 21:52:20 -0000 --e0cb4efe34001760f404d953a2c9 Content-Type: text/plain; charset=ISO-8859-1 On 1 April 2013 20:28, Petr Praus wrote: > An attacker would have to find a collision between two specific pieces of > code - his malicious code and a useful innoculous code that would be > accepted as pull request. This is the second, much harder case in the > birthday problem. When people talk about SHA-1 being broken they actually > mean the first case in the birthday problem - find any two arbitrary values > that hash to the same value. So, no I don't think it's a feasible attack > vector any time soon. > > Besides, with that kind of hashing power, it might be more feasible to > cause problems in the chain by e.g. constantly splitting it. > OK, maybe im being *way* too paranoid here ... but what if someone had access to github, could they replace one file with one they had prepared at some point? > > > On 1 April 2013 03:26, Melvin Carvalho wrote: > >> I was just looking at: >> >> https://bitcointalk.org/index.php?topic=4571.0 >> >> I'm just curious if there is a possible attack vector here based on the >> fact that git uses the relatively week SHA1 >> >> Could a seemingly innocuous pull request generate another file with a >> backdoor/nonce combination that slips under the radar? >> >> Apologies if this has come up before ... >> >> >> ------------------------------------------------------------------------------ >> Own the Future-Intel® Level Up Game Demo Contest 2013 >> Rise to greatness in Intel's independent game demo contest. >> Compete for recognition, cash, and the chance to get your game >> on Steam. $5K grand prize plus 10 genre and skill prizes. >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > --e0cb4efe34001760f404d953a2c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 1 April 2013 20:28, Petr Praus <petr@praus.net> wrot= e:
An attacker would have to find a collision between two spe= cific pieces of code - his malicious code and a useful innoculous code that= would be accepted as pull request. This is the second, much harder case in= the birthday problem. When people talk about SHA-1 being broken they actua= lly mean the first case in the birthday problem - find any two arbitrary va= lues that hash to the same value. So, no I don't think it's a feasi= ble attack vector any time soon.

Besides, with that kind of hashing power, it might be more f= easible to cause problems in the chain by e.g. constantly splitting it.

OK, maybe im being *way* too paran= oid here ... but what if someone had access to github, could they replace o= ne file with one they had prepared at some point?
=A0


On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
I'm just curio= us if there is a possible attack vector here based on the fact that git use= s the relatively week SHA1

Could a seemingly innocuous pull request generate another file wi= th a backdoor/nonce combination that slips under the radar?

Ap= ologies if this has come up before ...

-----------------------------------------------------------= -------------------
Own the Future-Intel&reg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___________= ____________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment



--e0cb4efe34001760f404d953a2c9-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UMnCp-0004hW-TD for bitcoin-development@lists.sourceforge.net; Mon, 01 Apr 2013 22:27:59 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.51 as permitted sender) client-ip=209.85.215.51; envelope-from=melvincarvalho@gmail.com; helo=mail-la0-f51.google.com; Received: from mail-la0-f51.google.com ([209.85.215.51]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UMnCo-0006K0-AD for bitcoin-development@lists.sourceforge.net; Mon, 01 Apr 2013 22:27:59 +0000 Received: by mail-la0-f51.google.com with SMTP id fo13so2548536lab.10 for ; Mon, 01 Apr 2013 15:27:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.38.202 with SMTP id i10mr6592097lbk.127.1364855271511; Mon, 01 Apr 2013 15:27:51 -0700 (PDT) Received: by 10.112.143.38 with HTTP; Mon, 1 Apr 2013 15:27:51 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Apr 2013 00:27:51 +0200 Message-ID: From: Melvin Carvalho To: Will Content-Type: multipart/alternative; boundary=90e6ba25e8c1a0dfa304d9542109 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (melvincarvalho[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UMnCo-0006K0-AD Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] bitcoin pull requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 22:28:00 -0000 --90e6ba25e8c1a0dfa304d9542109 Content-Type: text/plain; charset=ISO-8859-1 On 2 April 2013 00:10, Will wrote: > The threat of a SHA1 collision attack to insert a malicious pull request > are tiny compared with the other threats - e.g. github being compromised, > one of the core developers' passwords being compromised, one of the core > developers going rogue, sourceforge (distribution site) being compromised > etc etc... believe me there's a lot more to worry about than a SHA1 > attack... > > Not meaning to scare, just to put things in perspective - this is why we > all need to peer review each others commits and keep an eye out for > suspicious commits, leverage the benefits of this project being open source > and easily peer reviewed. > Very good points, and I think you're absolutely right. But just running the numbers, to get the picture, based of scheiner's statistics: http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html We're talking about a million terrahashes = 2^60 right? With the block chain, you only have a 10 minute window, but with source code you have a longer time to prepare. Couldnt this be done with an ASIC in about a week? > > Will > > > On 1 April 2013 23:52, Melvin Carvalho wrote: > >> >> >> >> On 1 April 2013 20:28, Petr Praus wrote: >> >>> An attacker would have to find a collision between two specific pieces >>> of code - his malicious code and a useful innoculous code that would be >>> accepted as pull request. This is the second, much harder case in the >>> birthday problem. When people talk about SHA-1 being broken they actually >>> mean the first case in the birthday problem - find any two arbitrary values >>> that hash to the same value. So, no I don't think it's a feasible attack >>> vector any time soon. >>> >>> Besides, with that kind of hashing power, it might be more feasible to >>> cause problems in the chain by e.g. constantly splitting it. >>> >> >> OK, maybe im being *way* too paranoid here ... but what if someone had >> access to github, could they replace one file with one they had prepared at >> some point? >> >> >>> >>> >>> On 1 April 2013 03:26, Melvin Carvalho wrote: >>> >>>> I was just looking at: >>>> >>>> https://bitcointalk.org/index.php?topic=4571.0 >>>> >>>> I'm just curious if there is a possible attack vector here based on the >>>> fact that git uses the relatively week SHA1 >>>> >>>> Could a seemingly innocuous pull request generate another file with a >>>> backdoor/nonce combination that slips under the radar? >>>> >>>> Apologies if this has come up before ... >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Own the Future-Intel® Level Up Game Demo Contest 2013 >>>> Rise to greatness in Intel's independent game demo contest. >>>> Compete for recognition, cash, and the chance to get your game >>>> on Steam. $5K grand prize plus 10 genre and skill prizes. >>>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d >>>> _______________________________________________ >>>> Bitcoin-development mailing list >>>> Bitcoin-development@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>>> >>>> >>> >> >> >> ------------------------------------------------------------------------------ >> Own the Future-Intel® Level Up Game Demo Contest 2013 >> Rise to greatness in Intel's independent game demo contest. >> Compete for recognition, cash, and the chance to get your game >> on Steam. $5K grand prize plus 10 genre and skill prizes. >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > --90e6ba25e8c1a0dfa304d9542109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 2 April 2013 00:10, Will <will@phase.net> wrote:
=
The threat of a SHA1 collision attack to insert a maliciou= s pull request are tiny compared with the other threats - e.g. github being= compromised, one of the core developers' passwords being compromised, = one of the core developers going rogue, sourceforge (distribution site) bei= ng compromised etc etc... believe me there's a lot more to worry about = than a SHA1 attack...

Not meaning to scare, just to put things in perspective - th= is is why we all need to peer review each others commits and keep an eye ou= t for suspicious commits, leverage the benefits of this project being open = source and easily peer reviewed.

Very good points, and I think you= 9;re absolutely right.=A0

But just running the numbers, to get the = picture, based of scheiner's statistics:

http://www.schneier= .com/blog/archives/2012/10/when_will_we_se.html

We're talking about a million terrahashes =3D 2^60 right= ?

With the block chain, you only have a 10 minute window,= but with source code you have a longer time to prepare.

Couldnt this be done with an ASIC in about a week?

=A0
=

Will


On 1= April 2013 23:52, Melvin Carvalho <melvincarvalho@gmail.com>= ; wrote:



On 1 April 2= 013 20:28, Petr Praus <petr@praus.net> wrote:
An attacker would have to find a collision between two spe= cific pieces of code - his malicious code and a useful innoculous code that= would be accepted as pull request. This is the second, much harder case in= the birthday problem. When people talk about SHA-1 being broken they actua= lly mean the first case in the birthday problem - find any two arbitrary va= lues that hash to the same value. So, no I don't think it's a feasi= ble attack vector any time soon.

Besides, with that kind of hashing power, it might be more f= easible to cause problems in the chain by e.g. constantly splitting it.

OK, maybe im being *way* too= paranoid here ... but what if someone had access to github, could they rep= lace one file with one they had prepared at some point?
=A0
=


On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
I'm just curio= us if there is a possible attack vector here based on the fact that git use= s the relatively week SHA1

Could a seemingly innocuous pull request generate another file wi= th a backdoor/nonce combination that slips under the radar?

Ap= ologies if this has come up before ...

-----------------------------------------------------------= -------------------
Own the Future-Intel&reg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___________= ____________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment




-----------------------------------------------------------------------= -------
Own the Future-Intel&reg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___________= ____________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment



--90e6ba25e8c1a0dfa304d9542109-- From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) id 1UMnJa-0006gG-1R for bitcoin-development@lists.sourceforge.net; Mon, 01 Apr 2013 22:34:58 +0000 X-ACL-Warn: Received: from mail-qc0-f174.google.com ([209.85.216.174]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UMnJY-0000dy-Mq for bitcoin-development@lists.sourceforge.net; Mon, 01 Apr 2013 22:34:58 +0000 Received: by mail-qc0-f174.google.com with SMTP id z24so1273571qcq.5 for ; Mon, 01 Apr 2013 15:34:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=Pk7K09JRMyHT4H715znlsCAAPKRFx7CaCz+6aySxHhA=; b=hF/aRfpM5Ku6fYs93+SGHDEGCvTe+cthlm739Z8gPgnueUZKEJd0Oh+17iC4bZkRZL 7BYXJPm35ndNFQ7r8EN8s1ElG0swUqpt+BO9S+HtX+tBDg0BrjEoOQEDgvxH+o5Ssfo8 6QAJRwj1+dUgcjlbDiqYqMPz+9SU2utPsOVuSXEVPoyafZyz7pzMHoMMKGlk+ThcWJMl hgjdRGMnHMjJ4eIWMFNpKv40D+gzccFSlfJuUEeytysaETbhdNPHlNWrYshDuUnm7vuZ UxN6UveCkwUFgfx15o++GOFRin0nXoH9ZEvBaRuw9WDY8/h8vn59+0fp//vmWp4lnebm m8og== X-Received: by 10.49.87.40 with SMTP id u8mr15450968qez.62.1364854246721; Mon, 01 Apr 2013 15:10:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.14.194 with HTTP; Mon, 1 Apr 2013 15:10:26 -0700 (PDT) In-Reply-To: References: From: Will Date: Tue, 2 Apr 2013 00:10:26 +0200 Message-ID: To: Melvin Carvalho Content-Type: multipart/alternative; boundary=047d7bdc8b0a8be23604d953e4a5 X-Gm-Message-State: ALoCoQnXvciVBEBoYHuFADCJJARmfJr7WjNeVRocgd+FOEn66uEwTdBHzjxkxwbBI2BcrT2JHjQS X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1UMnJY-0000dy-Mq Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] bitcoin pull requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 22:34:58 -0000 --047d7bdc8b0a8be23604d953e4a5 Content-Type: text/plain; charset=ISO-8859-1 The threat of a SHA1 collision attack to insert a malicious pull request are tiny compared with the other threats - e.g. github being compromised, one of the core developers' passwords being compromised, one of the core developers going rogue, sourceforge (distribution site) being compromised etc etc... believe me there's a lot more to worry about than a SHA1 attack... Not meaning to scare, just to put things in perspective - this is why we all need to peer review each others commits and keep an eye out for suspicious commits, leverage the benefits of this project being open source and easily peer reviewed. Will On 1 April 2013 23:52, Melvin Carvalho wrote: > > > > On 1 April 2013 20:28, Petr Praus wrote: > >> An attacker would have to find a collision between two specific pieces of >> code - his malicious code and a useful innoculous code that would be >> accepted as pull request. This is the second, much harder case in the >> birthday problem. When people talk about SHA-1 being broken they actually >> mean the first case in the birthday problem - find any two arbitrary values >> that hash to the same value. So, no I don't think it's a feasible attack >> vector any time soon. >> >> Besides, with that kind of hashing power, it might be more feasible to >> cause problems in the chain by e.g. constantly splitting it. >> > > OK, maybe im being *way* too paranoid here ... but what if someone had > access to github, could they replace one file with one they had prepared at > some point? > > >> >> >> On 1 April 2013 03:26, Melvin Carvalho wrote: >> >>> I was just looking at: >>> >>> https://bitcointalk.org/index.php?topic=4571.0 >>> >>> I'm just curious if there is a possible attack vector here based on the >>> fact that git uses the relatively week SHA1 >>> >>> Could a seemingly innocuous pull request generate another file with a >>> backdoor/nonce combination that slips under the radar? >>> >>> Apologies if this has come up before ... >>> >>> >>> ------------------------------------------------------------------------------ >>> Own the Future-Intel® Level Up Game Demo Contest 2013 >>> Rise to greatness in Intel's independent game demo contest. >>> Compete for recognition, cash, and the chance to get your game >>> on Steam. $5K grand prize plus 10 genre and skill prizes. >>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>> >>> >> > > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --047d7bdc8b0a8be23604d953e4a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The threat of a SHA1 collision attack to insert a maliciou= s pull request are tiny compared with the other threats - e.g. github being= compromised, one of the core developers' passwords being compromised, = one of the core developers going rogue, sourceforge (distribution site) bei= ng compromised etc etc... believe me there's a lot more to worry about = than a SHA1 attack...

Not meaning to scare, just to put things in perspectiv= e - this is why we all need to peer review each others commits and keep an = eye out for suspicious commits, leverage the benefits of this project being= open source and easily peer reviewed.

Will

On 1 April 2013 23:52, Melvin Carvalho <melvincarvalho@gmail.com> wrote:



On 1 April 2013 20= :28, Petr Praus <petr@praus.net> wrote:
An attacker would have to find a collision between two spe= cific pieces of code - his malicious code and a useful innoculous code that= would be accepted as pull request. This is the second, much harder case in= the birthday problem. When people talk about SHA-1 being broken they actua= lly mean the first case in the birthday problem - find any two arbitrary va= lues that hash to the same value. So, no I don't think it's a feasi= ble attack vector any time soon.

Besides, with that kind of hashing power, it might be more f= easible to cause problems in the chain by e.g. constantly splitting it.

OK, maybe im being *way* too= paranoid here ... but what if someone had access to github, could they rep= lace one file with one they had prepared at some point?
=A0


On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
I'm just curio= us if there is a possible attack vector here based on the fact that git use= s the relatively week SHA1

Could a seemingly innocuous pull request generate another file wi= th a backdoor/nonce combination that slips under the radar?

Ap= ologies if this has come up before ...

-----------------------------------------------------------= -------------------
Own the Future-Intel&reg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___________= ____________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment




-----------------------------------------------------------------------= -------
Own the Future-Intel&reg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___________= ____________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--047d7bdc8b0a8be23604d953e4a5-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UMnZW-0005bq-D0 for bitcoin-development@lists.sourceforge.net; Mon, 01 Apr 2013 22:51:26 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gnomon.org.uk designates 93.93.131.22 as permitted sender) client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk; helo=darla.gnomon.org.uk; Received: from darla.gnomon.org.uk ([93.93.131.22]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1UMnZS-00022M-Ko for bitcoin-development@lists.sourceforge.net; Mon, 01 Apr 2013 22:51:26 +0000 Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id r31Mp7R8000170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Apr 2013 23:51:12 +0100 (BST) (envelope-from roy@darla.gnomon.org.uk) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at darla.gnomon.org.uk Received: (from roy@localhost) by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id r31Mp7oq000169; Mon, 1 Apr 2013 23:51:07 +0100 (BST) (envelope-from roy) Date: Mon, 1 Apr 2013 23:51:07 +0100 From: Roy Badami To: Melvin Carvalho Message-ID: <20130401225107.GU65880@giles.gnomon.org.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -3.8 (---) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -2.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1UMnZS-00022M-Ko Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] bitcoin pull requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 22:51:26 -0000 The attack Schneier is talking about is a collision attack (i.e. it creates two messages with the same hash, but you don't get to choose either of the messages). It's not a second preimage attack, which is what you would need to be able to create a message that hashes to the same value of an existing message. (And it neither have anything to do with the birthday paradox, BTW - which relates to the chance of eventually finding two messages that hash to the same value by pure change) If someone gets malicious code into the repo, it's going to be by social engineering, not by breaking the cyrpto. roy On Tue, Apr 02, 2013 at 12:27:51AM +0200, Melvin Carvalho wrote: > On 2 April 2013 00:10, Will wrote: > > > The threat of a SHA1 collision attack to insert a malicious pull request > > are tiny compared with the other threats - e.g. github being compromised, > > one of the core developers' passwords being compromised, one of the core > > developers going rogue, sourceforge (distribution site) being compromised > > etc etc... believe me there's a lot more to worry about than a SHA1 > > attack... > > > > Not meaning to scare, just to put things in perspective - this is why we > > all need to peer review each others commits and keep an eye out for > > suspicious commits, leverage the benefits of this project being open source > > and easily peer reviewed. > > > > Very good points, and I think you're absolutely right. > > But just running the numbers, to get the picture, based of scheiner's > statistics: > > http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html > > We're talking about a million terrahashes = 2^60 right? > > With the block chain, you only have a 10 minute window, but with source > code you have a longer time to prepare. > > Couldnt this be done with an ASIC in about a week? > > > > > > > Will > > > > > > On 1 April 2013 23:52, Melvin Carvalho wrote: > > > >> > >> > >> > >> On 1 April 2013 20:28, Petr Praus wrote: > >> > >>> An attacker would have to find a collision between two specific pieces > >>> of code - his malicious code and a useful innoculous code that would be > >>> accepted as pull request. This is the second, much harder case in the > >>> birthday problem. When people talk about SHA-1 being broken they actually > >>> mean the first case in the birthday problem - find any two arbitrary values > >>> that hash to the same value. So, no I don't think it's a feasible attack > >>> vector any time soon. > >>> > >>> Besides, with that kind of hashing power, it might be more feasible to > >>> cause problems in the chain by e.g. constantly splitting it. > >>> > >> > >> OK, maybe im being *way* too paranoid here ... but what if someone had > >> access to github, could they replace one file with one they had prepared at > >> some point? > >> > >> > >>> > >>> > >>> On 1 April 2013 03:26, Melvin Carvalho wrote: > >>> > >>>> I was just looking at: > >>>> > >>>> https://bitcointalk.org/index.php?topic=4571.0 > >>>> > >>>> I'm just curious if there is a possible attack vector here based on the > >>>> fact that git uses the relatively week SHA1 > >>>> > >>>> Could a seemingly innocuous pull request generate another file with a > >>>> backdoor/nonce combination that slips under the radar? > >>>> > >>>> Apologies if this has come up before ... > >>>> > >>>> > >>>> ------------------------------------------------------------------------------ > >>>> Own the Future-Intel® Level Up Game Demo Contest 2013 > >>>> Rise to greatness in Intel's independent game demo contest. > >>>> Compete for recognition, cash, and the chance to get your game > >>>> on Steam. $5K grand prize plus 10 genre and skill prizes. > >>>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > >>>> _______________________________________________ > >>>> Bitcoin-development mailing list > >>>> Bitcoin-development@lists.sourceforge.net > >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >>>> > >>>> > >>> > >> > >> > >> ------------------------------------------------------------------------------ > >> Own the Future-Intel® Level Up Game Demo Contest 2013 > >> Rise to greatness in Intel's independent game demo contest. > >> Compete for recognition, cash, and the chance to get your game > >> on Steam. $5K grand prize plus 10 genre and skill prizes. > >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > >> _______________________________________________ > >> Bitcoin-development mailing list > >> Bitcoin-development@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >> > >> > > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UMncV-00012A-Go for bitcoin-development@lists.sourceforge.net; Mon, 01 Apr 2013 22:54:31 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gnomon.org.uk designates 93.93.131.22 as permitted sender) client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk; helo=darla.gnomon.org.uk; Received: from darla.gnomon.org.uk ([93.93.131.22]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1UMncT-0002Ez-2s for bitcoin-development@lists.sourceforge.net; Mon, 01 Apr 2013 22:54:31 +0000 Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id r31MsHwW000200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Apr 2013 23:54:22 +0100 (BST) (envelope-from roy@darla.gnomon.org.uk) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at darla.gnomon.org.uk Received: (from roy@localhost) by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id r31MsHMW000199; Mon, 1 Apr 2013 23:54:17 +0100 (BST) (envelope-from roy) Date: Mon, 1 Apr 2013 23:54:17 +0100 From: Roy Badami To: Melvin Carvalho Message-ID: <20130401225417.GV65880@giles.gnomon.org.uk> References: <20130401225107.GU65880@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130401225107.GU65880@giles.gnomon.org.uk> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -3.8 (---) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -2.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1UMncT-0002Ez-2s Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] bitcoin pull requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 22:54:31 -0000 And the moment I hit send I realised it's not necessarily true. Conceivably, a collision attack might help you craft two commits (one good, one bad) with the same hash. But I still maintain what I just posted is true: if someone gets malicious code into the repo, it's going to be by social engineering, not by breaking the cyrpto. roy On Mon, Apr 01, 2013 at 11:51:07PM +0100, Roy Badami wrote: > The attack Schneier is talking about is a collision attack (i.e. it > creates two messages with the same hash, but you don't get to choose > either of the messages). It's not a second preimage attack, which is > what you would need to be able to create a message that hashes to the > same value of an existing message. > > (And it neither have anything to do with the birthday paradox, BTW - > which relates to the chance of eventually finding two messages that > hash to the same value by pure change) > > If someone gets malicious code into the repo, it's going to be by > social engineering, not by breaking the cyrpto. > > roy > > On Tue, Apr 02, 2013 at 12:27:51AM +0200, Melvin Carvalho wrote: > > On 2 April 2013 00:10, Will wrote: > > > > > The threat of a SHA1 collision attack to insert a malicious pull request > > > are tiny compared with the other threats - e.g. github being compromised, > > > one of the core developers' passwords being compromised, one of the core > > > developers going rogue, sourceforge (distribution site) being compromised > > > etc etc... believe me there's a lot more to worry about than a SHA1 > > > attack... > > > > > > Not meaning to scare, just to put things in perspective - this is why we > > > all need to peer review each others commits and keep an eye out for > > > suspicious commits, leverage the benefits of this project being open source > > > and easily peer reviewed. > > > > > > > Very good points, and I think you're absolutely right. > > > > But just running the numbers, to get the picture, based of scheiner's > > statistics: > > > > http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html > > > > We're talking about a million terrahashes = 2^60 right? > > > > With the block chain, you only have a 10 minute window, but with source > > code you have a longer time to prepare. > > > > Couldnt this be done with an ASIC in about a week? > > > > > > > > > > > > Will > > > > > > > > > On 1 April 2013 23:52, Melvin Carvalho wrote: > > > > > >> > > >> > > >> > > >> On 1 April 2013 20:28, Petr Praus wrote: > > >> > > >>> An attacker would have to find a collision between two specific pieces > > >>> of code - his malicious code and a useful innoculous code that would be > > >>> accepted as pull request. This is the second, much harder case in the > > >>> birthday problem. When people talk about SHA-1 being broken they actually > > >>> mean the first case in the birthday problem - find any two arbitrary values > > >>> that hash to the same value. So, no I don't think it's a feasible attack > > >>> vector any time soon. > > >>> > > >>> Besides, with that kind of hashing power, it might be more feasible to > > >>> cause problems in the chain by e.g. constantly splitting it. > > >>> > > >> > > >> OK, maybe im being *way* too paranoid here ... but what if someone had > > >> access to github, could they replace one file with one they had prepared at > > >> some point? > > >> > > >> > > >>> > > >>> > > >>> On 1 April 2013 03:26, Melvin Carvalho wrote: > > >>> > > >>>> I was just looking at: > > >>>> > > >>>> https://bitcointalk.org/index.php?topic=4571.0 > > >>>> > > >>>> I'm just curious if there is a possible attack vector here based on the > > >>>> fact that git uses the relatively week SHA1 > > >>>> > > >>>> Could a seemingly innocuous pull request generate another file with a > > >>>> backdoor/nonce combination that slips under the radar? > > >>>> > > >>>> Apologies if this has come up before ... > > >>>> > > >>>> > > >>>> ------------------------------------------------------------------------------ > > >>>> Own the Future-Intel® Level Up Game Demo Contest 2013 > > >>>> Rise to greatness in Intel's independent game demo contest. > > >>>> Compete for recognition, cash, and the chance to get your game > > >>>> on Steam. $5K grand prize plus 10 genre and skill prizes. > > >>>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > > >>>> _______________________________________________ > > >>>> Bitcoin-development mailing list > > >>>> Bitcoin-development@lists.sourceforge.net > > >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > >>>> > > >>>> > > >>> > > >> > > >> > > >> ------------------------------------------------------------------------------ > > >> Own the Future-Intel® Level Up Game Demo Contest 2013 > > >> Rise to greatness in Intel's independent game demo contest. > > >> Compete for recognition, cash, and the chance to get your game > > >> on Steam. $5K grand prize plus 10 genre and skill prizes. > > >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > > >> _______________________________________________ > > >> Bitcoin-development mailing list > > >> Bitcoin-development@lists.sourceforge.net > > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > >> > > >> > > > > > > ------------------------------------------------------------------------------ > > Own the Future-Intel® Level Up Game Demo Contest 2013 > > Rise to greatness in Intel's independent game demo contest. > > Compete for recognition, cash, and the chance to get your game > > on Steam. $5K grand prize plus 10 genre and skill prizes. > > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UNEZs-0001AH-2x for bitcoin-development@lists.sourceforge.net; Wed, 03 Apr 2013 03:41:36 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.43 as permitted sender) client-ip=209.85.214.43; envelope-from=laanwj@gmail.com; helo=mail-bk0-f43.google.com; Received: from mail-bk0-f43.google.com ([209.85.214.43]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UNEZo-00049E-Pq for bitcoin-development@lists.sourceforge.net; Wed, 03 Apr 2013 03:41:36 +0000 Received: by mail-bk0-f43.google.com with SMTP id jm2so545857bkc.30 for ; Tue, 02 Apr 2013 20:41:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.205.34.195 with SMTP id st3mr14810bkb.16.1364960486292; Tue, 02 Apr 2013 20:41:26 -0700 (PDT) Received: by 10.204.37.203 with HTTP; Tue, 2 Apr 2013 20:41:26 -0700 (PDT) In-Reply-To: <20130401225417.GV65880@giles.gnomon.org.uk> References: <20130401225107.GU65880@giles.gnomon.org.uk> <20130401225417.GV65880@giles.gnomon.org.uk> Date: Wed, 3 Apr 2013 05:41:26 +0200 Message-ID: From: Wladimir To: Roy Badami Content-Type: multipart/alternative; boundary=bcaec52c69cbeb2e8b04d96ca096 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (laanwj[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UNEZo-00049E-Pq Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] bitcoin pull requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 03:41:36 -0000 --bcaec52c69cbeb2e8b04d96ca096 Content-Type: text/plain; charset=UTF-8 Maybe now that bitcoin is growing out of the toy phase it's an idea to start gpg signing commits, like the Linux kernel ( https://lwn.net/Articles/466468/). But I suppose then we can't use github anymore to merge as-is and need manual steps? Wladimir On Tue, Apr 2, 2013 at 12:54 AM, Roy Badami wrote: > And the moment I hit send I realised it's not necessarily true. > Conceivably, a collision attack might help you craft two commits (one > good, one bad) with the same hash. > > But I still maintain what I just posted is true: if someone gets > malicious code into the repo, it's going to be by social engineering, > not by breaking the cyrpto. > > roy > > > On Mon, Apr 01, 2013 at 11:51:07PM +0100, Roy Badami wrote: > > The attack Schneier is talking about is a collision attack (i.e. it > > creates two messages with the same hash, but you don't get to choose > > either of the messages). It's not a second preimage attack, which is > > what you would need to be able to create a message that hashes to the > > same value of an existing message. > > > > (And it neither have anything to do with the birthday paradox, BTW - > > which relates to the chance of eventually finding two messages that > > hash to the same value by pure change) > > > > If someone gets malicious code into the repo, it's going to be by > > social engineering, not by breaking the cyrpto. > > > > roy > > > > On Tue, Apr 02, 2013 at 12:27:51AM +0200, Melvin Carvalho wrote: > > > On 2 April 2013 00:10, Will wrote: > > > > > > > The threat of a SHA1 collision attack to insert a malicious pull > request > > > > are tiny compared with the other threats - e.g. github being > compromised, > > > > one of the core developers' passwords being compromised, one of the > core > > > > developers going rogue, sourceforge (distribution site) being > compromised > > > > etc etc... believe me there's a lot more to worry about than a SHA1 > > > > attack... > > > > > > > > Not meaning to scare, just to put things in perspective - this is > why we > > > > all need to peer review each others commits and keep an eye out for > > > > suspicious commits, leverage the benefits of this project being open > source > > > > and easily peer reviewed. > > > > > > > > > > Very good points, and I think you're absolutely right. > > > > > > But just running the numbers, to get the picture, based of scheiner's > > > statistics: > > > > > > http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html > > > > > > We're talking about a million terrahashes = 2^60 right? > > > > > > With the block chain, you only have a 10 minute window, but with source > > > code you have a longer time to prepare. > > > > > > Couldnt this be done with an ASIC in about a week? > > > > > > > > > > > > > > > > > Will > > > > > > > > > > > > On 1 April 2013 23:52, Melvin Carvalho > wrote: > > > > > > > >> > > > >> > > > >> > > > >> On 1 April 2013 20:28, Petr Praus wrote: > > > >> > > > >>> An attacker would have to find a collision between two specific > pieces > > > >>> of code - his malicious code and a useful innoculous code that > would be > > > >>> accepted as pull request. This is the second, much harder case in > the > > > >>> birthday problem. When people talk about SHA-1 being broken they > actually > > > >>> mean the first case in the birthday problem - find any two > arbitrary values > > > >>> that hash to the same value. So, no I don't think it's a feasible > attack > > > >>> vector any time soon. > > > >>> > > > >>> Besides, with that kind of hashing power, it might be more > feasible to > > > >>> cause problems in the chain by e.g. constantly splitting it. > > > >>> > > > >> > > > >> OK, maybe im being *way* too paranoid here ... but what if someone > had > > > >> access to github, could they replace one file with one they had > prepared at > > > >> some point? > > > >> > > > >> > > > >>> > > > >>> > > > >>> On 1 April 2013 03:26, Melvin Carvalho > wrote: > > > >>> > > > >>>> I was just looking at: > > > >>>> > > > >>>> https://bitcointalk.org/index.php?topic=4571.0 > > > >>>> > > > >>>> I'm just curious if there is a possible attack vector here based > on the > > > >>>> fact that git uses the relatively week SHA1 > > > >>>> > > > >>>> Could a seemingly innocuous pull request generate another file > with a > > > >>>> backdoor/nonce combination that slips under the radar? > > > >>>> > > > >>>> Apologies if this has come up before ... > > > >>>> > > > >>>> > > > >>>> > ------------------------------------------------------------------------------ > > > >>>> Own the Future-Intel® Level Up Game Demo Contest 2013 > > > >>>> Rise to greatness in Intel's independent game demo contest. > > > >>>> Compete for recognition, cash, and the chance to get your game > > > >>>> on Steam. $5K grand prize plus 10 genre and skill prizes. > > > >>>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > > > >>>> _______________________________________________ > > > >>>> Bitcoin-development mailing list > > > >>>> Bitcoin-development@lists.sourceforge.net > > > >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > >>>> > > > >>>> > > > >>> > > > >> > > > >> > > > >> > ------------------------------------------------------------------------------ > > > >> Own the Future-Intel® Level Up Game Demo Contest 2013 > > > >> Rise to greatness in Intel's independent game demo contest. > > > >> Compete for recognition, cash, and the chance to get your game > > > >> on Steam. $5K grand prize plus 10 genre and skill prizes. > > > >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > > > >> _______________________________________________ > > > >> Bitcoin-development mailing list > > > >> Bitcoin-development@lists.sourceforge.net > > > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > >> > > > >> > > > > > > > > > > ------------------------------------------------------------------------------ > > > Own the Future-Intel® Level Up Game Demo Contest 2013 > > > Rise to greatness in Intel's independent game demo contest. > > > Compete for recognition, cash, and the chance to get your game > > > on Steam. $5K grand prize plus 10 genre and skill prizes. > > > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > > > > > _______________________________________________ > > > Bitcoin-development mailing list > > > Bitcoin-development@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > ------------------------------------------------------------------------------ > > Own the Future-Intel® Level Up Game Demo Contest 2013 > > Rise to greatness in Intel's independent game demo contest. > > Compete for recognition, cash, and the chance to get your game > > on Steam. $5K grand prize plus 10 genre and skill prizes. > > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --bcaec52c69cbeb2e8b04d96ca096 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Maybe now that bitcoin is growing out of th= e toy phase it's an idea to start gpg signing commits, like the Linux k= ernel (https://lwn.net/Article= s/466468/).

But I suppose then we can't use github anymore to merge = as-is and need manual steps?

Wladimir




On Tue, Apr 2, 2013 at 12:54 AM, Roy Badami <roy@gnomon.org.uk> wrote:
And the moment I hit send I realised it's not necessarily true.
Conceivably, a collision attack might help you craft two commits (one
good, one bad) with the same hash.

But I still maintain what I just posted is true: if someone gets
malicious code into the repo, it's going to be= by social engineering,
not by breaking the cyrpto.

roy


On Mon, Apr 01, 2013 at 11:51= :07PM +0100, Roy Badami wrote:
> The attack Schneier is talking about is a collision attack (i.e. it > creates two messages with the same hash, but you don't get to choo= se
> either of the messages). =C2=A0It's not a second preimage attack, = which is
> what you would need to be able to create a message that hashes to the<= br> > same value of an existing message.
>
> (And it neither have anything to do with the birthday paradox, BTW - > which relates to the chance of eventually finding two messages that > hash to the same value by pure change)
>
> If someone gets malicious code into the repo, it's going to be by<= br> > social engineering, not by breaking the cyrpto.
>
> roy
>
> On Tue, Apr 02, 2013 at 12:27:51AM +0200, Melvin Carvalho wrote:
> > On 2 April 2013 00:10, Will <will@phase.net> wrote:
> >
> > > The threat of a SHA1 collision attack to insert a malicious = pull request
> > > are tiny compared with the other threats - e.g. github being= compromised,
> > > one of the core developers' passwords being compromised,= one of the core
> > > developers going rogue, sourceforge (distribution site) bein= g compromised
> > > etc etc... believe me there's a lot more to worry about = than a SHA1
> > > attack...
> > >
> > > Not meaning to scare, just to put things in perspective - th= is is why we
> > > all need to peer review each others commits and keep an eye = out for
> > > suspicious commits, leverage the benefits of this project be= ing open source
> > > and easily peer reviewed.
> > >
> >
> > Very good points, and I think you're absolutely right.
> >
> > But just running the numbers, to get the picture, based of schein= er's
> > statistics:
> >
> > http://www.schneier.com/blog/archives/2012/= 10/when_will_we_se.html
> >
> > We're talking about a million terrahashes =3D 2^60 right?
> >
> > With the block chain, you only have a 10 minute window, but with = source
> > code you have a longer time to prepare.
> >
> > Couldnt this be done with an ASIC in about a week?
> >
> >
> >
> > >
> > > Will
> > >
> > >
> > > On 1 April 2013 23:52, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> > >
> > >>
> > >>
> > >>
> > >> On 1 April 2013 20:28, Petr Praus <petr@praus.net> wrote:
> > >>
> > >>> An attacker would have to find a collision between t= wo specific pieces
> > >>> of code - his malicious code and a useful innoculous= code that would be
> > >>> accepted as pull request. This is the second, much h= arder case in the
> > >>> birthday problem. When people talk about SHA-1 being= broken they actually
> > >>> mean the first case in the birthday problem - find a= ny two arbitrary values
> > >>> that hash to the same value. So, no I don't thin= k it's a feasible attack
> > >>> vector any time soon.
> > >>>
> > >>> Besides, with that kind of hashing power, it might b= e more feasible to
> > >>> cause problems in the chain by e.g. constantly split= ting it.
> > >>>
> > >>
> > >> OK, maybe im being *way* too paranoid here ... but what = if someone had
> > >> access to github, could they replace one file with one t= hey had prepared at
> > >> some point?
> > >>
> > >>
> > >>>
> > >>>
> > >>> On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho@gmail.com> wrote= :
> > >>>
> > >>>> =C2=A0I was just looking at:
> > >>>>
> > >>>> https://bitcointalk.org/index.php?topic=3D45= 71.0
> > >>>>
> > >>>> I'm just curious if there is a possible atta= ck vector here based on the
> > >>>> fact that git uses the relatively week SHA1
> > >>>>
> > >>>> Could a seemingly innocuous pull request generat= e another file with a
> > >>>> backdoor/nonce combination that slips under the = radar?
> > >>>>
> > >>>> Apologies if this has come up before ...
> > >>>>
> > >>>>
> > >>>> ------------------------------------------------= ------------------------------
> > >>>> Own the Future-Intel&reg; Level Up Game Demo= Contest 2013
> > >>>> Rise to greatness in Intel's independent gam= e demo contest.
> > >>>> Compete for recognition, cash, and the chance to= get your game
> > >>>> on Steam. $5K grand prize plus 10 genre and skil= l prizes.
> > >>>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_le= velupd2d
> > >>>> _______________________________________________<= br> > > >>>> Bitcoin-development mailing list
> > >>>> Bitcoin-development@lists.sourceforge.net
> > >>>> https://lists.sourceforge.ne= t/lists/listinfo/bitcoin-development
> > >>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >> --------------------------------------------------------= ----------------------
> > >> Own the Future-Intel&reg; Level Up Game Demo Contest= 2013
> > >> Rise to greatness in Intel's independent game demo c= ontest.
> > >> Compete for recognition, cash, and the chance to get you= r game
> > >> on Steam. $5K grand prize plus 10 genre and skill prizes= .
> > >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d=
> > >> _______________________________________________
> > >> Bitcoin-development mailing list
> > >> Bitcoin-development@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/= listinfo/bitcoin-development
> > >>
> > >>
> > >
>
> > -----------------------------------------------------------------= -------------
> > Own the Future-Intel&reg; Level Up Game Demo Contest 2013
> > Rise to greatness in Intel's independent game demo contest. > > Compete for recognition, cash, and the chance to get your game > > on Steam. $5K grand prize plus 10 genre and skill prizes.
> > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
>
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitc= oin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/= bitcoin-development
>
>
> ----------------------------------------------------------------------= --------
> Own the Future-Intel&reg; Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-d= evelopment@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitco= in-development
>

---------------------------------------------------------------------------= ---
Own the Future-Intel&reg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--bcaec52c69cbeb2e8b04d96ca096-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UNEqa-00042f-1b for bitcoin-development@lists.sourceforge.net; Wed, 03 Apr 2013 03:58:52 +0000 X-ACL-Warn: Received: from mail-pa0-f53.google.com ([209.85.220.53]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UNEqY-0000SN-Kv for bitcoin-development@lists.sourceforge.net; Wed, 03 Apr 2013 03:58:52 +0000 Received: by mail-pa0-f53.google.com with SMTP id bh4so663634pad.12 for ; Tue, 02 Apr 2013 20:58:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=EYl2Dk8+5cZKtdErjBrFPFnj5gKK3/EUvmZItzDiPAA=; b=YhVvqGynp4yQjdPaiGT5cTheXviNG6xKTj59zUe98xgT9LrcZjNWfvtelgewBwUpzb FJy8KTjtWznmLL7JQQR7kBjcLEmcKX/6BhLeDdGb7+0gLirmaUXCWvl9Kb7P0Mt1mlX5 AGEILIbzkXQpQGM9wEghsOaOaxWhFZXxYS453eMUg4QV6JiqCC+ovgwDBqPs3FHgwgcm w1cQtM6Rd7og0bxqPzNZBgaV4wVYmUQZXX7phsSVDXwj3Csa7EBWye685MhC2TizKvN8 jA3bsMSfCt2Mb660Hs/j2HxUVoPKoD/+BHCBoVu+IRW9yMHrBYRfoCs90T+dy/mwIsOH eUdQ== MIME-Version: 1.0 X-Received: by 10.66.161.33 with SMTP id xp1mr843582pab.36.1364961105522; Tue, 02 Apr 2013 20:51:45 -0700 (PDT) Received: by 10.68.253.35 with HTTP; Tue, 2 Apr 2013 20:51:45 -0700 (PDT) X-Originating-IP: [99.43.178.25] In-Reply-To: References: <20130401225107.GU65880@giles.gnomon.org.uk> <20130401225417.GV65880@giles.gnomon.org.uk> Date: Tue, 2 Apr 2013 23:51:45 -0400 Message-ID: From: Jeff Garzik To: Wladimir Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmX8dGMpQO5rxI6tgsd3GmETxzt3OAn9Gr6l/OmKsL8SJeSBT+2AvOcM4d6OMoq8ZXTXbuw X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1UNEqY-0000SN-Kv Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] bitcoin pull requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 03:58:52 -0000 On Tue, Apr 2, 2013 at 11:41 PM, Wladimir wrote: > Maybe now that bitcoin is growing out of the toy phase it's an idea to start > gpg signing commits, like the Linux kernel > (https://lwn.net/Articles/466468/). > > But I suppose then we can't use github anymore to merge as-is and need > manual steps? Correct, that rules out github, AFAICS. Though, honestly, when I ACK that means I read the code, which is more important than the author really. github seems fine for that still, though I do wonder if there is a race possible, * sneak uploads innocent branch sneak/bitcoin.git #innocent * sneak creates pull req * just before I click "pull", sneak rebases the branch to something evil -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti.com From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UNPzc-0001aB-KX for bitcoin-development@lists.sourceforge.net; Wed, 03 Apr 2013 15:52:56 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.128.170 as permitted sender) client-ip=209.85.128.170; envelope-from=grarpamp@gmail.com; helo=mail-ve0-f170.google.com; Received: from mail-ve0-f170.google.com ([209.85.128.170]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UNPzb-0000le-J2 for bitcoin-development@lists.sourceforge.net; Wed, 03 Apr 2013 15:52:56 +0000 Received: by mail-ve0-f170.google.com with SMTP id 15so1821896vea.15 for ; Wed, 03 Apr 2013 08:52:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.205.179 with SMTP id lh19mr1689422vec.7.1365004370003; Wed, 03 Apr 2013 08:52:50 -0700 (PDT) Received: by 10.220.115.7 with HTTP; Wed, 3 Apr 2013 08:52:49 -0700 (PDT) In-Reply-To: References: <20130401225107.GU65880@giles.gnomon.org.uk> <20130401225417.GV65880@giles.gnomon.org.uk> Date: Wed, 3 Apr 2013 11:52:49 -0400 Message-ID: From: grarpamp To: bitcoin-development@lists.sourceforge.net Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (grarpamp[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UNPzb-0000le-J2 Subject: Re: [Bitcoin-development] bitcoin pull requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 15:52:56 -0000 >> gpg signing commits, like the Linux kernel > Though, honestly, when I ACK that means I read the code, which is more > important than the author really. github seems fine for that still, > though I do wonder if there is a race possible, > > * just before I click "pull", sneak rebases the branch to something evil You might want to look at http://www.monotone.ca/, it does a good job of integrating crypto and review primitives into the workflow. It also has some reliable network distribution models (netsync) that work well over things like Tor, in case a new developer (or old Satoshi) doesn't wish to be in the public light. http://www.monotone.ca/monotone.html Once you have the crypto, it always boils down to human risk factors, rogue, password, cracks, etc which are harder. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UNQC2-00047K-Pl for bitcoin-development@lists.sourceforge.net; Wed, 03 Apr 2013 16:05:46 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.173 as permitted sender) client-ip=209.85.212.173; envelope-from=gavinandresen@gmail.com; helo=mail-wi0-f173.google.com; Received: from mail-wi0-f173.google.com ([209.85.212.173]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UNQC2-0001wH-1d for bitcoin-development@lists.sourceforge.net; Wed, 03 Apr 2013 16:05:46 +0000 Received: by mail-wi0-f173.google.com with SMTP id ez12so3804695wid.0 for ; Wed, 03 Apr 2013 09:05:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.97.132 with SMTP id ea4mr3698419wib.23.1365005139828; Wed, 03 Apr 2013 09:05:39 -0700 (PDT) Received: by 10.194.157.168 with HTTP; Wed, 3 Apr 2013 09:05:39 -0700 (PDT) In-Reply-To: References: <20130401225107.GU65880@giles.gnomon.org.uk> <20130401225417.GV65880@giles.gnomon.org.uk> Date: Wed, 3 Apr 2013 12:05:39 -0400 Message-ID: From: Gavin Andresen To: Bitcoin Dev Content-Type: multipart/alternative; boundary=f46d04426c4e79e91304d977061e X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UNQC2-0001wH-1d Subject: Re: [Bitcoin-development] bitcoin pull requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 16:05:47 -0000 --f46d04426c4e79e91304d977061e Content-Type: text/plain; charset=ISO-8859-1 I would rather we spend time working to make users' bitcoins safe EVEN IF their bitcoin software is compromised. Eliminate the "if you get a bad bitcoin-qt.exe somehow you're in big trouble" risk entirely, instead of worrying about unlikely scenarios like a timing attack in between ACKs/pulls. Eliminate one piece of software as the possible single point of failure... -- -- Gavin Andresen --f46d04426c4e79e91304d977061e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would rather we spend time working to make users' bitcoins safe EVEN = IF their bitcoin software is compromised.

Eliminate the = "if you get a bad bitcoin-qt.exe somehow you're in big trouble&quo= t; risk entirely, instead of worrying about unlikely scenarios like a timin= g attack in between ACKs/pulls. Eliminate one piece of software as the poss= ible single point of failure...

--=A0
--
Gavin Andresen
--f46d04426c4e79e91304d977061e-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UNQT9-0007Tl-Vy for bitcoin-development@lists.sourceforge.net; Wed, 03 Apr 2013 16:23:28 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.51 as permitted sender) client-ip=209.85.212.51; envelope-from=grarpamp@gmail.com; helo=mail-vb0-f51.google.com; Received: from mail-vb0-f51.google.com ([209.85.212.51]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UNQT9-0005jA-E2 for bitcoin-development@lists.sourceforge.net; Wed, 03 Apr 2013 16:23:27 +0000 Received: by mail-vb0-f51.google.com with SMTP id x19so595268vbf.10 for ; Wed, 03 Apr 2013 09:23:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.59.11.199 with SMTP id ek7mr1824216ved.19.1365006201841; Wed, 03 Apr 2013 09:23:21 -0700 (PDT) Received: by 10.220.115.7 with HTTP; Wed, 3 Apr 2013 09:23:21 -0700 (PDT) In-Reply-To: References: <20130401225107.GU65880@giles.gnomon.org.uk> <20130401225417.GV65880@giles.gnomon.org.uk> Date: Wed, 3 Apr 2013 12:23:21 -0400 Message-ID: From: grarpamp To: bitcoin-development@lists.sourceforge.net Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (grarpamp[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UNQT9-0005jA-E2 Subject: Re: [Bitcoin-development] bitcoin pull requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 16:23:28 -0000 > Eliminate the "if you get a bad bitcoin-qt.exe somehow you're in big > trouble" risk entirely This isn't really possible. A trojaned client will spend your coin as easily as the owner can, passphrases will be logged, windows box will be owned, secondary remote spendauth sigs into the network chain break similarly, securely hashcheck the trojaned client from cracked userspace on a hacked dll/kernel with uefi backdoor and a trojaned hasher, etc. It's easier for a few developers to meet in person to init and sig a new repo than to try fixing the world's userland and users :) At least that way you get something verifiable back to the root. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UNSAs-0001uq-7O for bitcoin-development@lists.sourceforge.net; Wed, 03 Apr 2013 18:12:42 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.182 as permitted sender) client-ip=209.85.220.182; envelope-from=grarpamp@gmail.com; helo=mail-vc0-f182.google.com; Received: from mail-vc0-f182.google.com ([209.85.220.182]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UNSAr-0007WT-9Q for bitcoin-development@lists.sourceforge.net; Wed, 03 Apr 2013 18:12:42 +0000 Received: by mail-vc0-f182.google.com with SMTP id ht11so1699386vcb.41 for ; Wed, 03 Apr 2013 11:12:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.68.235 with SMTP id z11mr1783033vdt.107.1365012755774; Wed, 03 Apr 2013 11:12:35 -0700 (PDT) Received: by 10.220.115.7 with HTTP; Wed, 3 Apr 2013 11:12:35 -0700 (PDT) In-Reply-To: References: <20130401225107.GU65880@giles.gnomon.org.uk> <20130401225417.GV65880@giles.gnomon.org.uk> Date: Wed, 3 Apr 2013 14:12:35 -0400 Message-ID: From: grarpamp To: bitcoin-development@lists.sourceforge.net Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (grarpamp[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UNSAr-0007WT-9Q Subject: Re: [Bitcoin-development] bitcoin pull requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 18:12:42 -0000 > Users will have available multisig addresses which require > transactions to be signed off by a wallet HSM. (E.g. a keyfob Hardware is a good thing. But only if you do the crypto in the hardware and trust the hardware and its attack models ;) For instance, the fingerprint readers you see everywhere... many of them just present the raw fingerprint scan to the host (and host software), instead of hashing the fingerprint internally and using that as primitive in crypto exchanges with the host. They cheaped out and/or didn't think. So oops, there went both your security (host replay) and your personal privacy (biometrics), outside of your control. All with no protection against physical fingerprint lifting. > This doesn't remove the need to improve repository integrity. ... but > repository integrity is a general problem that is applicable to many > things (after all, what does it matter if you can't compromise Bitcoin > if you can compromise boost, openssl, or gcc?) Yes, that case would matter zero to the end product. However having a strong repo permits better auditing of the BTC codebase. That's a good thing, and eliminates the need to talk chicken and egg. > It's probably best > that Bitcoin specalists stay focused on Bitcoin security measures, and > other people interested in repository security come and help out > improving it. An obvious area of improvement might be oddity > detection and alerting: It's weird that I can rewrite history on > github, so long as I do it quickly, without anyone noticing. If no one is verifying the repo, sure, even entire repos could be swapped out for seemingly identical ones. Many repos do not have any strong internal verification structures at all, and they run on filesystems that accept bitrot. Take a look at some OS's... OpenBSD and FreeBSD, supposedly the more secure ones out there... both use legacy repos on FFS. Seems rather ironic in the lol department. Thankfully some people out there are finally getting a clue on these issues, making and learning the tools, converting and migrating things, working on top down signed build and distribution chain, etc... so maybe in ten years the opensource world will be much farther ahead. Or at least have a strong audit trail. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UNgCa-0007W8-2Z for bitcoin-development@lists.sourceforge.net; Thu, 04 Apr 2013 09:11:24 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.172 as permitted sender) client-ip=209.85.214.172; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f172.google.com; Received: from mail-ob0-f172.google.com ([209.85.214.172]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UNgCY-0005HZ-A2 for bitcoin-development@lists.sourceforge.net; Thu, 04 Apr 2013 09:11:24 +0000 Received: by mail-ob0-f172.google.com with SMTP id tb18so2315371obb.17 for ; Thu, 04 Apr 2013 02:11:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.151.9 with SMTP id um9mr3430376obb.89.1365066675602; Thu, 04 Apr 2013 02:11:15 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.162.198 with HTTP; Thu, 4 Apr 2013 02:11:15 -0700 (PDT) In-Reply-To: References: <20130401225107.GU65880@giles.gnomon.org.uk> <20130401225417.GV65880@giles.gnomon.org.uk> Date: Thu, 4 Apr 2013 10:11:15 +0100 X-Google-Sender-Auth: 9SG0Og0cCEGnad5AXPyStwOxh84 Message-ID: From: Mike Hearn To: grarpamp Content-Type: multipart/alternative; boundary=f46d0444e9254b4b6f04d9855a8b X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UNgCY-0005HZ-A2 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] bitcoin pull requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 09:11:24 -0000 --f46d0444e9254b4b6f04d9855a8b Content-Type: text/plain; charset=UTF-8 My general hope/vague plan for bitcoinj based wallets is to get them all on to automatic updates with threshold signatures. Combined with regular audits of the initial downloads for new users, that should give a pretty safe result that is immune to a developer going rogue. On Wed, Apr 3, 2013 at 7:12 PM, grarpamp wrote: > > Users will have available multisig addresses which require > > transactions to be signed off by a wallet HSM. (E.g. a keyfob > > Hardware is a good thing. But only if you do the crypto in the > hardware and trust the hardware and its attack models ;) For > instance, the fingerprint readers you see everywhere... many > of them just present the raw fingerprint scan to the host (and > host software), instead of hashing the fingerprint internally and > using that as primitive in crypto exchanges with the host. They > cheaped out and/or didn't think. So oops, there went both your > security (host replay) and your personal privacy (biometrics), > outside of your control. All with no protection against physical > fingerprint lifting. > > > This doesn't remove the need to improve repository integrity. ... but > > repository integrity is a general problem that is applicable to many > > things (after all, what does it matter if you can't compromise Bitcoin > > if you can compromise boost, openssl, or gcc?) > > Yes, that case would matter zero to the end product. However > having a strong repo permits better auditing of the BTC codebase. > That's a good thing, and eliminates the need to talk chicken and > egg. > > > It's probably best > > that Bitcoin specalists stay focused on Bitcoin security measures, and > > other people interested in repository security come and help out > > improving it. An obvious area of improvement might be oddity > > detection and alerting: It's weird that I can rewrite history on > > github, so long as I do it quickly, without anyone noticing. > > If no one is verifying the repo, sure, even entire repos could be > swapped out for seemingly identical ones. > > Many repos do not have any strong internal verification structures > at all, and they run on filesystems that accept bitrot. > Take a look at some OS's... OpenBSD and FreeBSD, supposedly > the more secure ones out there... both use legacy repos on FFS. > Seems rather ironic in the lol department. > > Thankfully some people out there are finally getting a clue on these > issues, making and learning the tools, converting and migrating > things, working on top down signed build and distribution chain, etc... > so maybe in ten years the opensource world will be much farther > ahead. Or at least have a strong audit trail. > > > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --f46d0444e9254b4b6f04d9855a8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My general hope/vague plan for bitcoinj based wallets is t= o get them all on to automatic updates with threshold signatures. Combined = with regular audits of the initial downloads for new users, that should giv= e a pretty safe result that is immune to a developer going rogue.


On Wed, Apr 3= , 2013 at 7:12 PM, grarpamp <grarpamp@gmail.com> wrote:
=
> Users will have available multisig addresses which require
> transactions to be signed off by a wallet HSM. (E.g. a keyfob

Hardware is a good thing. But only if you do the crypto in the
hardware and trust the hardware and its attack models ;) For
instance, the fingerprint readers you see everywhere... many
of them just present the raw fingerprint scan to the host (and
host software), instead of hashing the fingerprint internally and
using that as primitive in crypto exchanges with the host. They
cheaped out and/or didn't think. So oops, there went both your
security (host replay) and your personal privacy (biometrics),
outside of your control. All with no protection against physical
fingerprint lifting.

> This doesn't remove the need to improve repository integrity. ... = but
> repository integrity is a general problem that is applicable to many > things (after all, what does it matter if you can't compromise Bit= coin
> if you can compromise boost, openssl, or gcc?)

Yes, that case would matter zero to the end product. However
having a strong repo permits better auditing of the BTC codebase.
That's a good thing, and eliminates the need to talk chicken and
egg.

> It's probably best
> that Bitcoin specalists stay focused on Bitcoin security measures, and=
> other people interested in repository security come and help out
> improving it. =C2=A0An obvious area of improvement might be oddity
> detection and alerting: =C2=A0It's weird that I can rewrite histor= y on
> github, so long as I do it quickly, without anyone noticing.

If no one is verifying the repo, sure, even entire repos could be
swapped out for seemingly identical ones.

Many repos do not have any strong internal verification structures
at all, and they run on filesystems that accept bitrot.
Take a look at some OS's... OpenBSD and FreeBSD, supposedly
the more secure ones out there... both use legacy repos on FFS.
Seems rather ironic in the lol department.

Thankfully some people out there are finally getting a clue on these
issues, making and learning the tools, converting and migrating
things, working on top down signed build and distribution chain, etc...
so maybe in ten years the opensource world will be much farther
ahead. Or at least have a strong audit trail.

---------------------------------------------------------------------------= ---
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/ind= ex.html
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--f46d0444e9254b4b6f04d9855a8b-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UNh1x-0008Em-3U for bitcoin-development@lists.sourceforge.net; Thu, 04 Apr 2013 10:04:29 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.52 as permitted sender) client-ip=209.85.219.52; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f52.google.com; Received: from mail-oa0-f52.google.com ([209.85.219.52]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UNh1v-00010Q-Pc for bitcoin-development@lists.sourceforge.net; Thu, 04 Apr 2013 10:04:29 +0000 Received: by mail-oa0-f52.google.com with SMTP id k14so2482008oag.25 for ; Thu, 04 Apr 2013 03:04:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.80.4 with SMTP id n4mr3496668oex.141.1365069862423; Thu, 04 Apr 2013 03:04:22 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.162.198 with HTTP; Thu, 4 Apr 2013 03:04:22 -0700 (PDT) In-Reply-To: References: <20130401225107.GU65880@giles.gnomon.org.uk> <20130401225417.GV65880@giles.gnomon.org.uk> Date: Thu, 4 Apr 2013 11:04:22 +0100 X-Google-Sender-Auth: ZmnLER8pUTNNwNQoL3btdQcA6sI Message-ID: From: Mike Hearn To: grarpamp Content-Type: multipart/alternative; boundary=089e0122789e3e560904d9861803 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UNh1v-00010Q-Pc Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] bitcoin pull requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 10:04:29 -0000 --089e0122789e3e560904d9861803 Content-Type: text/plain; charset=UTF-8 By the way, I have a download of the Bitcoin-Qt client and signature verification running in a cron job. On Thu, Apr 4, 2013 at 10:11 AM, Mike Hearn wrote: > My general hope/vague plan for bitcoinj based wallets is to get them all > on to automatic updates with threshold signatures. Combined with regular > audits of the initial downloads for new users, that should give a pretty > safe result that is immune to a developer going rogue. > > > On Wed, Apr 3, 2013 at 7:12 PM, grarpamp wrote: > >> > Users will have available multisig addresses which require >> > transactions to be signed off by a wallet HSM. (E.g. a keyfob >> >> Hardware is a good thing. But only if you do the crypto in the >> hardware and trust the hardware and its attack models ;) For >> instance, the fingerprint readers you see everywhere... many >> of them just present the raw fingerprint scan to the host (and >> host software), instead of hashing the fingerprint internally and >> using that as primitive in crypto exchanges with the host. They >> cheaped out and/or didn't think. So oops, there went both your >> security (host replay) and your personal privacy (biometrics), >> outside of your control. All with no protection against physical >> fingerprint lifting. >> >> > This doesn't remove the need to improve repository integrity. ... but >> > repository integrity is a general problem that is applicable to many >> > things (after all, what does it matter if you can't compromise Bitcoin >> > if you can compromise boost, openssl, or gcc?) >> >> Yes, that case would matter zero to the end product. However >> having a strong repo permits better auditing of the BTC codebase. >> That's a good thing, and eliminates the need to talk chicken and >> egg. >> >> > It's probably best >> > that Bitcoin specalists stay focused on Bitcoin security measures, and >> > other people interested in repository security come and help out >> > improving it. An obvious area of improvement might be oddity >> > detection and alerting: It's weird that I can rewrite history on >> > github, so long as I do it quickly, without anyone noticing. >> >> If no one is verifying the repo, sure, even entire repos could be >> swapped out for seemingly identical ones. >> >> Many repos do not have any strong internal verification structures >> at all, and they run on filesystems that accept bitrot. >> Take a look at some OS's... OpenBSD and FreeBSD, supposedly >> the more secure ones out there... both use legacy repos on FFS. >> Seems rather ironic in the lol department. >> >> Thankfully some people out there are finally getting a clue on these >> issues, making and learning the tools, converting and migrating >> things, working on top down signed build and distribution chain, etc... >> so maybe in ten years the opensource world will be much farther >> ahead. Or at least have a strong audit trail. >> >> >> ------------------------------------------------------------------------------ >> Minimize network downtime and maximize team effectiveness. >> Reduce network management and security costs.Learn how to hire >> the most talented Cisco Certified professionals. Visit the >> Employer Resources Portal >> http://www.cisco.com/web/learning/employer_resources/index.html >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > --089e0122789e3e560904d9861803 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
By the way, I have a download of the Bitcoin-Qt client and= signature verification running in a cron job.=C2=A0


On Thu, Apr 4, 2013 at 10:11 A= M, Mike Hearn <mike@plan99.net> wrote:
My general hope/vague plan = for bitcoinj based wallets is to get them all on to automatic updates with = threshold signatures. Combined with regular audits of the initial downloads= for new users, that should give a pretty safe result that is immune to a d= eveloper going rogue.


On Wed, Apr 3= , 2013 at 7:12 PM, grarpamp <grarpamp@gmail.com> wrote:
=
> Users will have available multisig addresses which require
> transactions to be signed off by a wallet HSM. (E.g. a keyfob

Hardware is a good thing. But only if you do the crypto in the
hardware and trust the hardware and its attack models ;) For
instance, the fingerprint readers you see everywhere... many
of them just present the raw fingerprint scan to the host (and
host software), instead of hashing the fingerprint internally and
using that as primitive in crypto exchanges with the host. They
cheaped out and/or didn't think. So oops, there went both your
security (host replay) and your personal privacy (biometrics),
outside of your control. All with no protection against physical
fingerprint lifting.

> This doesn't remove the need to improve repository integrity. ... = but
> repository integrity is a general problem that is applicable to many > things (after all, what does it matter if you can't compromise Bit= coin
> if you can compromise boost, openssl, or gcc?)

Yes, that case would matter zero to the end product. However
having a strong repo permits better auditing of the BTC codebase.
That's a good thing, and eliminates the need to talk chicken and
egg.

> It's probably best
> that Bitcoin specalists stay focused on Bitcoin security measures, and=
> other people interested in repository security come and help out
> improving it. =C2=A0An obvious area of improvement might be oddity
> detection and alerting: =C2=A0It's weird that I can rewrite histor= y on
> github, so long as I do it quickly, without anyone noticing.

If no one is verifying the repo, sure, even entire repos could be
swapped out for seemingly identical ones.

Many repos do not have any strong internal verification structures
at all, and they run on filesystems that accept bitrot.
Take a look at some OS's... OpenBSD and FreeBSD, supposedly
the more secure ones out there... both use legacy repos on FFS.
Seems rather ironic in the lol department.

Thankfully some people out there are finally getting a clue on these
issues, making and learning the tools, converting and migrating
things, working on top down signed build and distribution chain, etc...
so maybe in ten years the opensource world will be much farther
ahead. Or at least have a strong audit trail.

---------------------------------------------------------------------------= ---
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/ind= ex.html
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--089e0122789e3e560904d9861803--