Loading...
 

shimpsblog [en]

English blog at blog.shimps.org

Compiling GnuPG IX: Dependencies II

fmg Saturday March 22, 2025

Situation

Last time we compiled the libraries and GnuPG itself by invoking the classic method ./configure, make and make install with an additional configure option. That resulted in a first success. Now we try a different method by using a different makefile.

Installation destination path

This time we choose the relative installation path native and the absolute path /tmp/canary/native.

Copy to clipboard
$ pwd /tmp/canary/compile/gnupg-2.5.5 $ mkdir /tmp/canary/native

Compiling

Using the speedo.mk makefile it is possible to utilize the shipped all inclusive option with the make target native. The needed libraries will be downloaded and compiled by the makefile. There is no need to resolve dependency conflicts manually. But the build environment needs the Debian package patchelf to be installed. This tool helps to generate a more portable version of the binaries.

Copy to clipboard
make -f build-aux/speedo.mk native make -f build-aux/speedo.mk install SYSROOT=/tmp/canary/native

The smoke test

Copy to clipboard
$ /tmp/canary/native/bin/gpg --version gpg (GnuPG) 2.5.5 libgcrypt 1.11.0 Copyright (C) 2025 g10 Code GmbH License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/alice/.gnupg Supported algorithms: Pubkey: RSA, Kyber, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB

The environment variable LD_LIBRARY_PATH is not needed. The information about the location of libraries is taken from a configuration file which is installed next to the gpg binary.

Copy to clipboard
$ grep rootdir /tmp/canary/native/bin/gpgconf.ctl rootdir = /tmp/canary/native

The binaries are almost out of the box portable. When you move everything from /tmp/canary/native/* to another path /tmp/newlocation it should be sufficient to adjust the rootdir line in the file gpgconf.ctl to rootdir = /tmp/newlocation.

Copy to clipboard
mkdir /tmp/newlocation mv /tmp/canary/native/* /tmp/newlocation sed -i -e 's/tmp\/canary\/native/tmp\/newlocation/' \\ /tmp/newlocation/bin/gpgconf.ctl


To be continued...

Compiling GnuPG VIII: Dependencies I

fmg Thursday March 20, 2025

Situation

Last time we observed that the simple approach is not sufficient to compile GnuPG developer version 2.5 on a Debian bookworm or Devuan daedalus system. This is due to the fact that this version needs more recent versions of libraries than provided by the distribution. The libraries themselves are available and can be downloaded from the GnuPG project, but we need to make them visible where and when they are needed.

Installation destination path

Whenever a piece of software is compiled and ready to be used, it should be installed to a dedicated location. Since we do not want to interfere with the distribution setup we choose the relative installation path install and the absolute path will result into /tmp/canary/install. Remember from last time where we are and create the chosen destination:

Copy to clipboard
$ pwd /tmp/canary/compile/gnupg-2.5.5 $ mkdir /tmp/canary/install

Configuration with prefix

libassuan
Copy to clipboard
cd ../libassuan-3.0.2 ./configure --prefix="/tmp/canary/install" make make install
libgpg-error
Copy to clipboard
cd ../libgpg-error-1.51 ./configure --prefix="/tmp/canary/install" make make install

With this-+libgpg-error+- library we can compile libgcrypt.

libgcrypt-1.11.0
Copy to clipboard
cd ../libgcrypt-1.11.0 ./configure --prefix="/tmp/canary/install" make make install

Now all missing parts from the gnupg configuration feedback are available.

gnupg I
Copy to clipboard
cd ../gnupg-2.5.5 ./configure --prefix="/tmp/canary/install" echo "There is a new problem"

There is another library missing: libksba.

Copy to clipboard
configure: *** *** You need libksba to build this program. *** This library is for example available at *** https://gnupg.org/ftp/gcrypt/libksba/ *** (at least version 1.6.3 using API 1 is required). ***

The required version 1.6.3 is provided by the distribution package libksba-dev but since we changed the configuration prefix it is not found anymore. This is odd. This does not happen in a similar situation with npth later. We need to either fine tune the configuration or build a self-contained environment. We chose the latter one:

libksba
Copy to clipboard
cd ../libksba-1.6.7 ./configure --prefix="/tmp/canary/install" make make install
gnupg II
Copy to clipboard
cd ../gnupg-2.5.5 ./configure --prefix="/tmp/canary/install" echo "There is another new problem"

Again there is a library missing: npth.:

Copy to clipboard
configure: *** *** It is now required to build with support for the *** New Portable Threads Library (nPth). Please install this *** library first. The library is for example available at *** https://gnupg.org/ftp/gcrypt/npth/ *** (at least version 1.2 (API 1) is required). ***

The configuration would be fine with the distribution package libnpth0-dev installed, but we compile from the sources.

npth
Copy to clipboard
cd ../npth-1.8 ./configure --prefix="/tmp/canary/install" make make install

Back to the main software again...

gnupg III
Copy to clipboard
cd ../gnupg-2.5.5 ./configure --prefix="/tmp/canary/install" make make install

The smoke test

Copy to clipboard
$ /tmp/canary/install/bin/gpg --version /tmp/canary/install/bin/gpg: error while loading shared libraries: libassuan.so.9: cannot open shared object file: No such file or directory

This is not the intended behaviour.

Copy to clipboard
$ LD_LIBRARY_PATH="/tmp/canary/install/lib" /tmp/canary/install/bin/gpg --version gpg (GnuPG) 2.5.5 libgcrypt 1.11.0 Copyright (C) 2025 g10 Code GmbH License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/alice/.gnupg Supported algorithms: Pubkey: RSA, Kyber, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB

This is a first success. But there is a lot of fine tuning left to be done.

To be continued...

Compiling GnuPG VII: First Steps

fmg Tuesday March 18, 2025

Situation

Last time I explained merging the pull request. This time we do the first compiling experiments. There are two scripts from the Codeberg diy-gnupg repository involved: fetch-source.sh and unpack-source.sh, both in the folder self-compile/bin/. Run them and swith to /tmp/canary/compile as working directory. There are several folders from the extracted tarballs:

gnupg-2.5.5
libassuan-3.0.2
libgcrypt-1.11.0
libgpg-error-1.51
libksba-1.6.7
npth-1.8

Simple Configuration

npth
Copy to clipboard
cd npth-1.8 ./configure make
libassuan
Copy to clipboard
cd ../libassuan-3.0.2 ./configure make
libksba
Copy to clipboard
cd ../libksba-1.6.7 ./configure make
libgpg-error
Copy to clipboard
cd ../libgpg-error-1.51 ./configure make
libgcrypt-1.11.0
Copy to clipboard
cd ../libgcrypt-1.11.0 ./configure echo "There is a problem"

We cannot continue with make because Debian bookworm and Devuan daedalus ship the package libgpg-error-dev with version 1.46 but a modern one is needed:

Copy to clipboard
checking for GPG Error - version >= 1.49... no configure: error: libgpg-error is needed.
gnupg
Copy to clipboard
cd ../gnupg-2.5.5 ./configure echo "There is a problem"

The distribution package libgcrypt20-dev contains version 1.10.1 and libassuan-dev contains version 2.5.5 which are additional problems. Something we don't see yet is a problem with npth:

Copy to clipboard
configure: *** *** You need libgpg-error to build this program. ** This library is for example available at *** https://gnupg.org/ftp/gcrypt/gpgrt *** (at least version 1.51 is required.) *** configure: *** *** You need libgcrypt to build this program. ** This library is for example available at *** https://gnupg.org/ftp/gcrypt/libgcrypt/ *** (at least version 1.11.0 (API 1) is required.) *** configure: *** *** You need libassuan to build this program. *** This library is for example available at *** https://gnupg.org/ftp/gcrypt/libassuan/ *** (at least version 3.0.0 (API 3) is required). *** configure: error: *** *** Required libraries not found. Please consult the above messages *** and install them before running configure again. ***

Conclusion

The developer version needs more attention with its configuration. Dealing with libraries is always a little bit tricky. But the GnuPG project provides the tools to circumvent those problems in several ways.

To be continued...

Compiling GnuPG VI: Merge a Pull Request

fmg Friday March 14, 2025

Situation

Last time I presented a first result, i.e. compiling the software and creating a Debian style package. Later in the evening a pull request came to my attention. How to deal with it? Different platforms (Codeberg, Github, Gitlab) seem to have different workflows, all integrated into the web user interface, and maybe command line support. I used Stackoverflow to figure out what to do - even if that post refers to creating rather than applying the pull request.

Solution

First I created a branch to test the method there, with several checks:

Copy to clipboard
git branch -l git log -1 git remote add ka7 https://codeberg.org/ka7/diy-gnupg.git git fetch --all git checkout -b mergepullrequest git branch -l git log -1 git cherry-pick 240ed7ed6fc0684fefe661399b5dd6f070dbeb6a git show b70ca327434814a7b2bf76acade3670cdd73f748 git push -u origin mergepullrequest git log -1 git switch main git branch -l git log -1

This worked the way I hoped, thus I could do it similarly by merging into the main branch.

Copy to clipboard
git cherry-pick 240ed7ed6fc0684fefe661399b5dd6f070dbeb6a git push

The commit is visible in the git log with timestamp Wed Mar 12 20:19:14 2025 +0100.


Thanks

Many thanks to the contributor ka7 for the pull request, Alex from C3S for explaining the problems with specific and generic workflow and Martin from LUGA for pointing me into the direction of a generic command line solution.

To be continued...

Compiling GnuPG V: Upstream Version 2.5.5 Debian Package

fmg Wednesday March 12, 2025

Latest News

Last time I discussed the second refactoring. Before I am going to focus on explaning the self compiling process itself the next days, I did a test of the new diy-gnupg repository on Codeberg with the new version GnuPG 2.5.5 from last Friday. The preparation with the scripts worked as expected and I converted the result into an update of the Debian style package shimps-gnupg-ng. This is still not the final result I aim to produce and it is still an experimental package, but it should work out of the box without path problems.

Upcoming Tonight

There is an online Jitsi meeting with friends from the Austrian LUGA (timezone CET at 7:00 pm). Language is German - feel free to join this open meeting.

To be continued...

Compiling GnuPG IV: Refactoring Reloaded

fmg Monday March 10, 2025

Latest News

Migration

Meanwhile the software project migrated from the old incubator repository to the new dedicated repository diy-gnupg. To make things easier, there is a migration script for repository cloning provided. Please adjust the localdestinationpath to your preferences or run

Copy to clipboard
$ git clone https://codeberg.org/fmg/diy-gnupg.git

from an appropriate folder of your choice.

User Settings

Now it is very easy to override the chosen GnuPG version numbers in etc/local.conf. This wil be useful if the repository is out of sync with upstram versions.

Logging

The repository provides a folder log/ which is convenient to have. The c&p examples in the README were adjusted.

Local Notes

The repository ignores a folder local/ which is convenient to have for some notes. These notes will not interfere with the Git repository setup (i.e. they do not appear as e.g. new or modified files).


Situation

Last time I presented the second script for unpacking the source code together with a refactored code structure. This allows to include (in shell terminology: source) external files, i.e. the configuration and an error library for shared usage among different scripts. The configuration file itself sourced a local configuration file with user settings - kind of an ugly construct. And to make things worse, each script was supposed to source those two files. Coming up with the idea of introducing a function library independent from the error library, this would require to source a third file and put the code into each script. Guess what I thought! Something felt wrong - time to pull the emergency brake.

Code Design

Continuing this path wasn't an option because it would pile up technical debt. This will eventually increase maintenance time to an extend that the project consumes too much time working on it at all, meaning it's dead. Even the revamp of two scripts and the configuration file was annoying, but the prospect of a flexible code structure was worth the effort. I introduced a single adapter file to be sourced by the scripts, and this can be extended to future needs without touching countless files. The habit of duplicate code usage is considered to be an anti-pattern, and this is for good reasons. It is quite obvious that this idea was inspired by the adapter pattern. The surprising part from my point of view was the fact that I didn't expect it becoming that important let alone that fast in shell programming. At the time I introduced the adapter the project consisted of four relevant files, and it was already refactored three days earlier.

The Function Library

The code is already prepared to use another library in the near future. This will make the shell scripts smaller and IMHO better readable, and it will be possible to reuse functions without code duplication. Another revamp of the two shell scripts is still necessary, together with the environment setup. This is expected to be no big deal.

First Steps

The corresponding paragraph from last time still holds unchanged. But we are approaching this milestone.


WP: Technical debt
WP: Duplicate code
WP: Anti-pattern
WP: Adapter pattern

To be continued...

Compiling GnuPG III: Unpacking

fmg Saturday March 8, 2025

Situation

Last time I ranted about refactoring. This already happened and the refactored version together with an additional tool is online now. In this context the project was taken out of the incubator repository (the remainders there are considered legay) and migrated to diy-gnupg (do It Yourself - GnuPG).

Configuration

Now there is a file self-compile/etc/local.conf created when it does not exist. It is copied from a template and will not be changed by updates to the git repository. You can customize your preferred settings there.

Unpacking

The script self-compile/bin/unpack-source.sh will decompress the bzip2 files and extract the source code from the tarballs. It does not matter where you store the folder self-compile in your file system tree, since the scripts are portable and will figure out their location and the location of the configuration and shared library for error handling at runtime, but it is important to keep all the folders bin, etc and lib next to each other.

First Steps

Unfortunately the refactoring and migration took longer as expected, thus I won't present this part today. The work which is done now was very important for the structure of the project. But please, feel free to play around for yourself. The working environment can easily be reproduced at any time - that is what those scripts are for.

To be continued...

Compiling GnuPG II: Refactoring

fmg Thursday March 6, 2025

It started with a script...


Situation

Recently we prepared the compilation of GnuPG with the help of a convenient download script for the sources, including libraries. For today it was planned to unleash the source code from pandora's boxes aka the bzip2 tarballs and move around with the first steps. But then things started...

SNAFU

The plan was a little software project with a few shell scripts to construct a reproducible environment for compiling and testing GnuPG. No big deal, right? Wrong! It might seem surprising, but even after publishing a single script and preparing the second one things started running out of control. The original approach might have had a chance to work for a single file project with a growing shell script, but splitting the tasks into several scripts required thinking deeply and refactoring early. Yes, refactoring became necessary after the release of the first file. Almost unbelievable. I know about projects which have been running into the wrong direction for far too much time, making wrong decisions from the beginning or defering the necessary code refactoring for arbitrary reasons over and over. It's quite easy to see wrong doing somewhere else, but this time I was prepared and trained to observe myself and my own project. Something felt wrong - time to pull the emergency brake.

Code of Problems

One major problem is the fact that all the scripts work on the same data pool, with the filenames defined - where? Define them in each script? This will lead to hell style code maintenance. Especially the software version numbers will change with time, and the proposed target path will vary with user preferences. Do you want to change the path name in a whole bunch of files? Or do you prefer a single configuration file? Do you think I want to update the version numbers in a gazillion of files? Let me make an educated guess about your thoughts and wishes... of course no sane human being wants to edit the same stuff in a bunch of files over and over.

Clean Code Correction Proposal

Since I already introduced a folder bin, another folder etc. is the logical option, and to include shared code yet another one: lib There is another problem left to be solved: initial distribution of the code. People familiar with git can use this method, but maybe a single starting script for beginners would be a good idea. And finally: the repository. It feels like it's time to move away from the incubator repository since meanwhile it became clear which direction the journey takes. These are the remaining minor questions, but regarding the big think (this is poet slang for... you'll figure it out) I guess I can draw the line: the deed is done. There is refactored code already, but not uploaded yet, because some work still needs to be done. However, this won't take too much time since we have clear sight now.

Hopefully normal operation will resume with the next blog post regarding this topic.


WP: Code refactoring
WP: SNAFU

To be continued...

Compiling GnuPG I: Preparation

fmg Tuesday March 4, 2025

Situation

Assume you want to start to compile software yourself. There are many reasons to do so: learning, debugging, preparing a package, maybe just for fun. There are some questions raised immediately: where to start and how to proceed, And what needs to be thought about before going all in? This here describes the experiment and adventure of creating a GnuPG binary directly from the developers' GnuPG sources.

Preliminaries

Throw away destination

Starting things without some experience will cause some decision mistakes, thus need repetitiion from an earlier state. And someone surely doesn't want to mess up the main working system. Since this is an experiment, we choose a temporary destination in the filesystem to drop, compile and create all the stuff and artifacts needed on the way: /tmp/canary.

Prepare download

If you are too lazy to download the code, all the libraries, all the cryptographic signatures, and too lazy to verify the signatures, you can start with a meta download: a script which does all that work for you. We provide fetch-source.sh on the Codeberg non-profit community Git hosting project. The script is not in its final state yet, nor is the incubator repository the final repository. Even this is an experiment at this time.

Use script
Copy to clipboard
sh fetch-source.sh | tee -a download.log less download.log

For the beginning this is enough. The folder /tmp/canary/compile can be deleted an recreated with the script at any time. Have a look at the logfile and check whether there are any errors. Next time we will open the bzip2 pandora boxes and see what happens. Finally: feel free to analyze, understand, improve and/or customize the script itself. It is Free Software.

To be continued...

Update (2025-03-06): README with latest documentaion

Cryptowars reloaded?`

fmg Friday February 28, 2025

1993

Do you remember the Clipper chip? The EFFector Online Volume 6 No. 1 covered this topic more than 30 years ago. The idea is easy to understand: the government wanted to have a backdoor for decryption of encrypted communication data. The problem is as easy to understand: the bad guys can abuse the backdoor, or maybe the government itself consists of bad guys.

Does politics learn anything from the past? Obviously the answer is no.

2013

Edward Snowden initiated a public discussion whether we can trust our governments or not. Obviously the answer is no.

2020

2022

May
Jul
Oct

2023

2024

2025

2026

More news of nuts? Obviously the answer is yes. Stay tuned.

Science and Politics: Nightmare?

fmg Monday February 24, 2025

Prelude

Some years ago the power line energy loss and its technical connection to Kirchhoff's laws were topic in an EU meeting. A small percentage loss must be taken into account and is unavoidable. So far, so good. But the word law triggered an EU official to state laws can be changed. The idea of physics being decidable by parliament is... at least ambitious. This had to do nothing with Direct observation of the violation of Kirchhoff’s law of thermal radiation (2023-07-24). The latter one is an interesting scientific observation.

DEI 2020

DEI is short for diversity, equity, and inclusion. At least in the US and in Canada it eventually became mandatory to file DEI statements in conjunction with scientific job and research grant applications. As The Hill reported in 2020, UC Davis in California used those statements to filter:

[...] Of those applicants, 679 were eliminated solely because their diversity statements were deemed inadequate.

In other words, UC Berkeley rejected 76 percent of qualified applicants without even considering their teaching skills, their publication history, their potential for academic excellence or their ability to contribute to their field. [...]

DEI 2025

Recently in the US: President Donald Trump started tabula rasa:

Shortly after his inauguration, United States President Trump issued an executive order that ordered the dismantling of “radical and wasteful government DEI programs and preferencing.”

Lawrence Krauss, known to be far from being right wing or a Republican or dogmatic, supports canceling this nonsense on the Canadian side.

As DEI in American academia is being rolled back, Canada is grappling with a similar force. Here, DEI-related discrimination is actually much more severe than it ever was in the U.S. because it’s as long as the groups being discriminated against were the supposed perpetrators of discrimination in earlier times. So, university positions can legally be advertised as being off-limits to white males, for example.

Trump 2025

As the American Association for the Advancement of Science reports, US President Donald Trump is completely out of control.

Thousands of other federal scientists were similarly shocked over subsequent days as President Donald Trump’s administration unleashed a massive, unprecedented, and chaotic wave of firings across the U.S. government.

And this is only the tip of the iceberg. There are tens of thousands of workers affected by those decisions.


WP: Kirchhoff's circuit laws
WP: Kirchhoff's law of thermal radiation
WP: Diversity, equity, and inclusion
WP: Lawrence Krauss

Conversation: Abigail Shrier with Jordan B Peterson

fmg Thursday February 20, 2025

The transgender topic is emotionally charged, thus the debate is very difficult. American author and journalist Abigail Shrier tries to promote some scientific foundation into it. There are a lot of details and subtopics which shouldn't be mixed up.

The conversation was recorded Jan 06, 2021.

Irreversible Damage? | Abigail Shrier | EP 159

Jordan B Peterson
Mar 22, 2021

WP: Abigail Shrier
WP: Jordan Peterson
WP: Transgender

Werner Koch at The Linux Inlaws

fmg Tuesday February 18, 2025

A Podcast Interview

The Stage

The Linux Inlaws is a podcast project around Free and Open Source Software. The project is driven by Dr. Chris Zimmermann and Martin Visser.

The Content

Last year Werner Koch, the inventor of GnuPG, was interviewed about his software and related stuff. The podcast episode S02E22 (might be moved to the episode archive meanwhile) was published early November. Among other topic details LibrePGP was mentioned as an alternative to IETF RFC 9580 OpenPGP, which became effective 2024-07-31 (while the podcast was recorded earlier last year in May).


Service: c&p full link:
https://ia904506.us.archive.org/34/items/LI_S02E22_OpenPGP__7525/LI_S02E22_OpenPGP_.mp3

GnuPG Upstream Version 2.5.4

fmg Friday February 14, 2025

Situation

In December SHIMPS published a repository as Christmas present for the community to provide current versions of GnuPG for the distributions Debian und Devuan.

Latest

Wednesday GnuPG published version 2.5.4 (upstream release notes available), which is now included in SHIMPS repository as Debian style package shimps-gnupg-ng.

Changelog

All dependencies of the Debian package structure were removed, because probably these are neccessary only for the build process. There is still some testing required to clarify the situation finally.

Neil Turok: Astonishing Simplicity

fmg Wednesday February 12, 2025

According to Neil Turok nature is quiet simple. This might sound surprising because Quantum Mechanics and General Relativity are not the easiest subjects in science. The public lecture starts with a reference (video) to Art McDonald (2015 Nobel Laureate) and neutrino oscillations.

Neil Turok Public Lecture: The Astonishing Simplicity of Everything

Perimeter Institute for Theoretical Physics
Oct 8, 2015

WP: Arthur B. McDonald
WP: Neutrino oscillation
Arthur B. McDonald Nobel Lecture - video