We won't be able to use them in GTK3, or when compiling with GTK2 and
-DGDK_DISABLE_DEPRECATED.
This applies to the one we use for the main terminal window, and also
the small one we use for the preview pane in the unified font selector.
Now it's got an inner half that does actual drawing given a draw
context, and an outer half that sets up and tears down the draw
context. Sooner or later the inner half will need calling
independently of the outer, because GTK3's draw event will provide a
ready-made cairo_t.
A small bug in yesterday's work: since in Cairo mode
draw_stretch_before changes the transformation matrix, if we do it
before calling draw_clip then the clip region will be interpreted in
the transformed coordinates.
This caused a subtle display bug in yesterday's commit: drawing one
half of double-height text would have drawn _both_ halves of it on to
the window's backing pixmap, but only copied the correct half on to
the window proper - but the overdrawing on the pixmap would have shown
up if the window was hidden and re-exposed.
We were previously building our own mouse pointers out of pixmaps,
having first drawn characters from the X server standard font 'cursor'
on to those pixmaps, giving an effect almost exactly the same as just
calling gdk_cursor_new(some constant) except that we got to choose the
foreground and background colours of the resulting pointers.
But it's not clear why we needed to do that! In both GTK1 and GTK2 as
of my current testing, the standard colours appear to be just what I
wanted anyway (white pointer with black outline). The previous
implementation (and commit comment) was written in 2002, so perhaps it
was working around a GTK1 bug of the time.
So I've removed it completely, and replaced it with simple calls to
gdk_cursor_new (plus a workaround for GTK1's lack of GDK_BLANK_CURSOR,
but that's still much simpler than the previous code). If anyone does
report a colour problem, I may have to go back to doing something
clever, but if I can possibly arrange it, I'll want to do it by some
other technique, probably (as suggested in a comment in the previous
implementation) getting the underlying X cursor id and calling
XRecolorCursor.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
I was tacitly assuming that mfont->fallback would always be non-NULL,
which is true in a world containing Pango, but untrue in GTK1 when
Pango isn't there. In that situation we fall back to just omitting the
characters that would be displayed in the fallback font, on the
grounds that that's better than dereferencing through a NULL vtable.
GTK 2 has deprecated it and provided no replacement; a bug tracker
entry I found on the subject suggested that it was functionality that
didn't really belong in GTK, and glib ought to provide a replacement
instead, which would be a perfectly fine thing to suggest if they had
waited for glib to get round to doing so *before* throwing out a
function people were actually using. Sigh.
Anyway, it turns out that subsidiary invocations of gtk_main() don't
happen inside GTK as far as I can see, so all I need to do is to make
sure my own invocations of gtk_main() are followed by a cleanup
function which runs any quit functions that I've registered.
That was the last deprecated GTK function, so we now build cleanly
with -DGTK_DISABLE_DEPRECATED. (But, as mentioned a couple of commits
ago, we still don't build with -DGDK_DISABLE_DEPRECATED, because that
has migrating to Cairo drawing as a prerequisite.)
Now that I've got a general place to centralise handling of at least
the simple differences between GTK 1 and 2, I should use it wherever
possible. So this commit removes just a small number of ifdefs which
are either obsoleted by definitions already in gtkcompat.h (like
set_size_request vs set_usize), or can easily be replaced by adding
another (e.g. gtk_color_selection_set_has_opacity_control).
Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile
failure, for the use of gtk_quit_add() in idle_toplevel_callback_func.
That function is apparently removed with no replacement in GTK 3, so
I'll need to find a completely different approach to getting toplevel
callbacks to run only in the outermost instance of gtk_main().
Also, this change doesn't do anything about the use of *GDK*
deprecated functions, because those include the entire family of
old-style drawing functions - i.e. the only way to build cleanly with
-DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
On GTK versions where it's available, this is a much nicer way of
handling the -geometry command-line option, since not only do we get
all the faffing about with gravity for free, it also automatically
sets the user-position WM hints.
I've put in a special #define to control this selection, in case I
decide that for reasons of taste I'd prefer to switch back to
GtkFileSelection in GTK2 which supports both!
Replaces the deprecated gtk_color_selection_set_color() which took an
array of four doubles (RGBA), and instead takes a 'GdkColor' struct
containing four 16-bit integers.
For GTK1, we still have to retain the original version.
All the things like GtkType, GtkObject, gtk_signal_connect and so on
should now consistently have the new-style glib names like GType,
GObject, g_signal_connect, etc.
A major aim of introducing GTK 3 support is to permit compiling for
non-X11 platforms that GTK 3 supports, so I'm going to need to be able
to build as a pure GTK application with no use of X11 internals.
Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode
in which X server-side bitmap fonts are available.
Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's
the same compatibility flag that was already used by the unfinished OS
X port to disable the X-specific parts of uxpty.c; now it just applies
to more source files.
(There's no 'configure' option to set this flag at present. I haven't
worked out whether we'll need one yet.)
GTK 2 doesn't _documentedly_ provide a helpful compile option to let
us check this one in advance of GTK 3, but you can fake one anyway by
compiling with -D__GDK_KEYSYMS_COMPAT_H__, so that gdkkeysyms-compat.h
will believe that it's already been included :-) We now build cleanly
under GTK 2 with that predefine.
This is the first of several cleanup steps recommended by the GTK 2->3
migration guide.
I intend to begin work towards compatibility with GTK 3, but without
breaking GTK 2 and even GTK 1 compatibility in the process; GTK 2 is
still useful to _me_ (not least because it permits much easier support
of old-style server-side X11 fonts), and I recall hearing a rumour
that at least one kind of strange system can only run GTK 1, so for
the moment I don't intend to stop supporting either.
Including gdkkeysyms.h is not optional in GTK 2, because gdk.h does
not include it. In GTK 3 it does, so we don't explicitly reinclude it
ourselves.
We now build cleanly in GTK2 with -DGTK_DISABLE_SINGLE_INCLUDES. (But
that doesn't say much, because we did already! Apparently gdkkeysyms.h
was a special case which that #define didn't forbid.)
This is less than ideal - passphrase input now happens in ISO 8859-1,
and the passphrase prompt window is neither centred nor always-on-top.
But it basically works, and restores bare-minimum GTK 1 support to the
codebase as a whole.
If you're counting up to ms_limit in steps of ms_step, it's silly to
add ms_step at the end of the loop body _and_ increment the loop
variable by 1 in the loop header. I must have been half asleep.
The general plan is that if PuTTY knows a host key for a server, it
should preferentially ask for the same type of key so that there's some
chance of actually getting the same key again. This should mean that
when a server (or PuTTY) adds a new host key type, PuTTY doesn't
gratuitously switch to that key type and then warn the user about an
unrecognised key.
An unguarded write() in the dputs function caused gcc -Werror to fail
to compile. I'm confused that this hasn't bitten me before, though -
obviously normal builds of PuTTY condition out the faulty code, but
_surely_ this can't be the first time I've enabled the developer
diagnostics since gcc started complaining about unchecked syscall
returns!
When anyone connects to a PuTTY tool's listening socket - whether it's
a user of a local->remote port forwarding, a connection-sharing
downstream or a client of Pageant - we'd like to log as much
information as we can find out about where the connection came from.
To that end, I've implemented a function sk_peer_info() in the socket
abstraction, which returns a freeform text string as best it can (or
NULL, if it can't get anything at all) describing the thing at the
other end of the connection. For TCP connections, this is done using
getpeername() to get an IP address and port in the obvious way; for
Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some
moderately hairy autoconfery) to get the pid and owner of the peer. I
haven't implemented anything for Windows named pipes, but I will if I
hear of anything useful.
Caused an embarrassing failure just now trying to run the test program
from a command prompt - I had Return still held down by the time it
started up, and my release of it immediately terminated input :-)
Having found a lot of unfixed constness issues in recent development,
I thought perhaps it was time to get proactive, so I compiled the
whole codebase with -Wwrite-strings. That turned up a huge load of
const problems, which I've fixed in this commit: the Unix build now
goes cleanly through with -Wwrite-strings, and the Windows build is as
close as I could get it (there are some lingering issues due to
occasional Windows API functions like AcquireCredentialsHandle not
having the right constness).
Notable fallout beyond the purely mechanical changing of types:
- the stuff saved by cmdline_save_param() is now explicitly
dupstr()ed, and freed in cmdline_run_saved.
- I couldn't make both string arguments to cmdline_process_param()
const, because it intentionally writes to one of them in the case
where it's the argument to -pw (in the vain hope of being at least
slightly friendly to 'ps'), so elsewhere I had to temporarily
dupstr() something for the sake of passing it to that function
- I had to invent a silly parallel version of const_cmp() so I could
pass const string literals in to lookup functions.
- stripslashes() in pscp.c and psftp.c has the annoying strchr nature
All the name strings in ssh_cipher, ssh_mac, ssh_hash, ssh_signkey
point to compile-time string literals, hence should obviously be const
char *.
Most of these const-correctness patches are just a mechanical job of
adding a 'const' in the one place you need it right now, and then
chasing the implications through the code adding further consts until
it compiles. But this one has actually shown up a bug: the 'algorithm'
output parameter in ssh2_userkey_loadpub was sometimes returning a
pointer to a string literal, and sometimes a pointer to dynamically
allocated memory, so callers were forced to either sometimes leak
memory or sometimes free a bad thing. Now it's consistently
dynamically allocated, and should be freed everywhere too.
I've written my own analogue of OpenSSH's ssh-askpass. At the moment,
it's contained inside Pageant proper, though it could easily be
compiled into a standalone binary as well or instead.
Unlike OpenSSH's version, I don't use a GTK edit box; instead I just
process key events myself and append them to a buffer. The big
advantage of doing this is that I can arrange for ^W and ^U to
function as they do in terminal line editing, i.e. delete a word or
delete the whole line.
^W in particular is really valuable when typing a multiple-word
passphrase unseen. If you feel yourself making the kind of typo in
which you're not sure if you pressed six keys or just five, you can
hit ^W and restart just that word, without either having to go right
back to the beginning or carry on and see if you feel lucky.
A delete-word function would of course be an information leak in even
an obscured edit box (displaying a blob per character), so instead I
give a visual acknowledgment of keypresses by a more ad-hoc means: I
display three lights in the box, and every meaningful keypress turns
off the currently active one and instead turns on a randomly selected
one of the others. (So the lit light doesn't even indicate _mod 3_ how
many keys have been pressed.)
I had freed the comment string coming back from pageant_add_keyfile,
but not NULLed out the pointer, so that the cleanup code at the end of
the function would have freed it again.
I've decided against implementing an option exactly analogous to
'ssh-add -L' (printing the full public key of everything in the
agent). Instead, you can identify a specific key to display in full,
by any of the same means -d lets you use, and then print it in either
of the public key formats we support.
Unlike ssh-add, we can identify the key by its comment or by a prefix
of its fingerprint as well as using a public key file on disk. The
string given as an argument to -d is interpreted as whichever of those
things matches; disambiguating prefixes are available if needed.
You can now load keys at Pageant init time, by putting the key file
names as bare arguments on the command line, e.g. 'pageant -T key.ppk'
or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk'
behaves more or less like ssh-add, contacting an existing agent to add
the key.
The askpass() function currently supports terminal-based prompting
only. X11 askpass is yet to be implemented.
This brings in the code we'll need to request passphrases from the
terminal, and to talk to an existing SSH agent as a client.
Adding uxcons.c required adjusting the set of stub functions in
uxpgnt.c: uxcons.c removed the need for several, but added one of its
own (log_eventlog). A net win, though.
I've moved the setup and running of the actual agent server into
run_agent(), so that main() is now only command-line parsing and
validation. We recognise a collection of new command-line options for
talking to an existing agent as a client (analogous to ssh-add), which
go to a new run_client() function, but I haven't filled in that
function itself yet.
This is only intended for use in Unix Pageant; for any application
that's actually trying to get something else useful done at the same
time as the agent request is pending, it's much more sensible to use
the more rigorous existing approach of requesting a callback once the
agent request is answered.
Adding this mode is the easiest way to allow Unix Pageant's
command-line key loading to work, but it doesn't solve the underlying
problem that the supposedly cross-platform pageant_add_keyfile will
not work on a platform where we really _are_ constrained to do agent
requests asynchronously (perhaps because we're a GUI app in some
system that doesn't let us control our own top-level event loop).
If and when that situation arises, I'll have no choice but to turn
pageant_add_keyfile and friends (specifically, any function in
pageant.c that calls agent_query) into coroutine-structured functions,
and have clients call them repeatedly until they return 'finished'.
But for now, this is a lot easier!
Now --exec instantly terminates option processing, by treating
everything after it as the command. This means it doesn't matter if
the --exec command word looks like another option, and it also means
we can simplify the handling of real non-option argument words, when I
get round to adding some for loading keys.
This is intended to be a useful mode when you want to run an ssh agent
in a terminal session with no X11 available. You just execute a
command along the lines of eval $(pageant -T), and then Pageant will
run in the background for the rest of that terminal session - and when
the terminal session ends, so that Pageant loses its controlling tty,
it will take that as the signal to shut down. So, no need to manually
kill it, and unlike 'pageant --exec $SHELL', you can also do this half
way through a session if you don't realise until later that you need
an SSH agent, without losing any shell command history or other shell
context that you've accumulated so far in the session.
Unfortunately, I haven't been able to find any reliable way to
actually implement this -T mode, short of having Pageant wake up at
regular intervals and try to open /dev/tty to see if it's still there.
I had hoped that I could arrange to reliably get SIGHUP, or select on
/dev/tty for exceptional conditions, or some such, but nothing I've
tried along those lines seems to work.
The last use of it, to store the contents of the saved session name
edit box, was removed nearly two years ago in svn r9923 and replaced
by ctrl_alloc_with_free. The mechanism has been unused ever since
then, and I suspect any further uses of it would be a bad idea for the
same reasons, so let's get rid of it.
The memory dangling off ssd->sesslist should be freed when ssd itself
goes away, and the font settings ctrlset we delete in gtkcfg.c should
be freed as well once it's been removed from its containing array.
Thanks to Ranjini Aravind for pointing these out.
I've moved the listening socket setup back to before the lifetime
preparations, so in particular we find out that we couldn't bind to
the socket _before_ we fork. The only part that really needed to come
after lifetime setup was the logging setup, so that's now a separate
function called later.
Also, the random exit(0)s in silly places like x11_closing have turned
into setting a time_to_die flag, so that all clean exits funnel back
to the end of main() which at least tries to tidy up a bit afterwards.
(Finally, fixed a small bug in testing the return value of waitpid(),
which only showed up once we didn't exit(0) after the first wait.
Ahem.)
Now it actually logs all its requests and responses, the fingerprints
of keys mentioned in all messages, and so on.
I've also added the -v option, which causes Pageant in any mode to
direct that logging information to standard error. In --debug mode,
however, the logging output goes to standard output instead (because
when debugging, that information changes from a side effect to the
thing you actually wanted in the first place :-).
An internal tweak: the logging functions now take a va_list rather
than an actual variadic argument list, so that I can pass it through
several functions.
LIFE_EXEC is already dealt with, and I forgot to take out the comment
reminding me to do it, ahem.
The LIFE_PARENT mentioned in the same comment was an idea I had but
couldn't think of a way to make it work: if you have a terminal-only
shell session in which you want to eval $(ssh-agent), then it's
annoying and fragile to have to remember to kill the agent when you
log out, so you'd like it to automatically tie its lifetime to that of
the shell from which you invoked it. Unfortunately, I don't know of
any way to do that without race conditions. (E.g. if only pageant
didn't fork, then it could poll its own ppid until it became 1 - but
the child process would find it was 1 already.)
This is much more like ssh-agent than the Windows version is - it sets
SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other
processes, rather than Windows Pageant's approach of establishing
itself in a well-known location. But the actual agent code is the same
as Windows Pageant.
For the moment, this is an experimental utility and I don't expect it
to be useful to many people; its immediate use to me is that it
provides a way to test and debug the agent code on Unix, and also to
use the agent interface as a convenient way to exercise public key
functions I want to debug. And of course it means I can be constantly
using and testing my own code, on whatever platform I happen to be
using. In the further future, I have a list of possible features I
might add to it, but I don't know which ones I'll decide are
worthwhile.
One feature I've already put in is a wider range of lifetime
management options than ssh-agent: the -X mode causes Pageant to make
a connection to your X display, and automatically terminate when that
connection closes, so that it has the same lifetime as your X session
without having to do the cumbersome trick of exec()ing the subsequent
session-management process.
