I got flamed a month ago [1] for noting how difficult it is to get up and running on GitHub in the Windows world, where things like generating SSH keys aren't exactly part of the daily routine. Glad to hear that they were listening.
As a Windows user I initially found the setup a little daunting, but the GitHub install guide was a great help and guided me through everything fairly painlessly. If I'm honest about it though, without that help guide, I would have been pretty lost.
The ssh setup is a barrier to entry for a great deal of Windows users, simply because they don't have to deal with such things on a daily basis. Whether they all should know these things is debatable.
I personally couldn't give shit how 'it' works, as long as I don't have to waste my precious time having to learn something I don't need to. I don't want to have to learn machine code for the same reason. We abstract to become more productive. We build on the shoulders of giants. We don't re-invent the wheel. I could go on...
The bottom line is that the previous installation for Windows was manageable, but still it was a drag. Luckily there were enough good resources on the web to help you through it. However, it was time consuming and that barrier has now been removed.
In my opinion that's great. It follows Dieter Rams' principles of good design, namely:
Good design is as little design as possible.
Less, but better – because it concentrates on the essential aspects,
and the products are not burdened with non-essentials.
Let's remember that Git is a distributed source control mechanism. It needs to move versioned code around. That is its pure purpose. When the security setup takes more effort than the source control you're doing it wrong.
That being said, the common language of the Git world will remain the command line. The vast majority of examples you will find on the web when you are learning how to use Git will be executed via the command line. That fact in itself means that you should still learn the basic commands and get familiar with git bash.
EDIT: I hope this gives a fairly balanced opinion from a typical Windows Git user. I appreciate that this topic is a heated one.
I think it would really help you to have a play with command line Git, just to get a feel for what's going on. SSH keys aren't hard to learn and are useful enough to be worth the time spent.
It's not about being unfamiliar with the CLI, it's that Windows isn't like OSX/Linux in that you can just store your keys in a .ssh folder and be done with it (at least not if you don't use cygwin/msys)
The method I chose in Windows was to use pageant (part of Putty) to load the keys. Not sure if I missed this option but you can't autoload keys so when you restart pageant you have to readd the keys (which is not terrible bad, just annoying).
Haven't tried Github For Windows yet but if it fixes the hassle of using ssh keys then I'll probably use it as my main git client for Windows.
It's not simply a matter of checking an option unfortunately, but you can still get Pageant to load keys at startup by creating a shortcut to it in Programs -> Startup:
You can autoload keys with pageant. You have to change the shortcut in your Programs\Startup folder that loads pageant itself. From memory I think it's as simple as adding the paths (in quotes) space separated after the executable. It's certainly in the help documentation at any rate.
> Windows isn't like OSX/Linux in that you can just store your keys in a .ssh folder and be done with it (at least not if you don't use cygwin/msys)
Then, by all means, use Cygwin or anything that helps you, even if it doesn't come with Windows, if it isn't provided by Microsoft, doesn't look familiar and if it doesn't play well with Visual Studio. If you code for Windows you are coding against an insanely complicated set of APIs.
It's not a question of familiarity, it's that git doesn't play nice on Windows. It requires a POSIX emulation environment, like cygwin, which is a second class experience.
Compare this with Mercurial, which runs great from the command line on multiple platforms. I actually prefer the command line for SCM work, but git makes it hard.
Putting all of your SSH keys in a .SSH folder (inside your user directory) and setting up OpenSSH to look through those when you try to connect to something is exactly what installing Git on Windows does.
This seems pretty friendly to me. Is there something I'm missing?
Just ignore the internet warriors below. :). Smile, nod and continue being productive. The GUI saves you time and reduces the learning curve for new developers. If you feel like using the command prompt, you still can.
For my team, which consists of designers and developers, this will make the learning curve of my designers a lot easier.
Saying that because you don't know how to use SSH keys on a windows machine means you can't write secure code is just silly. It is a slippery slope to say that. If the majority of senior guys actually believed it then we wouldn't have a use for higher level languages (ruby, php, etc), frameworks like .net, etc.
I really don't want to get involved in this flamewar but I have one question: You can use github with https and you never have to setup ssh and manage keys. So what's the problem? SSH is not the only choice.
"Scary crypto stuff"? So you don't understand how PKI works and you're trying to use distributed source control? (I say this not to be a jerk, but because there aren't exactly a wealth of good alternatives given it is a distributed source control mechanism. PKI comes with the territory and an SSH key generation is part of that)
GitHub doesn't take any more setup than a standard Git setup takes (well, outside of signing up, a very short process anyhow). Install the Git client via the Windows installer, (point and click, a minute, tops). Generate an SSH key. Upload the id_rsa.pub. Done. I mean, it would be one thing if they left users in the dark about this, but I'm fairly sure that the "Thanks for signing up page" links directly to the OS-specific meticulous step-by-step instructions of generating the key.
I'm not sure you understand what it means to be flamed. Every one of the comments is specific about your misconceptions and why signing up for a GitHub account is as trivially easy as signing up for a Twitter account. (Using GitHub as an oAuth account does not require actually uploading a public key)
None of us want to understand every single domain of knowledge from set theory or quantum physics up to cosmology or social psychology.
I personally have been forced to learn more low-level Unixy things than I ever wanted to. I want to write simple and elegant front and back end code quickly so I can spend my spare time honing UX and other human-facing aspects of my work.
I resent being flamed because I don't fully understand the subtleties of zsh or nginx or or whatever other shiny toy someone else happens to find essential knowledge. Your world might not necessarily be mine.
Actually. I agree with you (apart from the fact that I haven't had a chance to learn much about social psychology). I was just trying to think of examples of disciplines at opposite ends of an imagined continuum.
You might be right about any number of such subtleties, but you are not right about this. There is no way that spending half an hour to learn how public-key authentication works is a bad investment for any person working on an application that communicates with something over a network.
You can't follow 3 step-by-step instructions, insult me by implying I'm flaming and then drudge up completely unrelated tools in a discussion about ssh-keygen?
What do you people want? Seriously? Yes, I'd love to have a big red easy button. It could autoconfigure MySQL, and write init scripts, configure deploy environments because apache conf files are too complicated to learn. Hell, it could even write my backend code and then commit it for me too!
I'm done with this ludicrous conversation. I've never seen such an ignorant-excusing entitled discussion in a "technical" community before. Downvote me because you can't follow steps or can't be bothered to learn how to use one of your most important development tools, I've lost interest.
From looking at the desktops of an ordinary office, it may be difficult to realize that, when you are talking about internet connected servers, it's a very *nix world.
One of the reasons why I recommend using Linux on the desktop if you develop software for anything non-Windows: it's handy to have more exposure to the environment your code will run on. If you run Eclipse to develop Java code that'll run under Tomcat on Linux, you have a lot to gain by moving to Linux yourself.
If, for some reason, I end up writing Windows-specific code once again, I'll probably develop it on a Windows box. Visual Studio is a great IDE if you want to write programs for Windows.
Nobody in this thread implied that you are flaming, nor intended to insult you; the person you are responding to is not the person you originally responded to, and he is commenting about people in other threads flaming him. I resent having to explain this to you.
What the hell are you so angry about, seriously? People have less expertise than you, and that makes you upset?
He's probably angry because he's had a person with 15 years experience unstage 10 commits already pushed to origin (reset HEAD~10) then readd them to the index and complain to everyone that git tells him every file in his repo is conflicting after a merge. After a serious bout of ROFL he has to help the coworker use merge correctly weekly. After a while of this the person decides to manually fix the conflicts each time he has to push to origin there adding a comment in the git log that says :merged master back into branch.
So to all of you that actually know the difference between merge and rebase and what the difference between origin and local branches are :hattip:
>I resent being flamed because I don't fully understand the subtleties of zsh or nginx or or whatever other shiny toy someone else happens to find essential knowledge. Your world might not necessarily be mine.
That was in the post I replied to. It's insulting because it's accusing me of things that I didn't do. I merely am just a bit floored by the notion that following these instructions, http://help.github.com/win-set-up-git/, is asking too much of someone who is going to be using Git regularly.
I guess I expect too much and seem to be wasting my energy. I apologize.
For many people there Github = git, so saying github isn't much harder to set up than Git isn't saying much.
Using git on Windows has historically not been super fun. The CLI installer mostly works, but it's pretty clunky. Cygwin works fine too, but it's also not especially elegant. At the very least, known of these solutions conform to the expectations of people of the platform. The GUI clients on Windows last I looked (a year ago) were pretty terrible, especially compared to TortoiseSVN, which isn't bad. OS X, on the other hand, had several very nice GUI clients even before the official Github client came out.
Maybe it's gotten better, but last I tried it, TortoiseGit simply did not work well. It was buggy and awkward. It crashed. And I agree with what I think you're saying in that it obscures a lot of what makes Git different. (That said, I still think it would be very useful if it worked well.)
I don't know what difference the "Github = git" distinction makes, from an oAuth perspective it still seems implicitly obvious to me that completing the signup and adding SSH keys are distinct tasks.
As for "CLI installer" (I presume you mean the installer for the CLI git client), and Cygwin, I'm not sure what to say. I've used the Git installer dozens of times without problem, there aren't exactly tons of places for it to go wrong. Are there specific or particular issues you have with it?
I do indeed forget that some programmers manage to make it far resisting learning to use the command line. Even with step-by-step instructions. I guess at some people I'm willing to fault the developer rather than tools that are powerful that come with good documentation.
I think you're right and I guess that's what I'm beginning to realize. I just kind of assumed that in that case... Git is the wrong tool for their job. If you don't need the "power of Git" (I swear, I'm not in love with Git), then use Dropbox or SVN or something simpler. Seems easier than fighting with keys, and then fighting with git's distributed nature and then fighting with all of the complexities of merging and conflicts.
Haha, maybe another of way of putting things from my perspective, I found keys to be the least of my concerns once I got into projects that really used Git and I have a hard time seeing people be successful with Git if the keygen steps throws them off.
I hope that explains things from a different perspective :)
I'm sure you'd love to still be programming in assembly, but some of us prefer to spend our time actually, you know, not mucking around with stuff that is an utter waste of our time.
It takes less than 4 minutes to do. And way to ignore every, other, thing I mention in there, like how something else is probably better suited for your needs if you think it is an "utter waste of time".
The level of discourse and use the downvote just amazes me anymore. Seriously, how can you be that much of a douche after I made very basic, undisputed points?
What I don't get is why some people are so against making things simpler to get started with.
So what if it takes 4 minutes? Why not save all the people who might use your tool 4 minutes of clicking 'OK' through a half dozen boxes you assure them they should just ignore? Particularly if github (as seems clear) want to get more people to pay them money.
Well, in the original quote that was cited from "scary crypto stuff" was surrounded with:
Last I checked they[GitHub] made you perform a bunch of scary crypto stuff on your local machine before they'd let you in.
If performing `ssh-keygen` and entering in an (optional) password from a command line constitutes "scary crypto", then maybe Git and GitHub isn't for everyone. Not that anyone needs to know how PKI works, but they might be better off knowing that `ssh-keygen` generates an ssh key pair, a pretty essential component of the `git` workflow.
Maybe that's why SVN is so strong in older development shops. Outside of the effort required to convert an SVN repo to a Git repo, all those developers already have all the tools necessary on their machines (Windows is high on that list) and in many cases inside a VPN like my division we just use WebDAV anyways, completely bypassing the need for SSH Keys in favor of ActiveDirectory.
My apologies, I abuse "PKI" to mean "PK infrastructure" (which I know is what the acronym stands for, I'm making a bit of tongue-in-cheek commentary), I think it's silly that PKI implicitly means CAs but according to Wikipedia at least, you're correct.
No, he isn't, and the relevant Wikipedia article is very poorly written. PKI is a highly generic term. Webs of trust are just as much a PKI as a certificate-based system.
Everything you've said in this thread has been bang-on, and the replies you're getting are deeply depressing.
Can we at least agree that if we attempted a list of all the Xs a programmer needs to know before doing Y and made it law that nobody could write any software at all?
You got flamed for that comment because you called generating SSH keys "scary crypto stuff." If that scares you, you probably also enjoy the simplicity of storing passwords in plaintext...
What is your problem with someone being scared of crypto stuff?
I find this shows the necessary respect when dealing with security related tasks, since they are HARD.
I'm not talking about developing crypto related software, but just setting up a "safe" environment where you can store your SSH Keys in a way that doesn't defeat the purpose of using them in the first place is non-trivial, even for people with degrees.
IT Security is a complex field of its own and if a user is afraid of making the wrong choice it only shows that he understands the basics of it.
It's one thing to be scared of the deep inner-workings of OpenSSH (which truly can be scary). It's another thing to be "scared" of ssh-keygen, especially considering it's something that most competent developers will use when managing servers, deploying to Heroku, managing source, etc.
"ssh-keygen -t rsa", set a passcode on it, upload the id_rsa.pub and you're done.
Demonstrating a lack of understanding of that was worrisome for myself and other users that commented on his post a few weeks ago.
The important thing you missed then and are still missing now is that none of that stuff you mention happens in the Windows world.
We set up VPNs to our servers and access them via network paths or directly using Remote Desktop. One can go one's entire career without ever typing ssh-keygen into a terminal window. It's certainly not a step involved in setting up a client to talk to version control.
You don't have to believe me on this. You can read the article we're talking about here and see this same sentiment expressed by the GitHub team themselves.
Thanks to that team, folks in our side of the dev world now have an easy path into Git and GitHub, and can go about our merry way building things without ever having to parse what it was that you did in your second paragraph.
"Thanks to that team, folks in our side of the dev world now have an easy path into Git and GitHub, and can go about our merry way building things without ever having to parse what it was that you did in your second paragraph."
... except when github messes up, forces you to do a SSH key audit and then you're back to needing to know "scary crypto stuff".
Problem is, not everyone who wants to program is willing to go through these steps. Even being a security engineer myself, I balked at some of the steps. I know why they're required, and I understand the steps behind them, but man all I want to do is put this little script somewhere where I don't have to worry about it getting lost.
I don't want to have to do it all command-line, I don't want to have to copy and paste from their blog, I don't want to have to do it by hand. I'm not a competent developer (and I reject your assertion that you need to be a competent developer to use version control), I'm not setting up a server, I'm not deploying to Heroku. I want this script backed up and I want it version controlled. No reason why it should be hard.
No reason why it should be hard, because the whole goal of technology is to make life easier. I'm scared by the thought of a lot of stuff inside my computer and OS, but luckily there wasn't someone with your mindset and now anyone can easily get a computer from bare metal to running Angry Birds in Chrome. I'm not a developer although I write scripts sometimes, and the barrier to entry should not be set higher than absolutely necessary. If that means GUI, then so be it.
Nobody said anything about it being scary to type "ssh-keygen -t rsa" but rather about the responsibility that comes with it.
I'd bet my right hand the more than 25% of "competent developers" that are "managing servers" will have made security mistakes while storing their ssh keys on a level with storing the password in plaintext on a .txt file on the desktop.
Thats whats scary about "crypto stuff", not that it isn't easy to use the tools, its hard to be really sure how to put them to good use when you are no expert on IT security.
Outside of checking id_rsa into your Git repo or emailing it, (which would be equivalent to doing so with passwords.txt), SSH (and thus Git) protect you from leaving id_rsa with open permissions. Though it may not be obvious that id_rsa is something to protect. (though again, I don't go emailing random files I don't understand either).
That having been said, I'm certainly not a security expert. Are there other common things to look out for to ensure my private key(s) are safe?
Do I understand right that id_rsa is an equivalent of password.txt in that you have big broblems if someone gets it? In this case I really worry about its being stored in the open in some /users/AppData and not on some TrueCrypt drive that is not mounted by default.
This is why you protect it with a passphrase, which SSH asks you to do by default. Choose a good passphrase, it's encrypted on disk, and decrypted only as needed.
Seriously guys, you're not even trying. Here are the instructions everyone is freaking out about, they contain an explanation of this very issue.
> managing servers, deploying to Heroku, managing source
I'd hate to say it but if you're introducing someone in Windows land to source control then NONE of the items on that list are part of their skill set.
I'm surprised that the responses to this amount to, "I don't understand it, don't want to follow instructions and want a two-click GUI". Git isn't magic. To leverage it well, you need to be willing to get down and dirty with the CLI sooner or later. If you're unwilling to learn Git, don't use it.
If you're a dev, source control is one of your tools. Learn it or find a tool that holds your hand more. I don't know how it gets more hand-holdy than step by step instructions that take 4 minutes to carry out.
Is anyone going to actually reply, or should I continue taking downvotes as "I disagree or I deserve more hand-holding"?
You're being down-voted into oblivion. You get even more insulting as you're falling down in your edit.
Mm disclaimer: I'm a windows dev by day. I introduced git into that shop I'm working at, the rogue 'I set it up, would you technical guys like to work with it' way. This happened 1.5 years earlier, today it's the blessed and only source control in play (ignoring one sad division having to deal with tfs.. Oh the agony).
So, I a) was the driving force pushing git and b) work in an environment where unix/linux knowledge is rare and ssh is a weird thing.
You are, again and again in this thread, missing the point and just plain insulting. Take it from this guy that types this message from his linux box and has a linux to windows box ratio of 5:1..: The git toolset sucks. It's crap for people that are used to windows only. You can mock people for them being uncomfortable with putty-gen (more likely, btw) or ssh-keygen, but the fact is that it's arcane and unintuitive to do that, if you have no clue what ssh is in the first place.
It doesn't help that git really doesn't _need_ ssh. It's just one (well, _the_ one) protocol you can use. I've coworkers that generated their key and didn't keep it afterwards. They thought it's kind of like a registration or that the client will keep this 'stuff' around somewhere. Most 'git doesn't work' errors are related to crappy windows clients being not helpful if the ssh key isn't available (ssh-agent/pageant not running or key not loaded).
SSH, in the company I work at, is 'that git stuff'. You consider that funny? Well.. Go ahead. My totally socially awkward inner geek might agree with you, but to the real world you're laughing about a weird kind of a maths joke right now. Most people don't get it, you're mocking things no one cares about and in the end you just look out of place.
Maybe GitHub for Windows will alleviate some of the problems with bad key handling, but I wonder if a few strategically logged bug reports with GitExtensions and TortoiseGit would go a fair way to fixing a lot of the friction people experience.
"You want to use Git, you should know how to use Git"
If that's insulting, then I'm going to have to learn to live with being a cruel, mean person.
Also, it's GitHub's fault that they use an existing secure method of transferring source code instead of writing a new protocol that's easier for you to use. Because 4 step-by-step instructions are too hard to follow. OK.
I'm not even asking that you understand it, but simply be able to follow very, very simple instructions.
(It's perfectly reasonable to not like Git's toolset. There are dozens of other source control utilities out there. The only ones I know of that are more 'usable' are SVN and TFS, and the tradeoffs there are pretty stark in my humble opinion)
The insulting and derogatory remarks is stuff like:
"Also, it's GitHub's fault that they use an existing secure method of transferring source code instead of writing a new protocol that's easier for you to use. Because 4 step-by-step instructions are too hard to follow. OK."
"I'm not even asking that you understand it, but simply be able to follow very, very simple instructions."
"If you're a dev, source control is one of your tools. Learn it or find a tool that holds your hand more. I don't know how it gets more hand-holdy than step by step instructions that take 4 minutes to carry out."
It's not insulting to point out that the instructions are very simple, easy to follow, and easy to understand. Everyone here is smart enough to understand these things, and it's utterly bewildering that they angrily refuse to spend 5 minutes learning about something new in order to use something new.
Ah, but to the people who may have trouble with the instructions (for whatever reason) or using the product beyond the instructions it is quite insulting. It is a direct insult to their intelligence and/or their ability for no good reason. That attitude does nothing to help our community, especially the people who are new to all this.
Let's imagine a company creates some form of hardware widget that requires some form of setup before it can be used. Initially the setup involves four steps that the company feels is "simple". Now, let's say a number of their customers have trouble with those simple instructions for different reasons. What's the proper response from that company?
A: Maybe we should think over the instructions to identify some problem spots as to why people are having trouble? Maybe we should ask some of these people what part are they having trouble with? Maybe we should consider a more in-depth explanation to people who have never used a similar device before?
B: If people aren't smart enough to figure out our simple instructions then they're too stupid to use our product. We could just ignore them but instead we'll insult them because they just don't get it. After all, if they're in our industry then they should already know how to do this.
I'm not saying that everyone should use response A, since most likely the problem has been answered somewhere. But too many people go with response B with absolutely no benefit to anyone in any way.
People telling you to follow the instructions are not questioning your intelligence. They're telling you to you know, follow the instructions. Because they work.
If you don't want to do that, you now have the option not to.
Please, bring me someone who actually had trouble with those instructions, and not because they freaked out at the first sign of a command line. They must have actually read them, including the expandable bits, made a serious effort to follow them, and failed.
I had a couple of breakages, because step 2 tells you to remove SSH keys if they are already present (without saying "Wait! Why do you have SSH keys? Maybe you should ask why they are there"), which broke various tools that expected the old keys to be there.
So in all the rules, the one place that isn't just "press OK, press OK, press OK", tells you to do something probably dangerous, depending on your setup.
It tells you to back them up, that makes it an inconvenience in the worst case, not dangerous.
More fundamentally, you had SSH keys and no understanding of what they were for? Sorry, but this is exactly what I'm talking about. You are choosing to use systems you have no understanding of, and taking no time at all to learn about them. You are dangerous.
I guess the problem some people don't want to realize is that you actually create that situation with this "Why can't you just follow this simple list" attitude.
I agree that everyone should be able to follow that list. And now you have someone with ssh keys and no idea what they are.
I think it's dangerous to mock people that are scared of these things (defined as opaque instructions that install various products and ask you to copy paste commands in a terminal) and afterwards mocking people that potentially DID follow that list, succeeded and now use a system they have no understanding of.
I love git. Git on Windows feels out of place for every Windows only guy I showed it to. Why is that something to argue about - and why does it lead to borderline insulting comments? It's interface is.. different and UIs are bolted on only and it packs a lot of mental dependencies (learn about ssh, different newlines) that aren't really related to your ability to write (Windows) code.
That Github link is perfectly correct and still full of WTF material for people that never left Visual Studio. I work with those, and I have a couple dozen anecdotal evidences available..
First of all, I should have clarifed that "I had a couple of issues" means I had to fix some broken computers where that had happened.
Secondly, you just said you wanted "A single person actually who had trouble with these rules". I presented you with such a person (indirectly).
While it isn't dangerous, it was annoying, because it took some time to figure out why various tools where no longer working correctly.
To be honest, you seem to be getting surprisingly angry that there at people who might want to use this shiny thing called github, on which many projects they use might reside, without fulling understanding every detail of git, ssh, etc.
I know some mathematicans who can write amazing algorithms, who I would want involved in projects I work on. However, they use windows and don't really care about the finer workings of unix. Personally, I think it's good if such people has the easiest access possible to making a quick push request, on their own machine in their comfort zone.
I'm angry at willful ignorance and attempts to justify it.
I truly, TRULY have no problem with making key generation push-button. I really don't. I have a very BIG problem with people who don't understand it pushing that button.
But you're right, I give up. All I can do is ensure that these people who demand of themselves nothing but the most disgusting of human characteristics -- willful ignorance -- do not come anywhere near my systems or projects.
First of all, thanks for answering my question so clearly. However, I feel the need to make a reply, despite the fact I think we have reached an impasse (not saying that is your fault, just a difference of opinion). I just feel you are really expressing yourself in an insulting way (you consider it a most disgusting of human characteristics that someone might just not care to learn about how ssh keys are generated)?
It's isn't "wilful ignorance" to not try and learn everything, ever, about everything. Particularly things which you don't want to learn, and probably aren't going to help you. We all specialise to one degree or another. I work with mathematicians who have spent years learning and refining their craft, who certainly know more maths than I could ever learn. I accept that there are things they know, and things I know. I want them to continue doing amazing maths, so I don't want to pile on them a bunch of things they don't want to learn. Despite the fact I did a maths degree, I know there are things they commonly discuss I don't really understand, which would be their equivalent of ssh keys. Things everyone knows. I've learnt some of them for work. I've learnt some of them for fun. But I don't have the time to learn all of them, and that's fine.
Now, these people do still learn. They learn about all kinds of fields, and all kinds of areas. They learnt CVS, but they didn't enjoy it.
Also, I find it very productive, and fun, to work with people whose skill sets are almost entirely disjoint from mine. It does make working together a bit tricky, but some of my most productive times have risen from such situations.
In most cases you are probably correct, I'm not really commenting on those particular instructions. I'm just making an observation about the responses based on comments people give about problems they are having.
I've read through the instructions and they do seem straight-forward enough. In fact, they are actually quite nice. But that still does not mean that some people will not have problems along the way. Not that I have any evidence to back this up but I can think of a few possibilities of why people may have problems:
1: The installer keeps failing for some unexplainable reason. Maybe they don't have the user rights, maybe the IT department is blocking it, whatever other possible install problems. You can't assume that everyone will understand why the installer is having issues on their particular computer as compared to another. We're already seeing reports like this for the new installer just released, I guess those people can't follow the simplest instructions of double-clicking an exe installer correctly. Right?
2: When they get to the line ending conversions part; what if they don't understand the options and abandon the process? Remember, some of these people are new to Git and without some hand-holding they may feel lost. In the screenshot I see there's no recommended option. So it's up to the user to pick the one they need without knowing what they need. Unless there's someone to point it out. And considering some people's attitudes about noobs doing the "wrong" thing then options like that are rather important to consider properly. Do you want to bet whether someone has complained about someone else picking the Windows-style checkout?
3: Even though the instructions are nicely laid out, not everyone is accustomed to the command line. I bet there's a huge number of Windows users who have never used the command line. Even with simple instructions there's the possibility for mistakes. There's even an extra section just for SSH that clearly shows that some people have issues with that part, even Github is trying to address it right there. But they can't possibly cover every conceivable issue.
Notice that most of my examples have nothing to do with the instructions themselves, but unforeseen problems that we have to deal with simply because so many people have different computers with different configurations with different networks with different IT departments with their different mandates. The attitude that it's simple for me therefore it must be simple for you is a bad one. The new installer worked for me on the first try, I don't dismiss the ones that did have a problem for some reason.
But to further prove my point about my two responses from before, Github decided to go with response A. How do we know? The release of the even simpler all-in-one application that started this whole conversation. Even with the "simple" instructions that have been pointed out, Github decided to listen about problems with the process and have responded with an even easier method to accomplish the same task. Even go above and beyond.
That is the mark of a good software developer/company/project. These are people trying to be inclusive, not exclusive.
Sadly, too many people in this thread decided to go with response B. Thankfully, Github disagrees with that attitude.
> The installer keeps failing for some unexplainable reason.
Not a problem following the instructions -- such a failure is clearly outside their scope.
You also conveniently ignore the reality that if they don't have permissions to install it... They're not supposed to be installing it in the first place. Report them to their corporate IT department, you'll be doing everyone a favor.
> When they get to the line ending conversions part; what if they don't understand the options and abandon the process?
Purely hypothetical. But if they give up that easily, yes, I consider it PEBKAC. People must take responsibility for their own ignorance and laziness.
> Even though the instructions are nicely laid out, not everyone is accustomed to the command line.
It. Is. Text. Read it. We read every day, we type every day. This is not difficult. Fear of the command line is irrational, which is exactly why I excluded it.
Oh I agree, I'm just providing examples. As I stated, the instructions are quite nice and easy to follow. I'm just pointing out possible problems people may have during the install process when so many people seem to be saying surely no problems exist because it is so simple.
I tried to make it quite clear that it was all hypothetical and outside the scope of the instructions, maybe I failed. But they are indeed possible problems that people can have during the install process. Whether the people are correctly identifying their problems is a different discussion. You are making my point for me, it is simple for you therefore it should be simple for everyone else. I'm just saying that it is quite possibly not so simple for other people, for various reasons. Nothing more.
Here you ask for five minutes of learning, later in this thread you seem to (correct me) expect people to get a good grasp on ssh and key management to avoid being 'dangerous'.
Is both correct? Or would you agree that 5min to learn how ssh works, even for a broad overview, is not exactly helping / changing anything.
Two different issues got mixed together here, and I wasn't good at distinguishing them in my comments.
It should take five minutes for them to learn the basics of public key crypto so that their eyes don't glaze over when you say "public key", "private key", "fingerprint", or "RSA". I consider this basic knowledge absolutely essential for anyone using these concepts, even indirectly. Without it, you're dangerous.
Once those concepts are in place, it shouldn't even take five minutes for them to understand what SSH is doing, because SSH is a very simple and obvious application of the concepts. It should be self-evident from the brief discussions in github's instructions what is going on.
And once you've taken the five minutes to understand the concepts, not being dangerous is likewise simple and obvious:
* Put a good passphrase on your key.
* Don't share your key with others.
* Don't type in the passphrase for your key on any computer you don't trust at least as much as your own.
Notice how these aren't fundamentally different from protecting a password.
We are talking about inherently intelligent people with a good capacity for learning. It is mind-boggling to me that anyone would argue that these people should not have to spend five minutes to understand at even the most basic, limited level, how critical tools they want to use work.
When seeing other people who have problems and difficulties - one group only feels righteous indignation; while another group sees a business opportunity.
Here's the fundamental problem. If you can't understand very basic security tools and concepts, you cannot securely operate a computer, much less hope to ever write secure code.
SSH is one of the easiest security tools to use safely that has ever existed. I would say it is second in usability only to HTTPS in browsers, while having a much better actual security record, and is infinitely more powerful, while keeping basic operation so simple I once taught my mother to use it.
I am 100% confident that anyone competently engaged in development or systems administration can understand the basic concepts and operations of SSH in five minutes. Any fear of it is irrational. It is not hard, it was specifically designed not to be hard.
I'm equally confident you've not taken the five minutes to understand these relevant concepts, because your statement about setting up a "safe" environment makes no sense in the context of OpenSSH. The defaults are inherently safe, as they should be. You must take specific actions to make the system unsafe.
> Here's the fundamental problem. If you can't understand very basic security tools and concepts, you cannot securely operate a computer, much less hope to ever write secure code.
He didn't say he was incapable of understanding it.
> SSH is one of the easiest security tools to use safely that has ever existed. I would say it is second in usability only to HTTPS in browsers
Perhaps that's true, but I suggest testing it would show a massive discrepancy between ease of HTTPS use and SSH use.
In short: I think this is a UX issue, not a PEBCAK one.
There is no UX issue, it's entirely an irrational fear of having to read. Putting it in a GUI accomplishes nothing but clutter the screen with irrelevant crap.
nknight@unassigned-hostname:~$ ssh-keygen -t rsa -C "foo@example.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/nknight/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/nknight/.ssh/id_rsa.
Your public key has been saved in /home/nknight/.ssh/id_rsa.pub.
The key fingerprint is:
d3:c0:19:ae:5b:ff:46:fd:a0:b5:9c:a2:93:a4:ca:c2 foo@example.com
The key's randomart image is:
+--[ RSA 2048]----+
| . |
| o o |
| = |
| . o |
| . S . . |
| o o. . + |
| . . o.o + = |
| E. . o.+ + .|
| .o. .+.. |
+-----------------+
nknight@unassigned-hostname:~$
Read. READ. Comprehend. Don't throw your hands up and say "But it's sooooo confusing!". It's not. It's very simple, and it is not possible to simplify further, no matter how you try to dress it up in eyecandy, you still must read and comprehend the exact same concepts. If you do not, you cannot be secure. Ever. The basic concepts of public key crypto are mandatory knowledge for everybody.
Get over your irrational fear and you will have no more trouble than you would reading a technical book.
That is an excellent example of "scary crypto stuff".
Most people aren't going to change where the file is saved, or care. They don't know, or care what a fingerprint is. I still have no idea what the 'randomart' images are about.
I don't see any benefit to all of that over having a button marked "make keys" which just gets me set up so I can use github.
Of course, you could force people to care about what files are placed where, and their permissions. Then you should probably remove the default values of course.
So long as you're unwilling to learn, very simple things will forever elude you.
> I don't see any benefit to all of that over having a button marked "make keys" which just gets me set up so I can use github.
It's not that the form has any strong benefit in itself, it's that if you understand what is going on, which is required for security, the text form is in no way mysterious, complicated, or intimidating. The GUI isn't fixing anything, it's just masking a serious problem with the user.
I also like being told where semi-automated processes are placing critical files on my filesystem. I'm surprised that annoys you.
> I also like being told where semi-automated processes are placing critical files on my filesystem. I'm surprised that annoys you.
No, it really doesn't annoy me. I'm very happy for you to use git from the command line. I use git from the command line and don't intend to use this new GUI. It would be no good to me anyway, as I use linux.
However, I get the feeling that you are annoyed that other people might want to have a full automated process, and not care where the critical files are being placed.
As time goes by I feel one of the most important things is to reduce the amount of work it takes for people to get started with something, particular because I have wasted so much time on it. Did I waste the time I spent getting started with git? vim? python? Not at all.
Did I waste the time I spent getting started with emacs? ruby on rails? mercurial? FreeBSD? Arch Linux? screen? To be honest yes. Each of these things, in their own way, had an annoying and non-user friendly setup and start, and I've since stopped using them and don't believe the skills were transferable. While I enjoy learning things, sometimes I just want to get started. Also, sometimes I want to get many collegues, who are less computer literate but still experts in their own fields, started.
GitHub for Windows generates and associates the key automatically without any user intervention. This is arguably better UX, and indicates that how to use ssh-keygen isn't necessarily mandatory knowledge.
All sorts of things can be done without any user intervention, but if the user doesn't understand how it works, they can't use it safely, and they are a danger to themselves and those around them.
One can perform the act of driving a car without any understanding of what the engine does, but if you lack any understanding of what it does, you're going to park it in a closed garage, leave it running, and kill yourself or someone else because you were too afraid of scary mechanical stuff to learn.
If you can't be bothered to learn about public key crypto, someone's going to social engineer your key out of you without you having any clue what happened.
It could use a "Key generated in `c:\users\james\.ssh\`. Don't share keys indiscriminately." dialog, but that's about it to achieve social engineering education parity with ssh-keygen. Users aren't inherently less secure just because they didn't copy and paste a command and see a randomart image.
I found some of the responses to be as troubling as some found the original post. The responders made assumptions and didn't bother asking why he called it "scary crypto stuff". He might have had a point since new people to all this might have reacted that way. But who cares about that right?
I got flamed a month ago [1] for noting how difficult it is to get up and running on GitHub in the Windows world, where things like generating SSH keys aren't exactly part of the daily routine. Glad to hear that they were listening.
[1] http://news.ycombinator.com/item?id=3871699