Following all the recent discussion about Segwit and Bech32, I felt the urge to have some fun. I happily put together
Core’s secp256k1 and
luke-jr’s libbase58 (plus
sipa’s reference bech32) to whip up a trivial Segwit bulk address generator—which of course, just
had to grow a simple regex bruteforce vanity function:
Segwit addresses are sexy! Pleased with my new toy, I grabbed my little C file plus its few dependencies, and catapaulted them to an airgap Unix machine. It would be so nice to let it grind away on some spiffy long-term tip addresses.
No, wait: secp256k1 and libbase58 both use autoreconf in their build systems. Sigh. Download GNU autoconf and its signature, load ’em into the catapault, and let fly across the airgap. ./configure. Easy, right?
checking for GNU M4 that supports accurate traces... configure: error: no acceptable m4 could be found in $PATH.
GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended.
GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
Sigh. So much for a way to relax and unwind.
My system has an M4, but not GNU M4. More downloading. Ready the catapault
again. It is running out of fuel—actually, it’s not a catapault: It’s a magnetic railgun. I take my airgap seriously.
configure: error: perl is not found
At this point, I gave up and hacked together some ersatz—with OpenSSL’s[1] libcrypto, for secp256k1 and bignums (base58). Of course, I still want to use Core’s code on machines which have autoreconf. Thus now, my neat little C file is a mess of #ifdefs—plus a few
ad hoc extern declarations to another C file, where I put my OpenSSL glue and my quicky little base58check encoder.
Then, I wrote a set of automatic runtime self-tests to make sure this bucket of bolts gives
exactly the same observable behavior in both configurations.
So—is there any reasonable way to get this stuff built without autoreconf? It’s an absurdly horrid “portability” fix, if
it gives your project a build-time dependency on GNU M4, Perl (!!!), and who knows what hundred other packages in the spiralling dependency chain. This would be inconvenient in ordinary circumstances. It can be much worse for software expected to be used in a security-critical context, implying an airgapped machine with the minimum possible junk installed on it. Seriously—I use the kernel’s virtual terminals there, because I reasonably distrust Xorg, window managers, toolkit libraries.... I was exaggerating about the railgun; I am not exaggerating about shell job control and my trusty old nvi.
Thanks for any reasonable[2] suggestions.
1. Yes, I know that OpenSSL’s build system
directly uses Perl. My platform’s distributor runs all that Perl stuff as a sort of preprocessing step, and imports the results into a vendor directory in the source tree. It is unfortunate that that piece of bugware because such a ubiquitous dependency, though this is slowly changing.
2. Please, nobody say “just use Linux”. That would sound exactly to me as “just use Microsoft” would sound to you.