On Sun, May 31, 2015 at 3:37 AM, Ron Frederick <ronf@xxxxxxxxxxxxx> wrote: > On May 29, 2015, at 12:12 AM, Damien Miller <djm@xxxxxxxxxxx> 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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev