Problem
I am using Amazon Linux 2 EC2 instances. I needed to decrypt files that were encrypted using gpg 2.3, but amazon linux 2 only tracks repos up to 2.0.28 (including amazon linux extras). Decryption fails when using gpg 2.0.28 with this error:
gpg: [don't know]: partial length for invalid packet type 20
Interestingly, the key used for encryption was generated using gpg 2.0.28. But encryption itself took place using gpg 2.3, which creates this issue.
I found more recent gnupg packages on Fedora: https://fedora.pkgs.org/35/fedora-x86_64/gnupg2-2.3.2-2.fc35.x86_64.rpm.html. 2.3.2 for x86-64 might have worked, but I didn't test it because I can't afford to upgrade all of my existing dependencies (libgcrypt etc.).
My solution
Firstly, I am not highly experienced at building from source, especially in terms of best-practice or identifying common problems - I might be missing the obvious.
I built the gnupg statically from source by modifying an existing script I already use, that builds gnupg dynamically. I also download and compile gnupg dependencies from source in the original script, but they are linked against gcc dev tools at tracked versions. These dev tools would not support the upgraded versions of gnupg 2.3 dependencies:
checking whether C compiler works... no
configure: error: C compiler cannot create executables
At least, that appeared to be the issue.
With guidance from skeeto's build script (found here: https://github.com/skeeto/lean-static-gpg), I used the musl-gcc compiler wrapper, and linked against musl which was also built from source. This was a good way to isolate the dependencies and get them to successfully build against upgraded base C libraries. In fact, skeeto's script in itself would be a solution for someone with my problem, as long as none of the encrypted files use compression or any of the other features he omitted.
Adding compression
The static gpg 2.3.6 executable worked, but it didn't support any compression algorithms, which I needed. So I went back and built zlib and bzip2 from source as well, packing it into gpg using musl-gcc like the rest of the deps. bzip2 didn't have a configure file so I had to modify the Makefile to set CC and the destination prefix.
There are many more features and optional deps that I assume could be packed into the executable in this way.
Reason for posting
Is there an alternative/better solution? My solution worked for a very small set of use cases, but with 0 related issues online, I wonder if there is a more practical, extendable approach. If you wanted to add more of the optional features of gnupg, you'd likely have to compile even more low-level libraries in. Feels like a dependency and maintenance nightmare.
This was also my first exposure to musl. It worked and was interesting to learn about, but is it anyone else's first choice?
