URGENT: Windows Bitcoin-Qt update

[Gavin Andresen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A potential security vulnerability has been discovered in the Windows
version of Bitcoin-Qt. If you are running Bitcoin-Qt versions 0.5
through 0.6 on Windows you should shut it down and upgrade to either
version 0.5.3.1 or 0.6rc4 NOW.

The command-line bitcoin daemon (bitcoind), Mac and Linux versions of
Bitcoin-Qt, and versions prior to 0.5 are not affected.

Due to the nature of the vulnerability, we believe it would be very
difficult for an attacker to do anything more than crash the
Bitcoin-Qt process. However, because there is a possibility of such a
crash causing remote code execution we consider this a critical issue.

Binaries are available at SourceForge:
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/

If you have questions, feel free to drop by the #bitcoin-dev channel
on FreeNode IRC.

- --
Gavin Andresen
Gregory Maxwell
Matt Corallo
Nils Schneider
Wladimir J. van der Laan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9j12IACgkQdYgkL74406iIyQCfbxFTO3yD4Q2bHDjPlDuJn3Mj
9GAAn3mV+ggo+5q1Ujd0A5zwpFYojkE2
=g1Ad
-----END PGP SIGNATURE-----

[1715318116]

1715318116

[1715318116]

1715318116

[1715318116]

1715318116

[1715318116]

1715318116

[1715318116]

1715318116

[mcorlett]

Can we get more information on the nature of the vulnerability itself, please?

[Fiyasko]

when was this discovered?!

[kentrolla]

thats nuts.......        can this effect any other processes?

[Retired]

I assume you are not publishing more detailed information on purpose, right? And, as JackRabiit asked, when was this discovered?

[Clipse]

bitcoin.org lists the 0.5.3.1 update posted for 16 April 2012, perhaps correct that.

[apetersson]

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.

i am not suggesting that it should be rewritten. but i think it is very important that alternative implementations like BitcoinJ, multibit, armory, electrum exist.

[ThiagoCMC]

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.

i am not suggesting that it should be rewritten. but i think it is very important that alternative implementations like BitcoinJ, multibit, armory, electrum exist.

The most important re-implementation of Satoshi's oroginal code, from my point of view, is Libcoin from Michael Grønager.

[mcorlett]

Can we get more information on the nature of the vulnerability itself, please?

You can check out Github.

Did you check before posting? There is no relevant commit to the main branch.

[Luke-Jr]

The most important re-implementation of Satoshi's oroginal code, from my point of view, is Libcoin from Michael Grønager.

Libcoin is not a reimplementation, it is just the Satoshi client made into a library. Perhaps you meant Amir's libbitcoin?

[cypherdoc]

are the backups in 0.6.0 for windows encrypted?

[Luke-Jr]

are the backups in 0.6.0 for windows encrypted?

No

[cypherdoc]

are the backups in 0.6.0 for windows encrypted?

No

why wouldn't it be?  if you encrypt your working wallet, then run a backup, it should be encrypted as well i would think.

[wumpus]

why wouldn't it be?  if you encrypt your working wallet, then run a backup, it should be encrypted as well i would think.

yes, it's simply a copy

[Luke-Jr]

are the backups in 0.6.0 for windows encrypted?

No

why wouldn't it be?  if you encrypt your working wallet, then run a backup, it should be encrypted as well i would think.

Encrypted wallets aren't really encrypted entirely. Only your private keys are. There's still a lot of sensitive data in there you probably don't want public.

[grue]

so all the 0.4.* versions are still safe, right?

[Luke-Jr]

so all the 0.4.* versions are still safe, right?

For this specific bug, yes. But wxBitcoin (the GUI in 0.4.x) is not maintained or supported at all, so it likely has other unfixed vulnerabilities.

[da2ce7]

If the installer ain't working for you... Make sure you select 'Run As Administrator'.

Users whom wisely don't run as a super user, will get the error 'cannot access file.'  Instead of a prompt for an escalation of privileges.

[gmaxwell]

With respect to detailed questions about the issue, we're currently being somewhat vague— simply because it's helpful to give innocent users as much of a head-start on trouble makers as possible.  

At the current time we don't know that the issue is exploitable. The class of issue and the overall paranoid design of the reference client make it hard to tell for sure. It is probably hard to exploit if it is exploitable at all.  Because of the potential seriousness the issue has been dealt with promptly and as if it were exploitable. (I'm not answering the specific timing questions because they may identify the issue too clearly).

If the issue turns out to be practically exploitable we'd much rather learn of it as a purely academic fact— academic because almost all impacted users had already applied fixes—  a few weeks from now, than learn about that in the form of hundreds of wallets being stolen through an exploit in the next few days.

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), if you like you can contact me privately and I'll gladly tell everyone how smart you were later. —  Reviewing the commits is generally good advice it's always good to have more eyes on the code, and even if you don't satisfy your curiosity with respect to this issue you may learn something else useful.

[hongus]

So if I have 0.5.3.1-beta I'm safe?

[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.

[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

[Luke-Jr]

At least python and ruby are both implemented in a wide variety of other languages, not just C.

My point is that every language eventually reduces to C somewhere, even C++.

[Diapolo]

I always use MS EMET on Windows, to make application bugs or security issues harder to exploit. I can confirm MS EMET 2.1 can be used with 0.6 RC4 and did work with all earlier versions of the BC client. Have a look here: https://www.microsoft.com/download/en/details.aspx?id=1677

You just have to install it and add bitcoin-qt.exe and bitcoind.exe to it's application list.

Dia

[Luke-Jr]

FYI, Windows binaries from the 0.6.0rc4 source (in git) will not get you a fixed build.

[Revalin]

My point is that every language eventually reduces to C somewhere, even C++.

While true, string and array handling is very well-proven in Python/Ruby/etc.  You are far more likely to make an input bounds checking error in C than to discover an existing bug in Python's read().

It's not a silver bullet, but it helps.

[Luke-Jr]

Here are Windows binaries for coderrr's coin control patchset with 0.5.3.1 fix applied

[Diapolo]

FYI, Windows binaries from the 0.6.0rc4 source (in git) will not get you a fixed build.

How long do you plan to keep the fix "secret" and what's the deadline for making the vulnerability public?

Dia

[coreking]

Sure the language that is chosen eventually reduces to native code, however you can use a minimal amount of native code to "boot strap" the language, then write the more advanced language features in the language itself. Then you only have a small amount of code to review for low level issues, such as memory corruption.

A few languages are implemented in this way, the GHCi Haskell compiler apparently uses a "stripped down" C language called "C--" to do the bootstrapping.

So there definitely appear to be advantages in writing security critical applications in high level languages...

[Gavin Andresen]

How long do you plan to keep the fix "secret" and what's the deadline for making the vulnerability public?

We'll release full detail tomorrow (Monday) at 16:00 GMT, after essentially the entire world has had a chance to go into work Monday morning, see the alert message, and shutdown/upgrade.

[CIYAM]

And there's a long list of languages immune to buffer overflows (this is mostly a glaring hole in C/C++).

So exactly how do you get a buffer overflow using std::string?

[coinft]

Sure the language that is chosen eventually reduces to native code, however you can use a minimal amount of native code to "boot strap" the language, then write the more advanced language features in the language itself. Then you only have a small amount of code to review for low level issues, such as memory corruption.

A few languages are implemented in this way, the GHCi Haskell compiler apparently uses a "stripped down" C language called "C--" to do the bootstrapping.

So there definitely appear to be advantages in writing security critical applications in high level languages...

Exactly. Other examples are pypy (python written in python, capable of creating new advanced pypy versions without a C compiler), and many variations of lisp. The key is having a compiler toolchain written in the language itself. After some iterations the original C-code used to bootstrap (if it was C) can be replaced totally.

After all, you needed assembler or direct machine code to bootstrap a C compiler if you didn't use fortran or something else, C is not  magically special, it's just widely used. You could say everything boils down to machine code eventually, but than there's CPU micro/nano code and the original arguments become quite absurd.

-coinft

[cypherdoc]

How long do you plan to keep the fix "secret" and what's the deadline for making the vulnerability public?

We'll release full detail tomorrow (Monday) at 16:00 GMT, after essentially the entire world has had a chance to go into work Monday morning, see the alert message, and shutdown/upgrade.

take your time.  maybe Tuesday?

[Luke-Jr]

The key is having a compiler toolchain written in the language itself. After some iterations the original C-code used to bootstrap (if it was C) can be replaced totally.

Only if the language can be compiled to native code at all. In which case it's just as "at risk" of buffer overflows etc as C++ is. For Python, Java (for practical purposes; GCJ seems to have trouble with most real Java software), etc, they cannot be compiled to native code, and thus always require a C/equivalent interpretor.

[BrightAnarchist]

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.

I'm sorry but you are completely wrong here.

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/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).

That you think "this is nonsense" means that your own code is already insecure, and you just don't know it.

+1

C++ used to be my favorite language... until I learned Lisp and Python.

Now my foot is finally recovering from being shot too many times

[defxor]

Only if the language can be compiled to native code at all. In which case it's just as "at risk" of buffer overflows etc as C++ is. For Python, Java (for practical purposes; GCJ seems to have trouble with most real Java software), etc, they cannot be compiled to native code, and thus always require a C/equivalent interpretor.

Sorry, but no. Buffer overflow opportunities don't somehow appear in library code just because the calling program has been compiled. (And Java JIT is a compiler, there's no difference between doing the compiling statically beforehand or dynamically when needed).

[Gavin Andresen]

Full disclosure blog post is at:
  http://gavintech.blogspot.com/2012/03/full-disclosure-bitcoin-qt-on-windows.html

Executive summary: we were compiling Windows binaries with the wrong flags.

[makomk]

Full disclosure blog post is at:
  http://gavintech.blogspot.com/2012/03/full-disclosure-bitcoin-qt-on-windows.html

Executive summary: we were compiling Windows binaries with the wrong flags.

Ah, so it was that. A quick Google at the time turned up this mailing list message which has an interesting explanation of what apparently happens if you do that. Not sure if it's accurate though.

Just out of curiosity, are non-gitian Windows compiles of bitcoin-qt safe now?

[dooglus]

FYI, Windows binaries from the 0.6.0rc4 source (in git) will not get you a fixed build.

Why's that?  The v0.6.0rc4 tag includes the -lmingwthrd fix.

When I first saw your post I figured I must have guessed wrongly what the update was all about, because the changes for safe multi-threading in mingw were included in the rc4 source.

[REF]

Full disclosure blog post is at:
  http://gavintech.blogspot.com/2012/03/full-disclosure-bitcoin-qt-on-windows.html

Executive summary: we were compiling Windows binaries with the wrong flags.

nicely worded article. very straight forward and easy to understand. even those with limiting coding knowledge should get it.

[Luke-Jr]

FYI, Windows binaries from the 0.6.0rc4 source (in git) will not get you a fixed build.

Why's that?  The v0.6.0rc4 tag includes the -lmingwthrd fix.

When I first saw your post I figured I must have guessed wrongly what the update was all about, because the changes for safe multi-threading in mingw were included in the rc4 source.

The v0.6.0rc4 tag includes the fix, but it removes -lmingw only in the gitian build of Qt. Since it doesn't also change the filename, there is a probability anyone using gitian will not rebuild Qt; they, and non-gitian builders, will therefore not get the change. I submitted a pull request to move the change to bitcoin-qt.pro where it belongs, and incorporated this into the v0.5.3.1 tag.

While it would be possible (and in the case of the binaries, was done) to build v0.6.0rc4 with the adjusted Qt, doing so required inside knowledge of the fix, and could not be explained without disclosing the nature of the security issue; therefore, I stuck with a blanket "will not" to be on the safe side.

[Schwede65]

Binaries are available at SourceForge:
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/

now please for the non-coders:

are the the posted (above) windows-binaries safe?

[Pieter Wuille]

https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/

now please for the non-coders:

are the the posted (above) windows-binaries safe?

Yes.

[Nyaaan]

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.

I'm sorry but you are completely wrong here.

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/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).

That you think "this is nonsense" means that your own code is already insecure, and you just don't know it.

+1

C++ used to be my favorite language... until I learned Lisp and Python.

Now my foot is finally recovering from being shot too many times

I think you mean your knee.

Also, thank you for the fix, developers.

[NothinG]

Anyone else having this problem?

[Diapolo]

Anyone else having this problem?

You could try this, perhaps it's related: https://bitcointalk.org/index.php?topic=66887.msg779221#msg779221

Dia

[NothinG]

You could try this, perhaps it's related: https://bitcointalk.org/index.php?topic=66887.msg779221#msg779221

Dia

I just tried that, seemed to make it worse. Looked into the logs (new information after what Diapolo said to do), said something about the indexing.
So, I am re-building my blkindex.dat.
I'll post what I find.

[JackH]

Is this affecting Bitcoin version 0.3.21?

[Vandroiy]

+1 for an implementation in a safer language.

I keep saying the same thing; it's just absurd to use a highspeed-hacker-language for financial transactions.

We need another client for broad usage. If everyone hates Mono so much, well then use Java or something, but not something that cares little about type safety, operates directly on memory pointers etc. Think aspect-oriented programming, contracts, this is the kind of stuff we need, and it's as far from C++ as you get.

[Pieter Wuille]

Is this affecting Bitcoin version 0.3.21?

No, only windows version of Bitcoin-Qt are affected, a GUI that was only merged in 0.5.0.

However, it's generally a bad idea to keep using such old versions...

[Luke-Jr]

Is this affecting Bitcoin version 0.3.21?

Not this, but 0.3.* are not maintained and have several security and other bugs. Upgrade to at least 0.4.4.

[Diapolo]

+1 for an implementation in a safer language.

I keep saying the same thing; it's just absurd to use a highspeed-hacker-language for financial transactions.

We need another client for broad usage. If everyone hates Mono so much, well then use Java or something, but not something that cares little about type safety, operates directly on memory pointers etc. Think aspect-oriented programming, contracts, this is the kind of stuff we need, and it's as far from C++ as you get.

I hate Java more than Python, than Basic ... Windows is written in what language? Linux kernel is written in?

Dia

[Pieter Wuille]

+1 for an implementation in a safer language.

I keep saying the same thing; it's just absurd to use a highspeed-hacker-language for financial transactions.

We need another client for broad usage. If everyone hates Mono so much, well then use Java or something, but not something that cares little about type safety, operates directly on memory pointers etc. Think aspect-oriented programming, contracts, this is the kind of stuff we need, and it's as far from C++ as you get.

I hate Java more than Python, than Basic ... Windows is written in what language? Linux kernel is written in?

Dia

Can you please stop discussing what language Bitcoin clients are supposed to be written in? This thread is about the specific security problem found here.

Start a discussion in the dev section, if you like a language flamewar.

[Luke-Jr]

FWIW, this issue has been assigned CVE-2012-1910

[Diapolo]

FWIW, this issue has been assigned CVE-2012-1910

That's a great step, it would be even better to link the advisory. One I found by that number was for JavaRE and the other for Bind DNS :-/.

Dia

[Luke-Jr]

FWIW, this issue has been assigned CVE-2012-1910

That's a great step, it would be even better to link the advisory. One I found by that number was for JavaRE and the other for Bind DNS :-/.

Dia

This thread is the advisory...

[Diapolo]

FWIW, this issue has been assigned CVE-2012-1910

That's a great step, it would be even better to link the advisory. One I found by that number was for JavaRE and the other for Bind DNS :-/.

Dia

This thread is the advisory...

Then who did chose that CVE numbers? I thought these numbers were assigned by an external company or organisation ... my fault then.

[Pieter Wuille]

The numbers are chosen by an external advisory yes, but apparently it's just a number to identify the problem.

I think it'd be a little more useful if information about the issue could actually be found in online databases directly about it.

[Diapolo]

The numbers are chosen by an external advisory yes, but apparently it's just a number to identify the problem.

I think it'd be a little more useful if information about the issue could actually be found in online databases directly about it.

I had exactly this in my mind , a public database, an external given ID and independent information about issues.

Dia

[fabrizziop]

Is it safe to use the 0.6.0 version?, newly released.

[Luke-Jr]

Is it safe to use the 0.6.0 version?, newly released.

Yes