-\define{versionidfaq} \versionid $Id$
-
\A{faq} PuTTY \i{FAQ}
This FAQ is published on the PuTTY web site, and also provided as an
\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.
Yes. SSH-1 support has always been available in PuTTY.
+However, the SSH-1 protocol has many weaknesses and is no longer
+considered secure; you should use SSH-2 instead if at all possible.
+
+\#{XXX-REVIEW-BEFORE-RELEASE:
+As of 0.68, PuTTY will no longer fall back to SSH-1 if the server
+doesn't appear to support SSH-2; you must explicitly ask for SSH-1. }
+
\S{faq-localecho}{Question} Does PuTTY support \i{local echo}?
Yes. Version 0.52 has proper support for local echo.
does make \e{that} much difference.
If you're having a specific problem with host key checking - perhaps
-you want an automated batch job to make use of PSCP or Plink, and
-the interactive host key prompt is hanging the batch process - then
-the right way to fix it is to add the correct host key to the
-Registry in advance. That way, you retain the \e{important} feature
-of host key checking: the right key will be accepted and the wrong
-ones will not. Adding an option to turn host key checking off
-completely is the wrong solution and we will not do it.
+you want an automated batch job to make use of PSCP or Plink, and the
+interactive host key prompt is hanging the batch process - then the
+right way to fix it is to add the correct host key to the Registry in
+advance, or if the Registry is not available, to use the \cw{-hostkey}
+command-line option. That way, you retain the \e{important} feature of
+host key checking: the right key will be accepted and the wrong ones
+will not. Adding an option to turn host key checking off completely is
+the wrong solution and we will not do it.
If you have host keys available in the common \i\c{known_hosts} format,
we have a script called
-\W{http://www.tartarus.org/~simon-anonsvn/viewcvs.cgi/putty/contrib/kh2reg.py?view=markup}\c{kh2reg.py}
+\W{https://git.tartarus.org/?p=simon/putty.git;a=blob;f=contrib/kh2reg.py;hb=HEAD}\c{kh2reg.py}
to convert them to a Windows .REG file, which can be installed ahead of
time by double-clicking or using \c{REGEDIT}.
\S{faq-ports-general}{Question} What ports of PuTTY exist?
-Currently, release versions of PuTTY tools only run on full Win32
-systems and Unix. \q{Win32} includes Windows 95, 98, and ME, and it
-includes Windows NT, Windows 2000 and Windows XP.
+Currently, release versions of PuTTY tools only run on Windows
+systems and Unix.
+
+\#{XXX-REVIEW-BEFORE-RELEASE: replace following two lines with:
+As of 0.68, the supplied PuTTY executables run on versions of
+Windows from XP onwards,}
+PuTTY runs on versions of Windows from Windows 95 onwards (but not
+the 16-bit Windows 3.1; see \k{faq-win31}),
+up to and including Windows 10; and we know of no reason why PuTTY
+should not continue to work on future versions of Windows.
-In the development code, a partial port to the Mac OS (see
-\k{faq-mac-port}) is under way.
+The 32-bit Windows executables we provide for the \q{\i{x86}}
+processor architecture should also work fine on 64-bit processors
+that are backward-compatible with that architecture.
+\#{XXX-REVIEW-BEFORE-RELEASE: The 64-bit executables will only
+work on 64-bit versions of Windows. They will run somewhat faster
+than 32-bit executables would on the same processor, but will
+consume slightly more memory.}
-Currently PuTTY does \e{not} run on Windows CE (see \k{faq-wince}),
-and it does not quite run on the Win32s environment under Windows
-3.1 (see \k{faq-win31}).
+(We used to also provide executables for Windows for the Alpha
+processor, but stopped after 0.58 due to lack of interest.)
+
+In the development code, a partial port to Mac OS exists (see
+\k{faq-mac-port}).
+
+Currently PuTTY does \e{not} run on Windows CE (see \k{faq-wince}).
We do not have release-quality ports for any other systems at the
-present time. If anyone told you we had an EPOC port, or an iPaq port,
-or any other port of PuTTY, they were mistaken. We don't.
+present time. If anyone told you we had an Android port, or an iOS
+port, or any other port of PuTTY, they were mistaken. We don't.
There are some third-party ports to various platforms, mentioned
-on the Links page of our website.
+on the
+\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/links.html}{Links page of our website}.
\S{faq-unix}{Question} \I{Unix version}Is there a port to Unix?
tools, and also one entirely new application.
If you look at the source release, you should find a \c{unix}
-subdirectory containing \c{Makefile.gtk}, which should build you Unix
+subdirectory. There are a couple of ways of building it,
+including the usual \c{configure}/\c{make}; see the file \c{README}
+in the source distribution. This should build you Unix
ports of Plink, PuTTY itself, PuTTYgen, PSCP, PSFTP, and also
\i\c{pterm} - an \cw{xterm}-type program which supports the same
-terminal emulation as PuTTY. We do not yet have a Unix port of
-Pageant.
+terminal emulation as PuTTY. \#{XXX-REVIEW-BEFORE-RELEASE:}
+We do not yet have a Unix port of Pageant.
If you don't have \i{Gtk}, you should still be able to build the
command-line tools.
-Note that Unix PuTTY has mostly only been tested on Linux so far;
-portability problems such as BSD-style ptys or different header file
-requirements are expected.
-
\S{faq-unix-why}{Question} What's the point of the Unix port? Unix
has OpenSSH.
\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}?
C at least have stopped being backwards compatible to Win32s. Also,
the last time we tried this it didn't work very well.
-If you're interested in running PuTTY under Windows 3.1, help and
-testing in this area would be very welcome!
-
\S{faq-mac-port}{Question} Will there be a port to the \I{Mac OS}Mac?
-There are several answers to this question:
+We hope so!
-\b The Unix/Gtk port is already fully working under Mac OS X as an X11
-application.
+We attempted one around 2005, written as a native Cocoa application,
+but it turned out to be very slow to redraw its window for some reason
+we never got to the bottom of.
-\b A native (Cocoa) Mac OS X port is in progress. It's just about
-usable, but is of nowhere near release quality yet, and is likely to
-behave in unexpected ways.
+In 2015, after porting the GTK front end to work with GTK 3, we began
+another attempt based on making small changes to the GTK code and
+building it against the OS X Quartz version of GTK 3. This doesn't
+seem to have the window redrawing problem any more, so it's already
+got further than the last effort, but it is still substantially
+unfinished.
-\b A separate port to the classic Mac OS (pre-OSX) is also in
-progress; it too is not ready yet.
+If any OS X and/or GTK programming experts are keen to have a finished
+version of this, we urge them to help out with some of the remaining
+problems!
\S{faq-epoc}{Question} Will there be a port to EPOC?
for, it might be a long time before any of us get round to learning
a new system and doing the port for that.
-However, some of the work has been done by other people, and a beta
-port of PuTTY for the Nokia 9200 Communicator series is available
-from \W{http://s2putty.sourceforge.net/}\cw{http://s2putty.sourceforge.net/}
+However, some of the work has been done by other people; see the
+\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/links.html}{Links page of our website}
+for various third-party ports.
+
+\S{faq-iphone}{Question} Will there be a port to the iPhone?
+
+We have no plans to write such a port ourselves; none of us has an
+iPhone, and developing and publishing applications for it looks
+awkward and expensive.
+
+However, there is a third-party SSH client for the iPhone and
+iPod\_Touch called \W{http://www.instantcocoa.com/products/pTerm/}{pTerm},
+which is apparently based on PuTTY. (This is nothing to do with our
+similarly-named \c{pterm}, which is a standalone terminal emulator for
+Unix systems; see \k{faq-unix}.)
\H{faq-embedding} Embedding PuTTY in other programs
Most of the code cleanup work would be a good thing to happen in
general, so if anyone feels like helping, we wouldn't say no.
+See also
+\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/dll-frontend.html}{the wishlist entry}.
+
\S{faq-vb}{Question} Is the SSH or Telnet code available as a Visual
Basic component?
PuTTY also requires a random number seed file, to improve the
unpredictability of randomly chosen data needed as part of the SSH
-cryptography. This is stored by default in a file called \i\c{PUTTY.RND}
-in your Windows home directory (\c{%HOMEDRIVE%\\%HOMEPATH%}), or in
-the actual Windows directory (such as \c{C:\\WINDOWS}) if the home
-directory doesn't exist, for example if you're using Win95. If you
+cryptography. This is stored by default in a file called \i\c{PUTTY.RND};
+this is stored by default in the \q{Application Data} directory,
+or failing that, one of a number of fallback locations. If you
want to change the location of the random number seed file, you can
put your chosen pathname in the Registry, at
\c HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\RandSeedFile
+You can ask PuTTY to delete all this data; see \k{faq-cleanup}.
+
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
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.)
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.
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.
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
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. This was fixed in 0.59. 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.
+
+\S{faq-system32}{Question} When I put
+\#{XXX-REVIEW-BEFORE-RELEASE 32-bit} PuTTY in
+\cw{C:\\WINDOWS\\\i{SYSTEM32}} on my \i{64-bit Windows} system,
+\i{\q{Duplicate Session}} doesn't work.
+
+The short answer is not to put the PuTTY executables in that location.
+
+On 64-bit systems, \cw{C:\\WINDOWS\\SYSTEM32} is intended to contain
+only 64-bit binaries; Windows' 32-bit binaries live in
+\cw{C:\\WINDOWS\\SYSWOW64}. When a 32-bit PuTTY executable runs
+on a 64-bit system, it cannot by default see the \q{real}
+\cw{C:\\WINDOWS\\SYSTEM32} at all, because the
+\W{http://msdn.microsoft.com/en-us/library/aa384187(v=vs.85).aspx}{File
+System Redirector} arranges that the running program sees the
+appropriate kind of binaries in \cw{SYSTEM32}. Thus, operations in
+the PuTTY suite that involve it accessing its own executables, such as
+\i{\q{New Session}} and \q{Duplicate Session}, will not work.
+
\H{faq-secure} Security questions
\S{faq-publicpc}{Question} Is it safe for me to download PuTTY and
If you do trust the PC, then it's probably OK to use PuTTY on it
(but if you don't trust the network, then the PuTTY download might
be tampered with, so it would be better to carry PuTTY with you on a
-floppy).
+USB stick).
\S{faq-cleanup}{Question} What does PuTTY leave on a system? How can
I \i{clean up} after it?
PuTTY will leave some Registry entries, and a random seed file, on
-the PC (see \k{faq-settings}). If you are using PuTTY on a public
-PC, or somebody else's PC, you might want to clean these up when you
-leave. You can do that automatically, by running the command
-\c{putty -cleanup}. (Note that this only removes settings for
-the currently logged-in user on \i{multi-user systems}.)
+the PC (see \k{faq-settings}). Windows 7 and up also remember some
+information about recently launched sessions for the \q{jump list}
+feature.
+
+If you are using PuTTY on a public PC, or somebody else's PC, you
+might want to clean this information up when you leave. You can do
+that automatically, by running the command \c{putty -cleanup}. See
+\k{using-cleanup} in the documentation for more detail. (Note that
+this only removes settings for the currently logged-in user on
+\i{multi-user systems}.)
If PuTTY was installed from the installer package, it will also
-appear in \q{Add/Remove Programs}. Older versions of the uninstaller
-do not remove the above-mentioned registry entries and file.
+appear in \q{Add/Remove Programs}. Current versions of the installer
+do not offer to remove the above-mentioned items, so if you want them
+removed you should run \c{putty -cleanup} before uninstalling.
\S{faq-dsa}{Question} How come PuTTY now supports \i{DSA}, when the
website used to say how insecure it was?
ways to implement DSA which do not suffer nearly as badly from this
weakness, and indeed which don't need to rely on random numbers at
all. For this reason we now believe PuTTY's DSA implementation is
-probably OK. However, if you have the choice, we still recommend you
-use RSA instead.
+probably OK.
+
+The recently added elliptic-curve signature methods are also DSA-style
+algorithms, so they have this same weakness in principle. Our ECDSA
+implementation uses the same defence as DSA, while our Ed25519
+implementation uses the similar system (but different in details) that
+the Ed25519 spec mandates.
\S{faq-virtuallock}{Question} Couldn't Pageant use
\cw{VirtualLock()} to stop private keys being written to disk?
If you have software based on PuTTY, or specifically designed to
interoperate with PuTTY, or in some other way of genuine interest to
PuTTY users, then we will probably be happy to add a link to you on
-our Links page. And if you're running a mirror of the PuTTY web
-site, we're \e{definitely} interested.
+our Links page. And if you're running a particularly valuable mirror
+of the PuTTY web site, we might be interested in linking to you from
+our Mirrors page.
\S{faq-sourceforge}{Question} Why don't you move PuTTY to
SourceForge?
Also, security reasons. PuTTY is a security product, and as such it
is particularly important to guard the code and the web site against
unauthorised modifications which might introduce subtle security
-flaws. Therefore, we prefer that the Subversion repository, web site and
+flaws. Therefore, we prefer that the Git repository, web site and
FTP site remain where they are, under the direct control of system
administrators we know and trust personally, rather than being run
by a large organisation full of people we've never met and which is
Having said all that, if you still really \e{want} to give us money,
we won't argue :-) The easiest way for us to accept donations is if
you send money to \cw{<anakin@pobox.com>} using PayPal
-(\W{http://www.paypal.com/}\cw{www.paypal.com}). Alternatively, if
-you don't trust PayPal, you could donate through e-gold
-(\W{http://www.e-gold.com}\cw{www.e-gold.com}): deposit your
-donation in account number 174769, then send us e-mail to let us
-know you've done so (otherwise we might not notice for months!).
+(\W{http://www.paypal.com/}\cw{www.paypal.com}). If you don't like
+PayPal, talk to us; we can probably arrange some alternative means.
Small donations (tens of dollars or tens of euros) will probably be
spent on beer or curry, which helps motivate our volunteer team to
\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.
+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.
-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.
+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.
+
+\S{faq-vendor}{Question} As one of our existing software vendors, can
+you just fill in this questionnaire for us?
+
+We periodically receive requests like this, from organisations which
+have apparently sent out a form letter to everyone listed in their big
+spreadsheet of \q{software vendors} requiring them all to answer some
+long list of questions about supported OS versions, paid support
+arrangements, compliance with assorted local regulations we haven't
+heard of, contact phone numbers, and other such administrivia. Many of
+the questions are obviously meaningless when applied to PuTTY (we
+don't provide any paid support in the first place!), most of the rest
+could have been answered with only a very quick look at our website,
+and some we are actively unwilling to answer (we are private
+individuals, why would we want to give out our home phone numbers to
+large corporations?).
+
+We don't make a habit of responding in full to these questionnaires,
+because \e{we are not a software vendor}.
+
+A software \e{vendor} is a company to which you are paying lots of
+money in return for some software. They know who you are, and they
+know you're paying them money; so they have an incentive to fill in
+your forms and questionnaires, to research any local regulations you
+cite if they don't already know about them, and generally to provide
+every scrap of information you might possibly need in the most
+convenient manner for you, because they want to keep being paid.
+
+But we are a team of free software developers, and that means your
+relationship with us is nothing like that at all. If you once
+downloaded our software from our website, that's great and we hope you
+found it useful, but it doesn't mean we have the least idea who you
+are, or any incentive to do lots of unpaid work to support our
+\q{relationship} with you.
+
+It's not that we are unwilling to \e{provide information}. We put as
+much of it as we can on our website for your convenience, and if you
+actually need to know some fact about PuTTY which you haven't been
+able to find on the website (and which is not obviously inapplicable
+to free software in the first place) then please do ask us, and we'll
+try to answer as best we can. But we put up the website and this FAQ
+precisely so that we \e{don't} have to keep answering the same
+questions over and over again, so we aren't prepared to fill in
+completely generic form-letter questionnaires for people who haven't
+done their best to find the answers here first.
+
+If you work for an organisation which you think might be at risk of
+making this mistake, we urge you to reorganise your list of software
+suppliers so that it clearly distinguishes paid vendors who know about
+you from free software developers who don't have any idea who you are.
+Then, only send out these mass mailings to the former.
+
+\S{faq-checksums}{Question} The \c{sha1sums} / \c{sha256sums} / etc
+files on your download page don't match the binaries.
+
+People report this every so often, and usually the reason turns out to
+be that they've matched up the wrong checksums file with the wrong
+binaries.
+
+The PuTTY download page contains more than one version of the
+software. There's a \e{latest release} version; there are the
+\e{development snapshots}; and when we're in the run-up to making a
+release, there are also \e{pre-release} builds of the upcoming new
+version. Each one has its own collection of binaries, and its own
+collection of checksums files to go with them.
+
+So if you've downloaded the release version of the actual program, you
+need the release version of the checksums too, otherwise you will see
+a mismatch. Similarly, the development snapshot binaries go with the
+development snapshot checksums, and so on. (We've colour-coded the
+download page in an effort to reduce this confusion a bit.)
+
+If you have double-checked that, and you still think there's a real
+mismatch, then please send us a report carefully quoting everything
+relevant:
+
+\b the exact URL you got your binary from
+
+\b the checksum of the binary after you downloaded
+
+\b the exact URL you got your checksums file from
+
+\b the checksum that file says the binary should have.
\H{faq-misc} Miscellaneous questions
\S{faq-openssh}{Question} Is PuTTY a port of \i{OpenSSH}, or based on
-OpenSSH?
+OpenSSH or OpenSSL?
No, it isn't. PuTTY is almost completely composed of code written
from scratch for PuTTY. The only code we share with OpenSSH is the
-detector for SSH-1 CRC compensation attacks, written by CORE SDI S.A.
+detector for SSH-1 CRC compensation attacks, written by CORE SDI
+S.A; we share no code at all with OpenSSL.
\S{faq-sillyputty}{Question} Where can I buy silly putty?
\S{faq-pronounce}{Question} How do I pronounce \q{PuTTY}?
Exactly like the English word \q{putty}, which we pronounce
-/\u02C8{'}p\u028C{V}t\u026A{I}/.
+/\u02C8{'}p\u028C{V}ti/.
projects / PuTTY.git / blobdiff