X-Git-Url: https://git.distorted.org.uk/~mdw/sgt/putty/blobdiff_plain/65b15d17c0ddb172ca361f8ad1e8b1d13618e765..3d025d91eadd6d4953936db1bf1e605eb9eb441f:/doc/faq.but diff --git a/doc/faq.but b/doc/faq.but index ffcd00c6..e0b7df96 100644 --- a/doc/faq.but +++ b/doc/faq.but @@ -55,7 +55,9 @@ version 0.52. \S{faq-ssh2-keyfmt}{Question} Does PuTTY support reading OpenSSH or \cw{ssh.com} SSH-2 private key files? -PuTTY doesn't support this natively, but as of 0.53 +PuTTY doesn't support this natively (see +\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/key-formats-natively.html}{the wishlist entry} +for reasons why not), but as of 0.53 PuTTYgen can convert both OpenSSH and \cw{ssh.com} private key files into PuTTY's format. @@ -266,13 +268,12 @@ expect our Unix port to be the right thing for everybody. \S{faq-wince}{Question} Will there be a port to Windows CE or PocketPC? -It's currently being worked on, but it's only in its early stages yet, -and certainly isn't yet useful. PuTTY on portable devices would -clearly be a useful thing, so in the long term I hope it can be -brought up to release quality. +We have done some work on such a port, but it only reached an early +stage, and certainly not a useful one. It's no longer being actively +worked on. -There's also a third-party port at -\W{http://pocketputty.duxy.net/}\c{http://pocketputty.duxy.net/}. +However, there's a third-party port at +\W{http://www.pocketputty.net/}\c{http://www.pocketputty.net/}. \S{faq-win31}{Question} Is there a port to \i{Windows 3.1}? @@ -298,9 +299,10 @@ There are several answers to this question: \b The Unix/Gtk port is already fully working under Mac OS X as an X11 application. -\b A native (Cocoa) Mac OS X port is in progress. It's just about +\b A native (Cocoa) Mac OS X port has been started. It's just about usable, but is of nowhere near release quality yet, and is likely to -behave in unexpected ways. +behave in unexpected ways. Currently it's unlikely to be completed +unless someone steps in to help. \b A separate port to the classic Mac OS (pre-OSX) is also in progress; it too is not ready yet. @@ -394,12 +396,33 @@ On Unix, PuTTY stores all of this data in a directory \cw{~/.putty}. \H{faq-howto} HOWTO questions +\S{faq-login}{Question} What login name / password should I use? + +This is not a question you should be asking \e{us}. + +PuTTY is a communications tool, for making connections to other +computers. We maintain the tool; we \e{don't} administer any computers +that you're likely to be able to use, in the same way that the people +who make web browsers aren't responsible for most of the content you can +view in them. \#{FIXME: less technical analogy?} We cannot help with +questions of this sort. + +If you know the name of the computer you want to connect to, but don't +know what login name or password to use, you should talk to whoever +administers that computer. If you don't know who that is, see the next +question for some possible ways to find out. + +\# FIXME: some people ask us to provide them with a login name +apparently as random members of the public rather than in the +belief that we run a server belonging to an organisation they already +have some relationship with. Not sure what to say to such people. + \S{faq-commands}{Question} \I{commands on the server}What commands can I type into my PuTTY terminal window? -This is not a question you should be asking \e{us}. You need to read -the manuals, or ask the administrator, of \e{the computer you have -connected to}. +Again, this is not a question you should be asking \e{us}. You need +to read the manuals, or ask the administrator, of \e{the computer +you have connected to}. PuTTY does not process the commands you type into it. It's only a communications tool. It makes a connection to another computer; it @@ -438,7 +461,7 @@ To run a PuTTY session saved under the name \q{\cw{mysession}}, create a Windows shortcut that invokes PuTTY with a command line like -\c \path\name\to\putty.exe -load mysession +\c \path\name\to\putty.exe -load "mysession" (Note: prior to 0.53, the syntax was \c{@session}. This is now deprecated and may be removed at some point.) @@ -779,8 +802,8 @@ your terminal runs the risk of sending the same control sequence by accident, and cause unexpected changes in the window title. Don't do it. -\S{faq-password-fails}{Question} My keyboard stops working once -PuTTY displays the password prompt. +\S{faq-password-fails}{Question} My \i{keyboard} stops working once +PuTTY displays the \i{password prompt}. No, it doesn't. PuTTY just doesn't display the password you type, so that someone looking at your screen can't see what it is. @@ -790,8 +813,8 @@ as a row of asterisks either. This is so that someone looking at your screen can't even tell how \e{long} your password is, which might be valuable information. -\S{faq-keyboard}{Question} One or more function keys don't do what I -expected in a server-side application. +\S{faq-keyboard}{Question} One or more \I{keyboard}\i{function keys} +don't do what I expected in a server-side application. If you've already tried all the relevant options in the PuTTY Keyboard panel, you may need to mail the PuTTY maintainers and ask. @@ -812,8 +835,8 @@ application is expecting. The simplest way to investigate this is to find some other terminal environment, in which that function key \e{does} work; and then investigate what sequence the function key is sending in that -situation. One reasonably easy way to do this on a Unix system is to -type the command \c{cat}, and then press the function key. This is +situation. One reasonably easy way to do this on a \i{Unix} system is to +type the command \i\c{cat}, and then press the function key. This is likely to produce output of the form \c{^[[11~}. You can also do this in PuTTY, to find out what sequence the function key is producing in that. Then you can mail the PuTTY maintainers and tell @@ -985,6 +1008,17 @@ will be sacrificing security for this. (Falling back to SSH-1 would also remove the delays, but would lose a \e{lot} more security still. We do not recommend it.) +\S{faq-xpwontrun}{Question} PuTTY fails to start up. Windows claims that +\q{the application configuration is incorrect}. + +This is caused by a bug in certain versions of \i{Windows XP} which is +triggered by PuTTY 0.58. It can be avoided by installing +Service Pack 2, by using a different version of PuTTY, or by installing +a special \i{manifest file} alongside the PuTTY executable. +The +\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/xp-wont-run}{\q{xp-wont-run}} +entry in PuTTY's wishlist has more details. + \H{faq-secure} Security questions \S{faq-publicpc}{Question} Is it safe for me to download PuTTY and @@ -1177,18 +1211,192 @@ feel perfectly free not to donate. We don't mind. \S{faq-permission}{Question} Can I have permission to put PuTTY on a cover disk / distribute it with other software / etc? -Yes. You need not bother asking us explicitly for permission. You -already have permission. Redistribution of the unmodified PuTTY -binary in this way is entirely permitted by our licence (see -\k{licence}), and you are welcome to do it as much as you like. - -If you are distributing PuTTY within your own organisation, or for -use with your own product, then we recommend (but do not insist) -that you offer your own first-line technical support, to answer -questions directly relating to the interaction of PuTTY with your -particular environment. If your users mail us directly, we won't be -able to give them very much help about things specific to your own -setup. +Yes. For most things, you need not bother asking us explicitly for +permission; our licence already grants you permission. + +See \k{feedback-permission} for more details. + +\S{faq-indemnity}{Question} Can you sign an agreement indemnifying +us against security problems in PuTTY? + +No! + +A vendor of physical security products (e.g. locks) might plausibly +be willing to accept financial liability for a product that failed +to perform as advertised and resulted in damage (e.g. valuables +being stolen). The reason they can afford to do this is because they +sell a \e{lot} of units, and only a small proportion of them will +fail; so they can meet their financial liability out of the income +from all the rest of their sales, and still have enough left over to +make a profit. Financial liability is intrinsically linked to +selling your product for money. + +There are two reasons why PuTTY is not analogous to a physical lock +in this context. One is that software products don't exhibit random +variation: \e{if} PuTTY has a security hole (which does happen, +although we do our utmost to prevent it and to respond quickly when +it does), every copy of PuTTY will have the same hole, so it's +likely to affect all the users at the same time. So even if our +users were all paying us to use PuTTY, we wouldn't be able to +\e{simultaneously} pay every affected user compensation in excess of +the amount they had paid us in the first place. It just wouldn't +work. + +The second, much more important, reason is that PuTTY users +\e{don't} pay us. The PuTTY team does not have an income; it's a +volunteer effort composed of people spending their spare time to try +to write useful software. We aren't even a company or any kind of +legally recognised organisation. We're just a bunch of people who +happen to do some stuff in our spare time. + +Therefore, to ask us to assume financial liability is to ask us to +assume a risk of having to pay it out of our own \e{personal} +pockets: out of the same budget from which we buy food and clothes +and pay our rent. That's more than we're willing to give. We're +already giving a lot of our spare \e{time} to developing software +for free; if we had to pay our own \e{money} to do it as well, we'd +start to wonder why we were bothering. + +Free software fundamentally does not work on the basis of financial +guarantees. Your guarantee of the software functioning correctly is +simply that you have the source code and can check it before you use +it. If you want to be sure there aren't any security holes, do a +security audit of the PuTTY code, or hire a security engineer if you +don't have the necessary skills yourself: instead of trying to +ensure you can get compensation in the event of a disaster, try to +ensure there isn't a disaster in the first place. + +If you \e{really} want financial security, see if you can find a +security engineer who will take financial responsibility for the +correctness of their review. (This might be less likely to suffer +from the everything-failing-at-once problem mentioned above, because +such an engineer would probably be reviewing a lot of \e{different} +products which would tend to fail independently.) Failing that, see +if you can persuade an insurance company to insure you against +security incidents, and if the insurer demands it as a condition +then get our code reviewed by a security engineer they're happy +with. + +\S{faq-permission-form}{Question} Can you sign this form granting us +permission to use/distribute PuTTY? + +If your form contains any clause along the lines of \q{the +undersigned represents and warrants}, we're not going to sign it. +This is particularly true if it asks us to warrant that PuTTY is +secure; see \k{faq-indemnity} for more discussion of this. But it +doesn't really matter what we're supposed to be warranting: even if +it's something we already believe is true, such as that we don't +infringe any third-party copyright, we will not sign a document +accepting any legal or financial liability. This is simply because +the PuTTY development project has no income out of which to satisfy +that liability, or pay legal costs, should it become necessary. We +cannot afford to be sued. We are assuring you that \e{we have done +our best}; if that isn't good enough for you, tough. + +The existing PuTTY licence document already gives you permission to +use or distribute PuTTY in pretty much any way which does not +involve pretending you wrote it or suing us if it goes wrong. We +think that really ought to be enough for anybody. + +See also \k{faq-permission-general} for another reason why we don't +want to do this sort of thing. + +\S{faq-permission-future}{Question} Can you write us a formal notice +of permission to use PuTTY? + +We could, in principle, but it isn't clear what use it would be. If +you think there's a serious chance of one of the PuTTY copyright +holders suing you (which we don't!), you would presumably want a +signed notice from \e{all} of them; and we couldn't provide that +even if we wanted to, because many of the copyright holders are +people who contributed some code in the past and with whom we +subsequently lost contact. Therefore the best we would be able to do +\e{even in theory} would be to have the core development team sign +the document, which wouldn't guarantee you that some other copyright +holder might not sue. + +See also \k{faq-permission-general} for another reason why we don't +want to do this sort of thing. + +\S{faq-permission-general}{Question} Can you sign \e{anything} for +us? + +Not unless there's an incredibly good reason. + +We are generally unwilling to set a precedent that involves us +having to enter into individual agreements with PuTTY users. We +estimate that we have literally \e{millions} of users, and we +absolutely would not have time to go round signing specific +agreements with every one of them. So if you want us to sign +something specific for you, you might usefully stop to consider +whether there's anything special that distinguishes you from 999,999 +other users, and therefore any reason we should be willing to sign +something for you without it setting such a precedent. + +If your company policy requires you to have an individual agreement +with the supplier of any software you use, then your company policy +is simply not well suited to using popular free software, and we +urge you to consider this as a flaw in your policy. + +\S{faq-permission-assurance}{Question} If you won't sign anything, +can you give us some sort of assurance that you won't make PuTTY +closed-source in future? + +Yes and no. + +If what you want is an assurance that some \e{current version} of +PuTTY which you've already downloaded will remain free, then you +already have that assurance: it's called the PuTTY Licence. It +grants you permission to use, distribute and copy the software to +which it applies; once we've granted that permission (which we +have), we can't just revoke it. + +On the other hand, if you want an assurance that \e{future} versions +of PuTTY won't be closed-source, that's more difficult. We could in +principle sign a document stating that we would never release a +closed-source PuTTY, but that wouldn't assure you that we \e{would} +keep releasing \e{open}-source PuTTYs: we would still have the +option of ceasing to develop PuTTY at all, which would surely be +even worse for you than making it closed-source! (And we almost +certainly wouldn't \e{want} to sign a document guaranteeing that we +would actually continue to do development work on PuTTY; we +certainly wouldn't sign it for free. Documents like that are called +contracts of employment, and are generally not signed except in +return for a sizeable salary.) + +If we \e{were} to stop developing PuTTY, or to decide to make all +future releases closed-source, then you would still be free to copy +the last open release in accordance with the current licence, and in +particular you could start your own fork of the project from that +release. If this happened, I confidently predict that \e{somebody} +would do that, and that some kind of a free PuTTY would continue to +be developed. There's already precedent for that sort of thing +happening in free software. We can't guarantee that somebody +\e{other than you} would do it, of course; you might have to do it +yourself. But we can assure you that there would be nothing +\e{preventing} anyone from continuing free development if we +stopped. + +(Finally, we can also confidently predict that if we made PuTTY +closed-source and someone made an open-source fork, most people +would switch to the latter. Therefore, it would be pretty stupid of +us to try it.) + +\S{faq-export-cert}{Question} Can you provide us with export control +information / FIPS certification for PuTTY? + +Some people have asked us for an Export Control Classification Number +(ECCN) for PuTTY. We don't know whether we have one, and as a team of +free software developers based in the UK we don't have the time, +money, or effort to deal with US bureaucracy to investigate any +further. We believe that PuTTY falls under 5D002 on the US Commerce +Control List, but that shouldn't be taken as definitive. If you need +to know more you should seek professional legal advice. The same +applies to any other country's legal requirements and restrictions. + +Similarly, some people have asked us for FIPS certification of the +PuTTY tools. Unless someone else is prepared to do the necessary work +and pay any costs, we can't provide this. \H{faq-misc} Miscellaneous questions