specifying both PRINTER_ENUM_LOCAL and PRINTER_ENUM_CONNECTIONS
catches more printers in some circumstances than two EnumPrinters()
calls each specifying just one of them. We'll try it for a bit; if
it goes wrong I might have to put back the two original calls as
well and sort out some means of removing duplicate printers from the
list.
[originally from svn r1829]
uncompressed block at the end of each compressed packet) which we
were embarrassingly unable to deal with because we assumed every
uncompressed block contained at least one byte. Particularly silly
because I _knew_ about the existence of sync flush when I coded this
module. Arrgh. Still, now fixed.
[originally from svn r1824]
it for preserving file attributes in PSCP! Ah well; looks as if
that's one where we'll have to agree to differ with OpenSSH.
[originally from svn r1821]
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]
now be processed in cmdline.c, which is called from all utilities
(well, not Pageant or PuTTYgen). This should mean we get to
standardise almost all options across almost all tools. Also one
major change: `-load' is now the preferred option for loading a
saved session in PuTTY proper. `@session' still works but is
deprecated.
[originally from svn r1799]
authentication: a k-i request packet can contain any number of auth
prompts (including zero!) and we must ask the user all of them and
send back a packet containing the same number of responses. FreeBSD
systems were sending a zero-prompts packet which was crashing us;
this now appears fixed (we correctly return a zero-responses packet)
but I haven't tested a multiple-prompts packet because I can't
immediately think of a server that generates them.
[originally from svn r1797]
which suggested bufchain_prefix() was finding an improperly
initialised bufchain structure. Looking at the code, this may indeed
have been able to happen, since the bufchain in a SOCKDATA_DORMANT
channel was not initialised until CHANNEL_OPEN_CONFIRMATION was
received. This seems utterly daft, so I now call bufchain_init()
when the channel structure is actually created. With any luck the
crash will mystically disappear now (I wasn't able to reproduce it
myself).
[originally from svn r1735]
broken: the OpenSSL EVP layer specifies a very particular form of
padding, which I wasn't generating because it hadn't occurred to me
that it might be mandatory. Irritatingly this was causing our
exported OpenSSH keys to load perfectly happily back in through our
OpenSSH import routines, but to be rejected by OpenSSH proper. Sigh.
[originally from svn r1733]
not sending us large attachments, and in particular remove the
emphasis on screen shots in the hope of also decreasing the number
of _other_ large attachments we get.
[originally from svn r1715]
inclusive. Padding is accomplished by rewriting the signature blob
rather than at the point of generation, in order to avoid having to
move part of the workaround into Pageant (and having to corrupt the
agent wire protocol to allow PuTTY to specify whether it wants its
signatures padded!).
[originally from svn r1708]
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]
