mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-03-13 10:33:51 -05:00
423ce20ffb
Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
This is the README for PuTTY, a free Windows and Unix Telnet and SSH
client.
PuTTY is built using CMake <https://cmake.org/>. To compile in the
simplest way (on any of Linux, Windows or Mac), run these commands in
the source directory:
cmake .
cmake --build .
Then, to install in the simplest way on Linux or Mac:
cmake --build . --target install
On Unix, pterm would like to be setuid or setgid, as appropriate, to
permit it to write records of user logins to /var/run/utmp and
/var/log/wtmp. (Of course it will not use this privilege for
anything else, and in particular it will drop all privileges before
starting up complex subsystems like GTK.) The cmake install step
doesn't attempt to add these privileges, so if you want user login
recording to work, you should manually ch{own,grp} and chmod the
pterm binary yourself after installation. If you don't do this,
pterm will still work, but not update the user login databases.
Documentation (in various formats including Windows Help and Unix
`man' pages) is built from the Halibut (`.but') files in the `doc'
subdirectory using `doc/Makefile'. If you aren't using one of our
source snapshots, you'll need to do this yourself. Halibut can be
found at <https://www.chiark.greenend.org.uk/~sgtatham/halibut/>.
The PuTTY home web site is
https://www.chiark.greenend.org.uk/~sgtatham/putty/
If you want to send bug reports or feature requests, please read the
Feedback section of the web site before doing so. Sending one-line
reports saying `it doesn't work' will waste your time as much as
ours.
See the file LICENCE for the licence conditions.