cmdgen.c has contained code for ages to build a test main() if you
compile with -DTEST_CMDGEN. But it's painful to do so manually, since
you've still got to link in all the same supporting objects, and also
nobody can have actually done that for a while because the stub test
code hasn't been kept up to date with changes in the internal APIs
(specifically prompt_t).
Now we have the ability to include our test programs in Recipe as [UT]
or [XT] so as to leave them out of 'make install', that seems like a
useful thing to do with cmdgen's test suite. So here's a Recipe change
that builds it as 'cgtest', plus fixes for compiler warnings and bit
rot. Pleasantly, the test suite still _passes_ after those are fixed.
E.g. you might pass '--random-device=/dev/urandom'.
Mostly because I got sick of waiting for /dev/random to finish
blocking while I was trying to generate throwaway keys for testing bug
fixes in cmdgen itself. But it might also be useful on systems that
call their random device by a different name that we haven't
encountered.
(Since cmdgen also reads the saved PuTTY random seed file, setting
this option to /dev/zero will not render key generation deterministic.
It's tempting to provide _some_ way to do that, for testing purposes
and clearly marked as dangerous of course, but I think it would take
more faff than this.)
Partly this is because the geometry_widget functionality is going away
in a later version of GTK3, so sooner or later we'll need not to be
using it anyway. But also, it turns out that GTK 3's geometry
calculations have the unfortunate effect of setting the window's base
and min heights to values that are not congruent mod height_increment
(because the former is the value we gave, but the latter is based on
the minimum height of the scrollbar), which confuses at least one
window manager (xfwm4) and causes the window to be created one row too
small.
So I've redone all the geometry computations my own way, based on the
knowledge that the only widgets visible in the top-level window are
the drawing area and the scrollbar and I know how both of those
behave, and taking care to keep base_height and min_height congruent
to avoid that xfwm4 bug.
Both in a new section about reporting vulnerabilities, and in the
section about large attachments (since some large attachments will
surely contain confidential information from the sender).
I think the deterministic DSA system we've been using for ages can now
be considered proven in use, not to mention the fact that RFC 6979 and
the Ed25519 spec both give variants on the same idea. So I've removed
the 'don't use DSA if you can avoid it' warning.
Previously, due to confusion, it was placed either at the end of the
list or at the start, depending on whether the user had any saved
configuration at all. Now we get to choose a sensible place for it in
the list, and for the moment I think second place behind AES is
reasonable.
It was only prepared to position a new element relative to an existing
one if the latter was specified in the saved configuration, not if the
latter was another element new to this run of gprefs(). This wasn't
deliberate at all: it was just due to me failing to update the 'seen'
bitmap in the loop adding new elements.
If you're connecting to a new server and it _only_ provides host key
types you've configured to be below the warning threshold, it's OK to
give the standard askalg() message. But if you've newly demoted a host
key type and now reconnect to some server for which that type was the
best key you had cached, the askalg() wording isn't really appropriate
(it's not that the key we've settled on is the first type _supported
by the server_, it's that it's the first type _cached by us_), and
also it's potentially helpful to list the better algorithms so that
the user can pick one to cross-certify.
When Jacob introduced this message in d0d3c47a0, he was right to
assume that hostkey_algs[] and ssh->uncert_hostkeys[] were sorted in
the same order. Unfortunately, he became wrong less than an hour later
when I committed d06098622. Now we avoid making any such assumption.
It won't return true, because pterm's use of conf is a bit nonstandard
(it doesn't really bother about the protocol field, and has no use for
either host names _or_ serial port filenames). Was affecting both
gtkapp and gtkmain based builds.
Since we got a dynamic preference order, it's been bailing out at a
random point, and listing keys we wouldn't use.
(It would still be nice to only mention keys that we'd actually use, but
that's now quite fiddly.)
I noticed this in passing while tinkering with the hostkey_algs array:
these arrays are full of pointers-to-const, but are not also
themselves declared const, which they should have been all along.
Now we actually have enough of them to worry about, and especially
since some of the types we support are approved by organisations that
people might make their own decisions about whether to trust, it seems
worth having a config list for host keys the same way we have one for
kex types and ciphers.
To make room for this, I've created an SSH > Host Keys config panel,
and moved the existing host-key related configuration (manually
specified fingerprints) into there from the Kex panel.
It's too esoteric to be the first thing on the Auth panel; I've never
heard of any SSH server that supports it in the decade since I
implemented it. The only Google hits are lost souls mistakenly believing
they need it for passwordless public-key login and the like.
The current state of the OS X GTK port is looking more or less
plausible - it's not finished, of course, but then neither was the old
native Cocoa port. So I'm inclined to advertise it as *the* unfinished
OS X port: it's the one I intend to keep working on, and it's the one
I'd prefer people offered us help with if they're going to offer.
Hence, leaving the old macosx directory around is just confusing; that
directory is long-unmaintained, probably doesn't even compile, and its
only effect will be to mislead people into thinking it's still
relevant. I'm unilaterally deleting it; of course we can always
recover it from source control history if it's ever necessary to do
so.
This is an absolutely horrible piece of code, relying not only on font
metrics but also on an observed correlation between the length of a
key algorithm name and whether or not it needs a separate key size
displayed. But it'll do for the moment, and it's less effort than
writing a custom piece of Windows API code to display the list box
entries in a properly robust way :-(
Jacob pointed out that a free-text field for entering a key size in
bits is all very well for key types where we actually _can_ generate a
key to a size of your choice, but less useful for key types where
there are only three (or one) legal values for the field, especially
if we don't _say_ what they are.
So I've revamped the UI a bit: now, in ECDSA mode, you get a dropdown
list selector showing the available elliptic curves (and they're even
named, rather than just given by bit count), and in ED25519 mode even
that disappears. The curve selector for ECDSA and the bits selector
for RSA/DSA are independent controls, so each one remembers its last
known value even while temporarily hidden in favour of the other.
The actual generation function still expects a bit count rather than
an actual curve or algorithm ID, so the easiest way to actually
arrange to populate the drop-down list was to have an array of bit
counts exposed by sshecc.c. That's a bit ugly, but there we go.
One small functional change: if you enter an absurdly low value into
the RSA/DSA bit count box (under 256), PuTTYgen used to give a warning
and reset it to 256. Now it resets it to the default key length of
2048, basically because I was touching that code anyway to change a
variable name and just couldn't bring myself to leave it in a state
where it intentionally chose such an utterly useless key size. Of
course this doesn't prevent generation of 256-bit keys if someone
still really wants one - it just means they don't get one selected as
the result of a typo.
The About box is where it showed up most obviously that I'd hastily
bunged a GtkBox inside another GtkBox without considering their
margins: the 'action area' had twice the margin it should have had and
the rightmost button didn't align with the right edge of the rest of
the window contents.
Easily fixed by giving the inner hbox margin 0 (fixing the right align
and the excessive space around all the buttons), and using the
'spacing' property of GtkBox to ensure multiple buttons in it are
nicely separated without having to take care over that in the client
code that adds them.
This is a file that generally seems to turn up when you start using OS
X Finder to interact with directories - which is more likely now that
we're building OS X app bundles into this source tree.
This commit adds two .plist files, which go in the app bundles; two
.bundle files, which are input to gtk-mac-bundler and explain to it
how to _create_ the bundles; and a piece of manual addition to
Makefile.am that actually runs gtk-mac-bundler after building the
gtkapp.c based binaries and the OSX launcher. The latter is
conditionalised on configuring --with-quartz (unlike the binaries
themselves, which you can build on other platforms too, though they
won't do much that's useful).
The big problem with making an OS X application out of a GTK program
is that it won't start unless DYLD_LIBRARY_PATH and several other
environment variables point at all the GTK machinery. So your app
bundle has to contain two programs: a launcher to set up that
environment, and then the real main program that the launcher execs
once it's done so.
But in our case, we also need pterm to start subprocesses _without_
all that stuff in the environment - so our launcher has to be more
complicated than the usual one, because it's also got to save every
detail of how the environment was when it started up. So this is the
launcher program I'm going to use. Comments in the header explain in
more detail how it'll work.
Also in this commit, I add the other end of the same machinery to
gtkapp.c and uxpty.c: the former catches an extra command-line
argument that the launcher used to indicate how it had munged the
environment, and stores it in a global variable where the latter can
pick it up after fork() and use to actually undo the munging.
When it's finished, this will be the backbone of the OS X GTK port:
using a GtkApplication automatically gives us a properly OS X
integrated menu bar.
Using this source file in place of gtkmain.c turns the usual Unix
single-session-per-process PuTTY or pterm into the multi-session-per-
process OS X style one.
Things like Duplicate Session can be done much more simply here - we
just grab the Conf * from the source window and launch a new window
using it, with no fiddly interprocess work needed.
This is still experimental and has a lot of holes, but it's usable
enough to test and improve.
This is a weird thing to have to do, but it is necessary: the OS X
PuTTY will need its top-level windows to be instances of a thing
called GtkApplicationWindow, rather than plain GtkWindow. Hence, the
actual creation of windows needs to be somewhere that isn't
centralised between the two kinds of front end.
This is to [X] what [UT] is to [U]: that is, it's a program linked
against the GTK libraries, but one which doesn't become part of the
'make install' set. I'll use this for the individual binaries that
will go in the OS X application bundles, and then have another
makefile rule pick those up in turn.
Instead of main() living in uxputty.c and uxpterm.c, and doing a
little bit of setup before calling the larger pt_main() in gtkmain.c,
I've now turned things backwards: the big function in gtkmain.c *is*
main(), and the small pieces of preliminary setup in uxputty.c and
uxpterm.c are now a function called setup() which is called from
there. This will allow me to reuse the rest of ux{putty,pterm}.c, i.e.
the assorted top-level bits and pieces that distinguish PuTTY from
pterm, in the upcoming OS X application that will have its own main().
