URGENT: Windows Bitcoin-Qt update

[gmaxwell]

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.

[1714489619]

1714489619

[1714489619]

1714489619

[Killdozer]

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]

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]

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]

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]

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]

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.

[malevolent]

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.

[TheSeven]

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.

[Gabi]

Updated, i have 0.6rc4 now

I wonder what happens now with older wallets...

[gmaxwell]

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]

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]

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]

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]

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]

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]

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]

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.

[check_status]

NIST publishes 50kish vulnerable code samples in Java/C/C++, is officially krad

SAMATE - Software Assurance Metrics And Tool Evaluation

Welcome to the NIST SAMATE Reference Dataset Project

Veracode - Vulnerability Scanner for Excutable of C, C++, C#, Java

[coinft]

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