absent, and also (I think) all the frontend request functions (such
as request_resize) take a context pointer, so that multiple windows
can be handled sensibly. I wouldn't swear to this, but I _think_
that only leaves the Unicode stuff as the last stubborn holdout.
[originally from svn r2147]
The current pty.c backend is temporarily a loopback device for
terminal emulator testing, the display handling is only just enough
to show that terminal.c is functioning, the keyboard handling is
laughable, and most features are absent. Next step: bring output and
input up to a plausibly working state, and put a real pty on the
back to create a vaguely usable prototype. Oh, and a scrollbar would
be nice too.
In _theory_ the Windows builds should still work fine after this...
[originally from svn r2010]
function, because it's silly to have two (and because the old one
was not the same as the new one, violating the Principle of Least
Surprise).
[originally from svn r1811]
Import command; the former warns you if you load a foreign key,
whereas the latter doesn't. So the user should always be aware, one
way or the other, that a format conversion is taking place.
[originally from svn r1687]
now be told that the key is the wrong type, _and_ what type it is,
rather than being given a blanket `unable to read key file' message.
[originally from svn r1662]
Specifically, we explicitly closesocket() all open sockets, which
appears to be necessary since otherwise Windows sends RST rather
than FIN. I'm _sure_ that's a Windows bug, but there we go.
[originally from svn r1574]
individual documentation of the various PuTTYgen controls; also
implemented context help in PuTTYgen to go with it. Shame there
isn't space for a generic `Help' button in the PuTTYgen window.
[originally from svn r1478]
now a passphrase-keyed MAC covering _all_ important data in the
file, including the public blob and the key comment. Should
conclusively scupper any attacks based on nobbling the key file in
an attempt to sucker the machine that decrypts it. MACing the
comment field also protects against a key-substitution attack (if
someone's worked out a way past our DSA protections and can extract
the private key from a signature, swapping key files and
substituting comments might just enable them to get the signature
they need to do this. Paranoid, but might as well).
[originally from svn r1413]
(as well as showing it for cut and paste). For SSH1, this feature is
largely cosmetic and added for orthogonality; it comes into its own
in SSH2, where it saves the Official One True Public Key Format as
specified in the draft spec, and more particularly as used by
ssh.com's product for authentication. Now that ssh-3.0.1 supports
RSA user keys, this is suddenly actually useful.
[originally from svn r1217]
spawn another command after starting Pageant. Also, if Pageant is
already running, `pageant keyfile' and `pageant -c command' will do
the Right Thing, that is, add the key to the _first_ Pageant and/or
run a command and then exit. The only time you now get the `Pageant
is already running' error is if you try to start the second copy
with no arguments.
NB the affected files in this checkin are rather wide-ranging
because I renamed the not really SSH1-specific
`ssh1_bignum_bitcount' function to just `bignum_bitcount'.
[originally from svn r1044]
error messages are currently wrong, and Pageant doesn't yet support
the new key type, and I haven't thoroughly tested that falling back
to password authentication and trying invalid keys etc all work. But
what I have here has successfully performed a public key
authentication, so it's working to at least some extent.
[originally from svn r973]
smalloc() macros and thence to the safemalloc() functions in misc.c.
This should allow me to plug in a debugging allocator and track
memory leaks and segfaults and things.
[originally from svn r818]
the primegen() function doesn't work well with <100 bits, so RSA
keys need to be >=200 to be generated correctly, and I thought 256
was a nice round number beyond that just to be sure. Perhaps I
should also have a security warning on any key less than 768; or
perhaps I should let people shoot themselves in the feet if they
really want to.
[originally from svn r767]
features (prompt for passphrase twice, prompt before overwriting a
file, check the key file was actually saved OK), testing of the
generated keys to make sure I got the file format right, and support
for a variable key size. I think what's already here is basically
sound though.
[originally from svn r715]
Simon Tatham
Jacob Nevins