Discussion:
Call for testing: OpenSSH 7.8
Damien Miller
2018-08-10 01:16:34 UTC
Permalink
Hi,

OpenSSH 7.8p1 is almost ready for release, so we would appreciate testing
on as many platforms and systems as possible. This is a bugfix release.

Snapshot releases for portable OpenSSH are available from
http://www.mindrot.org/openssh_snap/

The OpenBSD version is available in CVS HEAD:
http://www.openbsd.org/anoncvs.html

Portable OpenSSH is also available via git using the
instructions at http://www.openssh.com/portable.html#cvs
At https://anongit.mindrot.org/openssh.git/ or via a mirror at Github:
https://github.com/openssh/openssh-portable

Running the regression tests supplied with Portable OpenSSH does not
require installation and is a simply:

$ ./configure && make tests

Live testing on suitable non-production systems is also appreciated.
Please send reports of success or failure to
openssh-unix-***@mindrot.org. Security bugs should be reported
directly to ***@openssh.com.

Below is a summary of changes. More detail may be found in the ChangeLog
in the portable OpenSSH tarballs.

Thanks to the many people who contributed to this release.

Potentially-incompatible changes
================================

This release includes a number of changes that may affect existing
configurations:

* ssh-keygen(1): write OpenSSH format private keys by default
instead of using OpenSSL's PEM format. The OpenSSH format,
supported in OpenSSH releases since 2014 and described in the
PROTOCOL.key file in the source distribution, offers substantially
better protection against offline password guessing and supports
key comments in private keys. If necessary, it is possible to write
old PEM-style keys by adding "-m PEM" to ssh-keygen's arguments
when generating or updating a key.

* sshd(8): remove internal support for S/Key multiple factor
authentication. S/Key may still be used via PAM or BSD auth.

* ssh(1): remove vestigal support for running ssh(1) as setuid. This
used to be required for hostbased authentication and the (long
gone) rhosts-style authentication, but has not been necessary for
a long time. Attempting to execute ssh as a setuid binary, or with
uid != effective uid will now yield a fatal error at runtime.

* sshd(8): the semantics of PubkeyAcceptedKeyTypes and the similar
HostbasedAcceptedKeyTypes options have changed. These now specify
signature algorithms that are accepted for their respective
authentication mechanism, where previously they specified accepted
key types. This distinction matters when using the RSA/SHA2
signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their
certificate counterparts. Configurations that override these
options but omit these algorithm names may cause unexpected
authentication failures (no action is required for configurations
that accept the default for these options).

* sshd(8): the precedence of session environment variables has
changed. ~/.ssh/environment and environment="..." options in
authorized_keys files can no longer override SSH_* variables set
implicitly by sshd.

* ssh(1)/sshd(8): the default IPQoS used by ssh/sshd has changed.
They will now use DSCP AF21 for interactive traffic and CS1 for
bulk. For a detailed rationale, please see the commit message:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284

Changes since OpenSSH 7.7
=========================

This is primarily a bugfix release.

New Features
------------

* ssh(1)/sshd(8): add new signature algorithms "rsa-sha2-256-cert-
***@openssh.com" and "rsa-sha2-512-cert-***@openssh.com" to
explicitly force use of RSA/SHA2 signatures in authentication.

* sshd(8): extend the PermitUserEnvironment option to accept a
whitelist of environment variable names in addition to global
"yes" or "no" settings.

* sshd(8): add a PermitListen directive to sshd_config(5) and a
corresponding permitlisten= authorized_keys option that control
which listen addresses and port numbers may be used by remote
forwarding (ssh -R ...).

* sshd(8): add some countermeasures against timing attacks used for
account validation/enumeration. sshd will enforce a minimum time
or each failed authentication attempt consisting of a global 5ms
minimum plus an additional per-user 0-4ms delay derived from a
host secret.

* sshd(8): add a SetEnv directive to allow an administrator to
explicitly specify environment variables in sshd_config.
Variables set by SetEnv override the default and client-specified
environment.

* ssh(1): add a SetEnv directive to request that the server sets
an environment variable in the session. Similar to the existing
SendEnv option, these variables are set subject to server
configuration.

* ssh(1): allow "SendEnv -PATTERN" to clear environment variables
previously marked for sending to the server. bz#1285

* ssh(1)/sshd(8): make UID available as a %-expansion everywhere
that the username is available currently. bz#2870

* ssh(1): allow setting ProxyJump=none to disable ProxyJump
functionality. bz#2869

Bugfixes
--------

* all: substantial internal refactoring

* sshd(8): avoid observable differences in request parsing that could
be used to determine whether a target user is valid.

* ssh(1)/sshd(8): fix some memory leaks; bz#2366

* ssh(1): fix a pwent clobber (introduced in openssh-7.7) that could
occur during key loading, manifesting as crash on some platforms.

* sshd_config(5): clarify documentation for AuthenticationMethods
option; bz#2663

* ssh(1): ensure that the public key algorithm sent in a
public key SSH_MSG_USERAUTH_REQUEST matches the content of the
signature blob. Previously, these could be inconsistent when a
legacy or non-OpenSSH ssh-agent returned a RSA/SHA1 signature
when asked to make a RSA/SHA2 signature.

* sshd(8): fix failures to read authorized_keys caused by faulty
supplemental group caching. bz#2873

* scp(1): apply umask to directories, fixing potential mkdir/chmod
race when copying directory trees bz#2839

* ssh-keygen(1): return correct exit code when searching for and
hashing known_hosts entries in a single operation; bz#2772

* ssh(1): prefer the ssh binary pointed to via argv[0] to $PATH when
re-executing ssh for ProxyJump. bz#2831

* sshd(8): do not ban PTY allocation when a sshd session is
restricted because the user password is expired as it breaks
password change dialog. (regression in openssh-7.7).

* ssh(1)/sshd(8): fix error reporting from select() failures.

* ssh(1): improve documentation for -w (tunnel) flag, emphasising
that -w implicitly sets Tunnel=point-to-point. bz#2365

* ssh-agent(1): implement EMFILE mitigation for ssh-agent. ssh-agent
will no longer spin when its file descriptor limit is exceeded.
bz#2576

* ssh(1)/sshd(8): disable SSH2_MSG_DEBUG messages for Twisted Conch
clients. Twisted Conch versions that lack a version number in
their identification strings will mishandle these messages when
running on Python 2.x (https://twistedmatrix.com/trac/ticket/9422)

* sftp(1): notify user immediately when underlying ssh process dies
expectedly. bz#2719

* ssh(1)/sshd(8): fix tunnel forwarding; regression in 7.7 release.
bz#2855

* ssh-agent(1): don't kill ssh-agent's listening socket entirely if
it fails to accept(2) a connection. bz#2837

* sshd(8): relax checking of authorized_keys environment="..."
options to allow underscores in variable names (regression
introduced in 7.7). bz#2851

* ssh(1): add some missing options in the configuration dump output
(ssh -G). bz#2835

Portability
-----------

* sshd(8): Expose details of completed authentication to PAM auth
modules via SSH_AUTH_INFO_0 in the PAM environment. bz#2408

* Fix compilation problems caused by fights between zlib and OpenSSL
colliding uses of "free_func"

* Improve detection of unsupported compiler options. Recently these
may have manifested as "unsupported -Wl,-z,retpoline" warnings
during linking.

* sshd(8): some sandbox support for Linux/s390 bz#2752.

* regress tests: unbreak key-options.sh test on platforms without
openpty(3). bz#2856

* use getrandom(2) for PRNG seeding when built without OpenSSL.

OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de
Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre,
Tim Rice and Ben Lindstrom.
Zev Weiss
2018-08-10 09:34:17 UTC
Permalink
On Thu, Aug 09, 2018 at 08:16:34PM CDT, Damien Miller wrote:
>Hi,
>
>OpenSSH 7.8p1 is almost ready for release, so we would appreciate testing
>on as many platforms and systems as possible. This is a bugfix release.
>
>Snapshot releases for portable OpenSSH are available from
>http://www.mindrot.org/openssh_snap/
>
>The OpenBSD version is available in CVS HEAD:
>http://www.openbsd.org/anoncvs.html
>
>Portable OpenSSH is also available via git using the
>instructions at http://www.openssh.com/portable.html#cvs
>At https://anongit.mindrot.org/openssh.git/ or via a mirror at Github:
>https://github.com/openssh/openssh-portable
>
>Running the regression tests supplied with Portable OpenSSH does not
>require installation and is a simply:
>
>$ ./configure && make tests
>
>Live testing on suitable non-production systems is also appreciated.
>Please send reports of success or failure to
>openssh-unix-***@mindrot.org. Security bugs should be reported
>directly to ***@openssh.com.
>

On Void Linux (kernel 4.14, glibc 2.26, gcc 7.3) I'm seeing a failure in
the test_kex unit test:

$ git rev-parse HEAD
e1b26ce504662a5d5b991091228984ccfd25f280
$ ./configure --with-pam --with-pie --with-sandbox=seccomp_filter
<...snip...>
$ make tests
<...snip...>
test_kex: ....
regress/unittests/kex/test_kex.c:76 test #5 "kex"
ASSERT_INT_EQ(server->kex->done, 1) failed:
server->kex->done = -649425904
1 = 1
Aborted
make[1]: *** [Makefile:225: unit] Error 134
make[1]: *** Waiting for unfinished jobs....

Manually invoking regress/unittests/kex/test_kex, I see the value
printed for server->kex->done changing from one run to the next, which
made me suspect some sort of memory corruption or lack of
initialization, but running under valgrind doesn't show anything of the
sort:

$ valgrind ./regress/unittests/kex/test_kex
==12365== Memcheck, a memory error detector
==12365== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==12365== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==12365== Command: ./regress/unittests/kex/test_kex
==12365==
test_kex: ....
regress/unittests/kex/test_kex.c:76 test #5 "kex"
ASSERT_INT_EQ(server->kex->done, 1) failed:
server->kex->done = 103646864
1 = 1
==12365==
==12365== Process terminating with default action of signal 6 (SIGABRT)
==12365== at 0x5CAF920: raise (raise.c:51)
==12365== by 0x5CB0FFC: abort (abort.c:90)
==12365== by 0x10E33E: test_die (test_helper.c:302)
==12365== by 0x10FDD3: assert_int (test_helper.c:431)
==12365== by 0x10E9C6: run_kex (test_kex.c:76)
==12365== by 0x10ED27: do_kex_with_key (test_kex.c:117)
==12365== by 0x10F1CF: do_kex (test_kex.c:181)
==12365== by 0x10F21F: kex_tests (test_kex.c:192)
==12365== by 0x10E65D: main (test_helper.c:162)
==12365==
==12365== HEAP SUMMARY:
==12365== in use at exit: 66,964 bytes in 1,732 blocks
==12365== total heap usage: 2,350 allocs, 618 frees, 401,681 bytes allocated
==12365==
==12365== LEAK SUMMARY:
==12365== definitely lost: 0 bytes in 0 blocks
==12365== indirectly lost: 0 bytes in 0 blocks
==12365== possibly lost: 0 bytes in 0 blocks
==12365== still reachable: 66,964 bytes in 1,732 blocks
==12365== suppressed: 0 bytes in 0 blocks
==12365== Rerun with --leak-check=full to see details of leaked memory
==12365==
==12365== For counts of detected and suppressed errors, rerun with: -v
==12365== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Aborted

Let me know if there's any additional information that would be
useful...


Zev
The Doctor
2018-08-10 11:46:06 UTC
Permalink
All checks out on FreeBsd 11.2

--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism
We cannot direct the wind, but we can adjust the sails. -Bertha Calloway
Damien Miller
2018-08-10 12:14:13 UTC
Permalink
On Fri, 10 Aug 2018, Zev Weiss wrote:

> On Void Linux (kernel 4.14, glibc 2.26, gcc 7.3) I'm seeing a failure
> in the test_kex unit test:

[snip]

Thanks for testing!

I tried to recreate this by installing void x64_64 to a VM, but couldn't
- the test passes for me.a

My system ended up with a slightly newer kernel (4.17 IIRC). What
hardware platform are you using?

-d
Zev Weiss
2018-08-10 15:36:01 UTC
Permalink
On Fri, Aug 10, 2018 at 07:14:13AM CDT, Damien Miller wrote:
>On Fri, 10 Aug 2018, Zev Weiss wrote:
>
>> On Void Linux (kernel 4.14, glibc 2.26, gcc 7.3) I'm seeing a failure
>> in the test_kex unit test:
>
>[snip]
>
>Thanks for testing!
>
>I tried to recreate this by installing void x64_64 to a VM, but couldn't
>- the test passes for me.a
>
>My system ended up with a slightly newer kernel (4.17 IIRC). What
>hardware platform are you using?
>
>-d

Also x86_64 here (Core i7-4771, for what it's worth). I too have 4.17
installed, I just haven't yet gotten around to actually running it, so
4.14 is what's presently live on the system. If you want I think you
should be able to replicate that aspect via 'xbps-install linux4.14'
(and then of course booting said kernel).

Zev
Damien Miller
2018-08-10 17:16:20 UTC
Permalink
On Fri, 10 Aug 2018, Zev Weiss wrote:

> Also x86_64 here (Core i7-4771, for what it's worth). I too have 4.17
> installed, I just haven't yet gotten around to actually running it, so 4.14 is
> what's presently live on the system. If you want I think you should be able
> to replicate that aspect via 'xbps-install linux4.14' (and then of course
> booting said kernel).

I booted to linux-4.14 and test_kex still passes. Have you twiddled any
sysctls related to ASLR or security?

-d
Zev Weiss
2018-08-10 17:31:51 UTC
Permalink
On Fri, Aug 10, 2018 at 12:16:20PM CDT, Damien Miller wrote:
>On Fri, 10 Aug 2018, Zev Weiss wrote:
>
>> Also x86_64 here (Core i7-4771, for what it's worth). I too have 4.17
>> installed, I just haven't yet gotten around to actually running it, so 4.14 is
>> what's presently live on the system. If you want I think you should be able
>> to replicate that aspect via 'xbps-install linux4.14' (and then of course
>> booting said kernel).
>
>I booted to linux-4.14 and test_kex still passes. Have you twiddled any
>sysctls related to ASLR or security?
>
>-d

The only entry in my /etc/sysctl.conf is kernel.yama.ptrace_scope = 0;
kernel.randomize_va_space is at its default value of 2.

I'm a bit busy at the moment, but I'll hopefully be able to dig in with
a debugger and investigate in more detail sometime in the next couple
days.


Zev
Zev Weiss
2018-08-10 23:10:59 UTC
Permalink
On Fri, Aug 10, 2018 at 12:31:51PM CDT, Zev Weiss wrote:
>On Fri, Aug 10, 2018 at 12:16:20PM CDT, Damien Miller wrote:
>>On Fri, 10 Aug 2018, Zev Weiss wrote:
>>
>>>Also x86_64 here (Core i7-4771, for what it's worth). I too have 4.17
>>>installed, I just haven't yet gotten around to actually running it, so 4.14 is
>>>what's presently live on the system. If you want I think you should be able
>>>to replicate that aspect via 'xbps-install linux4.14' (and then of course
>>>booting said kernel).
>>
>>I booted to linux-4.14 and test_kex still passes. Have you twiddled any
>>sysctls related to ASLR or security?
>>
>>-d
>
>The only entry in my /etc/sysctl.conf is kernel.yama.ptrace_scope = 0;
>kernel.randomize_va_space is at its default value of 2.
>
>I'm a bit busy at the moment, but I'll hopefully be able to dig in
>with a debugger and investigate in more detail sometime in the next
>couple days.
>

...and it turns out it was just a stale build artifact --
regress/unittests/kex/test_kex.o didn't get recompiled after an update
to kex.h that changed the layout of struct kex. (Since from a cursory
glance it doesn't appear that there's currently any effort being made to
track header dependencies for things in the regress/ directory, I'm
assuming this wouldn't be considered a bug worth fixing.)

After a make clean all tests pass -- apologies for the noise.


Zev
Michael Felt
2018-08-10 20:19:46 UTC
Permalink
On 10/08/2018 03:16, Damien Miller wrote:
> OpenSSH 7.8p1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a bugfix release.
I am getting a build error. But this is also a new build system - based
on AIX 6.1 rather than AIX 5.3.
Will research asap.

configure: WARNING: Please check and edit blibpath in LDFLAGS in Makefile
+ /opt/bin/make > .buildaix/make.out
"kludge-fd_set.c", line 28.1: 1506-356 (W) Compilation unit is empty.
"glob.c", line 94.9: 1506-236 (W) Macro name TILDE has been redefined.
"glob.c", line 94.9: 1506-358 (I) "TILDE" is defined on line 271 of
/usr/include/sys/ioctl.h.
"/usr/include/syms.h", line 290.9: 1506-236 (W) Macro name T_NULL has
been redefined.
"/usr/include/syms.h", line 290.9: 1506-358 (I) "T_NULL" is defined on
line 150 of /usr/include/arpa/onameser_compat.h.
"/usr/include/sys/file.h", line 128.9: 1506-236 (W) Macro name LOCK_SH
has been redefined.
"/usr/include/sys/file.h", line 128.9: 1506-358 (I) "LOCK_SH" is defined
on line 149 of ../openbsd-compat/bsd-misc.h.
"/usr/include/sys/file.h", line 129.9: 1506-236 (W) Macro name LOCK_EX
has been redefined.
"/usr/include/sys/file.h", line 129.9: 1506-358 (I) "LOCK_EX" is defined
on line 150 of ../openbsd-compat/bsd-misc.h.
"/usr/include/sys/file.h", line 130.9: 1506-236 (W) Macro name LOCK_NB
has been redefined.
"/usr/include/sys/file.h", line 130.9: 1506-358 (I) "LOCK_NB" is defined
on line 151 of ../openbsd-compat/bsd-misc.h.
"/usr/include/sys/file.h", line 131.9: 1506-236 (W) Macro name LOCK_UN
has been redefined.
"/usr/include/sys/file.h", line 131.9: 1506-358 (I) "LOCK_UN" is defined
on line 152 of ../openbsd-compat/bsd-misc.h.
"port-aix.c", line 207.45: 1506-045 (S) Undeclared identifier ctx.
"port-aix.c", line 268.22: 1506-045 (S) Undeclared identifier r.
"port-aix.c", line 479.18: 1506-204 (S) Unexpected end of file.
make[1]: *** [Makefile:98: port-aix.o] Error 1
make: *** [Makefile:164: openbsd-compat/libopenbsd-compat.a] Error 2
/opt/bin/make returned an error

> Snapshot releases for portable OpenSSH are available from
> http://www.mindrot.org/openssh_snap/
Damien Miller
2018-08-10 20:29:55 UTC
Permalink
On Fri, 10 Aug 2018, Michael Felt wrote:

> On 10/08/2018 03:16, Damien Miller wrote:
> > OpenSSH 7.8p1 is almost ready for release, so we would appreciate testing
> > on as many platforms and systems as possible. This is a bugfix release.
> I am getting a build error. But this is also a new build system - based
> on AIX 6.1 rather than AIX 5.3.
> Will research asap.

[snip]

> "port-aix.c", line 207.45: 1506-045 (S) Undeclared identifier ctx.
> "port-aix.c", line 268.22: 1506-045 (S) Undeclared identifier r.
> "port-aix.c", line 479.18: 1506-204 (S) Unexpected end of file.

these look like real errors. Please try this:

diff --git a/openbsd-compat/port-aix.c b/openbsd-compat/port-aix.c
index eabb5249..943177c7 100644
--- a/openbsd-compat/port-aix.c
+++ b/openbsd-compat/port-aix.c
@@ -204,7 +204,7 @@ sys_auth_passwd(struct ssh *ssh, const char *password)
*/
expired = passwdexpired(name, &msg);
if (msg && *msg) {
- if ((r = sshbuf_put(ctx->loginmsg,
+ if ((r = sshbuf_put(ctxt->loginmsg,
msg, strlen(msg))) != 0)
fatal("%s: buffer error: %s",
__func__, ssh_err(r));
@@ -241,7 +241,7 @@ int
sys_auth_allowed_user(struct passwd *pw, struct sshbuf *loginmsg)
{
char *msg = NULL;
- int result, permitted = 0;
+ int r, result, permitted = 0;
struct stat st;

/*
@@ -267,6 +267,7 @@ sys_auth_allowed_user(struct passwd *pw, struct sshbuf *loginmsg)
else if (msg != NULL) {
if ((r = sshbuf_put(loginmsg, msg, strlen(msg))) != 0)
fatal("%s: buffer error: %s", __func__, ssh_err(r));
+ }
if (msg == NULL)
msg = xstrdup("(none)");
aix_remove_embedded_newlines(msg);
Michael Felt
2018-08-12 06:27:24 UTC
Permalink
On 10/08/2018 22:29, Damien Miller wrote:
> these look like real errors. Please try this:

snip.

Patch worked.

make tests ...

make[1]: Leaving directory '/data/prj/openbsd/openssh/openssh-7.8/regress'
all tests passed
Hisashi T Fujinaka
2018-08-12 16:39:21 UTC
Permalink
NetBSD-8 amd64
2 -pipe -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -mfunction-return=thunk -mindirect-branch=thunk -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-me
mset -fstack-protector-strong -I. -I.. -I. -I./.. -D_OPENBSD_SOURCE -DHAVE_CONFIG_H -c bsd-getline.c
bsd-getline.c:50:1: error: static declaration of 'getdelim' follows non-static declaration
getdelim(char **buf, size_t *bufsiz, int delimiter, FILE *fp)
^
In file included from /usr/include/resolv.h:65:0,
from ../openbsd-compat/getrrsetbyname.h:59,
from ../openbsd-compat/openbsd-compat.h:44,
from ../includes.h:174,
from bsd-getline.c:36:
/usr/include/stdio.h:535:10: note: previous declaration of 'getdelim' was here
ssize_t getdelim(char ** __restrict, size_t * __restrict, int,
^
*** Error code 1

Stop.
make[1]: stopped in /home/htodd/openssh-portable/openbsd-compat
*** Error code 1

Stop.
make: stopped in /home/htodd/openssh-portable


--
Hisashi T Fujinaka - ***@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee
Darren Tucker
2018-08-12 16:49:05 UTC
Permalink
On 13 August 2018 at 02:39, Hisashi T Fujinaka <***@twofifty.com> wrote:
[...]
> /usr/include/stdio.h:535:10: note: previous declaration of 'getdelim' was
> here

Did you run "autoreconf" to rebuild configure after updating and
before running ./configure? That has been the cause once before:
https://bugzilla.mindrot.org/show_bug.cgi?id=2881

--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Hisashi T Fujinaka
2018-08-12 21:40:12 UTC
Permalink
On Mon, 13 Aug 2018, Darren Tucker wrote:

> On 13 August 2018 at 02:39, Hisashi T Fujinaka <***@twofifty.com> wrote:
> [...]
>> /usr/include/stdio.h:535:10: note: previous declaration of 'getdelim' was
>> here
>
> Did you run "autoreconf" to rebuild configure after updating and
> before running ./configure? That has been the cause once before:
> https://bugzilla.mindrot.org/show_bug.cgi?id=2881

Yeesh, you're right. Every project uses a different auto* command to
preconfigure configure and like a noob, I didn't read INSTALL.

NetBSD-current amd64
checking OpenSSL library version... configure: error: OpenSSL >= 1.1.0 is not yet supported (have "1010008f (OpenSSL 1.1.0h 27 Mar 2018)")

NetBSD-8.0_STABLE amd64 passed

NetBSD-8.0_STABLE i386
In file included from /usr/include/ssp/string.h:35:0,
from /usr/include/string.h:127,
from /usr/include/strings.h:68,
from ../includes.h:58,
from bsd-misc.c:18:
bsd-misc.c:289:1: error: expected declaration specifiers or '...' before numeric constant
bzero(void *b, size_t n)

--
Hisashi T Fujinaka - ***@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee
Corinna Vinschen
2018-08-13 11:19:01 UTC
Permalink
On Aug 10 11:16, Damien Miller wrote:
> Hi,
>
> OpenSSH 7.8p1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a bugfix release.

Problems building on Cygwin, partially a result of a new GCC version.
I'm still collecting and fixing. I hope I have a few days to create a
useful report with patches?


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat
Corinna Vinschen
2018-08-13 18:30:56 UTC
Permalink
On Aug 13 13:19, Corinna Vinschen wrote:
> On Aug 10 11:16, Damien Miller wrote:
> > Hi,
> >
> > OpenSSH 7.8p1 is almost ready for release, so we would appreciate testing
> > on as many platforms and systems as possible. This is a bugfix release.
>
> Problems building on Cygwin, partially a result of a new GCC version.
> I'm still collecting and fixing. I hope I have a few days to create a
> useful report with patches?

Ok, it was less tragic than anticipated. I attached two patches which
are required to make this build work on Cygwin. With these two
patches OpenSSH builds and all tests pass.


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat
Damien Miller
2018-08-13 20:02:11 UTC
Permalink
On Mon, 13 Aug 2018, Corinna Vinschen wrote:

> On Aug 13 13:19, Corinna Vinschen wrote:
> > On Aug 10 11:16, Damien Miller wrote:
> > > Hi,
> > >
> > > OpenSSH 7.8p1 is almost ready for release, so we would appreciate testing
> > > on as many platforms and systems as possible. This is a bugfix release.
> >
> > Problems building on Cygwin, partially a result of a new GCC version.
> > I'm still collecting and fixing. I hope I have a few days to create a
> > useful report with patches?
>
> Ok, it was less tragic than anticipated. I attached two patches which
> are required to make this build work on Cygwin. With these two
> patches OpenSSH builds and all tests pass.

Thanks Corinna - these have been merged.

-d
Corinna Vinschen
2018-08-14 10:40:36 UTC
Permalink
On Aug 14 06:02, Damien Miller wrote:
> On Mon, 13 Aug 2018, Corinna Vinschen wrote:
>
> > On Aug 13 13:19, Corinna Vinschen wrote:
> > > On Aug 10 11:16, Damien Miller wrote:
> > > > Hi,
> > > >
> > > > OpenSSH 7.8p1 is almost ready for release, so we would appreciate testing
> > > > on as many platforms and systems as possible. This is a bugfix release.
> > >
> > > Problems building on Cygwin, partially a result of a new GCC version.
> > > I'm still collecting and fixing. I hope I have a few days to create a
> > > useful report with patches?
> >
> > Ok, it was less tragic than anticipated. I attached two patches which
> > are required to make this build work on Cygwin. With these two
> > patches OpenSSH builds and all tests pass.
>
> Thanks Corinna - these have been merged.
>
> -d

Thanks Damien!


Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat
Val Baranov
2018-08-13 22:06:25 UTC
Permalink
On Thu, Aug 09, 2018 at 08:16:34PM CDT, Damien Miller wrote:
>Hi,
>
>OpenSSH 7.8p1 is almost ready for release, so we would appreciate testing
>on as many platforms and systems as possible. This is a bugfix release.

AIX 7.1 TL5, C compiler 11.1.0.23 - error in "test_utf8":
test_sshbuf: .................................................................................................... 101 tests ok
test_sshkey: .......................................................................................... 90 tests ok
test_bitmap: .. 2 tests ok
test_conversion: . 1 tests ok
test_kex: ................................................................................................................................................................................................................................................................................................................................................................ 352 tests ok
test_hostkeys: .................. 18 tests ok
test_match: ...... 6 tests ok
test_utf8: ........................
regress/unittests/utf8/tests.c:48 test #25 "c_esc"
ASSERT_INT_EQ(len, wantlen) failed:
len = -1
wantlen = 5
make: 1254-059 The signal code from the last command is 6.

Let me know if addl info is needed.

Val
Predrag Zecevic
2018-08-14 08:22:00 UTC
Permalink
On Thu, Aug 09, 2018 at 08:16:34PM CDT, Damien Miller wrote:
>> Hi,
>>
>> OpenSSH 7.8p1 is almost ready for release, so we would appreciate testing
>> on as many platforms and systems as possible. This is a bugfix release.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-***@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Hi all,

tried OpenIndiana /hipster compile of openssh-SNAP-20180813.tar.gz,
within bare zone... Details:
$ gcc --version
gcc (OpenIndiana 6.4.0-OI-3) 6.4.0

$ ./configure --prefix=/pz/SFW/snapssh --with-pam
--with-solaris-projects --with-solaris-privs --with-xauth=/usr/bin/xauth
--with-md5-passwords --with-mantype=man # note absence of kerberos setup
- it fails in any case
...
OpenSSH has been configured with the following options:
                     User binaries: /pz/SFW/snapssh/bin
                   System binaries: /pz/SFW/snapssh/sbin
               Configuration files: /pz/SFW/snapssh/etc
                   Askpass program: /pz/SFW/snapssh/libexec/ssh-askpass
                      Manual pages: /pz/SFW/snapssh/share/man/manX
                          PID file: /var/run
  Privilege separation chroot path: /var/empty
            sshd default user PATH:
/usr/ccs/bin:/usr/bin:/bin:/usr/sbin:/sbin:/pz/SFW/snapssh/bin
   (If PATH is set in /etc/default/login it will be used instead. If
   used, ensure the path to scp is present, otherwise scp will not work.)
                    Manpage format: man
                       PAM support: yes
                   OSF SIA support: no
                 KerberosV support: no
                   SELinux support: no
              MD5 password support: yes
                   libedit support: no
                   libldns support: no
  Solaris process contract support: no
           Solaris project support: yes
         Solaris privilege support: yes
       IP address in $DISPLAY hack: no
           Translate v4 in v6 hack: no
                  BSD Auth support: no
              Random number source: OpenSSL internal ONLY
             Privsep sandbox style: solaris

              Host: i386-pc-solaris2.11
          Compiler: gcc
    Compiler flags: -g -O2 -pipe -Wall -Wpointer-arith -Wuninitialized
-Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess
-Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing
-D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-strong
Preprocessor flags:
      Linker flags:  -Wl,-z,now -fstack-protector-strong
         Libraries: -lresolv -lcrypto -lnsl -lz -lsocket  -lproject
         +for sshd:  -lpam -ldl

SVR4 style packages are supported with "make package"

PAM is enabled. You may need to install a PAM control file
for sshd, otherwise password authentication may fail.
Example PAM control files can be found in the contrib/
subdirectory

...
$ gmake -j 1 # has produced code, only few warnings (I can provide full
log, on demand).

$ file /pz/SFW/snapssh/sbin/sshd
/pz/SFW/snapssh/sbin/sshd:      ELF 32-bit LSB executable 80386 Version
1, dynamically linked, stripped

$ file /pz/SFW/snapssh/bin/ssh
/pz/SFW/snapssh/bin/ssh:        ELF 32-bit LSB executable 80386 Version
1, dynamically linked, stripped

$ /pz/SFW/snapssh/bin/ssh -V
OpenSSH_7.8p1-snap20180813, OpenSSL 1.0.2o  27 Mar 2018

It generally works, but no Kerberos support:
$ /pz/SFW/snapssh/bin/ssh -A ***@HOST
/export/home/predrag_zecevic/.ssh/config line 22: Unsupported option
"gssapidelegatecredentials"
/export/home/predrag_zecevic/.ssh/config line 23: Unsupported option
"gssapiauthentication"
...

I will try to make 64 bit executable, and I am also keen to get in
Kerberos support...

This is doable on OI, but needs more work.

Regards.
Predrag Zecevic
2018-08-14 09:47:29 UTC
Permalink
On 08/14/18 10:22, Predrag Zecevic wrote:
> On Thu, Aug 09, 2018 at 08:16:34PM CDT, Damien Miller wrote:
>>> Hi,
>>>
>>> OpenSSH 7.8p1 is almost ready for release, so we would appreciate
>>> testing
>>> on as many platforms and systems as possible. This is a bugfix release.
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-***@mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> Hi all,
>
> tried OpenIndiana /hipster compile of openssh-SNAP-20180813.tar.gz,
> within bare zone... Details:
> $ gcc --version
> gcc (OpenIndiana 6.4.0-OI-3) 6.4.0
>
> $ ./configure --prefix=/pz/SFW/snapssh --with-pam
> --with-solaris-projects --with-solaris-privs
> --with-xauth=/usr/bin/xauth --with-md5-passwords --with-mantype=man #
> note absence of kerberos setup - it fails in any case
> ...
> OpenSSH has been configured with the following options:
>                      User binaries: /pz/SFW/snapssh/bin
>                    System binaries: /pz/SFW/snapssh/sbin
>                Configuration files: /pz/SFW/snapssh/etc
>                    Askpass program: /pz/SFW/snapssh/libexec/ssh-askpass
>                       Manual pages: /pz/SFW/snapssh/share/man/manX
>                           PID file: /var/run
>   Privilege separation chroot path: /var/empty
>             sshd default user PATH:
> /usr/ccs/bin:/usr/bin:/bin:/usr/sbin:/sbin:/pz/SFW/snapssh/bin
>    (If PATH is set in /etc/default/login it will be used instead. If
>    used, ensure the path to scp is present, otherwise scp will not work.)
>                     Manpage format: man
>                        PAM support: yes
>                    OSF SIA support: no
>                  KerberosV support: no
>                    SELinux support: no
>               MD5 password support: yes
>                    libedit support: no
>                    libldns support: no
>   Solaris process contract support: no
>            Solaris project support: yes
>          Solaris privilege support: yes
>        IP address in $DISPLAY hack: no
>            Translate v4 in v6 hack: no
>                   BSD Auth support: no
>               Random number source: OpenSSL internal ONLY
>              Privsep sandbox style: solaris
>
>               Host: i386-pc-solaris2.11
>           Compiler: gcc
>     Compiler flags: -g -O2 -pipe -Wall -Wpointer-arith -Wuninitialized
> -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess
> -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing
> -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-strong
> Preprocessor flags:
>       Linker flags:  -Wl,-z,now -fstack-protector-strong
>          Libraries: -lresolv -lcrypto -lnsl -lz -lsocket -lproject
>          +for sshd:  -lpam -ldl
>
> SVR4 style packages are supported with "make package"
>
> PAM is enabled. You may need to install a PAM control file
> for sshd, otherwise password authentication may fail.
> Example PAM control files can be found in the contrib/
> subdirectory
>
> ...
> $ gmake -j 1 # has produced code, only few warnings (I can provide
> full log, on demand).
>
> $ file /pz/SFW/snapssh/sbin/sshd
> /pz/SFW/snapssh/sbin/sshd:      ELF 32-bit LSB executable 80386
> Version 1, dynamically linked, stripped
>
> $ file /pz/SFW/snapssh/bin/ssh
> /pz/SFW/snapssh/bin/ssh:        ELF 32-bit LSB executable 80386
> Version 1, dynamically linked, stripped
>
> $ /pz/SFW/snapssh/bin/ssh -V
> OpenSSH_7.8p1-snap20180813, OpenSSL 1.0.2o  27 Mar 2018
>
> It generally works, but no Kerberos support:
> $ /pz/SFW/snapssh/bin/ssh -A ***@HOST
> /export/home/predrag_zecevic/.ssh/config line 22: Unsupported option
> "gssapidelegatecredentials"
> /export/home/predrag_zecevic/.ssh/config line 23: Unsupported option
> "gssapiauthentication"
> ...
>
> I will try to make 64 bit executable, and I am also keen to get in
> Kerberos support...
>
> This is doable on OI, but needs more work.
>
> Regards.
>
When I have included Kerberos, compilations fails with:

gcc -o sshd sshd.o auth-rhosts.o auth-passwd.o audit.o audit-bsm.o
audit-linux.o platform.o sshpty.o sshlogin.o servconf.o serverloop.o
auth.o auth2.o auth-options.o session.o auth2-chall.o groupaccess.o
auth-bsdauth.o auth2-hostbased.o auth2-kbdint.o auth2-none.o
auth2-passwd.o auth2-pubkey.o monitor.o monitor_wrap.o auth-krb5.o
auth2-gss.o gss-serv.o gss-serv-krb5.o loginrec.o auth-pam.o
auth-shadow.o auth-sia.o md5crypt.o sftp-server.o sftp-common.o
sandbox-null.o sandbox-rlimit.o sandbox-systrace.o sandbox-darwin.o
sandbox-seccomp-filter.o sandbox-capsicum.o sandbox-pledge.o
sandbox-solaris.o uidswap.o -L. -Lopenbsd-compat/ -m64
-R/usr/gnu/lib/amd64 -R/usr/lib/amd64 -L/usr/gnu/lib/amd64
-L/usr/lib/amd64 -Wl,-z,now -fstack-protector-strong -R/usr/bin/lib
-lssh -lopenbsd-compat -lpam -ldl -lcrypto -lz -lresolv -lsocket -lnsl
-lm -lintl -lproject -L/usr/lib -lgss -lkrb5 -L/usr/lib -lkrb5
Undefined                       first referenced
 symbol                             in file
gss_krb5_copy_ccache                gss-serv-krb5.o
ld: fatal: symbol referencing errors. No output written to sshd
collect2: error: ld returned 1 exit status
gmake: *** [Makefile:175: sshd] Error 1

Regards.
Michael
2018-08-17 13:51:51 UTC
Permalink
On 14/08/2018 00:06, Val Baranov wrote:
> On Thu, Aug 09, 2018 at 08:16:34PM CDT, Damien Miller wrote:
>> Hi,
>>
>> OpenSSH 7.8p1 is almost ready for release, so we would appreciate testing
>> on as many platforms and systems as possible. This is a bugfix release.
> AIX 7.1 TL5, C compiler 11.1.0.23 - error in "test_utf8":
> test_sshbuf: .................................................................................................... 101 tests ok
> test_sshkey: .......................................................................................... 90 tests ok
> test_bitmap: .. 2 tests ok
> test_conversion: . 1 tests ok
> test_kex: ................................................................................................................................................................................................................................................................................................................................................................ 352 tests ok
> test_hostkeys: .................. 18 tests ok
> test_match: ...... 6 tests ok
> test_utf8: ........................
> regress/unittests/utf8/tests.c:48 test #25 "c_esc"
> ASSERT_INT_EQ(len, wantlen) failed:
> len = -1
> wantlen = 5
> make: 1254-059 The signal code from the last command is 6.
FYI - just rebuilt on AIX 6.1., xlc 11.1.0.20

 All tests succeeded BUT!
TEST_SSH_IPV6="yes" ; \^M
TEST_SSH_UTF8="no" ; \^M
TEST_SSH_ECC="yes" ; \^M

So, it seems the UTF test on my system is being skipped.

> Let me know if addl info is needed.
>
> Val
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-***@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Darren Tucker
2018-08-17 14:04:16 UTC
Permalink
On 17 August 2018 at 06:51, Michael <***@felt.demon.nl> wrote:
[...]
> All tests succeeded BUT!
> TEST_SSH_IPV6="yes" ; \^M
> TEST_SSH_UTF8="no" ; \^M
> TEST_SSH_ECC="yes" ; \^M
>
> So, it seems the UTF test on my system is being skipped.

That's controlled by the following fragment in configure.ac. Either
the test failed to compile or it could not set the locale. You can
look in config.log to see what happened.

AC_MSG_CHECKING([for utf8 locale support])
AC_RUN_IFELSE(
[AC_LANG_PROGRAM([[
#include <locale.h>
#include <stdlib.h>
]], [[
char *loc = setlocale(LC_CTYPE, "en_US.UTF-8");
if (loc != NULL)
exit(0);
exit(1);
]])],
AC_MSG_RESULT(yes),
[AC_MSG_RESULT(no)
TEST_SSH_UTF8=no],
AC_MSG_WARN([cross compiling: assuming yes])
)

Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Darren Tucker
2018-08-17 14:16:03 UTC
Permalink
On 13 August 2018 at 15:06, Val Baranov <***@duke.edu> wrote:
[...]
> test_utf8: ........................
> regress/unittests/utf8/tests.c:48 test #25 "c_esc"
> ASSERT_INT_EQ(len, wantlen) failed:
> len = -1
> wantlen = 5

This boils down to meaning OpenSSH's smnprintf call failed for the
string "\033x" instead of returning the expected escaped version
"\\033x". The code is in utf8.c but I am not sure why it failed.
What's your locale set to?

You can run the rest of the tests on your platform by running:

TEST_SSH_UTF8=no make testst

--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Ingo Schwarze
2018-08-17 15:15:37 UTC
Permalink
Hi Darren,

Darren Tucker wrote on Fri, Aug 17, 2018 at 07:16:03AM -0700:
> On 13 August 2018 at 15:06, Val Baranov <***@duke.edu> wrote:

>> test_utf8: ........................
>> regress/unittests/utf8/tests.c:48 test #25 "c_esc"
>> ASSERT_INT_EQ(len, wantlen) failed:
>> len = -1
>> wantlen = 5

> This boils down to meaning OpenSSH's smnprintf call failed for the
> string "\033x" instead of returning the expected escaped version
> "\\033x". The code is in utf8.c but I am not sure why it failed.

Actually, it is *supposed* to fail unless the locale is either
UTF-8 or the POSIX (ASCII) locale, because '\033' is not a
printable character and attempting to escape invalid stuff
is unsafe in arbitrary locales.

> What's your locale set to?

It doesn't matter on OpenBSD, but maybe you should consider setting
LC_CTYPE=en_US.UTF-8 by default in TEST_ENV in the portable version
of the test suite? Of course, it would do no harm on OpenBSD either.

If you worry that some target system might not have a en_US.UTF-8
locale installed, you can look at

http://mandoc.bsd.lv/cgi-bin/cvsweb/configure?rev=HEAD

for a way to autodetect a suitable UTF-8 locale - look for UTF8_LOCALE
in that script.

But that may be overkill for OpenSSH. Just recklessly forcing
LC_CTYPE=en_US.UTF-8 may be good enough for OpenSSH's purposes.
If the target system doesn't provide it, setlocale(3) will fall
back to POSIX, which should be good enough for the tests.

Yours,
Ingo
Michael Felt (aixtools)
2018-08-18 18:50:55 UTC
Permalink
Sent from my iPhone

> On 17 Aug 2018, at 17:15, Ingo Schwarze <***@usta.de> wrote:
>
> Hi Darren,
>
> Darren Tucker wrote on Fri, Aug 17, 2018 at 07:16:03AM -0700:
>> On 13 August 2018 at 15:06, Val Baranov <***@duke.edu> wrote:
>
>>> test_utf8: ........................
>>> regress/unittests/utf8/tests.c:48 test #25 "c_esc"
>>> ASSERT_INT_EQ(len, wantlen) failed:
>>> len = -1
>>> wantlen = 5
>
>> This boils down to meaning OpenSSH's smnprintf call failed for the
>> string "\033x" instead of returning the expected escaped version
>> "\\033x". The code is in utf8.c but I am not sure why it failed.
>
> Actually, it is *supposed* to fail unless the locale is either
> UTF-8 or the POSIX (ASCII) locale, because '\033' is not a
> printable character and attempting to escape invalid stuff
> is unsafe in arbitrary locales.
>
>> What's your locale set to?
>
Irrc the default on AIX. is iso-18559-15 (hope i have all the numbers right. In any case not utf-8.

AIX 7.2 may be different. In any case on AIX 6.1 the test logic automatically sets utf8 test to no.

> It doesn't matter on OpenBSD, but maybe you should consider setting
> LC_CTYPE=en_US.UTF-8 by default in TEST_ENV in the portable version
> of the test suite? Of course, it would do no harm on OpenBSD either.
>
> If you worry that some target system might not have a en_US.UTF-8
> locale installed, you can look at
>
> http://mandoc.bsd.lv/cgi-bin/cvsweb/configure?rev=HEAD
>
> for a way to autodetect a suitable UTF-8 locale - look for UTF8_LOCALE
> in that script.
>
> But that may be overkill for OpenSSH. Just recklessly forcing
> LC_CTYPE=en_US.UTF-8 may be good enough for OpenSSH's purposes.
> If the target system doesn't provide it, setlocale(3) will fall
> back to POSIX, which should be good enough for the tests.
>
> Yours,
> Ingo
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-***@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Damien Miller
2018-08-19 08:30:47 UTC
Permalink
On Sat, 18 Aug 2018, Michael Felt (aixtools) wrote:

> Irrc the default on AIX. is iso-18559-15 (hope i have all the numbers
> right. In any case not utf-8.

The numbers are ... not right:

https://www.iso.org/obp/ui/#iso:std:iso:18559:dis:ed-1:v1:en

ISO 18559 - Dentistry — Extraoral spatulas for mixing dental cements

Maybe ISO 8559-1? If it's basically ASCII then we could add it to the
check in utf8.c:dangerous_locale() and the test will probably pass.

-d
Ingo Schwarze
2018-08-19 14:18:47 UTC
Permalink
Hi,

Damien Miller wrote on Sun, Aug 19, 2018 at 06:30:47PM +1000:
> On Sat, 18 Aug 2018, Michael Felt (aixtools) wrote:

>> Irrc the default on AIX. is iso-18559-15 (hope i have all the numbers
>> right. In any case not utf-8.

> The numbers are ... not right:
>
> https://www.iso.org/obp/ui/#iso:std:iso:18559:dis:ed-1:v1:en
> ISO 18559 - Dentistry — Extraoral spatulas
> for mixing dental cements
>
> Maybe ISO 8559-1?

More likely ISO 8559-15, but whatever.

> If it's basically ASCII then we could add it to the check
> in utf8.c:dangerous_locale() and the test will probably pass.

I dislike that idea.

Sure, in theory, it would be possible and safe to add a long list
of all character encodings to that function which satisfy both of
the following conditions: (1) they do not carry internal state and
(2) they contain ASCII as a subset.

But i don't think it's worth the effort because such character
encodings (with the exception of UTF-8) have been moribund for
years. Also, such a list would not only be ugly, but also hard to
maintain because it would require the OpenSSH maintainers to judge
the properties of unfamiliar character sets. That hardship would
make maintenance error-prone. On top of that, all we can check is
the CODESET string returned from nl_langinfo(3), and those strings
are not specified by any standard. The more strings you whitelist
here, the higher the risk that some string that means a safe encoding
on one given system accidentally means a different, unsafe encoding
on some other system you never thought (or even heard) about.

I think the current whitelist is probably more or less safe, even
though the strcmp(loc, "646") looks a bit dubious - are we really
sure that there is no system out there using that for an unsafe
encoding? - and thinking about it again, i'm no longer all that
happy with the strcmp(loc, "") either - a broken (or even merely
unusual!) nl_langinfo(3) implementation could easily return that,
tricking OpenSSH into unsafe encoding behaviour.

In any case, i don't like the idea of adding yet more strings to
the list.

Yours,
Ingo
Damien Miller
2018-08-20 01:23:43 UTC
Permalink
On Sun, 19 Aug 2018, Ingo Schwarze wrote:

> > If it's basically ASCII then we could add it to the check
> > in utf8.c:dangerous_locale() and the test will probably pass.
>
> I dislike that idea.
>
> Sure, in theory, it would be possible and safe to add a long list
> of all character encodings to that function which satisfy both of
> the following conditions: (1) they do not carry internal state and
> (2) they contain ASCII as a subset.
>
> But i don't think it's worth the effort because such character
> encodings (with the exception of UTF-8) have been moribund for
> years. Also, such a list would not only be ugly, but also hard to
> maintain because it would require the OpenSSH maintainers to judge
> the properties of unfamiliar character sets. That hardship would
> make maintenance error-prone. On top of that, all we can check is
> the CODESET string returned from nl_langinfo(3), and those strings
> are not specified by any standard. The more strings you whitelist
> here, the higher the risk that some string that means a safe encoding
> on one given system accidentally means a different, unsafe encoding
> on some other system you never thought (or even heard) about.
>
> I think the current whitelist is probably more or less safe, even
> though the strcmp(loc, "646") looks a bit dubious - are we really
> sure that there is no system out there using that for an unsafe
> encoding? - and thinking about it again, i'm no longer all that
> happy with the strcmp(loc, "") either - a broken (or even merely
> unusual!) nl_langinfo(3) implementation could easily return that,
> tricking OpenSSH into unsafe encoding behaviour.
>
> In any case, i don't like the idea of adding yet more strings to
> the list.

Well, the alternative is that OpenSSH basically doesn't work properly
systems that use one of those codesets, so I'm happy to take the
risk for codesets that seem prima facie safe.

-d
Michael Felt
2018-08-20 08:33:57 UTC
Permalink
On 17/08/2018 17:15, Ingo Schwarze wrote:
> Hi Darren,
>
> Darren Tucker wrote on Fri, Aug 17, 2018 at 07:16:03AM -0700:
>> On 13 August 2018 at 15:06, Val Baranov <***@duke.edu> wrote:
>>> test_utf8: ........................
>>> regress/unittests/utf8/tests.c:48 test #25 "c_esc"
>>> ASSERT_INT_EQ(len, wantlen) failed:
>>> len = -1
>>> wantlen = 5
>> This boils down to meaning OpenSSH's smnprintf call failed for the
>> string "\033x" instead of returning the expected escaped version
>> "\\033x". The code is in utf8.c but I am not sure why it failed.
> Actually, it is *supposed* to fail unless the locale is either
> UTF-8 or the POSIX (ASCII) locale, because '\033' is not a
> printable character and attempting to escape invalid stuff
> is unsafe in arbitrary locales.
>
>> What's your locale set to?
OK. Double checked.
AIX defaults:
environment:
LANG=en_US
***@x064:[/usr/lib/nls/loc]ls -l /usr/lib/nls/loc/en_US
lrwxrwxrwx    1 bin      bin              32 Aug 02 06:40
/usr/lib/nls/loc/en_US -> /usr/lib/nls/loc/en_US.ISO8859-1

And, after installing the UTF-8 fileset ( 
/usr/lib/nls/loc/en_US.UTF-8                bos.loc.utf.EN_US     File)

The test is attempted, and fails.

Question #1 - how can I run only this test? Then it is easier to look
for potential resolutions.

> It doesn't matter on OpenBSD, but maybe you should consider setting
> LC_CTYPE=en_US.UTF-8 by default in TEST_ENV in the portable version
> of the test suite? Of course, it would do no harm on OpenBSD either.
While I wait for the answer - I'll just run the tests prefixed with
export  LC_CTYPE=en_US.UTF-8 - maybe that is all that is needed.

Reminds me of Question #2: how is your definition of POSIX different
from ISO8859-1 (and/or ISO8859-15, the "UK" or EN_US variant)?
> If you worry that some target system might not have a en_US.UTF-8
> locale installed, you can look at
>
> http://mandoc.bsd.lv/cgi-bin/cvsweb/configure?rev=HEAD
>
> for a way to autodetect a suitable UTF-8 locale - look for UTF8_LOCALE
> in that script.
>
> But that may be overkill for OpenSSH. Just recklessly forcing
> LC_CTYPE=en_US.UTF-8 may be good enough for OpenSSH's purposes.
> If the target system doesn't provide it, setlocale(3) will fall
> back to POSIX, which should be good enough for the tests.
>
> Yours,
> Ingo
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-***@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Michael Felt
2018-08-20 09:28:26 UTC
Permalink
On 20/08/2018 10:33, Michael Felt wrote:
> On 17/08/2018 17:15, Ingo Schwarze wrote:
>> Hi Darren,
>>
>> Darren Tucker wrote on Fri, Aug 17, 2018 at 07:16:03AM -0700:
>>> On 13 August 2018 at 15:06, Val Baranov <***@duke.edu> wrote:
>>>> test_utf8: ........................
>>>> regress/unittests/utf8/tests.c:48 test #25 "c_esc"
>>>> ASSERT_INT_EQ(len, wantlen) failed:
>>>> len = -1
>>>> wantlen = 5
>>> This boils down to meaning OpenSSH's smnprintf call failed for the
>>> string "\033x" instead of returning the expected escaped version
>>> "\\033x". The code is in utf8.c but I am not sure why it failed.
>> Actually, it is *supposed* to fail unless the locale is either
>> UTF-8 or the POSIX (ASCII) locale, because '\033' is not a
>> printable character and attempting to escape invalid stuff
>> is unsafe in arbitrary locales.
>>
>>> What's your locale set to?
> OK. Double checked.
> AIX defaults:
> environment:
> LANG=en_US
> ***@x064:[/usr/lib/nls/loc]ls -l /usr/lib/nls/loc/en_US
> lrwxrwxrwx    1 bin      bin              32 Aug 02 06:40
> /usr/lib/nls/loc/en_US -> /usr/lib/nls/loc/en_US.ISO8859-1
>
> And, after installing the UTF-8 fileset ( 
> /usr/lib/nls/loc/en_US.UTF-8                bos.loc.utf.EN_US     File)
>
> The test is attempted, and fails.
>
> Question #1 - how can I run only this test? Then it is easier to look
> for potential resolutions.
>
>> It doesn't matter on OpenBSD, but maybe you should consider setting
>> LC_CTYPE=en_US.UTF-8 by default in TEST_ENV in the portable version
>> of the test suite? Of course, it would do no harm on OpenBSD either.
> While I wait for the answer - I'll just run the tests prefixed with
> export  LC_CTYPE=en_US.UTF-8 - maybe that is all that is needed.
Test fails.

Use smitty to change primary "cultural", "language" and "keyboard"

  Primary CULTURAL convention  UTF-8   English (United States)
[EN_US]                         +
  Primary LANGUAGE translation UTF-8   English (UTF-8)
[en.UTF-8]                              +
  Primary KEYBOARD             UTF-8   English(POSIX) KBD ID 103P
[EN_US]                      +

initially fails, as these are also required:
Error:  The selected settings for cultural convention, language,
        and keyboard require the installation of additional filesets
        that are not currently installed.  Select an installation device
        that contains the following filesets:

 bos.msg.EN_US.net.tcp.client
 bos.msg.EN_US.rte

After that is added, and set:
***@x064:[/data/prj/openbsd/mindrot/openssh-7.8.0.20]grep LANG
/etc/environment
LANG=EN_US
***@x064:[/data/prj/openbsd/mindrot/openssh-7.8.0.20]grep LC
/etc/environment
LC__FASTMSG=true
LC_MESSAGES=***@lft

***@x064:[/usr/lib/nls/loc]ls -l EN_US
lrwxrwxrwx    1 bin      bin              28 Aug 03 12:28 EN_US ->
/usr/lib/nls/loc/EN_US.UTF-8

unset LC_CTYPE
export LANG=EN_US

Still same error sequence as above.

regress/unittests/utf8/tests.c:48 test #25 "c_esc"
ASSERT_INT_EQ(len, wantlen) failed:
         len = -1
     wantlen = 5
make: 1254-059 The signal code from the last command is 6.

(back to question #2: en_US is what I would expect to be enough to
satisfy "posix". traditionally EN_US has been to mean iso8559-15 while
en_US has been iso8559-1. Not clear on what the key differences are. So,
what is needed for OpenBSD definition of "POSIX"?


>
> Reminds me of Question #2: how is your definition of POSIX different
> from ISO8859-1 (and/or ISO8859-15, the "UK" or EN_US variant)?
>> If you worry that some target system might not have a en_US.UTF-8
>> locale installed, you can look at
>>
>> http://mandoc.bsd.lv/cgi-bin/cvsweb/configure?rev=HEAD
>>
>> for a way to autodetect a suitable UTF-8 locale - look for UTF8_LOCALE
>> in that script.
>>
>> But that may be overkill for OpenSSH. Just recklessly forcing
>> LC_CTYPE=en_US.UTF-8 may be good enough for OpenSSH's purposes.
>> If the target system doesn't provide it, setlocale(3) will fall
>> back to POSIX, which should be good enough for the tests.
>>
>> Yours,
>> Ingo
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-***@mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-***@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
Ingo Schwarze
2018-08-20 14:00:54 UTC
Permalink
Hi,

Michael Felt wrote on Mon, Aug 20, 2018 at 11:28:26AM +0200:
> On 20/08/2018 10:33, Michael Felt wrote:
>> On 17/08/2018 17:15, Ingo Schwarze wrote:
>>> Darren Tucker wrote on Fri, Aug 17, 2018 at 07:16:03AM -0700:
>>>> On 13 August 2018 at 15:06, Val Baranov <***@duke.edu> wrote:

>>>>> test_utf8: ........................
>>>>> regress/unittests/utf8/tests.c:48 test #25 "c_esc"
>>>>> ASSERT_INT_EQ(len, wantlen) failed:
>>>>> len = -1
>>>>> wantlen = 5

>>>> This boils down to meaning OpenSSH's smnprintf call failed for the
>>>> string "\033x" instead of returning the expected escaped version
>>>> "\\033x". The code is in utf8.c but I am not sure why it failed.

>>> Actually, it is *supposed* to fail unless the locale is either
>>> UTF-8 or the POSIX (ASCII) locale, because '\033' is not a
>>> printable character and attempting to escape invalid stuff
>>> is unsafe in arbitrary locales.

Sorry, i spoke too soon, i didn't correctly remember how the tests
work. It is completely irrelevant what the user sets their locale to,
as it should in a test suite. The tests themselves make sure the
locale ist set correctly for the tests. The "c_esc" in the test
output above means that it is testing the "C" locale at that point.

So the problem is somewhere else, likely in what your nl_langinfo(3)
function does in the POSIX locale. Could you please run the following
simple test program on your system and show us the output, for further
diagnosis?

OpenBSD:
$ make nl_langinfo
cc -O2 -pipe -o nl_langinfo nl_langinfo.c
$ ./nl_langinfo
setlocale -> "C"
nl_langinfo -> "US-ASCII"

Linux:
$ make nl_langinfo
cc nl_langinfo.c -o nl_langinfo
$ ./nl_langinfo
setlocale -> "C"
nl_langinfo -> "ANSI_X3.4-1968"

AIX:
?

Thank you,
Ingo


$ cat nl_langinfo.c
#include <err.h>
#include <langinfo.h>
#include <locale.h>
#include <stdio.h>

int
main(void)
{
char *res;

res = setlocale(LC_CTYPE, "C");
if (res == NULL)
err(1, "setlocale");
printf("setlocale -> \"%s\"\n", res);

res = nl_langinfo(CODESET);
if (res == NULL)
err(1, "nl_langinfo");
printf("nl_langinfo -> \"%s\"\n", res);

return 0;
}
Michael
2018-08-20 15:00:17 UTC
Permalink
On 20/08/2018 16:00, Ingo Schwarze wrote:
> AIX:
> ?

Had to modify it, just a bit (errno.h is probably not needed)

***@x071:[/data/prj/openbsd/mindrot]cat *.c
#include <errno.h>
#include <langinfo.h>
#include <locale.h>
#include <stdio.h>

static err(int exitcode, char *msg)
{
        fflush(stdout);
        fprintf(stderr,"%s", msg);
        exit(exitcode);
}

int
main(void)
{
        char *res;

        res = setlocale(LC_CTYPE, "C");
        if (res == NULL)
                err(1, "setlocale");
        printf("setlocale -> \"%s\"\n", res);

        res = nl_langinfo(CODESET);
        if (res == NULL)
                err(1, "nl_langinfo");
        printf("nl_langinfo -> \"%s\"\n", res);

        return 0;
}

cc nl_langinfo.c -o nl_langinfo -lc

./nl_langinfo
setlocale -> "C"
nl_langinfo -> "ISO8859-1"

There is a program - /usr/lib/nls/lsmle (just learned about it!)

FYI: First stanza is:

CC:
  locale:         "C"
  text_string:    "C (POSIX)"
  text_string_id: 100
  codeset:        "ISO8859-1"
  messages:       "C"
  keyboards:      "C"
  package:        ""
  variables:      "LANG=C"
  bosinst_menu:   "y"
  menu:           "101 102"

  Keyboard Descriptions (1):
  (1) locale:         "C"
  (1) keyboard_map:   "C"
  (1) text_string:    "C (POSIX)"
  (1) text_string_id: 100
  (1) codeset:        "ISO8859-1"
  (1) package:        ""
  (1) variables:      ""
  (1) keyboard_cmd:   "/usr/bin/chkbd /usr/lib/nls/loc/C.lftkeymap"
  (1) key_text:       "English(POSIX) KBD ID 103P"
  (1) key_text_id:    200

  Message Descriptions (1):
  (1) message Lvalue: "C"
  (1) message string: "C (POSIX)"
  (1) codeset:        "ISO8859-1"
  (1) package:        ""
  (1) variables:      ""
Ingo Schwarze
2018-08-20 17:14:52 UTC
Permalink
Hi,

Michael Felt wrote on Mon, Aug 20, 2018 at 05:00:17PM +0200:

> ./nl_langinfo
> setlocale -> "C"
> nl_langinfo -> "ISO8859-1"

Thanks, that is helpful.

So i think i was wrong and Damien was right. This means that
OpenSSH returns truncated messages when non-ASCII bytes occur
in them, even when the user requests LC_CTYPE=POSIX.
That's not good.

While there is no need to cater for any potential locale that users
might wilfully select, we should probably try to show complete
messages to users who specifically select the POSIX locale.

Admittedly, AIX is weird in calling ASCII "ISO8859-1", which is
probably going to mean something different elsewhere. But given
that it is very unlikely that anything another system calls ISO8859-1
is an unsafe (ASCII-incompatible or state-dependent) encoding, i'm
proposing the following patch.

I suggest adding some comments because otherwise, we will
eventually forget where all these strings came from.

OK?

> There is a program - /usr/lib/nls/lsmle (just learned about it!)

That's non-standard. The standard program for similar purposes is
locale(1), though that usually won't report CODESET, but only
LC_CTYPE.

Yours,
Ingo


Index: utf8.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/utf8.c,v
retrieving revision 1.7
diff -u -p -r1.7 utf8.c
--- utf8.c 31 May 2017 09:15:42 -0000 1.7
+++ utf8.c 20 Aug 2018 17:11:33 -0000
@@ -51,9 +51,18 @@ dangerous_locale(void) {
char *loc;

loc = nl_langinfo(CODESET);
- return strcmp(loc, "US-ASCII") != 0 && strcmp(loc, "UTF-8") != 0 &&
- strcmp(loc, "ANSI_X3.4-1968") != 0 && strcmp(loc, "646") != 0 &&
- strcmp(loc, "") != 0;
+ return strcmp(loc, "UTF-8") != 0 &&
+ strcmp(loc, "US-ASCII") != 0 &&
+
+ /*
+ * What nl_langinfo(CODESET) returns for US-ASCII
+ * on various operating systems:
+ */
+
+ strcmp(loc, "ANSI_X3.4-1968") != 0 && /* Linux */
+ strcmp(loc, "ISO8859-1") != 0 && /* AIX */
+ strcmp(loc, "646") != 0 && /* Solaris, NetBSD */
+ strcmp(loc, "") != 0; /* Solaris 6 */
}

static int
Michael
2018-08-20 18:28:12 UTC
Permalink
On 20/08/2018 19:14, Ingo Schwarze wrote:
> Index: utf8.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/ssh/utf8.c,v
> retrieving revision 1.7
> diff -u -p -r1.7 utf8.c
> --- utf8.c 31 May 2017 09:15:42 -0000 1.7
> +++ utf8.c 20 Aug 2018 17:11:33 -0000
> @@ -51,9 +51,18 @@ dangerous_locale(void) {
> char *loc;
>
> loc = nl_langinfo(CODESET);
> - return strcmp(loc, "US-ASCII") != 0 && strcmp(loc, "UTF-8") != 0 &&
> - strcmp(loc, "ANSI_X3.4-1968") != 0 && strcmp(loc, "646") != 0 &&
> - strcmp(loc, "") != 0;
> + return strcmp(loc, "UTF-8") != 0 &&
> + strcmp(loc, "US-ASCII") != 0 &&
> +
> + /*
> + * What nl_langinfo(CODESET) returns for US-ASCII
> + * on various operating systems:
> + */
> +
> + strcmp(loc, "ANSI_X3.4-1968") != 0 && /* Linux */
> + strcmp(loc, "ISO8859-1") != 0 && /* AIX */
> + strcmp(loc, "646") != 0 && /* Solaris, NetBSD */
> + strcmp(loc, "") != 0; /* Solaris 6 */
> }
>
> static int

After applying the patch:

***@x064:[/data/prj/openbsd/mindrot/openssh-7.8.0.20]/data/prj/openbsd/mindrot/openssh-7.8.0.20/regress/unittests/utf8/test_utf8
test_utf8: .................................. 34 tests ok

August 20th snapshot patched, not the -r 1.7
Michael
2018-08-20 18:32:03 UTC
Permalink
On 20/08/2018 19:14, Ingo Schwarze wrote:
>> There is a program - /usr/lib/nls/lsmle (just learned about it!)
> That's non-standard. The standard program for similar purposes is
> locale(1), though that usually won't report CODESET, but only
> LC_CTYPE.

p.s. aka FYI: AIX also has the program locale(1), but that gives a lot
less information, imho.

And, maybe also a bit misleading - at least for the ignorant. I would
have expected UTF-8, but instead, it uses EN_US and a symbolic link.

***@x064:[/data/prj/openbsd/mindrot/openssh-7.8.0.20]locale
LANG=EN_US
LC_COLLATE="EN_US"
LC_CTYPE="EN_US"
LC_MONETARY="EN_US"
LC_NUMERIC="EN_US"
LC_TIME="EN_US"
LC_MESSAGES="EN_US"
LC_ALL=

While the default language locale(1) is:

***@x066:[/data/prj/python/python3-3.8]locale
LANG=en_US
LC_COLLATE="en_US"
LC_CTYPE="en_US"
LC_MONETARY="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_MESSAGES="en_US"
LC_ALL=
Ingo Schwarze
2018-08-20 19:39:41 UTC
Permalink
Hi Michael,

Michael wrote on Mon, Aug 20, 2018 at 08:32:03PM +0200:

> p.s. aka FYI: AIX also has the program locale(1), but that gives
> a lot less information, imho.

Sure it has, it's POSIX, and sure it provides less info than you
have shown from the non-standard tool. But by definition, it is
unclear what the output of a non-standard tool may mean.

> And, maybe also a bit misleading - at least for the ignorant. I would
> have expected UTF-8, but instead, it uses EN_US and a symbolic link.
>
> ***@x064:[/data/prj/openbsd/mindrot/openssh-7.8.0.20]locale
> LANG=EN_US
> LC_COLLATE="EN_US"
> LC_CTYPE="EN_US"
> LC_MONETARY="EN_US"
> LC_NUMERIC="EN_US"
> LC_TIME="EN_US"
> LC_MESSAGES="EN_US"
> LC_ALL=
>
> While the default language locale(1) is:
>
> ***@x066:[/data/prj/python/python3-3.8]locale
> LANG=en_US
> LC_COLLATE="en_US"
> LC_CTYPE="en_US"
> LC_MONETARY="en_US"
> LC_NUMERIC="en_US"
> LC_TIME="en_US"
> LC_MESSAGES="en_US"
> LC_ALL=

Seems quite unusual indeed and hard to understand - but AIX is free
to call their locales however they want. Neither locale names nor
the return value from nl_langinfo(CODESET) are standardized.
According to POSIX, they need contain elements relating to languages,
territories, encodings, or even filenames, and the return value
from nl_langinfo(CODESET) need not match the LC_CTYPE variable.
AIX would be free to ask their users to specify "apples" or "oranges"
in LC_CTYPE and yet report back "bananas" from nl_langinfo(CODESET).
;-)

Yours,
Ingo
Michael
2018-08-21 07:57:31 UTC
Permalink
On 20/08/2018 21:39, Ingo Schwarze wrote:
> Hi Michael,
>
> Michael wrote on Mon, Aug 20, 2018 at 08:32:03PM +0200:
>
> Seems quite unusual indeed and hard to understand - but AIX is free
> to call their locales however they want. Neither locale names nor
> the return value from nl_langinfo(CODESET) are standardized.
> According to POSIX, they need contain elements relating to languages,
> territories, encodings, or even filenames, and the return value
> from nl_langinfo(CODESET) need not match the LC_CTYPE variable.
> AIX would be free to ask their users to specify "apples" or "oranges"
> in LC_CTYPE and yet report back "bananas" from nl_langinfo(CODESET).
> ;-)
All meant to by FYI - as AIX peeps as myself are often silent.
Many thanks for the responses and the patches!

Michael
>
> Yours,
> Ingo
Val Baranov
2018-08-20 20:12:13 UTC
Permalink
Ingo Schwarze wrote on Aug 20, 2018 at 1:15 PM +0500;

> While there is no need to cater for any potential locale that users might wilfully select, we should probably try to show complete messages to
> users who specifically select the POSIX locale.
>
> Admittedly, AIX is weird in calling ASCII "ISO8859-1", which is probably going to mean something different elsewhere. But given that it is very
> unlikely that anything another system calls ISO8859-1 is an unsafe (ASCII-incompatible or state-dependent) encoding, i'm proposing the
> following patch.

The patch has been applied - no error for UTF-8. Completed with all tests "make tests" - no errors on AIX 7.1.
Damien Miller
2018-08-21 02:04:41 UTC
Permalink
On Mon, 20 Aug 2018, Ingo Schwarze wrote:

> Hi,
>
> Michael Felt wrote on Mon, Aug 20, 2018 at 05:00:17PM +0200:
>
> > ./nl_langinfo
> > setlocale -> "C"
> > nl_langinfo -> "ISO8859-1"
>
> Thanks, that is helpful.
>
> So i think i was wrong and Damien was right. This means that
> OpenSSH returns truncated messages when non-ASCII bytes occur
> in them, even when the user requests LC_CTYPE=POSIX.
> That's not good.
>
> While there is no need to cater for any potential locale that users
> might wilfully select, we should probably try to show complete
> messages to users who specifically select the POSIX locale.
>
> Admittedly, AIX is weird in calling ASCII "ISO8859-1", which is
> probably going to mean something different elsewhere. But given
> that it is very unlikely that anything another system calls ISO8859-1
> is an unsafe (ASCII-incompatible or state-dependent) encoding, i'm
> proposing the following patch.
>
> I suggest adding some comments because otherwise, we will
> eventually forget where all these strings came from.
>
> OK?

ok, djm@ (I'd prefer the comment before the return statement, but up to you)

> Index: utf8.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/ssh/utf8.c,v
> retrieving revision 1.7
> diff -u -p -r1.7 utf8.c
> --- utf8.c 31 May 2017 09:15:42 -0000 1.7
> +++ utf8.c 20 Aug 2018 17:11:33 -0000
> @@ -51,9 +51,18 @@ dangerous_locale(void) {
> char *loc;
>
> loc = nl_langinfo(CODESET);
> - return strcmp(loc, "US-ASCII") != 0 && strcmp(loc, "UTF-8") != 0 &&
> - strcmp(loc, "ANSI_X3.4-1968") != 0 && strcmp(loc, "646") != 0 &&
> - strcmp(loc, "") != 0;
> + return strcmp(loc, "UTF-8") != 0 &&
> + strcmp(loc, "US-ASCII") != 0 &&
> +
> + /*
> + * What nl_langinfo(CODESET) returns for US-ASCII
> + * on various operating systems:
> + */
> +
> + strcmp(loc, "ANSI_X3.4-1968") != 0 && /* Linux */
> + strcmp(loc, "ISO8859-1") != 0 && /* AIX */
> + strcmp(loc, "646") != 0 && /* Solaris, NetBSD */
> + strcmp(loc, "") != 0; /* Solaris 6 */
> }
>
> static int
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-***@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
Ingo Schwarze
2018-08-21 14:05:46 UTC
Permalink
Hi Damien,

Damien Miller wrote on Tue, Aug 21, 2018 at 12:04:41PM +1000:

> ok, djm@

Thanks for checking, and thanks to Val and Michael for testing.
I just committed the patch to OpenBSD, others will likely take
care of merging it to -portable.

> (I'd prefer the comment before the return statement, but up to you)

Immediately before the return statement, it looked really confusing,
like:

/* ASCII on various systems ... blabla */
return UTF-8 ... blabla

So i moved it up a few more lines and appended it to the existing
comment, keeping the code concise and yet clearly explaining it.

Yours,
Ingo
Steffen Nurpmeso
2018-08-21 14:57:30 UTC
Permalink
Hello.

Ingo Schwarze wrote in <***@athene.usta.de>:
...
| /* ASCII on various systems ... blabla */
...
| return UTF-8 ... blabla
|
|So i moved it up a few more lines and appended it to the existing
|comment, keeping the code concise and yet clearly explaining it.

Don't be too serious about that, 'am being 100% sure you know, but
having been stung by "concise" (and because my MUA had to
implement n_iconv_name_is_ascii()) i want to point out that the
IANA character sets define more aliases for US-ASCII, already in
RFC 1345. Here in reverse MIME preference order:

static char const * const names[] = {"csASCII", "cp367", "IBM367", "us",
"ISO646-US", "ISO_646.irv:1991", "ANSI_X3.4-1986", "iso-ir-6",
"ANSI_X3.4-1968", "ASCII", "US-ASCII"};

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Ingo Schwarze
2018-08-21 15:24:25 UTC
Permalink
Hi Steffen,

Steffen Nurpmeso wrote on Tue, Aug 21, 2018 at 04:57:30PM +0200:

> Don't be too serious about that, 'am being 100% sure you know,

I did not.

> but having been stung by "concise" (and because my MUA had to
> implement n_iconv_name_is_ascii()) i want to point out that the
> IANA character sets define more aliases for US-ASCII, already in
> RFC 1345. Here in reverse MIME preference order:
>
> static char const * const names[] = {"csASCII", "cp367", "IBM367",
> "us", "ISO646-US", "ISO_646.irv:1991", "ANSI_X3.4-1986",
> "iso-ir-6", "ANSI_X3.4-1968", "ASCII", "US-ASCII"};

But as far as i know, nothing requires nl_langinfo(CODESET) to
adhere to RFC 1345, and as a matter of fact, on some systems,
it does not (Solaris, NetBSD). So even including the full list
you are providing above would be insufficient.

On the other hand, using the full list *in addition* to what's
actually required provides no benefit, but poses gratuitous
additional risk of misidentification, in particular with names
as generic as "us". We were just told that AIX returns en_US
for ASCII and EN_US for UTF-8 (or was it the other way round?
That's hard to remember). Who knows what other systems out
there might return "us" for?

Given the lack of standardization of nl_langinfo(3), adding the
return values that actually matter in practice, and nothing else,
seems like the way to go, in my opinion.

Yours,
Ingo
Michael
2018-08-21 16:35:26 UTC
Permalink
On 21/08/2018 17:24, Ingo Schwarze wrote:
> Hi Steffen,
>
> Steffen Nurpmeso wrote on Tue, Aug 21, 2018 at 04:57:30PM +0200:
>
>> Don't be too serious about that, 'am being 100% sure you know,
> I did not.
>
>> but having been stung by "concise" (and because my MUA had to
>> implement n_iconv_name_is_ascii()) i want to point out that the
>> IANA character sets define more aliases for US-ASCII, already in
>> RFC 1345. Here in reverse MIME preference order:
>>
>> static char const * const names[] = {"csASCII", "cp367", "IBM367",
>> "us", "ISO646-US", "ISO_646.irv:1991", "ANSI_X3.4-1986",
>> "iso-ir-6", "ANSI_X3.4-1968", "ASCII", "US-ASCII"};
> But as far as i know, nothing requires nl_langinfo(CODESET) to
> adhere to RFC 1345, and as a matter of fact, on some systems,
> it does not (Solaris, NetBSD). So even including the full list
> you are providing above would be insufficient.
>
> On the other hand, using the full list *in addition* to what's
> actually required provides no benefit, but poses gratuitous
> additional risk of misidentification, in particular with names
> as generic as "us". We were just told that AIX returns en_US
> for ASCII and EN_US for UTF-8 (or was it the other way round?
> That's hard to remember).
Actually, :p, en_US stands for iso-8859-1 :wink:
> Who knows what other systems out
> there might return "us" for?
>
> Given the lack of standardization of nl_langinfo(3), adding the
> return values that actually matter in practice, and nothing else,
> seems like the way to go, in my opinion.
>
> Yours,
> Ingo
Steffen Nurpmeso
2018-08-21 21:35:02 UTC
Permalink
Hello.

Ingo Schwarze wrote in <***@athene.usta.de>:
|Steffen Nurpmeso wrote on Tue, Aug 21, 2018 at 04:57:30PM +0200:
|
|> Don't be too serious about that, 'am being 100% sure you know,
|
|I did not.
|
|> but having been stung by "concise" (and because my MUA had to
|> implement n_iconv_name_is_ascii()) i want to point out that the
|> IANA character sets define more aliases for US-ASCII, already in
|> RFC 1345. Here in reverse MIME preference order:
|>
|> static char const * const names[] = {"csASCII", "cp367", "IBM367",
|> "us", "ISO646-US", "ISO_646.irv:1991", "ANSI_X3.4-1986",
|> "iso-ir-6", "ANSI_X3.4-1968", "ASCII", "US-ASCII"};
|
|But as far as i know, nothing requires nl_langinfo(CODESET) to
|adhere to RFC 1345, and as a matter of fact, on some systems,
|it does not (Solaris, NetBSD). So even including the full list
|you are providing above would be insufficient.
|
|On the other hand, using the full list *in addition* to what's
|actually required provides no benefit, but poses gratuitous
|additional risk of misidentification, in particular with names
|as generic as "us". We were just told that AIX returns en_US
|for ASCII and EN_US for UTF-8 (or was it the other way round?
|That's hard to remember). Who knows what other systems out
|there might return "us" for?
|
|Given the lack of standardization of nl_langinfo(3), adding the
|return values that actually matter in practice, and nothing else,
|seems like the way to go, in my opinion.

Of course; i have seen the actual commit in the meantime, sorry
for the noise.

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Val Baranov
2018-08-20 16:05:34 UTC
Permalink
> On 17 August 2018 at 10:16, Darren Tucker <dtucker at dtucker.net> wrote:
>> On 13 August 2018 at 15:06, Val Baranov <***@duke.edu> wrote:
>> [...]
>> test_utf8: ........................
>> regress/unittests/utf8/tests.c:48 test #25 "c_esc"
>> ASSERT_INT_EQ(len, wantlen) failed:
>> len = -1
>> wantlen = 5

> This boils down to meaning OpenSSH's smnprintf call failed for the string "\033x" instead of returning the expected escaped version "\\033x". > The code is in utf8.c but I am not sure why it failed.
> What's your locale set to?
>
> You can run the rest of the tests on your platform by running:
>
> TEST_SSH_UTF8=no make testst

The locale is:
LANG=en_US
LC_COLLATE="en_US"
LC_CTYPE="en_US"
LC_MONETARY="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_MESSAGES="en_US"
LC_ALL=

"TEST_SSH_UTF8=no make tests " command produced the same error.

./nl_langinfo
setlocale -> "C"
nl_langinfo -> "ISO8859-1"
Jeff Wieland
2018-08-17 15:21:39 UTC
Permalink
On SPARC Solaris 10, using Solaris' native OpenSSL and Solaris
Studio 12.2, I got the following errors:


run test agent-getpeereid.sh ...
ssh-add did not fail for nobody: 1 < 2
failed disallow agent attach from other uid
gmake[1]: *** [t-exec] Error 1
gmake[1]: Leaving directory
`/scratch/wieland/src/openssh/openssh-SNAP-20180817/regress'
gmake: *** [tests] Error 2

--
Jeff Wieland, UNIX/Network Systems Administrator
Purdue University IT Infrastructure Services UNIX Platforms
Darren Tucker
2018-08-17 17:45:14 UTC
Permalink
On 17 August 2018 at 08:21, Jeff Wieland <***@purdue.edu> wrote:
> On SPARC Solaris 10, using Solaris' native OpenSSL and Solaris
> Studio 12.2, I got the following errors:
>
>
> run test agent-getpeereid.sh ...
> ssh-add did not fail for nobody: 1 < 2

I'm not sure why this might be. It passes for me on Solaris 10 x86
with gcc. I suggest adding a "set -x" at the start of
agent-getpeereid.sh and running the test ("make tests
LTESTS=agent-getpeereid.sh SKIP_UNIT=1") and see what it's doing under
the covers.

--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Darren Tucker
2018-08-17 17:56:32 UTC
Permalink
On 17 August 2018 at 10:45, Darren Tucker <***@dtucker.net> wrote:
> On 17 August 2018 at 08:21, Jeff Wieland <***@purdue.edu> wrote:
>> On SPARC Solaris 10, using Solaris' native OpenSSL and Solaris
>> Studio 12.2, I got the following errors:
>>
>>
>> run test agent-getpeereid.sh ...
>> ssh-add did not fail for nobody: 1 < 2
>
> I'm not sure why this might be. It passes for me on Solaris 10 x86
> with gcc. I suggest adding a "set -x" at the start of
> agent-getpeereid.sh and running the test ("make tests
> LTESTS=agent-getpeereid.sh SKIP_UNIT=1") and see what it's doing under
> the covers.

Correction on the command: you'll need to also set SUDO:
SUDO=sudo make tests SKIP_UNIT=1 LTESTS=agent-getpeereid

For comparision here's the output from my system:

[***@sol10]$ SUDO=sudo make tests SKIP_UNIT=1 LTESTS=agent-getpeereid
[make output snipped]
run test agent-getpeereid.sh ...
++ tid='disallow agent attach from other uid'
++ UNPRIV=nobody
++ ASOCK=/home/dtucker/openssh/upstream/openssh/build/sol10/regress/agent
++ SSH_AUTH_SOCK=/nonexistent
++ config_defined HAVE_GETPEEREID HAVE_GETPEERUCRED HAVE_SO_PEERCRED
++ str=HAVE_GETPEEREID
++ test xHAVE_GETPEERUCRED '!=' x
++ str='HAVE_GETPEEREID|HAVE_GETPEERUCRED'
++ shift
++ test xHAVE_SO_PEERCRED '!=' x
++ str='HAVE_GETPEEREID|HAVE_GETPEERUCRED|HAVE_SO_PEERCRED'
++ shift
++ test x '!=' x
++ egrep '^#define.*(HAVE_GETPEEREID|HAVE_GETPEERUCRED|HAVE_SO_PEERCRED)'
/home/dtucker/openssh/upstream/openssh/build/sol10/config.h
++ :
++ case "x$SUDO" in
++ sudo=1
++ trace 'start agent'
++ start_debug_log start agent
++ echo 'trace: start' agent
++ echo 'trace: start' agent
++ echo 'trace: start' agent
++ '[' X = Xyes ']'
+++ /home/dtucker/openssh/upstream/openssh/build/sol10/ssh-agent -s -a
/home/dtucker/openssh/upstream/openssh/build/sol10/regress/agent
++ eval 'SSH_AUTH_SOCK=/home/dtucker/openssh/upstream/openssh/build/sol10/regress/agent;'
export 'SSH_AUTH_SOCK;' 'SSH_AGENT_PID=8814;' export 'SSH_AGENT_PID;'
echo Agent pid '8814;'
+++ SSH_AUTH_SOCK=/home/dtucker/openssh/upstream/openssh/build/sol10/regress/agent
+++ export SSH_AUTH_SOCK
+++ SSH_AGENT_PID=8814
+++ export SSH_AGENT_PID
+++ echo Agent pid 8814
++ r=0
++ '[' 0 -ne 0 ']'
++ chmod 644 /home/dtucker/openssh/upstream/openssh/build/sol10/regress/agent
++ /home/dtucker/openssh/upstream/openssh/build/sol10/ssh-add -l
++ r=1
++ '[' 1 -ne 1 ']'
++ test -z 1
++ sudo -S -u nobody
/home/dtucker/openssh/upstream/openssh/build/sol10/ssh-add -l
++ r=2
++ '[' 2 -lt 2 ']'
++ trace 'kill agent'
++ start_debug_log kill agent
++ echo 'trace: kill' agent
++ echo 'trace: kill' agent
++ echo 'trace: kill' agent
++ '[' X = Xyes ']'
++ /home/dtucker/openssh/upstream/openssh/build/sol10/ssh-agent -k
++ rm -f /home/dtucker/openssh/upstream/openssh/build/sol10/regress/agent
+ cleanup
+ '[' x '!=' x ']'
+ '[' x '!=' x ']'
+ stop_sshd
+ '[' -f /home/dtucker/openssh/upstream/openssh/build/sol10/regress/pidfile ']'
+ '[' 0 -eq 0 ']'
+ verbose ok disallow agent attach from other uid
+ start_debug_log ok disallow agent attach from other uid
+ echo 'trace: ok' disallow agent attach from other uid
+ echo 'trace: ok' disallow agent attach from other uid
+ echo 'trace: ok' disallow agent attach from other uid
+ '[' X '!=' Xyes ']'
+ echo ok disallow agent attach from other uid
ok disallow agent attach from other uid
+ exit 0
make[1]: Leaving directory `/home/dtucker/openssh/upstream/openssh/regress'
all tests passed


>
> --
> Darren Tucker (dtucker at dtucker.net)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
> Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.



--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Jakub Jelen
2018-08-25 10:07:26 UTC
Permalink
On Fri, 2018-08-17 at 10:56 -0700, Darren Tucker wrote:
> On 17 August 2018 at 10:45, Darren Tucker <***@dtucker.net>
> wrote:
> > On 17 August 2018 at 08:21, Jeff Wieland <***@purdue.edu>
> > wrote:
> > > On SPARC Solaris 10, using Solaris' native OpenSSL and Solaris
> > > Studio 12.2, I got the following errors:
> > >
> > >
> > > run test agent-getpeereid.sh ...
> > > ssh-add did not fail for nobody: 1 < 2
> >
> > I'm not sure why this might be. It passes for me on Solaris 10 x86
> > with gcc. I suggest adding a "set -x" at the start of
> > agent-getpeereid.sh and running the test ("make tests
> > LTESTS=agent-getpeereid.sh SKIP_UNIT=1") and see what it's doing
> > under
> > the covers.
>
> Correction on the command: you'll need to also set SUDO:
> SUDO=sudo make tests SKIP_UNIT=1 LTESTS=agent-getpeereid

Please, document these missing environment variables in the
README.regress file. Every time I search for their names and their
usage, I have to go through the Makefile.

I hope I covered all the missing in the attached patch, but feel free
to improve the patch or add more missing.


-----------------------------------------------------------------------
diff --git a/regress/README.regress b/regress/README.regress
index 86785501..aee3e3c2 100644
--- a/regress/README.regress
+++ b/regress/README.regress
@@ -33,6 +33,10 @@ TEST_SSH_SSH_CONFOPTS: Configuration directives to
be added to ssh_config
before running each test.
TEST_SSH_SSHD_CONFOPTS: Configuration directives to be added to
sshd_config
before running each test.
+SKIP_UNIT: Skip unit tests.
+USE_VALGRIND: Run the tests under valgrind memory checker.
+LTESTS: Space separated list of of tests (filenames without the .sh
extension)
+ to run.


Individual tests.
-----------------------------------------------------------------------
Thanks,
--
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.
Damien Miller
2018-08-18 08:43:55 UTC
Permalink
On Fri, 17 Aug 2018, Jeff Wieland wrote:

> On SPARC Solaris 10, using Solaris' native OpenSSL and Solaris
> Studio 12.2, I got the following errors:
>
>
> run test agent-getpeereid.sh ...
> ssh-add did not fail for nobody: 1 < 2
> failed disallow agent attach from other uid
> gmake[1]: *** [t-exec] Error 1
> gmake[1]: Leaving directory
> `/scratch/wieland/src/openssh/openssh-SNAP-20180817/regress'
> gmake: *** [tests] Error 2

This test can get confused if run on a filesystem mounted nosuid.

-d
Jeff Wieland
2018-08-23 16:29:23 UTC
Permalink
Darren Tucker wrote:
> On 17 August 2018 at 08:21, Jeff Wieland <***@purdue.edu> wrote:
>> On SPARC Solaris 10, using Solaris' native OpenSSL and Solaris
>> Studio 12.2, I got the following errors:
>>
>>
>> run test agent-getpeereid.sh ...
>> ssh-add did not fail for nobody: 1 < 2
> I'm not sure why this might be. It passes for me on Solaris 10 x86
> with gcc. I suggest adding a "set -x" at the start of
> agent-getpeereid.sh and running the test ("make tests
> LTESTS=agent-getpeereid.sh SKIP_UNIT=1") and see what it's doing under
> the covers.
>
> --
> Darren Tucker (dtucker at dtucker.net)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
> Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.

Sorry that I didn't get back to you until now.   The output from adding
the "set -x" is:

++tid='disallow agent attach from other uid'
++UNPRIV=nobody
++ASOCK=/scratch/wieland/src/openssh/openssh-SNAP-20180823/regress/agent
++SSH_AUTH_SOCK=/nonexistent
++config_defined HAVE_GETPEEREID HAVE_GETPEERUCRED HAVE_SO_PEERCRED
++str=HAVE_GETPEEREID
++test xHAVE_GETPEERUCRED '!=' x
++str='HAVE_GETPEEREID|HAVE_GETPEERUCRED'
++shift
++test xHAVE_SO_PEERCRED '!=' x
++str='HAVE_GETPEEREID|HAVE_GETPEERUCRED|HAVE_SO_PEERCRED'
++shift
++test x '!=' x
++egrep '^#define.*(HAVE_GETPEEREID|HAVE_GETPEERUCRED|HAVE_SO_PEERCRED)'
/scratch/wieland/src/openssh/openssh-SNAP-20180823/config.h
++:
++case "x$SUDO" in
++sudo=1
++trace 'start agent'
++start_debug_log start agent
++echo 'trace: start' agent
++echo 'trace: start' agent
++echo 'trace: start' agent
++'[' X = Xyes ']'
+++/scratch/wieland/src/openssh/openssh-SNAP-20180823/ssh-agent -s -a
/scratch/wieland/src/openssh/openssh-SNAP-20180823/regress/agent
++eval
'SSH_AUTH_SOCK=/scratch/wieland/src/openssh/openssh-SNAP-20180823/regress/agent;'
export 'SSH_AUTH_SOCK;' 'SSH_AGENT_PID=21638;' export 'SSH_AGENT_PID;' echo
Agent pid '21638;'
+++SSH_AUTH_SOCK=/scratch/wieland/src/openssh/openssh-SNAP-20180823/regress/agent
+++export SSH_AUTH_SOCK
+++SSH_AGENT_PID=21638
+++export SSH_AGENT_PID
+++echo Agent pid 21638
++r=0
++'[' 0 -ne 0 ']'
++chmod 644 /scratch/wieland/src/openssh/openssh-SNAP-20180823/regress/agent
++/scratch/wieland/src/openssh/openssh-SNAP-20180823/ssh-add -l
++r=1
++'[' 1 -ne 1 ']'
++test -z 1
++sudo -S -u nobody /scratch/wieland/src/openssh/openssh-SNAP-20180823/ssh-add -l
++r=1
++'[' 1 -lt 2 ']'
++fail 'ssh-add did not fail for nobody: 1 < 2'
++save_debug_log 'FAIL: ssh-add did not fail for nobody: 1 < 2'
++echo FAIL: ssh-add did not fail for nobody: 1 '<' 2
++echo FAIL: ssh-add did not fail for nobody: 1 '<' 2
++echo FAIL: ssh-add did not fail for nobody: 1 '<' 2
++cat /scratch/wieland/src/openssh/openssh-SNAP-20180823/regress/regress.log
++echo
++cat /scratch/wieland/src/openssh/openssh-SNAP-20180823/regress/ssh.log
++echo
++cat /scratch/wieland/src/openssh/openssh-SNAP-20180823/regress/sshd.log
++echo
++RESULT=1
++echo 'ssh-add did not fail for nobody: 1 < 2'
ssh-add did not fail for nobody: 1 < 2
++test x '!=' x
++trace 'kill agent'
++start_debug_log kill agent
++echo 'trace: kill' agent
++echo 'trace: kill' agent
++echo 'trace: kill' agent
++'[' X = Xyes ']'
++/scratch/wieland/src/openssh/openssh-SNAP-20180823/ssh-agent -k
++rm -f /scratch/wieland/src/openssh/openssh-SNAP-20180823/regress/agent


--
Jeff Wieland, UNIX/Network Systems Administrator
Purdue University IT Infrastructure Services UNIX Platforms
Jakub Jelen
2018-08-22 15:31:47 UTC
Permalink
On Fri, 2018-08-10 at 11:16 +1000, Damien Miller wrote:
> Hi,
>
> OpenSSH 7.8p1 is almost ready for release, so we would appreciate
> testing
> on as many platforms and systems as possible. This is a bugfix
> release.
>
> Snapshot releases for portable OpenSSH are available from
> http://www.mindrot.org/openssh_snap/
>
> The OpenBSD version is available in CVS HEAD:
> http://www.openbsd.org/anoncvs.html

During rebasing I noticed, there is wrong file path in the Makefile
target:

diff --git a/Makefile.in b/Makefile.in
index 591d1955..64c9c518 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -281,7 +281,7 @@ distclean: regressclean
rm -f regress/unittests/utf8/*.o
rm -f regress/unittests/utf8/test_utf8
rm -f regress/misc/kexfuzz/*.o
- rm -f regress/unittests/misc/kexfuzz
+ rm -f regress/misc/kexfuzz
(cd openbsd-compat && $(MAKE) distclean)
if test -d pkg ; then \
rm -fr pkg ; \

I will continue with the tests soon.

Regards,
--
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.
Continue reading on narkive:
Loading...