Dropbear Latest on IRIX 6.5.30 - Problems
Greetings, I'm working with a friend of mine to port modern software to IRIX 6.5.30, and since OpenSSH is... very difficult to compile on IRIX at this point, we're hoping to use Dropbear as a good alternative. Unfortunately, we're not getting farther than the configure stage: Here's the config.log from GCC 4.7.3: https://pastebin.com/ZDftG1xa We also have tried the native cc and they choke here: gmake -j4 Creating default_options_guard.h Unknown flag: E gmake: *** [default_options_guard.h] Error 2 Unfortunately we're not familiar with the build system for Dropbear, so maybe we're doing something wrong? I've tried searching the mailing lists for info on IRIX compliation but I've not seen anything super recent. Best Regards, Kazuo K.
Update: Bundled Libtommcrypt broken on IRIX
Hi guys, Was able to get past that point with the libtommcrypt/libtommath from their website. It's working fine here. I guess time to update the bundle. Now to finish compilation (Slow build system to avoid too much noise/heat) -Kazuo
Update 2: Bundled Libtommcrypt broken on IRIX
Well, I was able to confirm this is a bug specific to MIPSPro, not to GCC, and is upstream with libtommcrypt. I will stop bothering you guys about this. Thanks anyways.
SIGCLD issues with dropbear server on IRIX 6.5.x
Hello, I've recently compiled dropbear 2019-78 as most people here are aware from my mailing list messages. I am updating that a build with GCC was successful, but there appears to be a problem with how dropbear is handing SIGCLD on IRIX, causing forked processes to hang. https://pastebin.com/04v74Yt5 Here is the output of attaching par (IRIX's version of truss) to the PID, then trying to logout of the session, which hangs the ssh client and that particular process of the server. I have to issue a sigkill to the process to stop it on the server side. Additionally, I'd like to report a small patch needed to fix IOV_MAX for IRIX in netio.c: #ifndef IOV_MAX #if defined(__CYGWIN__) && !defined(UIO_MAXIOV) #define IOV_MAX 1024 #elif defined(__sgi) #define IOV_MAX 512 #else #define IOV_MAX UIO_MAXIOV The elif and __sgi macro had to be added. This will fix it for both mipspro and gcc. I've also confirmed with the libtom upstream that the version of libtomcrypt that I reported in my earlier messages isn't exhibiting that bug; so if someone could give insight how to fix this: https://pastebin.com/gnGxGmZH then a build with MIPSPro may finally be possible. Thank you very much. - Kazuo Kuroi
IRIX/MIPSPro patches for Dropbear 2019.78
Hi guys, Finally worked with another user on the forums of irixnet.org and we got all of the compilation issues on IRIX fixed, including the reported SIGCLD issues Here's our patch for it: http://irix.cc/raion/patches/dropbear-2019-irix.patch I realize this isn't the most quality patch or best hack in the industry, so please be kind. If we need to explain anything, let us know. I hope this can be upstreamed, if Matt and the other users are still working on dropbear? -Kazuo Kuroi
Re: Question: Timeout of dropbear
Hi Yuhua, Dropbear supports an Idle timeout as StackExchange mentions here: https://unix.stackexchange.com/questions/183414/how-to-specify-connecttimeout-for-dropbear I do not know if it can do it otherwise. An idle timeout checks for lack of activity on the client end, and automatically disconnects it. If you have trouble understanding any messages written here, I do speak some Han Chinese, so I can probably translate the gist for you. Best, Kaz Kuroi On 10/14/2020 12:15 AM, 赵玉华 wrote: Hello,Does dropbear support timeout? For example, When a connection lasts for a certain time(timeout), server will drop this connection. If support, please tell me how to configure this property. Thanks Yuhua
Dropbear Compilation on IRIX 6.5 broken again (2020.80)
Hi folks,
MIPSPro 7.4.4m on IRIX doesn't like svr-chansession.c again:
cc-1029 c99: ERROR File = svr-chansession.c, Line = 696
An expression is expected at this point.
chansess->original_command = chansess->cmd ? :
m_strdup("");
^
cc-1053 c99: ERROR File = svr-chansession.c, Line = 696
A colon is expected at this point.
chansess->original_command = chansess->cmd ? :
m_strdup("");
^
2 errors detected in the compilation of "svr-chansession.c".
make: *** [svr-chansession.o] Error 2
make: *** Waiting for unfinished jobs
I'm not sure how to exactly fix that, if anyone has any suggestions I
can try that would be helpful, otherwise I can give access to a box if
needed!
Thanks as always for keeping these changes upstream.
There's also a minor issue of the build system setting inappropriate
flags for MIPSPro, such as -Wextra and -Wsystem-headers and such. I can
work with someone to add a definition for MIPSPro to set the CFLAGS
properly, I have a complete list around here somewhere. For now I just
deleted those CFLAGS.
Best Regards,
Kazuo Kuroi
Re: Tru64 configure issues
Hey Larkin, Hmm, this is a bit weird, but since Matt seems busy these days, I'll see what I can to do help someone else interested in Dropbear. This is all my own cursory, 5 minute check over the problem: Firstly, to disable PIE since you don't need it, pass --disable-harden to the configure script. The problematic part of the configure script is between lines 3983 and 4028, so commenting that out could temporarily at least get your configure going. If that still breaks zlib, you should be able to still build dropbear without zlib -- try passing --disable-zlib. Worst case, you can just add -lz manually to the makefile. As for correcting the issues permanently, there's a lot of minor issues in dropbear that are caused by the gnu autoconf and intermediate makefiles assuming many compilers support GCCisms, and there's not always good workarounds. You can refer to my old fix here for examples of potential issues: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2021q2/002294.html I have a lot of other patches that may prove beneficial. I'm not super familiar with the ins and outs of autoconf, but this should fix the build for you at least for now. If you're interested, I've considered making a POSIX Make fork of dropbear and related utilities that should prove easier for people on niche UNIX systems to build Dropbear. If you're interested, you can be a tester. I have people interested with HP-UX, IRIX (me lawl) and Unixware systems, so having a Tru64 tester would be beneficial. If this doesn't fix it, you'll need to dive deep into the macro soup that is autoconf, and that's something I'm not quite good at myself. Let me know if cutting out that bit fixes it for both, if it doesn't, then I can probably try to find it elsewhere. -- Kaz Kuroi On 6/4/2021 5:15 PM, Larkin Nickle wrote: On Tru64 5.1B with the Compaq C compiler, configure fails when finding zlib because multiple incompatible flags are added to CFLAGS. It appears the tests for these flags are passing even though the compiler doesn't actually support them. e.g. configure: Checking if compiler 'cc' supports -Wno-pointer-sign configure: Setting -Wno-pointer-sign configure: Checking if compiler 'cc' supports -fno-strict-overflow configure: Setting -fno-strict-overflow configure: Checking for available hardened build flags: configure: Setting -fPIE However, the zlib check fails due to: configure:3323: cc -o conftest -g -Wno-pointer-sign -fno-strict-overflow -fPIE -pie conftest.c >&5 ld: Invalid flag usage: Wno-pointer-sign, -Wx,-option must appear after -_SYSTYPE_SVR4 If the check for `-Wno-pointer-sign` is modified so that it doesn't actually get added to CFLAGS, then the zlib check fails as `-fno-strict-overflow` isn't supported. configure:4845: checking for deflate in -lz configure:4870: cc -o conftest -g -fno-strict-overflow -fPIE -fstack-protector-strong -D_FORTIFY_SOURCE=2 -mfunction-return=thunk -mindirect-branch=thunk -I/usr/util/include -L/usr/util/lib conftest.c -lz >&5 ld: -fno-strict-overflow: Unknown flag Larkin
Re: multiuser disabled - fail more gracefully
Hello Geoff,
That's a good suggestion. but I suggest that if your code can't run on
UNIX platforms that it would need an include guard against it. Matt has
taken a lot of time to ensure this not only runs on proprietary old C
compilers, but also on older OSes where OpenSSH is not a good option.
I only express personal hesitancy here because I had to, along with
another dev, meddle greatly in svr-chansession to allow it to run on
IRIX properly - and I'm mildly concerned your proposed change could
introduce linuxisms if it's not include guarded.
I would thus ask that any changes are first included on a Linux include
guard, and then we could test it on other platforms like IRIX or AIX
before we remove it.
Just my .02 as the sorta-kinda maintainer for IRIX.
- Kaz Kuroi
On 3/9/2021 5:18 AM, Geoff Winkless wrote:
Hi
I appreciate that there's an compile-time option
DROPBEAR_SVR_MULTIUSER=0 to skip the setuid/gid sections, but can I
make a humble suggestion that we fail gracefully if someone* runs a
dropbear that _doesn't_ have that option configured on a linux kernel
that's compiled single-user.
*Not me, of course, I would obviously never do anything that stupid...
The idea being, if you're running as root and logging in as root, it
shouldn't matter if the setuid stuff fails, so for example In
svr-chansession.c, something like:
/* We can only change uid/gid as root ... */
if (getuid() == 0) {
-if ((setgid(ses.authstate.pw_gid) < 0) ||
+if ((setgid(ses.authstate.pw_gid) < 0 &&
ses.authstate.pw_uid != 0) ||
(initgroups(ses.authstate.pw_name,
ses.authstate.pw_gid) < 0)) {
dropbear_exit("Error changing user group");
}
-if (setuid(ses.authstate.pw_uid) < 0 &&
ses.authstate.pw_uid != 0) {
+if (setuid(ses.authstate.pw_uid) < 0 &&
ses.authstate.pw_uid != 0) {
dropbear_exit("Error changing user");
}
} else {
There are a few other places (probably everywhere where SVR_MULTIUSER
is checked, I suppose) where the same principle could be applied.
Geoff
Fixing build flags for MIPSPro
Greetings Matt et al, I've finally gotten around to figuring out ways to guard the makefile_include.mk files for libtommath and libtomcrypt that's distributed by you guys with Dropbear to fix the last few build errors. Here's the patch: https://pastebin.com/TnSgHae9 Summary of changes: 1. Broke out a few loops that caught MIPSPro with -W flags it doesn't support into their own and guarded them with the GNUC macro. 2. LTM_CFLAGS required a major refactor, and in a sloppy display, the Makefile.in had an LTM_CFLAGS while most of those are in the include file instead. 3. Had to refactor the NO_ADDTL_WARNINGS loop to capture the same -W flags and combined it with some of the previously separate ones. I'm aware this itself is a bit of a hack and perhaps a little sloppy, but I would really really like to not have to go in and delete those flags every time an update comes out. This hopefully explains the problem spots, and maybe we can come up with a better method for reliable detection of the compiler's capabilities? Otherwise, I'll keep trying to find something that works - it doesn't seem to be picking up "sgi" or "__sgi" (gnu make, at least isn't) and ignoring those guards, it's just going ahead and passing them in. If someone has an alternative suggestion on how to fix this, then I am open to it. Best Regards, Kaz Kuroi
