Checking compatibility between configure.sh and gnu configure
After many years of sticking with an older copy of dropbear and after several months of being in the macos beta program (which on EVERY SINGLE FREAKING UPDATE overwrites the config files in /etc/ssh regardless of any local customisations anyone might put into ssh_config & sshd_config), I finally decided that I’d grab a newer copy and make a more determined attempt at getting it to actually build on my pile of hardware.
Problem: modern versions of dropbear use GNU c*nf*g*r*, and to add insult to injury don’t actually use c*nf*g*r* but use GNU autoconf (which generated the configure file, which is then used to generate, as is traditional, binaries for both Redhat & Debian) and I, as a matter of policy, try my damnest to keep that particular pile of cruft off my machines.
So what to do? configure.sh was written to mimic the published interface of GNU c*nf*g*r* so that it could theoretically be used to generate makefiles from GNU
.in files, but I’d never actually tested it out. But here was an opportunity, and an opportunity that carried most of its dependencies along with it (Tommath & Tomcrypt; the toplevel
Makefile.in has hooks in it to use external copies of these libraries, but it was easy to build a
configure.sh that told the makefile to use the internal ones) so I sat down for a couple of hours and worked on a configurator that would look for the proper things to build on a Centos 7 machine.
Which finally “worked” (generated a dhclient that I could use to ssh into localhost; The first dropbear is going to be on a machine that’s inside my local firewall so if it leaves any horrible gaping security holes floating around (will clang optimize out
memset(,0,)? Let’s not test that in an environment that the script kiddies have access to) I’ll have a chance to find them before anyone else), which means I actually have more of a chance of being able to take more recent software and getting it to work on machines that don’t run Redhat or Debian.