Bitcoin Forum
December 09, 2016, 09:55:59 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3] 4 »  All
  Print  
Author Topic: Please remove Bitcoin from Sourceforge.net  (Read 5003 times)
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
August 18, 2011, 04:39:12 AM
 #41

If someone shows up and wants to host a mirror in a country that we are allowed to export to, and that doesn't itself prohibit distribution to other countries, that person will find plenty of people willing and eager to help set things up.

Well, as far as i know sourceforge redirects download links to the geographically closest mirrors from where the download is requested, but people in those block lists don't even get redirected, they just get the part of their terms that say they are on the "forbidden" list, go figure...

So, i guess what you are saying is not the complete truth. Doesn't matter how many mirrors they have, the result will be the same. Unless you weren't talking about sourceforge in that paragraph and i understood you wrong. If so, I apologize, and ask for clarification about that statement.

Since the topic is getting around SourceForge's compliance with US Government policy, I had thought that it was pretty obvious that I was talking about a non-SF mirror.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
1481277359
Hero Member
*
Offline Offline

Posts: 1481277359

View Profile Personal Message (Offline)

Ignore
1481277359
Reply with quote  #2

1481277359
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481277359
Hero Member
*
Offline Offline

Posts: 1481277359

View Profile Personal Message (Offline)

Ignore
1481277359
Reply with quote  #2

1481277359
Report to moderator
1481277359
Hero Member
*
Offline Offline

Posts: 1481277359

View Profile Personal Message (Offline)

Ignore
1481277359
Reply with quote  #2

1481277359
Report to moderator
EricJ2190
Full Member
***
Offline Offline

Activity: 134


View Profile
August 18, 2011, 04:47:51 AM
 #42

Quote from: EricJ2190 link=topic=37687.msg464529#msg464529 date=1313641383
I assume you are referring to this: [url=http://courses.csail.mit.edu/6.885/spring05/papers/wangyinyu.pdf
Collision Search Attacks on SHA1[/url]

This only demonstrates a collision of SHA1 with a reduced number of rounds. Their research does reduce the complexity of an attack on full the 80-round SHA1, but not enough that anyone has been able to produce a full collision.

Scary stuff, and a very good reason to move to something better, but, at least for now, an attacker can't tamper with a file without changing the SHA1 hash.

By the way, I am using the term "broken" to mean that actual collisions have been found or could reasonably be found with current technology. If you use "broken" to mean that there is a known attack faster than a birthday attack, then SHA1 is definitely broken.

That is the right authors, but not the later paper,  they have another one that shows it to be much weaker yet.  Came out about 4 or 5 months later.  It is not recommended to use sha-1 in any new projects any more.  I personally would use two very different hashing algos to publish official binaries for  something like bitcoins.


I do think we may be using different definitions,  I think you are talking about what I would call cracked, and it is not cracked yet in any public papers I know of.

There are more attack that do make it weaker. Just no collisions yet. But I completely agree that it should not be used in new projects.

Bruce Schneier agrees with you the this counts as "broken." I am just not a big fan of that specific definition of broken since it would mean that algorithms like AES that are still quite strong would count as "broken."

What's wrong with just using SHA-1?

The the signed hash list is right along-side the binaries:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/

While we are on this side topic,  I would like to point out that hosting the signature files right along side the binaries is also probably not the best idea.  If I can replace files on sf I would just replace both now.

Sure, you could replace SHA1SUMS.asc, but you wouldn't be able to change it without invalidating the PGP signature.
twobits
Sr. Member
****
Offline Offline

Activity: 336

Firstbits: 1a6taw


View Profile
August 18, 2011, 04:51:28 AM
 #43


While we are on this side topic,  I would like to point out that hosting the signature files right along side the binaries is also probably not the best idea.  If I can replace files on sf I would just replace both now.

Sure, you could replace SHA1SUMS.asc, but you wouldn't be able to change it without invalidating the PGP signature.


Should be true,  but where does it show who is supposed to be signing it and the information for me to check it?  Right now if someone else signed it , or it even showed up as an unsigned file, as a user, downloading from the links on the front page, would I ever know? I still need more information from a source that is not sf to test this.


twobits
Sr. Member
****
Offline Offline

Activity: 336

Firstbits: 1a6taw


View Profile
August 18, 2011, 04:54:48 AM
 #44



Bruce Schneier agrees with you the this counts as "broken." I am just not a big fan of that specific definition of broken since it would mean that algorithms like AES that are still quite strong would count as "broken."


Yeah, I probably inadvertently picked up his usage of the terms, as the first I really learned about this was talking to him at a Usenix conference.

twobits
Sr. Member
****
Offline Offline

Activity: 336

Firstbits: 1a6taw


View Profile
August 18, 2011, 05:00:42 AM
 #45

If someone shows up and wants to host a mirror in a country that we are allowed to export to, and that doesn't itself prohibit distribution to other countries, that person will find plenty of people willing and eager to help set things up.

Well, as far as i know sourceforge redirects download links to the geographically closest mirrors from where the download is requested, but people in those block lists don't even get redirected, they just get the part of their terms that say they are on the "forbidden" list, go figure...

So, i guess what you are saying is not the complete truth. Doesn't matter how many mirrors they have, the result will be the same. Unless you weren't talking about sourceforge in that paragraph and i understood you wrong. If so, I apologize, and ask for clarification about that statement.

Since the topic is getting around SourceForge's compliance with US Government policy, I had thought that it was pretty obvious that I was talking about a non-SF mirror.

May a bittorent distribution could be used as well?

Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
August 18, 2011, 06:49:52 AM
 #46


While we are on this side topic,  I would like to point out that hosting the signature files right along side the binaries is also probably not the best idea.  If I can replace files on sf I would just replace both now.

Sure, you could replace SHA1SUMS.asc, but you wouldn't be able to change it without invalidating the PGP signature.


Should be true,  but where does it show who is supposed to be signing it and the information for me to check it?  Right now if someone else signed it , or it even showed up as an unsigned file, as a user, downloading from the links on the front page, would I ever know? I still need more information from a source that is not sf to test this.
The simple reality is, if you don't already know who the trusted developers are, how could you trust who the site says should be signing it? Point is, it'd create a false sense of security if the site said who can be trusted to sign the files.

As long as somebody can verify the files as having not come from a trusted developer, the word will spread that SourceForge was hacked. That would be the end of SourceForge.

By the way, Jeff Garzik is a trusted developer.

film2240
Legendary
*
Offline Offline

Activity: 994


Professional filmmaker/Freelance videographer


View Profile WWW
August 18, 2011, 12:23:41 PM
 #47

For those of you concerned about privacy and other stuff,I suggest we try mirrors based on Icelandic or Swiss servers due to good protection (Neither of these are in the EU yet so won't be subject to the monitoring of internet communications laws as such,however this is no guarantee that there won't be these types of laws in the future).I know because I live in a country that's part of the EU.

[This signature is available for rent]
[This signature is available for rent]
[This signature is available for rent]
[This signature is available for rent]
davout
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
August 18, 2011, 12:24:32 PM
 #48

The bitcoin binaries are now mirrored and available for download on Bitcoin-Central.net

twobits
Sr. Member
****
Offline Offline

Activity: 336

Firstbits: 1a6taw


View Profile
August 18, 2011, 01:14:26 PM
 #49


While we are on this side topic,  I would like to point out that hosting the signature files right along side the binaries is also probably not the best idea.  If I can replace files on sf I would just replace both now.

Sure, you could replace SHA1SUMS.asc, but you wouldn't be able to change it without invalidating the PGP signature.


Should be true,  but where does it show who is supposed to be signing it and the information for me to check it?  Right now if someone else signed it , or it even showed up as an unsigned file, as a user, downloading from the links on the front page, would I ever know? I still need more information from a source that is not sf to test this.
The simple reality is, if you don't already know who the trusted developers are, how could you trust who the site says should be signing it? Point is, it'd create a false sense of security if the site said who can be trusted to sign the files.

As long as somebody can verify the files as having not come from a trusted developer, the word will spread that SourceForge was hacked. That would be the end of SourceForge.

By the way, Jeff Garzik is a trusted developer.


hmm...  http://sourceforge.net/apps/wordpress/sourceforge/2011/01/27/sourceforge-net-attack-update/  they still seem to be around,  also recall issues  7 years or so back.  They also do not need to compromise sf,  just the accounts that can update the bitcoin stuff.  Hopefully it is not the same user  account that can update the binaries and change the bitcoin.org page!



The simple idea is that adding another factor makes distributing compromised binaries a lot more likely to be caught quickly.  It also gives me as a user some steps I can take to try and protect myself, rather then waiting for someone else to maybe verify it.  How often is it being checked really?  When set up properly I should at least know that it required tampering with two sites and/or two different users to spoof me. (of course I need to make sure my dns is not spoofed etc etc.... but this would still be a lot better then how it is right now)

It still all is moot though.  As the bitcoin.org site itself is hosted on sourceforge.  So even now that I know this,  I am still not protected, as you are right I can not trust the site to confirm sf is not giving me bad files, even knowing who's sig to now check.

One issue brought up was what if some government orders sf to plant a tampered binary.  They say give all those Freedoinians this binary instead.  Now  sf sets up geotargeting so they get those binaries and their version of the sf page.  Even knowing to check it with Jeff's signature, they get results that say it is ok.  Odds that the people that do check the signature are in the targeted country are also pretty low.  If the person that can check is not being targeted,  it does not matter that they can check even if they do it ever minute.

twobits
Sr. Member
****
Offline Offline

Activity: 336

Firstbits: 1a6taw


View Profile
August 18, 2011, 01:25:19 PM
 #50

The bitcoin binaries are now mirrored and available for download on Bitcoin-Central.net

May want to add a link to the verification file and the signature to use to verify it.

zellfaze
Full Member
***
Offline Offline

Activity: 142


Security Enthusiast


View Profile WWW
August 18, 2011, 02:02:24 PM
 #51

Would it be possible to use Code Signing to actually sing the executable themselves?  At least on Windows this would be effective as far as I know.

A+, CCENT, CCNA
Security Enthusiast
PHP Coder

Not that I expect anyone to, but should you like my post, please donate:
Donate: 1BRbfqii6Sm9tEUE8A16H7QeDmYFjyBZ7V
davout
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
August 18, 2011, 02:15:01 PM
 #52

May want to add a link to the verification file and the signature to use to verify it.
No. I trust myself. If you don't, feel free to check the binaries MD5/SHA Smiley

infested999
Hero Member
*****
Offline Offline

Activity: 490


DeCiB3l


View Profile WWW
August 18, 2011, 03:03:49 PM
 #53

Code:
Every developer can/should change the default settings in: Project Admin|Settings|Export Controls

Problem Solved?

twobits
Sr. Member
****
Offline Offline

Activity: 336

Firstbits: 1a6taw


View Profile
August 18, 2011, 03:09:55 PM
 #54

May want to add a link to the verification file and the signature to use to verify it.
No. I trust myself. If you don't, feel free to check the binaries MD5/SHA Smiley

It is not to protect you.  It is to protect anyone using your download mirror.   Also would help detect if someone changed it on you later etc....   how would someone who cant get to sf check your mirror?
It also would allow someone to double check that the sf binaries were not changed after you fetched them.  Has zero to do with if you trust yourself.    Would just make your mirroring service have a lot more useful by adding a link and a mirror of another small file.     Odd you are so quick to say no.

zellfaze
Full Member
***
Offline Offline

Activity: 142


Security Enthusiast


View Profile WWW
August 18, 2011, 03:33:29 PM
 #55

It is not to protect you.  It is to protect anyone using your download mirror.   Also would hep detect if someone changed it on you later etc....   how would someone who cant get to sf check your mirror?
It also would allow someone to double check that the sf binaries were not changed after you fetched them.  Has zero to do with if you trust yourself.    Would just make your mirroring service have a lot more useful by adding a link and a mirror of another small file.     Odd you are so quick to say no.


Lets not be so jumpy here.  I'm sure he means well.

I agree though, it has nothing to do with if you trust yourself.  It is to protect others.

A+, CCENT, CCNA
Security Enthusiast
PHP Coder

Not that I expect anyone to, but should you like my post, please donate:
Donate: 1BRbfqii6Sm9tEUE8A16H7QeDmYFjyBZ7V
davout
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
August 18, 2011, 03:50:13 PM
 #56

I don't really get it, how can I possibly protect others when the binaries I serve can potentially be malicious and I can potentially have malicious intentions ?

Should I post checksums ? Doesn't work :
 - if I have malicious intentions the checksums will match the malicious binaries.
 - if the binaries get changed without me knowing it means that the server got compromised, the checksums shouldn't then be trusted either
 - if I post a link to SF, that won't help since some users won't be able to access it and it also could be compromised

Let's face it, if you're truly paranoid, you read the source and then you compile it. Oh wait, you'd need to compile gcc too Wink

If you have better ideas than the couple I exposed I'm open. But I'd rather give no checksums than a false sense of security.

Quote from: Carl Sagan
If you want to make an apple pie from scratch, you must first create the universe.

twobits
Sr. Member
****
Offline Offline

Activity: 336

Firstbits: 1a6taw


View Profile
August 18, 2011, 04:06:03 PM
 #57

I don't really get it, how can I possibly protect others when the binaries I serve can potentially be malicious and I can potentially have malicious intentions ?

Should I post checksums ? Doesn't work :
 - if I have malicious intentions the checksums will match the malicious binaries.
 - if the binaries get changed without me knowing it means that the server got compromised, the checksums shouldn't then be trusted either
 - if I post a link to SF, that won't help since some users won't be able to access it and it also could be compromised

Let's face it, if you're truly paranoid, you read the source and then you compile it. Oh wait, you'd need to compile gcc too Wink

If you have better ideas than the couple I exposed I'm open. But I'd rather give no checksums than a false sense of security.



Actually I do compile gcc, but not for security reasons, lol.

And you are right about it being better to provide no checkfiles then provide a false sense of security.

What you could do is also mirror http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/SHA1SUMS.asc/download and provide a link  to http://bitcoin.org/jgarzik-exmulti.asc which an earlier post said is the right signature to verify.  Now you have not only provided a way to check your mirrored files, but that no one has changed the sf ones since you mirrored them.

EricJ2190
Full Member
***
Offline Offline

Activity: 134


View Profile
August 18, 2011, 05:58:31 PM
 #58

I don't really get it, how can I possibly protect others when the binaries I serve can potentially be malicious and I can potentially have malicious intentions ?

Should I post checksums ? Doesn't work :
 - if I have malicious intentions the checksums will match the malicious binaries.
 - if the binaries get changed without me knowing it means that the server got compromised, the checksums shouldn't then be trusted either
 - if I post a link to SF, that won't help since some users won't be able to access it and it also could be compromised

Let's face it, if you're truly paranoid, you read the source and then you compile it. Oh wait, you'd need to compile gcc too Wink

If you have better ideas than the couple I exposed I'm open. But I'd rather give no checksums than a false sense of security.



Actually I do compile gcc, but not for security reasons, lol.

And you are right about it being better to provide no checkfiles then provide a false sense of security.

What you could do is also mirror http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/SHA1SUMS.asc/download and provide a link  to http://bitcoin.org/jgarzik-exmulti.asc which an earlier post said is the right signature to verify.  Now you have not only provided a way to check your mirrored files, but that no one has changed the sf ones since you mirrored them.

The idea is that you would have Jeff's PGP already, and not simply download it whenever you are checking a new binary. When you get the key for the first time, as with all PGP public keys, you should not trust its validity until you are convinced it is correct. You make this decision based on several factors such as where you obtained the key, what other sources agree that this key is legitimate, the PGP web-of-trust, etc.

Jeff's key could use more signatures. Somebody make him attend a keysigning party.
zellfaze
Full Member
***
Offline Offline

Activity: 142


Security Enthusiast


View Profile WWW
August 18, 2011, 06:02:06 PM
 #59

Perhaps he could go to the Bitcoin World Expo in NYC tomorrow.  I'm sure plenty of people there use PGP and could sign his key.

A+, CCENT, CCNA
Security Enthusiast
PHP Coder

Not that I expect anyone to, but should you like my post, please donate:
Donate: 1BRbfqii6Sm9tEUE8A16H7QeDmYFjyBZ7V
gigabytecoin
Sr. Member
****
Offline Offline

Activity: 280


View Profile
August 22, 2011, 09:59:00 AM
 #60

Notepad++ left them for similar reasons iirc.
Pages: « 1 2 [3] 4 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!