Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On 3 January 2014 05:45, Troy Benjegerdes ho...@hozed.org wrote: On Tue, Dec 31, 2013 at 05:48:06AM -0800, Gregory Maxwell wrote: On Tue, Dec 31, 2013 at 5:39 AM, Drak d...@zikula.org wrote: The NSA has the ability, right now to change every download of bitcoin-qt, on the fly and the only cure is encryption. No, the only cure is the check the hashes. We should know something about hashes here. TLS is a big pile of 'too big to audit'. Spend a couple of satoshis and put the hash of the source tar.gz and the binaries in the blockchain. Problem solved. Which is why, as pointed out several times at 30c3 by several renowned figures, why cryptography has remained squarely outside of mainstream use. It needs to just work and until you can trust the connection and what the end point sends you, automatically, it's a big fail and the attack vectors are many. sarcasmI can just see my mother or grandma manually checking the hash of a download... /sarcasm Drak -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
You know if you want to make some form of investment, you might like make an attempt to look them up on the internet, check the phone number in a phone book or directory enquiries, look for references and reviews? So it is with the hash of the binary you are about to trust with your investment funds. I dont think its such a difficult question. Ask your more technical friends to confirm this hash is correct. Its interesting that hashes are more trustworthy than signatures, since all the NSLs and backdoors, its hard to trust a signature. I have the same problem with linux distros that want to install hundreds of components downloaded over the internet, based on signatures. I would far rather a merkle hash of the distribution at that point in time, which authenticates directly any of the optional downloadable components. (Or better yet a distro that like comes on a CD and doesnt download anything... Amazing how most CD and even DVD iso images immediately download stupid things like fonts??? What were they thinking? I downloaded fedora 4GB of stuff and they need to download a font just to get past step 2 of the installer? Thats a sensless, retrograde, selective backdoor opportunity.) Adam On Fri, Jan 03, 2014 at 11:22:35AM +, Tier Nolan wrote: On Fri, Jan 3, 2014 at 9:59 AM, Drak [1]d...@zikula.org wrote: Which is why, as pointed out several times at 30c3 by several renowned figures, why cryptography has remained squarely outside of mainstream use. It needs to just work and until you can trust the connection and what the end point sends you, automatically, it's a big fail and the attack vectors are many. sarcasmI can just see my mother or grandma manually checking the hash of a download... /sarcasm Maybe a simple compromise would be to add a secure downloader to the bitcoin client. The download link could point to a meta-data file that has info on the download. file_url= hash_url= sig_url= message=This is version x.y.z of the bitcoin client It still suffers from the root CA problem though. The bitcoin client would accept Gavin's signature or a core team signature. At least it would provide forward security. It could also be used to download files for different projects, with explicit warnings that you are adding a new trusted key. When you try to download, you would be given a window Project: Some Alternative Wallet Signed by: P. Lead Message: Confirm download Yes No However, even if you do that, each trusted key is only linked to a particular project. It would say if the project and/or leader is unknown. References 1. mailto:d...@zikula.org -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On 1/3/14, Troy Benjegerdes ho...@hozed.org wrote: 'make' should check the hash. An attacker could replace that part of the makefile. Anyway, I think this is more oriented for compiled binaries, not for people downloading the sources. I assume most of that people just use git. The binary should check it's own hash. I'm afraid this is not possible. The operating system should check the hash. There's package management systems like apt-secure that do exactly this. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On 12/31/13, Mike Hearn m...@plan99.net wrote: remember suggesting that we whack Google Analytics or some other statistics package on when the new website design was done and that was rejected for similar reasons (organisations are bad). Analytics software would be useful. I suggest using Piwik or another free software alternative instead of Google's package. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
So I looked into gitian, the first thing I noticed was the hashes that people were signing, for example: https://github.com/bitcoin/gitian.sigs/blob/master/0.8.6-win32/gavinandresen/bitcoin-build.assert don't match the hash of the file 'bitcoin-0.8.6-win32-setup.exe' actually hosted by sourceforce. That was a bit alarming at first, but I talked to BlueMatt and maaku on IRC and the difference is due to Gavin Authenticode signing the executable for windows. BlueMatt asked if someone could implement in gitian-downloader a way to strip off the signature so that we could get back to the raw binary with a hash that matches what everyone is producing from gitian. I found: http://blog.didierstevens.com/programs/disitool/ which is a Python script which can strip the signature nicely, but the hashes still don't match. I couldn't find a gitian build of 0.8.6 so I built my own, and after verifying the hash for v0.8.6 was '49547ff9...' as expected I looked at the hex diff between that and the sig-stripped .exe from sourceforge, and the only two differences are: - At offset D8 the stripped file has '5D E2 B2' versus 'F9 F4 00' in the gitian build - The sig-stripped file has an extra byte '00' at the end I started to look at the file spec for windows PE files and quickly thought better of it. Maybe someone better informed can chime in on what those three bytes at offset D8 specify. I'm not sure if we want to patch the signature onto the gitian build, or strip the signature off of the Gavin-signed build, but something of the sort is necessary if you want get gitian-downloader to match the official distro (for Windows at least). In any case, I think wallet users want to know when an upgrade is available, and ability to click an 'update' button get a binary they can trust. It's not a problem unique to bitcoind, deterministic builds are awesome, but I don't think fully solve it. Thanks, Jeremy On Tue, 31 Dec 2013 13:33:54 -0800, Matt Corallo bitcoin-l...@bluematt.me wrote: We already have a wonderful system for secure updating - gitian-downloader. We just neither use it not bother making actual gitian releases so anyone can use it to verify signatures of downloads. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
That seems overly complicated, there's no need for the Bitcoin protocol to be involved. Deterministic builds with threshold signed updates are a problem the entire crypto community is now interested in solving - any solution should be generic. Really all you need is an update engine that allows a CHECKMULTISIG type approach. When the update engine is not under our control, i.e. on Android, Shoup style RSA threshold signatures can potentially work (though I must admit, I have never found time to play with the implementation I have for that algorithm). On Tue, Dec 31, 2013 at 9:25 PM, Jeremy Spilman jer...@taplink.co wrote: I didn't know about the dedicated server meltdown, it wasn't any of my infra. Anyway, my previous offer still stands. One less 'security theater' approach would be if we could provide forward-validation of updates using the blockchain. It's always going to be up to the user the first time they install the wallet to verify the provenance of the binaries/source. From that point forward, we could make it easier if the wallet could detect updates and prove they were valid. This could be as simple as hard-coding a public key into the client and checking a signature on the new binaries. But it could also be more interesting... For example, a well known address on the blockchain corresponds to multi-sig with keys controlled by developers (or whatever key policy the release team wants to impose). A spend from that address announces a new release, and includes the expected hash of the file. You would probably need some way to handle the different release targets. A more rigorous approach could identify all the various releases in terms of a BIP32 xpubkey whose branches would correspond to the different release trains and platform builds. Spends from a node announce the release and the expected hash. This provides zero benefit if the wallet software is already compromised, but I think this would allow trusted automatic update notification, and a trusted way to deliver the expected hashes. It also might resolve some of the consternation around when a release is truly released, if that's really a problem. I'm not sure how far along the slope you would want to go; 1) announcing updates in the UI, 2) providing a button the user could click to verify a binary matches its expected hash, 3) click to download and verify the upgrade matches the expected hash, 4) click to upgrade Formalizing the release process around a set of privkeys (or split shares of keys) may raise its own set of questions. For the download itself, I've heard the advocates of announcing availability on the blockchain leading to a BitTorrent magnet link, but I also understand objections to adding an entire BitTorrent stack into a wallet. On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn m...@plan99.net wrote: The site was actually moved onto a dedicated server temporarily and it melted down under the load. I wouldn't call that no progress. Oh, it did? When was that? I must have missed this excitement :) Any idea how much load it had? Perhaps I wasn't clear on the point I was making Drak's threat model is not improved in the slightest by SSL. It would be improved by increasing the use of signature checking, e.g. by making it easier. Well, that depends. If you watch Applebaums talk he is pushing TLS pretty hard, and saying that based on the access to the source docs some of their MITM attacks can't beat TLS. It appears that they have the capability to do bulk MITM and rewrite of downloads as Drak says but *not* when TLS is present, that would force more targeted attacks. So to me that implies that TLS does raise the bar and is worth doing. However if we can't find a server that won't melt under the load, then that'd be an issue. We could consider hosting downloads on AppEngine or something else that can handle both high load and TLS. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
Oh, it did? When was that? I must have missed this excitement :) I would be very interested to learn more about this. It seems the steady state load on the site is not very high: https://github.com/bitcoin/bitcoin.org/pull/287 (Saivann ran Google Analytics on the site for a little while to get traffic figures). Peak of 10 visitors per second, assume a 10x blowup on resources, that's only ~100 reqs/sec steady state, that shouldn't strain any kind of reasonable server. So perhaps the specs of the dedicated server were not what you might imagine. Perhaps we should move the site over to Jeremy's hosting? It shouldn't be very expensive to serve outside of major press cycles. Once that is done, perhaps we can find/blag some SSL-protected file hosting. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
Has anyone seen the talk at 30c3 on the current NSA capabilities? https://www.youtube.com/watch?v=b0w36GAyZIA Specifically they are able to beat the speed of light between you and a website such that if you communicate with Bob, they can sent competing packets that will arrive before Bob's packets. They have realtime deep packet insertion able to inject arbitrary data into an TCP streams and can change file downloads **on the fly**. This can be done remotely. Sourceforge do not have https downloads, so this is yet another reason to move downloads to somewhere that does - like github. The NSA has the ability, right now to change every download of bitcoin-qt, on the fly and the only cure is encryption. Revealed as part of the presentation is the fact that if the NSA has access to these capabilities, then so do others and in fact one of the things revealed yesterday was independently discovered already and published. Same goes for the bitcoin.org site - why are we dragging our feet on installing an SSL certificate and redirecting all http to https? While no solution is perfect, it's a lot better than zero defense. You can see the irony of disseminating the bitcoin crypto-currency client in the clear. For anyone who has not seen the video. You will be shocked by what is actually in the wild being used today. It goes way beyond anything imaginable even in science fiction. https://www.youtube.com/watch?v=b0w36GAyZIA Drak -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On Tue, Dec 31, 2013 at 5:39 AM, Drak d...@zikula.org wrote: The NSA has the ability, right now to change every download of bitcoin-qt, on the fly and the only cure is encryption. Please cut it out with the snake oil pedaling. This is really over the top. You're invoking the NSA as the threat here? Okay. The NSA can trivially compromise an HTTPS download site: even ignoring the CA insecurity, and government run CAs certificate authorities issue CA certs to random governments and corporations for dataloss prevention purposes. Not to mention unparalleled access to exploits. The downloads are protected by something far stronger than SSL already, which might even have a chance against the NSA. Actual signatures of the downloads with offline keys. I'm all pro-SSL and all that, but you are— piece by piece— really convincing me that it produces an entirely false sense of security which is entirely unjustified. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
Given that hardly anyone checks the signatures, it's fair to say downloads aren't protected by anything at the moment. SSL for downloads can only raise the bar, never lower it, and if the NSA want to kick off the process of revoking some of the big CA's then I'm game (assuming anyone detects it of course) :) Anyway, nobody is dragging feet, the problem is right now we get what is effectively a huge free subsidy from github and SourceForge for site hosting. The cost is no SSL. So getting SSL would require that we pay for it ourselves, but the primary method we have for funding public goods/infrastructure (the Foundation) which is the subject of various conspiracy theories. Jeremy has made a generous offer further up the thread, the issue being I guess none of us know how much traffic we actually get :( I remember suggesting that we whack Google Analytics or some other statistics package on when the new website design was done and that was rejected for similar reasons (organisations are bad). So we are in a position where we get a subsidy of large but unknown size from various existing US corporations, but moving to different ones is controversial, hence no progress :) On Tue, Dec 31, 2013 at 1:48 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Dec 31, 2013 at 5:39 AM, Drak d...@zikula.org wrote: The NSA has the ability, right now to change every download of bitcoin-qt, on the fly and the only cure is encryption. Please cut it out with the snake oil pedaling. This is really over the top. You're invoking the NSA as the threat here? Okay. The NSA can trivially compromise an HTTPS download site: even ignoring the CA insecurity, and government run CAs certificate authorities issue CA certs to random governments and corporations for dataloss prevention purposes. Not to mention unparalleled access to exploits. The downloads are protected by something far stronger than SSL already, which might even have a chance against the NSA. Actual signatures of the downloads with offline keys. I'm all pro-SSL and all that, but you are— piece by piece— really convincing me that it produces an entirely false sense of security which is entirely unjustified. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
Interesting. I think the original BitDNS discussion was more interesting that what currently is happening with namecoin, see https://bitcointalk.org/index.php?topic=1790.0 Satoshi said there: 1) IP records don't need to be in the chain, just do registrar function not DNS. And CA problem solved, neat. Besides, ICANN is currently selling out the global public namespace - not that anybody really cares about such measly topics as the ownership of global namespaces. And so some guy on the Cayman Islands is now the largest holder of TLD's. On Tue, Dec 31, 2013 at 2:48 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Dec 31, 2013 at 5:39 AM, Drak d...@zikula.org wrote: The NSA has the ability, right now to change every download of bitcoin-qt, on the fly and the only cure is encryption. Please cut it out with the snake oil pedaling. This is really over the top. You're invoking the NSA as the threat here? Okay. The NSA can trivially compromise an HTTPS download site: even ignoring the CA insecurity, and government run CAs certificate authorities issue CA certs to random governments and corporations for dataloss prevention purposes. Not to mention unparalleled access to exploits. The downloads are protected by something far stronger than SSL already, which might even have a chance against the NSA. Actual signatures of the downloads with offline keys. I'm all pro-SSL and all that, but you are— piece by piece— really convincing me that it produces an entirely false sense of security which is entirely unjustified. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
I didn't know about the dedicated server meltdown, it wasn't any of my infra. Anyway, my previous offer still stands.One less 'security theater' approach would be if we could provide forward-validation of updates using the blockchain. It's always going to be up to the user the first time they install the wallet to verify the provenance of the binaries/source. From that point forward, we could make it easier if the wallet could detect updates and prove they were valid.This could be as simple as hard-coding a public key into the client and checking a signature on the new binaries. But it could also be more interesting...For example, a well known address on the blockchain corresponds to multi-sig with keys controlled by developers (or whatever key policy the release team wants to impose). A spend from that address announces a new release, and includes the expected hash of the file.You would probably need some way to handle the different release targets. A more rigorous approach could identify all the various releases in terms of a BIP32 xpubkey whose branches would correspond to the different release trains and platform builds. Spends from a node announce the release and the expected hash.This provides zero benefit if the wallet software is already compromised, but I think this would allow trusted automatic update notification, and a trusted way to deliver the expected hashes. It also might resolve some of the consternation around when a release is truly "released", if that's really a problem.I'm not sure how far along the slope you would want to go; 1) announcing updates in the UI, 2) providing a button the user could click to verify a binary matches its expected hash, 3) click to download and verify the upgrade matches the expected hash, 4) click to upgradeFormalizing the release process around a set of privkeys (or split shares of keys) may raise its own set of questions.For the download itself, I've heard the advocates of announcing availability on the blockchain leading to a BitTorrent magnet link, but I also understand objections to adding an entire BitTorrent stack into a wallet.On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn m...@plan99.net wrote:The site was actually moved onto a dedicated server temporarily and it melted down under the load. I wouldn't call that no progress.Oh, it did? When was that? I must have missed this excitement :)Any idea how much load it had? Perhaps I wasn't clear on the point I was making Drak's threat model is not improved in the slightest by SSL. It would be improved by increasing the use of signature checking, e.g. by making it easier.Well, that depends. If you watch Applebaums talk he is pushing TLS pretty hard, and saying that based on the access to the source docs some of their MITM attacks can't beat TLS. It appears that they have the capability to do bulk MITM and rewrite of downloads as Drak says but *not* when TLS is present, that would force more targeted attacks. So to me that implies that TLS does raise the bar and is worth doing. However if we can't find a server that won't melt under the load, then that'd be an issue. We could consider hosting downloads on AppEngine or something else that can handle both high load and TLS. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
We already have a wonderful system for secure updating - gitian-downloader. We just neither use it not bother making actual gitian releases so anyone can use it to verify signatures of downloads. Jeremy Spilman jer...@taplink.co wrote: I didn't know about the dedicated server meltdown, it wasn't any of my infra. Anyway, my previous offer still stands. One less 'security theater' approach would be if we could provide forward-validation of updates using the blockchain. It's always going to be up to the user the first time they install the wallet to verify the provenance of the binaries/source. From that point forward, we could make it easier if the wallet could detect updates and prove they were valid. This could be as simple as hard-coding a public key into the client and checking a signature on the new binaries. But it could also be more interesting... For example, a well known address on the blockchain corresponds to multi-sig with keys controlled by developers (or whatever key policy the release team wants to impose). A spend from that address announces a new release, and includes the expected hash of the file. You would probably need some way to handle the different release targets. A more rigorous approach could identify all the various releases in terms of a BIP32 xpubkey whose branches would correspond to the different release trains and platform builds. Spends from a node announce the release and the expected hash. This provides zero benefit if the wallet software is already compromised, but I think this would allow trusted automatic update notification, and a trusted way to deliver the expected hashes. It also might resolve some of the consternation around when a release is truly released, if that's really a problem. I'm not sure how far along the slope you would want to go; 1) announcing updates in the UI, 2) providing a button the user could click to verify a binary matches its expected hash, 3) click to download and verify the upgrade matches the expected hash, 4) click to upgrade Formalizing the release process around a set of privkeys (or split shares of keys) may raise its own set of questions. For the download itself, I've heard the advocates of announcing availability on the blockchain leading to a BitTorrent magnet link, but I also understand objections to adding an entire BitTorrent stack into a wallet. On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn m...@plan99.net wrote: The site was actually moved onto a dedicated server temporarily and it melted down under the load. I wouldn't call that no progress. Oh, it did? When was that? I must have missed this excitement :) Any idea how much load it had? Perhaps I wasn't clear on the point I was making Drak's threat model is not improved in the slightest by SSL. It would be improved by increasing the use of signature checking, e.g. by making it easier. Well, that depends. If you watch Applebaums talk he is pushing TLS pretty hard, and saying that based on the access to the source docs some of their MITM attacks can't beat TLS. It appears that they have the capability to do bulk MITM and rewrite of downloads as Drak says but *not* when TLS is present, that would force more targeted attacks. So to me that implies that TLS does raise the bar and is worth doing. However if we can't find a server that won't melt under the load, then that'd be an issue. We could consider hosting downloads on AppEngine or something else that can handle both high load and TLS. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
I've been lurking on this convo since it began, but I wanted to say thanks, theymos cheers to you all and yay for decentralization, wherever it leads. -odinn muh latest: http://github.com/ABISprotocol/ABIS On Sun, Dec 8, 2013, at 03:11 PM, Drak wrote: It's not just about trust, there is the robustness factor: what if he becomes sick, unavailable, hit by a bus? Others need the ability to pickup and run with it. The control over the domain (including ability to renew registration, alter nameservers) needs to be with more than one person. That's why I suggest using the same people who have control over the software project at sf,github The bitcoin.org domain is controlled by me, Sirius, and an anonymous person. Control will not be lost if Sirius becomes unavailable. SSL is probably a good idea, and it's probably also a good idea to separate bitcoin.org from Github. I don't know that I trust Github. I'm sure that you can find a sponsor for a dedicated server. Let us know if DNS changes to bitcoin.org are required. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
There is really no excuse for not using an SSL certificate. Without one it
would be trivial for an attacker to change the contents of the page via
MITM.
Recent studies have shown MASSIVE abuse of the BGP routing protocol being
used to redirect websites through a third party.
This is not a theoretical attack, it's happening every single day on a
global scale and could be used to divert users to a rogue versions of
software.
It's just a matter of time... it will happen sooner or later given the
incentives it could bring...
Recent references:
http://www.theregister.co.uk/2013/11/22/net_traffic_redirection_attacks/
http://www.wired.com/threatlevel/2013/12/bgp-hijacking-belarus-iceland/
The only way to mitigate these MITMs is to use SSL.
Also it's about time we hosted the Bitcoin Qt software at Github. They have
a releases feature where you can upload a packaged release (see
https://github.com/blog/1547-release-your-software). There are also no
adverts (another privacy leak at the least) and many feel are more
trustworthy than Sourceforge: it also makes sense to have the downloads
where the source is developed.
Regards,
Drak
On 8 December 2013 03:38, Odinn Cyberguerrilla
odinn.cyberguerri...@riseup.net wrote:
Hello, re. the dedicated server for bitcoin.org idea, I have a few
thoughts
1) I have commented in a blogpost of August 2013 at
https://odinn.cyberguerrilla.org/ with some thoughts relative to possible
issues with CA related to bitcoin.org - where I mentioned something
relative to the DigiCert certificate,
DigiCert “may revoke a Certificate, without notice, for the reasons
stated in the CPS, including if DigiCert reasonably believes that” (…)
“Applicant is added to a government list of prohibited persons or entities
or is operating from a prohibited destination under the laws of the United
States” (…) “the Private Key associated with a Certificate was disclosed
or Compromised”
In the same post I mentioned
Bitcoin.org has no certificate, no encryption — a situation which has its
own obvious problems. Bitcoin.org currently sends users to download the
bitcoin-qt client from sourceforge. Sourceforge is encrypted and has a
certificate based on GeoTrust:
https://www.geotrust.com/resources/repository/legal/;
(Currently (Dec. 7, 2013) bitcoin.org shows as 'not verified' and 'not
encrypted' examining it in a cursory fashion w/ Chrome)
Not sure how this would work, but it would be nice to see the content at
bitcoin.org encrypted, of course, but also further decentralized? how many
mirrors are there of bitcoin.org - not sure, but a few things that come to
mind when thinking of this are Tahoe-LAFS and also .bit stuff (namecoin).
There are many ways to decentralize something but that is just something
that comes to mind.
This has been discussed at https://bitcointalk.org/index.php?topic=16312.0
('Is Bitcoin.org a weakness of bitcoin?) in the past and see also this
https://bitcointalk.org/index.php?topic=119652.0 which discusses mirroring
of certain content
Some things to think about.
I would like to know what are your thoughts on moving bitcoin.org on a
dedicated server with a SSL certificate?
I am considering the idea more seriously, but I'd like some feedback
before taking steps.
Saïvann
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On Sun, Dec 8, 2013 at 11:16 AM, Drak d...@zikula.org wrote: BGP redirection is a reality and can be exploited without much You're managing to argue against SSL. Because it actually provides basically protection against an attacker who can actively intercept traffic to the server. Against that threat model SSL is clearly— based on your comments— providing a false sense of security. We _do_ have protection that protect against that— the pgp signature, but they are far from a solution since people do not check that. (I'm not suggesting we shouldn't have it, I'm suggesting you stop arguing SSL provides protection it doesn't before you manage to change my mind!) -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On Sun, Dec 8, 2013 at 12:40 PM, Drak d...@zikula.org wrote: Let me clarify. SSL renders BGP redirection useless because the browser holds the signatures of CA's it trusts: an attacker cannot spoof a certificate because it needs to be signed by a trusted CA: that's the point of SSL, it encrypts and proves identity, the latter part is what thwarts MITM. If there was an MITM the browser screams pretty loudly about it with a big threat warning interstitial. Sadly this isn't true: There are (many) CAs which will issue a certificate (apparently sometime within minutes, though last certificate I obtained took a couple hours total) to anyone who can respond to http (not https) requests on behalf of the domain from the perspective of the CA. This means you can MITM the site, pass all traffic through except the HTTP request from the CA, and start intercepting once the CA has signed your certificate. This works because the CA does nothing to verify identity except check that the requester can control the site. If you'd like to me to demonstrate this attack for you I'd be willing— I can provide a proxy that passes on :80 and :443, run your traffic through it and I'll get a cert with your domain name. I'm sorry for the tangent here— I think this sub-discussion is really unrelated to having Bitcoin.org behind SSL— but someone is wrong on the internet, and its important to know that SSL hardly does anything to reduce the need to check the offline signatures on the binaries. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On 8 December 2013 20:40, Gregory Maxwell gmaxw...@gmail.com wrote: On Sun, Dec 8, 2013 at 12:28 PM, Mike Hearn m...@plan99.net wrote: Right now I think Sirius still owns DNS for bitcoin.org which is nonsense. He needs to pass it on to someone who is actually still involved with the project. Again, the most obvious neutral candidate would be the Foundation. I am opposed to Bitcoin Foundation having control of Bitcoin.org, and I think it would be foolish of the foundation to accept it were it offered. What do you suggest though? We will need to trust someone (even in a group each person can act autonomously). The only thing I can suggest would be to hand the keys to the bitcoin project lead. Otherwise, who has admin rights to the code projects (github/sourceforge/this mailing list)? Those people have proven they can be trusted so far. Drak -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On Sunday, December 08, 2013 8:51:07 PM Drak wrote: Otherwise, who has admin rights to the code projects (github/sourceforge/this mailing list)? Those people have proven they can be trusted so far. Can someone explain how Sirius has proven the least bit untrustworthy? Luke -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On 8 December 2013 21:01, Luke-Jr l...@dashjr.org wrote: On Sunday, December 08, 2013 8:51:07 PM Drak wrote: Otherwise, who has admin rights to the code projects (github/sourceforge/this mailing list)? Those people have proven they can be trusted so far. Can someone explain how Sirius has proven the least bit untrustworthy? It's not just about trust, there is the robustness factor: what if he becomes sick, unavailable, hit by a bus? Others need the ability to pickup and run with it. The control over the domain (including ability to renew registration, alter nameservers) needs to be with more than one person. That's why I suggest using the same people who have control over the software project at sf,github. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On Sun, 8 Dec 2013 13:14:44 -0800, Gregory Maxwell wrote: On Sun, Dec 8, 2013 at 1:07 PM, Drak d...@zikula.org wrote: Simple verification relies on being able to answer the email sent to the person in the whois records, or standard admin/webmaster@ addresses to prove ownership of the domain Godaddy and many other CA's are verified from nothing other than a http fetch, no email involved. It's just as easy to steal emails via a BGP or DNS redirect anyway.. you could even take over the actual domain at the registry level by stealing a password reset via BGP or DNS redirect and actually many registries will hand over control of a domain by faxing them a forged driving license in the owner's name anyway so it doesn't even really need to be a particularly sophisticated attacker. Once you have registry control of the domain it's easy enough to get an SSL cert too, probably even an 'extended validation' one. When Afghanistan was taken over the entire .af TLD was probably transferred using a forged fax to ICANN (http://web.archive.org/web/20041017031020/http://www.iana.org/cctld/af/razeeq-letter-13aug02.pdf) but I guess that's a little different :p Rob -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On Sunday, December 08, 2013 9:16:09 PM Saïvann Carignan wrote: 1) Who pays for it? Most obvious answer: Foundation. However there's currently a fairly clear line between the foundation website and the bitcoin.org http://bitcoin.org website. I personally am fine with the bitcoin foundation funding the website, it's a lot closer to the bitcoin community than github. But some people might care. So next step would be to contact the Foundation board and see if they're willing to fund it. Actually I might find way to fund it. But I needed to have ACK comments from developers before anything. ... 4) Who admins it? Obviously, I thought it would be important that the server is owned by someone who can be trusted, with ssh access for all core developers. 5) Who controls DNS for it? I'm not sure we'll get any change on this level. I have no idea if the domain is in good hands, except for the fact that nothing bad happened thus far. If anything, moving it to core developers (as intended when the domain was registered) would make more sense IMO. But again, is it possible, I don't know. I don't think core developers should be directly in control here any more than the Foundation should. Developers are good for development, not necessarily web or server admin tasks. Only those directly involved in the needed roles should have access IMO. Luke -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On Sun, Dec 8, 2013, at 03:11 PM, Drak wrote: It's not just about trust, there is the robustness factor: what if he becomes sick, unavailable, hit by a bus? Others need the ability to pickup and run with it. The control over the domain (including ability to renew registration, alter nameservers) needs to be with more than one person. That's why I suggest using the same people who have control over the software project at sf,github The bitcoin.org domain is controlled by me, Sirius, and an anonymous person. Control will not be lost if Sirius becomes unavailable. SSL is probably a good idea, and it's probably also a good idea to separate bitcoin.org from Github. I don't know that I trust Github. I'm sure that you can find a sponsor for a dedicated server. Let us know if DNS changes to bitcoin.org are required. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
Have you considered black lotus dedicated servers? On 12/08/2013 03:16 PM, Saïvann Carignan wrote: Issues that would need to be resolved: 1) Who pays for it? Most obvious answer: Foundation. However there's currently a fairly clear line between the foundation website and the bitcoin.org http://bitcoin.org website. I personally am fine with the bitcoin foundation funding the website, it's a lot closer to the bitcoin community than github. But some people might care. So next step would be to contact the Foundation board and see if they're willing to fund it. Actually I might find way to fund it. But I needed to have ACK comments from developers before anything. 2) Anti-DoS? I assume github handles this at the moment, though I doubt there's anything to be gained from DoSing the informational website That is a fair question, we will need anti-DDoS. Unless something better (and affordable) can be recommended, this would yet put another Bitcoin website under CloudFlare. 4) Who admins it? Obviously, I thought it would be important that the server is owned by someone who can be trusted, with ssh access for all core developers. 5) Who controls DNS for it? I'm not sure we'll get any change on this level. I have no idea if the domain is in good hands, except for the fact that nothing bad happened thus far. If anything, moving it to core developers (as intended when the domain was registered) would make more sense IMO. But again, is it possible, I don't know. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
Maybe bitcointalk.org would like to donate a few BTC from the 6,000 BTC new forum fund to sponsor hosting? On Dec 8, 2013, at 5:51 PM, theymos they...@mm.st wrote: I'm sure that you can find a sponsor for a dedicated server. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On Sun, Dec 8, 2013 at 8:03 PM, Mike Hearn m...@plan99.net wrote: I bring this up because of the recent bitcointalk fiasco. AFAIK the domains are registered and controlled in the same way. It's likely that the current registrar isn't very secure. I registered bitcointalk.org originally, then passed along control. It is likely that the two domains are /not/ registered and controlled in the same way. The handling of bitcointalk.org was quite disappointing. Even after control passed from me to Sirius, he did not bother to change the registrar credentials for months afterward, despite repeated urging. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
I can provide the server hardware and colocation (space, power, and bandwidth) if dedicated 50Mbit in 55 S. Market, San Jose, CA data center is acceptable.If it needs more bandwidth than that, in a few months I hope to be getting space in LA with 1Gbit, but I can't commit to that now.On Sun, Dec 8, 2013, at 03:11 PM, Drak wrote: It's not just about trust, there is the robustness factor: what if he becomes sick, unavailable, hit by a bus? Others need the ability to pickup and run with it. The control over the domain (including ability to renew registration, alter nameservers) needs to be with more than one person. That's why I suggest using the same people who have control over the software project at sf,github The bitcoin.org domain is controlled by me, Sirius, and an anonymous person. Control will not be lost if Sirius becomes unavailable. SSL is probably a good idea, and it's probably also a good idea to separate bitcoin.org from Github. I don't know that I trust Github. I'm sure that you can find a sponsor for a dedicated server. Let us know if DNS changes to bitcoin.org are required. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
Hello, re. the dedicated server for bitcoin.org idea, I have a few thoughts
1) I have commented in a blogpost of August 2013 at
https://odinn.cyberguerrilla.org/ with some thoughts relative to possible
issues with CA related to bitcoin.org - where I mentioned something
relative to the DigiCert certificate,
DigiCert “may revoke a Certificate, without notice, for the reasons
stated in the CPS, including if DigiCert reasonably believes that” (…)
“Applicant is added to a government list of prohibited persons or entities
or is operating from a prohibited destination under the laws of the United
States” (…) “the Private Key associated with a Certificate was disclosed
or Compromised”
In the same post I mentioned
Bitcoin.org has no certificate, no encryption — a situation which has its
own obvious problems. Bitcoin.org currently sends users to download the
bitcoin-qt client from sourceforge. Sourceforge is encrypted and has a
certificate based on GeoTrust:
https://www.geotrust.com/resources/repository/legal/;
(Currently (Dec. 7, 2013) bitcoin.org shows as 'not verified' and 'not
encrypted' examining it in a cursory fashion w/ Chrome)
Not sure how this would work, but it would be nice to see the content at
bitcoin.org encrypted, of course, but also further decentralized? how many
mirrors are there of bitcoin.org - not sure, but a few things that come to
mind when thinking of this are Tahoe-LAFS and also .bit stuff (namecoin).
There are many ways to decentralize something but that is just something
that comes to mind.
This has been discussed at https://bitcointalk.org/index.php?topic=16312.0
('Is Bitcoin.org a weakness of bitcoin?) in the past and see also this
https://bitcointalk.org/index.php?topic=119652.0 which discusses mirroring
of certain content
Some things to think about.
I would like to know what are your thoughts on moving bitcoin.org on a
dedicated server with a SSL certificate?
I am considering the idea more seriously, but I'd like some feedback
before taking steps.
Saïvann
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
