bittorrent?
DHT?
you can literally share bittorrent with just a URI.
Topic: Please remove Bitcoin from Sourceforge.net (Read 5917 times)
Notepad++ left them for similar reasons iirc.
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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.
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.
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 
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.
Code:
Every developer can/should change the default settings in: Project Admin|Settings|Export Controls
Problem Solved?
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
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.
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.
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.
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.
The bitcoin binaries are now mirrored and available for download on Bitcoin-Central.net
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.
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.
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.
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?
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.
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.
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
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.
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/
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.
Jump to: