Call for testing: OpenSSH 6.9

[Darren Tucker]

On Sun, May 31, 2015 at 3:37 AM, Ron Frederick <ronf at timeheart.net> wrote:

> On May 29, 2015, at 12:12 AM, Damien Miller <djm at mindrot.org> wrote:
> > OpenSSH 6.9 is almost ready for release, so we would appreciate testing
> > on as many platforms and systems as possible. This release contains
> > some substantial new features and a number of bug fixes.
>
> I just compiled and ran the tests for openssl-snap-20150531 on Linux
> (Ubuntu 14.04.2 LTS) and MacOS (10.10.3).
>
> On Linux, the code compiled cleanly. However, during “make tests” I got
> the following error a number of times:
>
> WARNING: /usr/local/etc/moduli does not exist, using fixed modulus
>

Most of the tests will still work with that file missing, but there's one
test that specifically checks that the DH group sizes are right, and
that'll fail (because the server doesn't have groups of the sizes it wants,
but it'll fall back to the couple that are compiled in).  You can just copy
the file into place if you like (as long as it's world readable), or you
can use configure --sysconfdir to point it at wherever the file actually is.


> Later in the test sequence I got the error:
>
> run test connect.sh ...
> Missing privilege separation directory: /var/empty
> FATAL: sshd_proxy broken
> make[1]: *** [t-exec] Error 1
> make[1]: Leaving directory `/tmp/openssh/regress'
> make: *** [tests] Error 2
> make tests  153.92s user 4.68s system 98% cpu 2:41.52 total
>
> I was not running as root at the time, as I wasn’t intending to install
> this version. It looks like it assumes that /var/empty will already exist,
> though, which it doesn’t on my system.


The privsep chroot path is specified at build time (./configure
--with-privsep-path if you want to change it).


> The currently installed sshd does have UsePrivilegeSeparation enabled, and
> it looks like the sshd user is set up with have /var/run/sshd as its home
> directory on this system, but the test script didn’t pick that up.


Having the chroot dir as the user's home dir is not a great idea.  If
someone discovers a way to write inside the chroot (eg via a permission
misconfiguration) then they can trivially escalate to full access that by
creating authorized_keys or similar.


> On MacOS, the code compiled, but there were a large number of warnings
> about constructs that were deprecated back in OS X 10.7. The output is
> quite large, but I’d be happy to provide it to anyone who wants it.

[...]

I would be interested in seeing it, although it's not something that we
would be looking at working on at this time.  Could you please either send
it to me off-list or file a bug at bugzilla.mindrot.org and attach the log?

Thanks.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.