To reproduce: # at now at> date date date at> ^D Rollback to 7.9 fix this.
Created attachment 3267 [details] Config from Solaris 11 x86 for comparison. I was not able to reproduce on either Solaris 10 or 11 (both x86). Could you please provide more information about your system (version, architecture, patches) and attach the config.h file and output from configure? I am attaching config.h from mine for comparison.
Created attachment 3268 [details] Config from Solaris 10 x86 for comparison
(In reply to Darren Tucker from comment #1) > Created attachment 3267 [details] > Config from Solaris 11 x86 for comparison. > > I was not able to reproduce on either Solaris 10 or 11 (both x86). > Could you please provide more information about your system > (version, architecture, patches) and attach the config.h file and > output from configure? I am attaching config.h from mine for > comparison. It's independent from architecture, occurs on both amd64 and SPARCv9 (SunFire v490). Solaris 10 1/13 with latest patchsets (kernel Generic_150401-64 and Generic_150400-64). OS shell in all cases are bash v4.
Also - all systems runs on bare metal (no virtual machines) and, as I've told, 7.9p1 runs without any issues with same configuration.
Created attachment 3270 [details] Config from Solaris 10 amd64 openssh 8.0 This is 8.0 config.h on amd64.
Created attachment 3271 [details] Config from Solaris 10 amd64 openssh 7.9
Just tried bash 4.4 (on a VM) and couldn't reproduce it either. Comparing your config and mine, I see a number of differences due to the openssl version (which is probably not significant) and a few things that are likely due to configure flags. I think you have --with-pam, --with-sandbox=solaris and --with-solaris-privs. Are there any others?
There is one same config line on all platforms (both 7.9 and 8.0): # 64 bit LibreSSL ./configure --with-privsep-user=sshd --with-sandbox=solaris --with-solaris-privs --with-pam --with-pie --with-ssl-dir=/usr/local 'CFLAGS=-O3 -m64 -mtune=native' 'LDFLAGS=-m64'
Both uses LibreSSL right now. I see no dependencies from openssl/libressl - issue exists whenever used crypto library.
I've built as close to your config as I can and not been able to reproduce this (the VM is 32bit only, and I don't have access to current Solaris patches). Are the working 7.9p1 and non-working 8.0p1 built with exactly the same compiler? There's another bug about Solaris terminal handling (https://bugzilla.mindrot.org/show_bug.cgi?id=2945). That change is not in 8.0p1, but it can apparently be triggered by the presence (or not) of compiler flags.
(In reply to Darren Tucker from comment #10) > I've built as close to your config as I can and not been able to > reproduce this (the VM is 32bit only, and I don't have access to > current Solaris patches). Im using only bare-metal systems. > > Are the working 7.9p1 and non-working 8.0p1 built with exactly the > same compiler? There's another bug about Solaris terminal handling > (https://bugzilla.mindrot.org/show_bug.cgi?id=2945). That change is > not in 8.0p1, but it can apparently be triggered by the presence (or > not) of compiler flags. Exactly the same compiler (GCC 5.5 built from source).
(In reply to Yuri Voinov from comment #11) [...] > Exactly the same compiler (GCC 5.5 built from source). did you explicitly set $CC? one thing that did change between 7.9p1 and 8.0p1 is that configure will now check for "cc" before "gcc": https://github.com/openssh/openssh-portable/commit/c90a7928
(In reply to Darren Tucker from comment #12) > (In reply to Yuri Voinov from comment #11) > [...] > > Exactly the same compiler (GCC 5.5 built from source). > > did you explicitly set $CC? one thing that did change between 7.9p1 > and 8.0p1 is that configure will now check for "cc" before "gcc": > https://github.com/openssh/openssh-portable/commit/c90a7928 Nop. I see no one reason to change basics. This make difficult to reproduce issues and find problems. Im sure configure found gcc first (before Oracle Developer Studio cc) due to PATH (which is same like before).
(In reply to Yuri Voinov from comment #13) [...] > Im sure configure found gcc first (before Oracle Developer Studio > cc) due to PATH (which is same like before). That's not what it does, it'll search the entire path for cc, and only look for gcc if the former is not found. $ ln -s /usr/bin/gcc ~/bin/gcc $ export PATH=~/bin:$PATH $ which cc gcc /usr/bin/cc /home/dtucker/bin/gcc $ ./configure checking for cc... cc [...] Please compare the output from ./configure between openssh versions.
A good theory should explain everything. Suppose that 8.0 picks up the wrong compiler. How can this explain the fact that the terminal does not work normally in 8.0 and works in 7.9? I can unlink /bin/cc and remove it from search path. However, this is not a good workaround, is it? Even assuming that the matter is in the compiler. In principle, I can provide root access to my two Solaris servers - SPARС and amd64. To determine and solve issue. As I understand the problem, at the moment it can neither be reproduced, nor even detected. Well, I can provide the equipment on which the problem is reproduced.
Let's look to my setup: # which cc gcc /bin/cc /opt/csw/bin/gcc # ls -al /bin/cc lrwxrwxrwx 1 root root 31 Sep 5 2017 /bin/cc -> /opt/developerstudio12.6/bin/cc Even if picked /bin/cc - Studio 12.6 is standard C compiler and should work as good as GCC/Clang at least. So now I need to set the СС variable? Because the configuration is not able to determine the correct compiler in the system?
Anyway, ever if it true and configure picked up cc - DevStudio 12.6 fully compatible with GCC 5.5, on compiler and standard libraries level. And I can't understand, how it can break basic terminal functionality - console input/output.
(In reply to Yuri Voinov from comment #17) > Anyway, ever if it true and configure picked up cc - DevStudio 12.6 > fully compatible with GCC 5.5, on compiler and standard libraries > level. And I can't understand, how it can break basic terminal > functionality - console input/output. The bug I linked to (bug#2945) describes how the Solaris libc terminal setup varies depending on which XPG version it's compiling for, which can result in sshd pushing a second instance of some STREAMS modules. Anyway, you can test this theory by compiling 8.0p1 with the gcc the you probably compiled 7.9p1 with.
Created attachment 3272 [details] Diff between configure.log.79 and configure.log.80 Shit. Fk. Why 8.0 search cc first?! Anyway, what about compatibility?
Without explicity specified CC environment variable it is bad idea to make any assumptions and assumptions about compilers, IMHO. In system can be installed more than one compiler (by any reason). /bin/cc usually symbolic link to any compiler, it's not compiler itself. Correct?
It seems to me that it is generally advisable for compilers to ask who they are, and not just to look at names and symbolic links. For example, looking in -V output.
Just for example: # /bin/cc -V cc: Studio 12.6 Sun C 5.15 SunOS_i386 152882-02 2018/08/09 # gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/csw/libexec/gcc/i386-pc-solaris2.10/5.5.0/lto-wrapper Target: i386-pc-solaris2.10 Configured with: ./configure --prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin --sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec --datadir=/opt/csw/share --sysconfdir=/etc/opt/csw --sharedstatedir=/opt/csw/share --localstatedir=/var/opt/csw --libdir=/opt/csw/lib --infodir=/opt/csw/share/info --includedir=/opt/csw/include --mandir=/opt/csw/share/man --enable-cloog-backend=isl --enable-java-awt=xlib --enable-languages=c,c++ --enable-libada --enable-libssp --enable-nls --enable-objc-gc --enable-threads=posix --program-suffix=-5.5 --with-cloog=/opt/csw --with-gmp=/opt/csw --with-included-gettext --with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-libiconv-prefix=/opt/csw --with-mpfr=/opt/csw --with-ppl=/opt/csw --with-system-zlib=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas --with-ar=/usr/ccs/bin/ar Thread model: posix gcc version 5.5.0 (GCC) It will trivial script block to differentiate compilers and prevent such issues in the future.
(In reply to Yuri Voinov from comment #19) Please keep it polite. > Created attachment 3272 [details] > Why 8.0 search cc first?! Because we had instances where gcc did the wrong thing but the system cc didn't and we thought it should use the system one unless told otherwise by $CC. configure's preference of gcc is a gnuism that probably made sense when system 'cc' was a pre-ansi compiler but those days are gone. > Anyway, what about compatibility? OpenSSH should work with any ANSI C compiler, barring bugs. In this specific case it looks like it's sshd not handling the difference due to the newer XPG behaviour. There's a patch in bug#2945 (https://bugzilla.mindrot.org/attachment.cgi?id=3248) which should fix it however that did not make 8.0 due to insufficient testing. Does it resolve the problem for you? (In reply to Yuri Voinov from comment #20) > Without explicity specified CC environment variable it is bad idea > to make any assumptions and assumptions about compilers, IMHO. (In reply to Yuri Voinov from comment #21) > It seems to me that it is generally advisable for compilers to ask > who they are, and not just to look at names and symbolic links. configure is not making assumptions about the compiler based on its binary name, or at least none that are significant in this case. The tirggering behaviour was a difference in the default xpg version, which based on the comments in bug#2945 could just have easily been triggered by a newer version of gcc. > For example, looking in -V output. It does in fact do this for some things where necessary, however maintaining the mapping of returned version to inferred behaviour is fragile. You're better off explicitly testing for the thing you want where that's possible (see the OSSH_CHECK_CFLAG_COMPILE macro for an example). Anyway, does the patch in bug#2945 fix it when compiled with your cc?
> > Anyway, does the patch in bug#2945 fix it when compiled with your cc? Seems it fixed issue. Just tested.
thanks for confirming, I've committed the patch and it'll be in the next release.
closing resolved bugs as of 8.6p1 release