Bitcoin Signed Binaries

[ChloeST]

I have to ask why there are no signed binaries of the Bitcoin Clients? The bitcoin client is the center of what should be a very secure system for an individual. (Unless their primary accounts are on MtGox or a similar site, in which case they have to trust ssl and MtGox.)

On Windows the binary has no digital signature on the executable. Other less important software has digital signatures (media players, games, even poker clients are signed (PartyPoker is signed with a Thawte verified certificate).

On linux, there are no hashes available of the current distribution .tar.gz. Ubuntu offers hashes of their product through a ssl encrypted page: https://help.ubuntu.com/community/UbuntuHashes

PGP signatures for communication with bitcoin developers are readily available on the bitcoin.org front page next to their email addresses. Why aren't there verifiable gpg signatures for the binary downloads also available?

[1714882215]

1714882215

[1714882215]

1714882215

[LMGTFY]

I have to ask why there are no signed binaries of the Bitcoin Clients? The bitcoin client is the center of what should be a very secure system for an individual. (Unless their primary accounts are on MtGox or a similar site, in which case they have to trust ssl and MtGox.)

On Windows the binary has no digital signature on the executable. Other less important software has digital signatures (media players, games, even poker clients are signed (PartyPoker is signed with a Thawte verified certificate).

On linux, there are no hashes available of the current distribution .tar.gz. Ubuntu offers hashes of their product through a ssl encrypted page: https://help.ubuntu.com/community/UbuntuHashes

PGP signatures for communication with bitcoin developers are readily available on the bitcoin.org front page next to their email addresses. Why aren't there verifiable gpg signatures for the binary downloads also available?

Good question! I'd imagine it's because the developers are overworked and underpaid!

I'm not sure how practical digital signatures would be in the short term, as Thawte etc will charge for them - but hopefully someone nearer the issue than me can comment.

Regarding hashes, that should be pretty easy to implement - but I'd imagine it's time that's the problem. I don't suppose you'd be able to volunteer to help out the devs with this?

[grue]

there's no need for signing the binaries. the release announcements are pgp signed, with a hash of the binaries.

[Mike Hearn]

No, the binaries should be signed for the AV reasons discussed previously. It doesn't happen, basically because "nobody got around to it yet". There's work in progress to move to reproducible builds in which multiple trusted developers check that the source code compiles to the binary being released, and then all sign that. Certainly a regular Win32 signature should be included as part of that process and I'm sure soon it will be.

[BombaUcigasa]

Ontopic, I downloaded a RC bitcoin client from sourceforge, and NOD32 stopped the download because it got a PE/NewHeur trojan warning. None of the other releases give this warning. How can we be sure the binaries published on the official source control hubs are free of malware?

[matt.collier]

I am a GlobalSign reseller and I will sell a Microsoft Authenticode Code Signing Certificate for the BTC equivalent of $180 USD.  The retail price for this certificate is $229.

[matt.collier]

There's also the Certificate for Individuals which retails at $99, but I'm not sure if that's appropriate for this purpose.

[edit]

I will sell this one for $50, but it will have the name of an individual on the certificate, not an organization.

http://www.globalsign.com/code-signing/buy-code-signing-for-individual-developers.html

[ene]

there's no need for signing the binaries. the release announcements are pgp signed, with a hash of the binaries.

Not everybody has PGP installed.

[grue]

I am a GlobalSign reseller and I will sell a Microsoft Authenticode Code Signing Certificate for the BTC equivalent of $180 USD.  The retail price for this certificate is $229.

any chance you can donate this certificate to the bitcoin community?

[matt.collier]

The $180 price includes my reseller discount and $25 of my own money.  I feel comfortable with that level of assistance.

[Matt Corallo]

On 0.4.0 PGP signing:
Starting with 0.4.0, the bitcoin releases on Win32 will be generated deterministically (assuming me/devrandom have enough time to code the specifics) and signed by all the Bitcoin developers who have the ability to do so.  The "installer" will then install a minimal script and the relevant dependencies to the Bitcoin folder and then run that script.  That script then downloads the latest version of Bitcoin and checks that enough signatures are on it for it to be considered trusted and install that version.  The script will (hopefully) also be used to update bitcoin when new versions come out.

On code signing:
This one is a bit more difficult.  Because Bitcoin will be built deterministically, we have two options.  A. send the code signing private key around to all the devs for that to be a part of the building process (this is even harder as the building happens on Linux via the MinGW cross compiler) or B. find a way to strip out the code signing certificate in the download script and then check the stripped version instead of the signed version.  I googled this pretty quick and saw no simple CLI program which will do this, but I might have missed something as I didnt spend too much time on it.  If anyone finds something, please tell me. 

[grue]

On 0.4.0 PGP signing:
Starting with 0.4.0, the bitcoin releases on Win32 will be generated deterministically (assuming me/devrandom have enough time to code the specifics) and signed by all the Bitcoin developers who have the ability to do so.  The "installer" will then install a minimal script and the relevant dependencies to the Bitcoin folder and then run that script.  That script then downloads the latest version of Bitcoin and checks that enough signatures are on it for it to be considered trusted and install that version.  The script will (hopefully) also be used to update bitcoin when new versions come out.

On code signing:
This one is a bit more difficult.  Because Bitcoin will be built deterministically, we have two options.  A. send the code signing private key around to all the devs for that to be a part of the building process (this is even harder as the building happens on Linux via the MinGW cross compiler) or B. find a way to strip out the code signing certificate in the download script and then check the stripped version instead of the signed version.  I googled this pretty quick and saw no simple CLI program which will do this, but I might have missed something as I didnt spend too much time on it.  If anyone finds something, please tell me. 

auto-update = super bad idea. if a attacker can compromise the script, he can make tons of rouge clients.

[Matt Corallo]

auto-update = super bad idea. if a attacker can compromise the script, he can make tons of rouge clients.

Obviously we aren't going to blindly auto-update, there will be a user-prompt.  Also, the binaries are signed by multiple developers meaning you would have to compromise the pgp private keys of several developers.  If you think an attacker will try to compromise the download script, well how is that any different from compromising the current downloads?  You would have to compromise sourceforge, so it wouldn't make a difference.  If you think the script itself might be trickable into downloading without having enough signatures, then I ask you to look it over yourself https://github.com/devrandom/gitian-builder/blob/updater/share/gitian-updater

[jimbo77]

auto-update = super bad idea. if a attacker can compromise the script, he can make tons of rouge clients.

Wouldn't it be more risky NOT having an auto-update? As long as the process of getting the binaries is secure. I'm thinking from the point of view that there could be exploits in the network or old versions where you want people to update to protect themselves. People are notorious for not upgrading and what if we need them too to prevent an attack on the network? Newer web browsers seem to do it to enhance security so why wouldn't that be the case for bitcoin?

[ene]

As long as the process of getting the binaries is secure.

You missed the point. 

[jimbo77]

As long as the process of getting the binaries is secure.

You missed the point. 

I did? You can make updating secure such that other risks are higher than the update risk.

[matt.collier]

May I suggest another thread for the auto-update debate?

[publickeyhash]

The compiler should use ProPolice or /GS in case of M$

[ene]

As long as the process of getting the binaries is secure.

You missed the point. 

I did? You can make updating secure such that other risks are higher than the update risk.

They're different kinds of risk. If the auto-update has a vulnerability, somebody could steal the private keys of tens of thousands of users in a matter of minutes. If the client software has some other vulnerability, then depending on the nature of it, it will be more or less dangerous than what I just mentioned. Probably less.

[keystroke]

It's been over a year since this thread was touched. I was just looking at my system with Process Explorer and out of the 62 processes, only 3 are not signed. One of them is Bitcoin-qt. Is there any downside to signing? I always verify with Gavin's signature and I trust that keychain more than I would one issued by a centralized authority... We all know what has happened to SSL CAs. Is this the argument?

[Maged]

Is there any downside to signing?

As Matt said...

On code signing:
This one is a bit more difficult.  Because Bitcoin will be built deterministically, we have two options.  A. send the code signing private key around to all the devs for that to be a part of the building process (this is even harder as the building happens on Linux via the MinGW cross compiler) or B. find a way to strip out the code signing certificate in the download script and then check the stripped version instead of the signed version.  I googled this pretty quick and saw no simple CLI program which will do this, but I might have missed something as I didnt spend too much time on it.  If anyone finds something, please tell me. 

As you can see, that's a pretty big downside.

[kjj]

It's been over a year since this thread was touched. I was just looking at my system with Process Explorer and out of the 62 processes, only 3 are not signed. One of them is Bitcoin-qt. Is there any downside to signing? I always verify with Gavin's signature and I trust that keychain more than I would one issued by a centralized authority... We all know what has happened to SSL CAs. Is this the argument?

Matt hit it.  (And Maged beat me to it, but I think I explain more.)

On code signing:
This one is a bit more difficult.  Because Bitcoin will be built deterministically, we have two options.  A. send the code signing private key around to all the devs for that to be a part of the building process (this is even harder as the building happens on Linux via the MinGW cross compiler) or B. find a way to strip out the code signing certificate in the download script and then check the stripped version instead of the signed version.  I googled this pretty quick and saw no simple CLI program which will do this, but I might have missed something as I didnt spend too much time on it.  If anyone finds something, please tell me. 

Bitcoin-qt isn't built in Windows, it is cross-compiled from a Linux.  Even worse, the build process is totally scripted inside a Linux virtual machine.  There are several people that build the binaries in this way, and then they compute hashes on the outputs.  The official releases only get posted after a bunch of people have all built exactly the same files, as verified by the hashes.

To get signed Windows binaries, we would need to distribute the signing key to everyone that builds the releases, which would be bad.  Also, I'm guessing here, but I bet that Microsoft's policies for accepting CA certs for code signing require that the CA have policies that prevent distribution of the keys they hand out.

Phew, I managed to get all of the way through a PKI post without going off onto a tangent about how the current CA scheme used by SSL and everything else is absolutely and totally fucked and broken.  Er, almost.

[casascius]

If the objective is to sign the binaries in a Windows-favored style just so that it's signed for the sake of shutting up the OS about untrusted software, just one person doing the signature will accomplish the objective.  That person can just as well sign with a personal (rather than organizational) signature.  Until Windows makes any distinction between once-signed and multiply-signed binaries, the practical difference is moot.  Mac OS X likely falls under the same umbrella.  Multiple PGP signatures can and ought to be checked by those able to do so.

I might point out that someone downloading an update is far more in a position to be scammed than someone downloading the client for the first time, since the updater is far more likely to own coins.  Therefore, I would submit including an automated update mechanism in the client with authentication built in would be the most effective mechanism to bring secure client downloads to bitcoin users.

I believe that Windows binary signing is meant to make sure that code can be connected with a real person or organization.  It wasn't designed to be a technical based control against all rogue code, it's meant to be a legal/social one (where someone who signs something harmful can be identified and held accountable - as well as the certificate revoked - and therefore has an incentive not to abuse it).

[kjj]

If the objective is to sign the binaries in a Windows-favored style just so that it's signed for the sake of shutting up the OS about untrusted software, just one person doing the signature will accomplish the objective.  That person can just as well sign with a personal (rather than organizational) signature.  Until Windows makes any distinction between once-signed and multiply-signed binaries, the practical difference is moot.  Mac OS X likely falls under the same umbrella.  Multiple PGP signatures can and ought to be checked by those able to do so.

I might point out that someone downloading an update is far more in a position to be scammed than someone downloading the client for the first time, since the updater is far more likely to own coins.  Therefore, I would submit including an automated update mechanism in the client with authentication built in would be the most effective mechanism to bring secure client downloads to bitcoin users.

I believe that Windows binary signing is meant to make sure that code can be connected with a real person or organization.  It wasn't designed to be a technical based control against all rogue code, it's meant to be a legal/social one (where someone who signs something harmful can be identified and held accountable - as well as the certificate revoked - and therefore has an incentive not to abuse it).

I think you missed a key point, pun intended.  The build process demands that multiple people all produce exactly the same binary file, bit for bit.  The only way to do this is to have multiple people with the same private signing key, which is bad security, and had certainly better be grounds for revocation of the signing certificate.

You are somewhat right about the technical control / legal control aspect, but it turns out that whatever the intention was, lots of things treat binaries differently based on the validity of the signature.

[casascius]

I think you missed a key point, pun intended.  The build process demands that multiple people all produce exactly the same binary file, bit for bit.  The only way to do this is to have multiple people with the same private signing key, which is bad security, and had certainly better be grounds for revocation of the signing certificate.

This is a build process that can be changed as needs arise, right?

Simply eliminate the bytes belonging to the signature field from comparison.  Adding a signature, according to a cursory Google search, simply fills in a pre-allocated signature field inside the executable in a location that can be found deterministically from the executable file headers.  When Microsoft hashes the file for the purpose of signature validation, this field is located and excluded from the hash calculation by design, so a signed binary will hash the same as an unsigned one for their signing purposes.  The build process could do the same.  Then it could automatically confirm that the same binary (minus the signature) was signed by everyone, and then you'd have great security.

[Pieter Wuille]

Simply eliminate the bytes belonging to the signature field from comparison.  Adding a signature, according to a cursory Google search, simply fills in a pre-allocated signature field inside the executable in a location that can be found deterministically from the executable file headers.  When Microsoft hashes the file for the purpose of signature validation, this field is located and excluded from the hash calculation by design, so a signed binary will hash the same as an unsigned one for their signing purposes.  The build process could do the same.  Then it could automatically confirm that the same binary (minus the signature) was signed by everyone, and then you'd have great security.

Sounds like it's relatively easy to add/remove such a signature from a binary, so it could be done after the gitian building step, and still be verifiable. I'm all in favor of signing released binaries if it helps making Bitcoin trustworthy. I'm totally oblivious about the process to achieve that for Windows binaries, though.

[Diapolo]

One additional idea for thrustworthyness, could we compute the hash in the binary (a hash of itself during startup) and compare that agains the reference-hash, which resides on the download server or is stored where it can't be manipulated (no master plan for this though) and warn the user or block program usage, when the hashes don't match? I have to admit I never checked the hash of bitcoin-qt.exe btw. ^^ and I would love if I could easily ensure I have a valid and official binary.

Dia

[casascius]

One additional idea for thrustworthyness, could we compute the hash in the binary (a hash of itself during startup) and compare that agains the reference-hash, which resides on the download server or is stored where it can't be manipulated (no master plan for this though) and warn the user or block program usage, when the hashes don't match? I have to admit I never checked the hash of bitcoin-qt.exe btw. ^^ and I would love if I could easily ensure I have a valid and official binary.

Dia

Problem is that someone who modifies a binary to be malicious will just as easily modify the self-test to falsely report success.

The only self-testing that's really sensible is for the currently installed version to acquire and verify the next version you're about to install to replace it.  The way I see it, this would actually be a strong defense against a whole lot of potential fake-client attack avenues.

[Mike Hearn]

Agree with Mike, just one quibble - the main usage of PE signatures today is so anti-virus systems can automatically learn reputation. Having a binary signed by a "good" organization that has lots of installs and few/no reports of being a virus means even if the executable/DLL is brand new, it'll be left alone. It also helps AV engines detect modified system libraries. For this reason it's really helpful to let Bitcoin develop a good reputation - it'll reduce AV FPs.

A tool to strip the signatures from EXEs is probably already in existence, if not it'd be easy to write (for either windows or linux, though don't we already depend on Wine?).

[stevegee58]

Bitcoin is an open-source project.  Build the client yourself from source to guarantee you don't run a compromised executable.

That's the whole point of open source.

[kjj]

Bitcoin is an open-source project.  Build the client yourself from source to guarantee you don't run a compromised executable.

That's the whole point of open source.

Not a guarantee

[stevegee58]

Bitcoin is an open-source project.  Build the client yourself from source to guarantee you don't run a compromised executable.

That's the whole point of open source.

Not a guarantee

Well OK.  I meant you actually *read* the code before building it.

[stevegee58]

The point is that you have to *trust* the person who signed it.  What if s/he is hacked and a malicious exe is signed and uploaded?

The act of signing doesn't make it trustworthy.

[kjj]

Bitcoin is an open-source project.  Build the client yourself from source to guarantee you don't run a compromised executable.

That's the whole point of open source.

Not a guarantee

Well OK.  I meant you actually *read* the code before building it.

Heh.  You didn't read the whole thing.

(He put a backdoor-generator into a C compiler.)

[casascius]

The point is that you have to *trust* the person who signed it.  What if s/he is hacked and a malicious exe is signed and uploaded?

The act of signing doesn't make it trustworthy.

The act of signing makes it independently provable that they signed it, so they can be held accountable for doing so.  Most people will behave better when they know they are accountable for their actions.

The process of requiring multiple people to compile identical binaries before releasing anything mitigates the risk of a person getting hacked.  Having everyone hacked simultaneously when they live far apart is pretty unlikely, and certificate revocation always remains possible if it somehow did happen.

[kuzetsa]

((...snip...)) main usage of PE signatures today is so anti-virus systems can automatically learn reputation. Having a binary signed by a "good" organization that has lots of installs and few/no reports of being a virus means even if the executable/DLL is brand new, it'll be left alone. It also helps AV engines detect modified system libraries. For this reason it's really helpful to let Bitcoin develop a good reputation - it'll reduce AV FPs.
((...snip...))

Indeed. Thanks Mike.

Regardless of how open source platform(s) normally do things, over the next release or two, there will likely still be significant market share for microsoft OSes and the respective antivirus and security tech in use.

((...snip...)) I was just looking at my system with Process Explorer and out of the 62 processes, only 3 are not signed. One of them is Bitcoin-qt. Is there any downside to signing?
((...snip...))

I can think of at least two and a half reasons not to sign:

• Difficulties settling on a method (consensus) for implementing a signature recognized by microsoft OS platforms
• Assorted reservations, resentment, or paranoia regarding changes to the toolchain and/or methods to produce the signed version. (possibly using a non-free tool, or even a different compiler)
• If nobody else is willing, I might have to get off my lazy butt and do it myself. NO WANT MY THE EFFORTS!!! (partly joking, but I really could do this myself)

...Edited to add:

Oh, and as for the "unsigned processes" I have a similarly low number of unsigned ones. More than one of my signed processes is even open source.

[casascius]

I can think of at least two and a half reasons not to sign:

• Difficulties settling on a method (consensus) for implementing a signature recognized by microsoft OS platforms
• Assorted reservations, resentment, or paranoia regarding changes to the toolchain and/or methods to produce the signed version. (possibly using a non-free tool, or even a different compiler)
• If nobody else is willing, I might have to get off my lazy butt and do it myself. NO WANT MY THE EFFORTS!!! (partly joking, but I really could do this myself)

It sounds to me like the way Microsoft hashes and signs its binaries are based on industry standards and not proprietary toolchains. Search Google for windows portable authenticode executable signature format... it should be possible to validate the signature without a need for Microsoft's OS, possibly with a simple home-made tool.

[kuzetsa]

Yep. Google is nice

http://sourceforge.net/projects/libwdi/files/utilities/

cathash:
multiplatform MS CAT/Authenticode SHA-1 generation. Inspired by the tool of the same name by Michel I. Gallant.

Can be used to compute the custom SHA-1 used by Microsoft and others for Authenticode and CAT file validation.

Unlike its counterpart, this program will compile and run on any platform, including big endian UNIX.

[Matt Corallo]

Awesome! If anyone has the time to do this, it would need to be applied in gitian updater at:
https://github.com/devrandom/gitian-builder/blob/master/share/gitian_updater.py
(We will (hopefully) eventually use gitian-updater to do automatic updates with signature checking (before anyone starts complaining, yes, with user permission)).

[kuzetsa]

This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE

...

@Matt Corallo

  Uh... what?

That's not what a signed binary means. This is GPG, not "authenticode" (so it's not the type used on the microsoft OS platforms)

The original post wasn't requesting "auto update" either.  

[tucenaber]

Not a guarantee

Thank you! I've tried to locate that article several times but failed because I thought it was by Dijkstra

[Matt Corallo]

That's not what a signed binary means. This is GPG, not "authenticode" (so it's not the type used on the microsoft OS platforms)

The original post wasn't requesting "auto update" either.  

I'm sure Gavin is perfectly capable of signing binaries, so the only thing that needs written is a way for gitian updater to verify signed binaries (by ignoring signatures).  (Note that you can also use gitian to download the first time if you want, not just on updates).  Because most people just download and check hashes against Gavin's signed release announcement, nothing needs to change there...just report the hashes of the signed copies.

[kuzetsa]

...Note that you can also use gitian to download the first time if you want, not just on updates...

huh? I've been manually installing my bitcoin client (and checking hashes, etc.) what on earth are you referring to? What does this "gitian" thing have to do with:

Windows Authenticode Portable Executable Signature Format

Threat mitigation sometimes involves "silly" system enforced policies such as Allowing Only Signed Application to Run

... Isn't this thread about signing the windows version of bitcoin client?

[Matt Corallo]

...Note that you can also use gitian to download the first time if you want, not just on updates...

huh? I've been manually installing my bitcoin client (and checking hashes, etc.) what on earth are you referring to? What does this "gitian" thing have to do with:

Yes, that is one way to download the bitcoin client securely.  Gitian is used to build the client distributedly, as well as being capable of handling auto-update (which we will hopefully use in the not-too-distant-future), which needs to be able to verify the signed binary (by stripping the signature). 

... Isn't this thread about signing the windows version of bitcoin client?

Yes, I understand what this thread is about...

[kuzetsa]

But gitian uses pgp-type rather than  authenticode signing.

Suspect I'm likely missing something, but  why can't the result of whatever build process just get an authenticode signature added and be done with it? If gitian just builds the unsigned binary, why does gitian even need an update for this?

Is there a super-essential absolutely mandatory required step which wasn't explained in the original post or otherwise documented somewhere? It sure isn't anything the official microsoft instructors taught back when I was getting MCSD / MCSE / etc. at my "corporate training" center back in the day.

I highly suspect this is because the build process for the windows version is cross compiled using a non-windows system using non-microsoft compilers (probably mingw gcc target or something similar)

At this point I think I'm feeling defeated enough / begun to realize  I should probably give up trying to understand what's even being done, why, which tools, etc.

  Sorry, I really am a windows dev / sysadmin once you get past all my open-source hobby tinkering.

Feels soooo weird that any credentials or training I might have are completely and utterly irrelevant for making the windows build process any more standard-like. I'm not young enough, and by now I think I've been retired too long to be useful anymore.

[keystroke]

So Gitian needs to be updated to support checking the signature? Is that correct?
https://github.com/devrandom/gitian-builder/blob/master/share/gitian_updater.py

And before that we need the build process to include automatic signing with an Authenticode certificate?

Couldn't we have Gitian still check the GPG signature and not worry about Authenticode? Then just let Windows worry about Authenticode... that gives an extra layer because GPG is in place and trusted. The GPG signature would just been to be generated after the executable was signed with Authenticode.

eg.
1) Build process - (Any details on how this works? I see there is a distributed build process in place?)
2) Authenticode signs it
3) GPG signs it
...
4) Client side Gitian runs some auto-update eventually and asks the user if they want to upgrade
Note: Is Gitian definitely secure? Eg. no attacks against the auto-update mechanism? Some programs have had this issue...
5) Gitian verified GPG signature against keys which is trusts
6) Gitian executes new Bitcoin installer code
7) Windows checks Authenticode signature and install proceeds as normal

Does the above make sense or am I missing something?

[Gavin Andresen]

Microsoft/authenticode assumes one trusted master key (I think? Can a binary be signed by multiple keys?)

That is contrary to the no-central-authority idea, and it would be nice to avoid that.

However, given that Apple and Microsoft are both going in the direction of "thou shalt be a registered developer to distribute software for our OS" a central signing process for at least the initial install seems inevitable.

This is one of those "interact with existing systems that do not consider the possibility of radically decentralized solutions" hurdles that the Foundation can help jump; I expect the Foundation will soon be a registered Apple and Microsoft developer, and downloads will be signed with certificates owned by the Foundation.

The alternative is downloads only geeks can use (because only geeks know how to turn off cert checks) or binaries signed by me personally. And I don't want to be a single point of failure; having an organization that will hopefully outlive me is a better solution.

The best solution would be multi-signed binaries and a decentralized web of trust system, but we're not there yet.

[flatfly]

Microsoft/authenticode assumes one trusted master key (I think? Can a binary be signed by multiple keys?)

That is contrary to the no-central-authority idea, and it would be nice to avoid that.

However, given that Apple and Microsoft are both going in the direction of "thou shalt be a registered developer to distribute software for our OS" a central signing process for at least the initial install seems inevitable.

This is one of those "interact with existing systems that do not consider the possibility of radically decentralized solutions" hurdles that the Foundation can help jump; I expect the Foundation will soon be a registered Apple and Microsoft developer, and downloads will be signed with certificates owned by the Foundation.

The alternative is downloads only geeks can use (because only geeks know how to turn off cert checks) or binaries signed by me personally. And I don't want to be a single point of failure; having an organization that will hopefully outlive me is a better solution.

The best solution would be multi-signed binaries and a decentralized web of trust system, but we're not there yet.

Yeah this would be more or less similar to what Mozilla does with the Firefox binaries.
(The installer is signed by a "Mozilla Corporation" cert, delivered by Thawte)

[kuzetsa]

((...snip...))
That is contrary to the no-central-authority idea, and it would be nice to avoid that.

However, given that Apple and Microsoft are both going in the direction of "thou shalt be a registered developer to distribute software for our OS" a central signing process for at least the initial install seems inevitable.

This is one of those "interact with existing systems that do not consider the possibility of radically decentralized solutions" hurdles that the Foundation can help jump; I expect the Foundation will soon be a registered Apple and Microsoft developer, and downloads will be signed with certificates owned by the Foundation.
((...snip...))

Indeed, that was what I meant. Thanks gavin. 

Reassuring to know that my perception of the build process was roughly accurate. As to the question put forward in the original post, I think the answer might be something like: "only thing stopping it is that there is no plan in place to use an the appropriate certificate in the build process, and it doesn't help matters that we don't have one yet anyway"

Huh. Apple certificates... Maybe I should act one of my friends about the apple end. One who lives 3 blocks up the street from me is a self described "apple hipster" and whatnot. She happens to also be self-described as OS-agnostic though, among other technical goodies. Nothing wrong with favoring one platform other another.

[Matt Corallo]

The idea would be:
1. Build distributed (like is done now) with gitian (all builds PGP signed).
2. One person signs binaries (gavin, bitcoin foundation, etc).
3. Bitcoin sees a new version and calls gitian to verify the new version.
4. Gitian strips the signature from the binary before checking the PGP signatures made in step 1 (this is where support is needed).
5. Gitian installs new version.

[kuzetsa]

The idea would be:
1. Build distributed (like is done now) with gitian (all builds PGP signed).
2. One person signs binaries (gavin, bitcoin foundation, etc).
3. Bitcoin sees a new version and calls gitian to verify the new version.
4. Gitian strips the signature from the binary before checking the PGP signatures made in step 1 (this is where support is needed).
5. Gitian installs new version.

  So is there some sort of builtin updater (I've never personally used such a feature) which checks against pgp signatures?

Is that what all this fuss was about?

... I think I get it now  


Edited to add:

no wait nevermind I'm still quite stumped.

I just looked in the v0.7.0-beta of "bitcoind / bitcoinqt" and there seems to be no such feature. ya'll are talking about something I know nothing about. is there a thread somewhere that explains this tool or feature or whatever it is? I don't understand why is it important? (either in this context, or at all?)

[Matt Corallo]

So is there some sort of builtin updater (I've never personally used such a feature) which checks against pgp signatures?

Its not builtin (yet), but it exists, and we want to make sure whatever we do is compatible because we will hopefully use it (eventually).

Is that what all this fuss was about?

Yep

I just looked in the v0.7.0-beta of "bitcoind / bitcoinqt" and there seems to be no such feature. ya'll are talking about something I know nothing about. is there a thread somewhere that explains this tool or feature or whatever it is? I don't understand why is it important? (either in this context, or at all?)

https://github.com/bitcoin/bitcoin/pull/1453