Code signing certificates are insanely expensive. The cheapest one I could find from a CA was $73/year (3 year minimum). I could go on a long rant now about how much CAs are in collusion and how they're making everyone more insecure though their pricing, but that would be redundant as I think "everyone knows that" by now.
Let's Encrypt are welcome (when they arrive), but they still don't offer Code Signing, Wildcard Certificates, and so on. The whole certificate/CA industry needs change, Let's Encrypt doesn't go nearly far enough. I blame Microsoft, Mozilla, and Apple primarily as they decide who gets to be a CA, and could allow non-profits and other disruptive startups into the space if they wished.
You mean Autenticode on Windows? I once had an Authenticode code signing cert that I used to sign Windows executables. Mostly, I signed hobby projects with it.
I wrote a proof of concept keystroke logger for Windows, then Authenticode signed it and made it available along with source code for others to experiment with and review.
Several years later, some customers of Zemena and Comodo complained that the keystroke detection/security software (that they had paid money for) did not detect my keystroke logging software.
This caused a big fuss. Even though my software had been available for years, was code signed, came with full source code and was clearly labeled for educational purposes only, the security companies sent takedown notices to my ISP, placed my domain on DNS blacklists and 'fixed' the issue by declaring any exe signed by my Authenticode cert as malicious. Their customers were then happy and felt safer as it was now 'detected'.
The real issue was that the security software trusted any code that was Authenticode signed and let it run no matter what. There was a check-box somewhere to disable that, but long story short, I would not say that Authenitcode code signing is a big security benefit today. It may help some, but not much. Maybe in the future.
I still have the Keystroke logger source code: https://github.com/w8rbt/keycap
Someone with an Authenticode cert should compile it and then sign it and see if it still gets by the security vendors.
Putty should be signed, imo.
LE are a wonderful start, and they are succeeding in part because they're moving slowly. I expect them to go further, but only with full understanding of the obligations they take on by doing so. They're very, very right to be conservative in their operational practice, because they'll be allowed no more slack than anybody else, and maybe less.
Could something like LE have started ten years ago? Maybe, but nobody did. CAcert.org was a lovely dream, but didn't (and couldn't) hold to those standards of diligent practice.
This is something that Google should do.
Lastly let's say he gets the money and takes care of the taxes and all of that. Now he has to get a code signing cert (not a fast or easy process I would assume) and add that to the list of things he needs to do for each release. We are talking about a non-trivial amount of work over a month or more all so that people will stop bitching about the FREE and OPEN SOURCE product he is producing...
If you find code signing/HTTPS to be so important I suggest you do it yourself, the code is freely available and since it's under an MIT licence you can even SELL access to your code-signed and https-protected putty version. I'm not saying that either of these things are not important (they both are) but let's not jump down the dev's throat because they aren't giving up even more of their time on something they seen no return on.
Putty seeks to perform a security-critical function. It may simply not be realistic to expect that someone can simply step into the market and provide such a tool safely, without putting some effort into building trust with users through, e.g., a code signing certificate. That, after all, is one of the reasons why trust works--it is non-trivial to build.
Again, I don't blame a developer for not doing these things, and I am all for helping developers jump through the hoops they need to jump through, if they are willing.
I say all of that less towards you and more generally in the context of this thread as you did point out "I am all for helping developers jump through the hoops they need to jump through, if they are willing".
But what can we do? I don't think it's realistic to expect anyone to issue code-signing certs for free. Any credible process for issuing the certs, it seems to me, would be too resource intensive for anyone but a charity to do for free.
For projects like Putty it probably won't be a problem to raise money for the cert, if the dev wants to go that route. But I don't know what's to be done about the dev who, understandably, just isn't interested in dealing with all that entails, or projects with smaller followings than Putty.
Do we need to start some sort of organization to help hobbyist and independent devs with this problem? Even if there were a group of people willing to take this on, (I might be), would it be a good idea? Taking on the responsibility of verifying a dev's identity and helping him or her with things like code signing certificates seems like a liability nightmare, for one thing.
The FAQ gives an address for Paypal donations / beer money: http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#f...
Literally cheaper than sponsoring an African child or paying Sarah McLachlan to stop using commercials to make me cry.
I would cover the costs out of my profits, but the $0.00/yr I am pulling in from my open source projects doesn't quite cover it, let alone the $200/yr for the VPS and domain registration.
"When" being the keyword. Also they don't, as of this post, do code signing...
PuTTY is MIT licensed.
The primary author of PuTTY is unserious about traceable code, which is a shame, because as your essay implies, PuTTY is one of the motivating cases for traceable code. It's an actual lucrative real-world target for surreptitious replacement.
Clearly, the world cannot rely on PuTTY's author to provide a traceable download. Someone else needs to step in and do that.
That person can set up an HTTPS site, arrange to have their certificates pinned, get PGP-signed endorsements from people like you, the EFF, whatever, and --- given how awful PuTTY's SEO mojo is, easily take the top of the Google SERP for PuTTY with a reliable, traceable alternative.
What any of this has to do with WebCrypto is beyond me.
From yesterday: "Trojanized PuTTY"
I think it is a valid criticism, and I wish the person who wrote PuTTy (an SSH client for windows) would be more open/available/transparent but it is hard to force that on someone.
A small correction -- from the symantec blog post:
"this file has been in the wild since late 2013 and it was first seen in Virus Total around the same time. However, we have only seen this sample broadly distributed recently. Distribution in 2013 was minimal, and we saw a gap of a year and a half before it reappeared again."
If you see something potentially vulnerable, you don't have to wait until it's been exploited to report it.
If there was a formal package management system in place for these OSs this would have been less of a problem from the beginning, but they're only getting around to it now as I understand it.
Everyone who distributes exe files should include some form of authentication otherwise you are just sloppy. In all likelihood he doesn't check authenticity of software on his end so you can imagine other risks as well.
You're wrong, there is a code signature verification built-in in Windows, if the EXE is signed, from the GUI you just have to right click on the file, select "Digital Signatures" and click twice on the signature.
Putty however isn't signed. Maybe it would be good to motivate Simon Tatham to start doing this. He should be somehow supported for that.
The signature doesn't solve too much (e.g. imagine Putty is signed by Acme Inc -- how do we know that Simon actually worked for Acme Inc at the moment he signed, that is, how do we know we should expect Putty to be signed by Acme Inc, and what if it's signed by Acme LLC, is that the same company etc -- we still need some channels to spread the right information, and when we have them, spreading the right checksums of the binaries would also be enough) but it is probably better than nothing.
It has HTTPS and FTPS support natively. It also supports generating hashes in SHA1, SHA256, SHA384, SHA512, MACTripleDES, MD5, and RIPEMD160 using the aptly named Get-FileHash cmdlet.
> no authenticated package management
MSI installers can (and should) be signed, and well as many other Windows installers and other binaries. Windows 10 supports "real" package management, but security is unimpacted directly.
> Being concerned about privacy and security and running Windows may be mutually incompatible.
You've given zero plausible reasons for believing so. All you've demonstrated here is that you know little about Windows and what the term "verified trust chain" means.
Just Windows supporting HTTPS alone more or less ruins your point.
Windows has an SSH-like framework for PowerShell. One could argue that Linux doesn't ship with tools for connecting to non-Linux hosts, so why should Windows ship with tools for connecting to Linux hosts?
It will have package management in Windows 10 .
Powershell can get the hash of a file in many different algorithms.
But isn't Windows more like "a distribution of Linux" than "the bare Linux kernel"? When I choose to trust a distribution of Linux (or a BSD or any other complete operating system) I extend that trust to the ecosystem's package manager which usually includes mechanisms for verification. Downloading putty is not a case of trying to connect to a Linux host, though, and SSH is not a linux-only (or even linux originated) protocol.
I was just looking at OneGet and it seems like a huge boon to the Windows ecosystem. From my limited research Windows 10 looks pretty nice and is the first version since XP that I may be interested in using.
Except it does, to the extent that vendors make it possible: any repository will have at least one RDP client of sort (probably half-baked, because the protocol is what it is), and Samba is standard fare. Almost any other OS supports SSH, so yeah, Linux in fact does ship with tools to connect to non-Linux hosts, and plenty of them. (Btw, connecting Windows to NFS shares out of the box is much harder than connecting Linux oob to SMB shares...)
If there is one thing that would help Microsoft immensely, in their attempts at gaining some traction "in the cloud", is out-of-the-box SSH support. Powershell might be nice but it will never work on anything that is not Windows, so it's fundamentally useless for remote work.
And I'm fairly certain that Windows comes with even more robust tools out of the box for network trust management than Linux does - at least when it comes to managing networks of Windows machines. I could be wrong. I don't know many people who run office networks full of Linux boxes for comparison and maybe there is really no "out of the box" with Linux...but Windows does have controls baked in for trust and security.
Another important question is: even if there is a valid signature, how can the user know if the signer of the downloaded file is really the expected author?
And of course, none of this matters when you're running this software on a closed-source operating system - one which you, therefore, have virtually-zero ability to independently audit. So even if your programs are perfectly trustworthy, the underlying operating system has free reign to compromise them without you being able to detect it or do anything about it.
Probably the most surefire way of being actually secure is to drive to Calgary and pay Theo de Raadt to burn you an OpenBSD CD-ROM right before your eyes, then install it on your computer (and even this is fraught with danger; who's to say that Theo isn't going to backdoor your installation?). Virtually every other method of installing anything is insecure, whether you download the thing or have the thing mailed to you or what have you (the sole exception being to download the source code, manually audit it yourself, and manually hand-compile it to machine code - can't trust that compiler to not be compromised, after all). And on that note, you therefore still can't trust Theo's custom-made OpenBSD CD-ROM, since he very well might have compiled it with a compromised compiler, so now you have to take the OpenBSD source code and hand-compile that to machine code before you can do anything else.
That said, I haven't used Windows for awhile so maybe those reasons don't exist any more (perhaps it isn't a problem to install a Windows 8/10 app on someone else's machine or within a restricted corporate environment) or maybe there are some good browser-based alternatives.
Putty's keys are on the MIT server if you search for "putty": http://pgp.mit.edu/pks/lookup?search=putty&op=index
Still, agreed, it's a lot of work -- most people won't have gpg/pgp installed. Someone should sponsor Simon's codesigning cert for now.
Its built-in SSH server is great for moving files to and from my workstation quickly when I need it.
Best One Liner about commercial Open Source software : The only kind of profit strategy that is incompatible with Open Source is monopoly-based sales, also known as "royalties".  http://opensource.org/faq#profit
That being said, when I'm looking for git and friends I like to go further and install more of cygwin to run the native port of rxvt and then run ssh inside of THAT.
So it's not really a solution for a shell in the way that PuTTY is, since PuTTY also is a decent terminal emulator for Windows. Not the greatest, but decent. It's the single-binary, run from a thumbdrive option.
Let me buy you a beer. I just run linux.
Dealing with mixed OS environments... it keeps you busy.
Most of the people I know that use putty really use MTPutty  nowadays for multiple tabbed terminal windows. I haven't touched windows in years but if I were to go back I would use cygwin or similar before I used putty.
Can you seriously compare PuTTY with even the most lacklustre terminal available on OS X or Linux? It's an atrocity of UX design straight out of the Windows 95 era.
Their home page is also the epitome of not caring about user experience even to the slightest degree. Nearly zero effort: http://www.chiark.greenend.org.uk/~sgtatham/putty/
I've seen people construct more impressive pages given only a few hours of HTML and CSS training. I'm not even kidding.
I'm not saying everything has to be slick and beautiful, but there's a thing called pride in craftsmanship, and PuTTY has none of that. It's just sad.
> How about the fact that it's awful?
Is this really what passes today for a decent reply? It's an atrocity of attempted logic straight of the Windows 95 era.
The logic used is also the epitome of not caring about putting up a decent argument even to the slightest degree. Nearly zero effort.
I've seen people construct more impressive arguments given only a kindergarten education. I'm not even kidding.
I'm not saying everything has to be lengthy and grammatically correct, but there's such a thing called pride in logic, and astrodust has none of that. It's just sad.
There's not a single thing wrong with PuTTY's UX either. The terminal area is just a terminal area that does what it's supposed to and behaves exactly like any other terminal emulator, and the options are clearly organized. There is literally no meaningful change you could make to improve its UX because it's already optimal.
I don't see the rush of elephants to fork it, or write a replacement either, just a bunch of passive complaining.
If you prefer it, that's fine, but some people expect a bit more from their tools than merely being "functional" no matter how ugly.
Well designed can refer to more than just the interface. It meets historical windows human interface guidelines too.
I'd also suggest that its an open source project, and could be forked, with a new UI wrapped around the existing pretty good terminal emulation.
I think portable here is referring to being able to run software from a USB drive without running an installer or just being able to download a file into a temporary folder and removing trace of it by deleting the folder when done. I feel a lot of the initial love for putty was the fact that it was portable (and it also helped back in the day that the download was so small, too.)
It is possible as far as I know that it doesn't meet the formal definition in some way, but since you used the term in air quotes and didn't qualify it (like 'but it stores settings in the registry' or similar), I think you may be interpreting the term differently (i.e. I don't think the term is being used to suggest that you can use the same executable across operating systems.)
Yes, there is. It garbles some characters. Ncurses-based applications sometimes look like a hot mess.
I wonder how much of the hate here is from people who don't understand the problems that are inherent to writing a terminal emulator. It makes sense to be frustrated by it, but it's not putty's fault.
I've been using putty for about fifteen years, and use ncurses extensively. The only thing I've wanted to do in PuTTY that I've been unable to (that I can remember) is to get 24-bit colour working. It may be that I'm making the situation artificially simple for myself because I run everything in tmux, which may filter some translation issues.
Your point in another thread about the putty defaults being non-standard is a good point, and the only meaningful criticism I can see if it here. Not defaulting to UTF8 may be another.
Also, the default encoding was changed to UTF-8 only quite recently - IMO that should have been done much earlier.
That's because it's middle-click instead of right-click in X. But windows traditionally did not have 3-button mouses, so right-click it is. I use middle-click to paste several times per hour.
That page is awful. Period. What do I want from a website that exists to distribute one program? Some effort. Some class. Something more than the software equivalent of being wrapped in greasy newspaper.
When you say "its UX because it's already optimal" you're basically saying "I do not value fit and finish, I am purely interested in functionality, I also make my own underwear out of used socks."
Why am I so upset? It's because of this attitude. Taking the time to make a nice page and present your software with pride shows you care. Using the same old HTML from 1997 says you don't care.
Would it kill programmers to talk to designers and do some knowledge sharing?
I agree it's not obvious how to use that portion of the UI, and the UI is far from ideal, but once you understand how it switches profiles, then you're pretty much set. That issue doesn't occur again anywhere else in the application so it's a rather minor issue if you ask me.
Yes, I can compare. PuTTY is superior than the default xubuntu terminal, whatever it is.
1. I can configure it to connect to specific server automatically, including setting up all required SSH tunnels. On Linux I have to write shell scripts.
2. It allows to automatically set up a SOCKS proxy that sends my traffic through the remote server.
3. Selecting text copies it straight to clipboard. Copying to middle-click buffer is much less convenient, because I often want to replace other selected text with what I selected in terminal.
I wish more websites were functional and clean like that.
A more focused, no-networking kind of PuTTY. Reads your settings from your "home directory" on windows, very handy.
People don't like writing terminal emulators. I don't blame them!!!
Also, you'd always need dedicated key files because PuTTY uses PPK instead of regular OpenSSH ones.
1024-bit RSA, and 1024-bit DSA.
Please see my comment earlier today about why that's Very Bad™ in the thread on the "Logjam" attack which shows that 1024-bit keys are too small for safe use now: https://news.ycombinator.com/item?id=9577998
Come on, Simon, I know you know better than that. It really is time to upgrade.
Don't most people install stuff in Windows through Ninite when possible these days? I know it has at least one SSH client. And in my experience, the vast majority of good software is at the top of any search query.
No, most people do not.
I don't know if those are any good, but they are safe to install and run. In Windows 10 they will even run in a Window with your other desktop apps :-)
I do use chocolatey as much as possible for all windows installations.
and you're done.
"How do I know if I can trust the community feed (the packages on this site?) Until we have package moderation in place, the answer is that you can't trust the packages here. ..."
Their about page:
"Package moderation and package signing are planned to increase the security of the community feed. Bear with us, this is going to take time to get into place. ..."
However moderation seems to be implemented (at least putty is approved by a moderator), I see no signing in place. At least everything seems to be going trough https and they are going in a good direction.
>We have uploaded our various keys to public keyservers, so that even if you don't know any of the people who have signed our keys, you can still be reasonably confident that an attacker would find it hard to substitute fake keys on all the public keyservers at once.
Anyone want to be less lazy than me and find out which ones the keys are in?
Also, the first thing I'd do is download a Ubuntu ISO over https, install Ubuntu, after which I'd have an authenticated way of installing software (apt-get). putty is available through that, so I'm fine.
Most Linux users are not experts in any of the multiple languages that their applications might have been written in, and so are neither capable, nor likely willing, to pore over millions of lines of polyglot code just to verify that the latest version of Iceweasel doesn't have an NSA backdoor (or what have you.) Therefore, the blind trust most Linux users place in whomever wrote their distro and their applications is no different than the blind trust Windows and OSX users place in the companies that make their operating systems and any binaries they download from third parties.
Granted, in the open source case, anyone can look at the code, and the axiom that "with enough eyes, all bugs are shallow" does sometimes work. But it doesn't necessarily follow that no one at Microsoft or Apple is paying as much attention to their code as the masses are to open source code. It's just an assumption on the part of the open source community, that open source necessarily leads to greater code coverage because the code is available to everyone, versus a subset of employees at a company, and that it's harder to hide things in plain sight when the source code is available. This assumption of course turns out sometimes to be spectacularly untrue, as it was in the case of Heartbleed.
Not (normally) on the source site - but there's no guarantee that someone doesn't MITM you and inject something.
Someone could host the download on an https site, and yes, it'd be an improvement, but that just moves who to trust to the site owner (and everyone on the certificate/hosting chain for the site).
Downloading it from a place that serves it from a secured endpoint isn't really useful if the source didn't download it securely.
You have to be a pretty good programmer to identify obfuscated code in something like Putty I'd imagine - particularly as all the parts needed for snooping are intended to be there: certainly I (a non-programmer) couldn't guarantee to spot a reverse SSH connection being used for key-logging. Configure-make-install I can do but proper security level code review is not something I'd expect most programmers could do (otherwise we wouldn't have things like Heartbleed, surely?).
Web-of-trust in some form seems like the answer; but ultimately you need someone trustworthy to be paid (or equivalent) to do a proper review and oversee the securing/signing of that code as reviewed.
Web-of-trust, what ever that might mean, isn't helpful because you ultimately have to trust someone. How do you know the person you are trusting isn't an NSA agent?
You don't but the top node in your web has to be trusted by lots of other people, some ideally are able to confirm the code is kosher - you need a massive conspiracy to happen or to have put your trust in people who couldn't care less about putting their name to malicious software.
It's like if dang tells you something is an official HN policy you might trust it, but if that statement by dang is signed by other HN officials then you're going to be pretty certain that's true.
Kinda like a technical "social proof". If I know that Stallman, Torvalds, Wozniak are using a piece of software then I'm going to be pretty confident that it's been checked out as much as any piece of software. Yes they could _all_ be endorsing it because the NSA told them too.
PuTTY's Windows source code is ~190 files, or ~123145 lines.
If you assume you can read a line a second (and you can't), that's more than 34 hours (!).
What's so special about putty?
you can also try to build it from source https://github.com/FauxFaux/PuTTYTray
They have some neat features and the website is under https.
There are also some pretty good commercial alternatives although they get drowned out by all the free stuff on Google.
Antiviruses detected that their .exe was infected, and they solved it by removing the detection on the antiviruses
> 2015-04-19 PuTTY detected as malware
> We've had several reports recently of anti-virus software reporting PuTTY as malware (under a wide variety of names, often generic). This affects the latest release (0.64) and also the development snapshots (particularly puttygen).
> We believe these are false positives. In those cases where we've been able to contact the vendor (McAfee, Symantec, ClamAV), they have removed the detection.
We've had false-positive AV detections a few times in the last couple years affect an open-source project I'm involved in, it is a massive support burden.
What would you suggest a developer do other than contact the AV vendor to get it sorted out, since they caused the false detection?
What lead you to a different interpretation?
WHEN the sources have been audited, and cleared for any security or other bugs, you may consider compiling them.
That's where the real crux of the problem lies:
You cannot trust software more than you trust your compiler or your interpreter or in general, your processor.
Since big commercial OS providers are KNOWN to be collaborating with the NSA to but backdoors and spy on you in the first place, you cannot have any trust there anyways. Why worry about random binary software on the web, when your base OS is already compromized?
Otherwise, you may choose to use hardware that you trust, preferably, that you have built yourself. Alternatively, you may build a computer using triplicate parts from different sources (eg. put an Intel, an Elbrus-4C and a Godsoon, and compare bus traffic. As soon as a difference is detected, raise an exception and abort the process), similarly, put three different network controllers, made in three different countries, and compare output packets. As soon as there's a difference, drop the packets and signal the process. etc.
Once you've got a trustable hardware base, you can build a trustable software layer, using only sources and bootstrapping binaries by hand (with people you trust, preferably yourself), and as indicated in Countering Trusting Trust through Diverse Double-Compiling, http://www.acsa-admin.org/2005/abstracts/47.html
you may implement also at the software level, a similar kind of redundancy that allows you to increase the trust you may have in your bootstrapping chain.
But there is no way out, you have to start from the sources, read them and consider only source code when exchanging software.
Notice that debian is a binary distribution. Gentoo is a source distribution. Gentoo is more trustworthy (but you need to be careful how you bootstrap its installation, which is not easy).
This is why licenses such as the AGPL, and also works to make software higher level and shorter (understandable and therefore trustable by end users) such as Alan Kay's, are important.