gmaxwell
Staff
Legendary
Offline
Activity: 4242
Merit: 8684
|
|
March 17, 2012, 04:02:52 AM |
|
So if I have 0.5.3.1-beta I'm safe?
Yes. 0.5.3.1 is the fixed version of 0.5.3.
|
|
|
|
Killdozer
|
|
March 17, 2012, 09:05:46 AM |
|
about 3 days ago i was commenting on the language choice. from a software architecture standpoint other languages than c++ would make more sense in such a sensitive area. This is nonsense. If anything, more advanced languages can have their own vulnerabilities which could bitcoin vulnerable without any mistakes acutally made by the developers. This is almost impossible with a low level language like c++. Apart from that, a program's security does not depend on the language, it depends on the coding.
|
|
|
|
defxor
|
|
March 17, 2012, 09:31:30 AM |
|
Apart from that, a program's security does not depend on the language, it depends on the coding.
All software developers of any experience and educational background will tell you that programs will always have bugs. It's simply impossible to provable test all possible pathways as soon as you venture beyond Hello World type complexity. Thus it's better to use a programming and execution environment that protects you, as far as possible, when those bugs are found.
|
|
|
|
Schwede65
|
|
March 17, 2012, 09:38:13 AM |
|
only a question of a solo-mining-noob:
does an update effect the number of done shares to find a btc-block?
example: i have done 140.000 shares with 0.5.2 what will be there for me with update to 0.5.3.1 - start at share number 0 - without the 140.000?
|
|
|
|
psiborg
Newbie
Offline
Activity: 25
Merit: 0
|
|
March 17, 2012, 09:40:05 AM |
|
If anything, more advanced languages can have their own vulnerabilities which could bitcoin vulnerable without any mistakes acutally made by the developers. This is almost impossible with a low level language like c++. Apart from that, a program's security does not depend on the language, it depends on the coding.
Or on the (coding of the) language as you stated just earlier I'm using the anonymity patched bitcoin client ( https://bitcointalk.org/index.php?topic=24784.0), hope they get their security patches too.
|
|
|
|
wachtwoord
Legendary
Offline
Activity: 2338
Merit: 1125
|
|
March 17, 2012, 09:57:02 AM |
|
So if I have 0.5.3.1-beta I'm safe?
Yes. 0.5.3.1 is the fixed version of 0.5.3. What about 0.5.1-beta? (this versioning numbering is quite confusing)
|
|
|
|
wumpus
|
|
March 17, 2012, 10:08:44 AM |
|
0.5.1 (-beta) is *not* safe.
only 0.5.3.1 and 0.6.0pre4 are safe right now. As for next versions, 0.5.4 and 0.6.0 (final) and so on will also be safe.
All bitcoin versions have -beta added in the "About" dialog as a statement about the current phase of the project, not about the current version.
|
Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
|
|
|
malevolent
can into space
Legendary
Offline
Activity: 3472
Merit: 1722
|
|
March 17, 2012, 10:36:46 AM |
|
I always encourage people to review the git history, but if you spot the fix for this issue— please don't point it out yet (and I will remove posts that do)
Shouldn't you adher to full disclosure policy? This would actually encourage people to update.
|
Signature space available for rent.
|
|
|
TheSeven
|
|
March 17, 2012, 10:38:22 AM |
|
only a question of a solo-mining-noob:
does an update effect the number of done shares to find a btc-block?
example: i have done 140.000 shares with 0.5.2 what will be there for me with update to 0.5.3.1 - start at share number 0 - without the 140.000?
There is no such thing as shares when you are solo mining, so updating won't affect your solo mining income.
|
My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
|
|
|
Gabi
Legendary
Offline
Activity: 1148
Merit: 1008
If you want to walk on water, get out of the boat
|
|
March 17, 2012, 12:59:28 PM |
|
Updated, i have 0.6rc4 now
I wonder what happens now with older wallets...
|
|
|
|
gmaxwell
Staff
Legendary
Offline
Activity: 4242
Merit: 8684
|
|
March 17, 2012, 01:17:55 PM |
|
Shouldn't you adher to full disclosure policy? This would actually encourage people to update.
If you look a discussion about full disclosure you'll see that much of the discussion is completely moot when the "vendors" of the software are also the discoverers of the issue. There also isn't much more that could be disclosed right now.
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
March 17, 2012, 01:47:00 PM |
|
It's simply impossible to provable test all possible pathways as soon as you venture beyond Hello World type complexity. It actually isn't impossible, just complex enough it hasn't been accomplished yet. It's quite possible to write a specialized emulator that follows every possible code-path with "quantum" memory states...
|
|
|
|
defxor
|
|
March 17, 2012, 02:03:00 PM |
|
It actually isn't impossible, just complex enough it hasn't been accomplished yet.
It's impossible in the same way as brute forcing a 128 bit UUID is impossible E.g. in our relevant universe. (And enough so for the discussion at hand)
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
March 17, 2012, 02:10:39 PM |
|
If anything, more advanced languages can have their own vulnerabilities which could bitcoin vulnerable without any mistakes acutally made by the developers. This is almost impossible with a low level language like c++. Apart from that, a program's security does not depend on the language, it depends on the coding.
Or on the (coding of the) language as you stated just earlier I'm using the anonymity patched bitcoin client ( https://bitcointalk.org/index.php?topic=24784.0), hope they get their security patches too. I don't have any info on the vuln or code for the patch. So I'd advise you not to use my patched binaries until the vuln and fix have been disclosed and I can compile new ones. Dev team is doing builds of 0.5.3+coderrr with the fix applied; should be available later today.
|
|
|
|
malevolent
can into space
Legendary
Offline
Activity: 3472
Merit: 1722
|
|
March 17, 2012, 03:26:10 PM |
|
Shouldn't you adher to full disclosure policy? This would actually encourage people to update.
If you look a discussion about full disclosure you'll see that much of the discussion is completely moot when the "vendors" of the software are also the discoverers of the issue. There also isn't much more that could be disclosed right now.
|
Signature space available for rent.
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
March 17, 2012, 03:52:12 PM |
|
You have to be god-like to not create security vulnerabilities in significantly C/C++ software. 'Direct' buffer overflows can be avoided by littering your code with meticulous boiler plate (and praying you haven't made a mistake somewhere). But integer overflows leading to buffer overflows are so hopelessly trickly that I have no faith in any C/C++ being safe.
Java buffer overflows simply don't exist... a huge class of exploit eradicated by language choice. And there's a long list of languages immune to buffer overflows (this is mostly a glaring hole in C/C++). Look up US military/intelligence mandates about language choice. C/C++ is so bad that it should be immediately abandoned and _never_ used for _anything_. Why do you think computer security is such a disaster (it was all C/C++ until the recent xss/xsrf/sql havoc - and that too is a design flaw). Guess what language Java/Python/etc are implemented it.
|
|
|
|
grue
Legendary
Offline
Activity: 2058
Merit: 1434
|
|
March 17, 2012, 04:25:51 PM |
|
Java/Python/Ruby/Lisp buffer overflows simply don't exist... a huge class of exploit eradicated by language choice. And there's a long list of languages immune to buffer overflows (this is mostly a glaring hole in C/C++). Look up US military/intelligence mandates about language choice. C/C++ is so bad that it should be immediately abandoned and _never_ used for _anything_. Why do you think computer security is such a disaster (it was all C/C++ until the recent xss/xsrf/sql havoc - and that too is a design flaw).
I tried looking it up, but I could only find some random articles about switching to ada, but nothing stating that "C/C++ is so bad that it should be immediately abandoned and _never_ used for _anything_" . Can you point to the article claiming that?
|
|
|
|
stevegee58
Legendary
Offline
Activity: 916
Merit: 1003
|
|
March 17, 2012, 06:48:50 PM |
|
I upgraded my client yesterday and suddenly today I noticed I'm getting hit with a SYN flood attack.
Don't know if it's related but it's damn annoying. I've stopped my BTC client temporarily to see what happens.
|
You are in a maze of twisty little passages, all alike.
|
|
|
check_status
Full Member
Offline
Activity: 196
Merit: 100
Web Dev, Db Admin, Computer Technician
|
|
March 17, 2012, 09:05:09 PM |
|
|
For Bitcoin to be a true global currency the value of BTC needs always to rise. If BTC became the global currency & money supply = 100 Trillion then ⊅1.00 BTC = $4,761,904.76. P2Pool Server List | How To's and Guides Mega List | 1 EndfedSryGUZK9sPrdvxHntYzv2EBexGA
|
|
|
coinft
|
|
March 18, 2012, 12:22:12 AM |
|
You have to be god-like to not create security vulnerabilities in significantly C/C++ software. 'Direct' buffer overflows can be avoided by littering your code with meticulous boiler plate (and praying you haven't made a mistake somewhere). But integer overflows leading to buffer overflows are so hopelessly trickly that I have no faith in any C/C++ being safe.
Java buffer overflows simply don't exist... a huge class of exploit eradicated by language choice. And there's a long list of languages immune to buffer overflows (this is mostly a glaring hole in C/C++). Look up US military/intelligence mandates about language choice. C/C++ is so bad that it should be immediately abandoned and _never_ used for _anything_. Why do you think computer security is such a disaster (it was all C/C++ until the recent xss/xsrf/sql havoc - and that too is a design flaw). Guess what language Java/Python/etc are implemented it. At least python and ruby are both implemented in a wide variety of other languages, not just C. There's even a very good implementation of python in python. Perhaps surprisingly some of these alternate implementations are even faster than their C-built equivalents. Their main drawback of course is lack of ability to link directly with C code. With excellence and discipline it surely is possible to create decently secure code in C++. For me it's much harder and slower than ruby or python. Some projects are probably best done in C too, but I don't think bitcoin is one of those. Except of course if it's the language the main developers are most comfortable with, which most often is the main overruling argument deciding language for any given project.-coinft
|
|
|
|
|