(https = Secure downloads + SHA Checksums)

[Slingshot77]

Important Message to Crypto Wallet DEVELOPERS (https downloads + SHA Checksums)

https://bitcointalk.org/index.php?topic=315963.0

See my posts on these two issues. Of course today Bitcoin-Qt offers SHA-256 checksum verification (Verify release signatures). But NO SECURE download page.

WE need to SECURE our wallets as much as possible, and the source of those wallets as much as reasonably possible too. http just isn't safe. Only https is reasonably safe.

Sincerely,

Slingshot aka (Slingshot77@github

[saivann]

Duplicate of issue #253, please take a look at existing issues before opening a new one.

I have already explained on that issue what would be required, why it isn't possible in the mean time, and also the fact that it doesn't replace developers' signatures by any means, which are the only secure way to ensure that the build really comes from them.

[Slingshot77]

Hi,

1st thanks for responding so timely. That's wonderful.

I don't know the technical details you refer to, and well that doesn't concern me, or anyone that wishes to park a lot into Bitcoin through a downloadable Qt client from your GitHub http link.

What does though is knowing that Bitcoin security concerning it's Qt wallets are securely maintained, and on Secure https sites for downloading purposes, which are far harder to hack.

  Being injected with additional payloads while on a http site during downloads does occur. Being monitored, followed back to your IP and then digitally robbed is yet just one more of many things that can and will go awry. Maybe you want to ignore or even deny these. Or a long list of others for why your simply not doing what must be done in order to be taken seriously.

Your solution is no solution. NOT ACCEPTABLE. It does not a bit of good to get a 'good sig' (verifiable download) if it inadvertently comes with extra surprises, and well quite often and unknown to both sides of the equation that occurs.

That's just a couple of many ways to subvert http. Others including forged developers signatures are also known to have occurred.

  Your asking everyone to trust what isn't yet ready for Prime Time "as is". Hummmm. Gold still appears much safer, even if much more problematic.

WTF:  https on GitHub is quite easy is it not?

GET REAL.

Penny wise? Pound Foolish? OMG.

Very soon that, and any and all other exploitable flaws will spread like wildfire from Bitcoins enemies far and wide if my suspicions and instincts are correct, and they usually are.

Bitcoin is very likely to get in the biggest spotlight ever, along with being forced to take on more heat than thought imaginable, and when it does it best have it's act fully together.

As for being a duplicate issue. Your about to get flooded with problems resulting from you not solving this issue because your making excuses instead of solving just one of the most pressing of basic, fundamental security issues.

This reminds me of how Lockheed (or whomever it was that built it) didn't encrypt the most advanced spy drone that Iran overtook and took away from the world's sole super power. Or how the mess that the software concerning ObamaCare has turned out to be. Is that where this is headed? A virtual train wreck?

Sit back and reflect on this.

Ask yourself: Will many people of means dare to trust what cannot be reasonably trusted with larger and larger amounts of their savings? Answer: not a chance. At least not for most of the sane ones. And certainly not even a major chuck of a sane persons or companies assets flowing into any one Digital Crypto-Currency. Not in a Trillion years if this is how lackadaisical security matters to the likes of Bitcoin.

Result: Failure to launch.

Sincerely,

Chris

---

On Tue, 10/22/13, saivann notifications@github.com wrote:

Subject: Re: [bitcoin.org](https = Secure downloads + SHA Checksums) (#258)
To: "bitcoin/bitcoin.org" bitcoin.org@noreply.github.com
Cc: "Slingshot77" mymailbox7777@yahoo.com
Date: Tuesday, October 22, 2013, 12:17 AM

Duplicate of issue #253, please take a look at existing issues
before opening a new one.

I have already explained on that issue what would be
required, why it isn't possible in the mean time, and
also the fact that it doesn't replace by any means
developers signatures, which are the only
secure way to ensure that the build really comes from
them.

—
Reply to this email directly or view
it on GitHub.

[gmaxwell]

@Slingshot77 Please try for a moderate tone. The allcaps NOT ACCEPTABLE is not really acceptable.

It's not clear to me that you understand whats being provided currently. The software is cryptographically signed by keys which can be kept offline, this is a much more secure security compared to SSL where keys must be kept online (and, almost everywhere in the bitcoin ecosystem, on third party owned VPSes or even anti-ddos serivces like cloudflare).

I understand from your multiple posts on Bitcointalk that much of your concern is related to "altcoins", most of which do not provide any authentication at all... and many of them it wouldn't matter in any case, since they are often provided by fly-by-night anonymous parties who might themselves be giving you the malware. The situation is (hopefully :) ) not the same for Bitcoin.

As I've commented elsewhere, I think doing additional things would be good, but practicalities complicate things and when you respond with "I don't know the technical details you refer to, and well that doesn't concern me" the impression it gives anyone faced with those practicalities that perhaps they ought not care about your complaint. Successful communication requires a two-way give and take.

[Slingshot77]

message received.

https is required imo, everywhere in the Bitcoin.org domain. For all users safety.. i wont be at ease until that is done. I will find alternative stores of value in the mean time and stay much more deversified than what is presently desired..

Thanks for your feedback as well as the too many all caps reminder. (just realize that I just had a PC compromised just after a http download at Mega and I am in no mood for any "can't/wont/or isn't practical suggestions).

But at least I know now your doing what you can, at least the downloads are verifiable for the Qt's, and at least that's a start. If it's money that is the issue, or labor/time, maybe the Bitcoin foundation(s) would be more agreeable since this has already been brought to many others attention and I am rather certain this will remain a topic of serious interest to those that have larger amounts at stake, much less the very reputation of Bitcoin in the face of any serious adverse future events concerning http versus https.

And like I said: I and I gather others (mostly deeper pockets) will vote with our feet, elsewhere, into safer stores of value until priorities are much more attuned to the needs of Bitcoin users and their complete safety & security.

Please understand I am not in the least bit upset with you, just disappointed in the http aspect of these downloads plus the http everywhere else that exists in the bitcoin.org domain. Your reply was thoughtful, sincere and complete, and there is no need to reply again unless you wish to discuss this matter further.

Sincerely & Thanks for your time,

Christopher Bean

---

On Tue, 10/22/13, Gregory Maxwell notifications@github.com wrote:

Subject: Re: [bitcoin.org](https = Secure downloads + SHA Checksums) (#258)
To: "bitcoin/bitcoin.org" bitcoin.org@noreply.github.com
Cc: "Slingshot77" mymailbox7777@yahoo.com
Date: Tuesday, October 22, 2013, 8:30 AM

@Slingshot77 Please
try for a moderate tone. The allcaps NOT ACCEPTABLE is not
really acceptable.

It's not clear to me that you understand whats being
provided currently. The software is cryptographically
signed by keys which can be kept offline, this is a much
more secure security compared to SSL where keys must be kept
online (and, almost everywhere in the bitcoin ecosystem, on
third party owned VPSes or even anti-ddos serivces like
cloudflare).

As I've commented elsewhere, I think doing additional
things would be good, but practicalities complicate things
and when you respond with "I don't know the
technical details you refer to, and well that doesn't
concern me" the impression it gives anyone faced with
those practicalities that perhaps they ought not care about
your complaint. Successful communication requires a two-way
give and take.

—
Reply to this email directly or view
it on GitHub.