Loading...
 

shimpsblog [en]

English blog at blog.shimps.org

Unsolved Problem: Fine-structure Constant

fmg Sunday May 11, 2025

The strength of the electromagnetic interaction is desribed by the fine-structure constant aka Sommerfeld constant. It appears at different places in modern physics in an almost magical way, and it still remains mysterious.

Quote Wolfgang Pauli: When I die my first question to the Devil will be: What is the meaning of the fine structure constant?

Why Is 1/137 One of the Greatest Unsolved Problems In Physics?

PBS Space Time
Sep 28, 2022

WP: Fine-structure constant
WP: Arnold Sommerfeld
WP: Wolfgang Pauli

Neighborhood Black Holes

fmg Friday May 9, 2025

Where are the closest black holes in our cosmic neighborhood? How far away are they? Are they dangerous to us? Are they interesting for astronomers?

The closest KNOWN black holes to Earth (only three have ever held the title)

Dr. Becky
Aug 15, 2024

Physics Mystery: The Horizon Problem

fmg Wednesday May 7, 2025

The lifetime of the universe has not been long enough to transport information from every place to every other place. Despite this fact regions in different directions without contact have similar properties. How does this work? Superluminal transport of information is excluded by relativity. The observations of the cosmic microwave background are astonishing.

The Horizon Problem | The Universe's biggest UNSOLVED mystery

Dr. Becky
Feb 15, 2024

Search for Dark Matter

fmg Saturday May 3, 2025

Shielded laboratories below the surface of the earth are the place for experiments which try to find evidence for the existence of dark matter. It is difficult to filter out disturbing sources of radiation which might influence the results.

The Absurd Search For Dark Matter

Veritasium
Jun 2, 2022

Compiling GnuPG XVII: Order Of Compilation

fmg Tuesday April 29, 2025

Situation

Last time pinentry appeared as final missing piece to have a complete working self compiled GnuPG suite. To avoid old software and libraries from the distribution to the possible extend, we choose eight tarballs from the GnuPG Download page to be compiled.

  • GnuPG (devel)
  • Libgpg-error
  • Libgcrypt
  • Libksba
  • Libassuan
  • ntbTLS
  • nPth
  • Pinentry

Some parts require newer self compiled versions of libraries, other might benefit but can be compiled with the older versions from the distribution. It is an annoying exercise to figure the dependencies out by studying the documentation or the ldd output without being able to see them. Therefore I created an ASCII graph as pictorial support for understanding the situation.

ASCII Dependency Graph

The dependency graph has got two entry points, i.e. libraries to start with. These require no other libraries from the project itself and can be compiled against the distribution: libgpg-error and npth. Then there are two exit points, which provide the tools for usage of GnuPG: gnupg and pinentry. These tarballs are supposed to be compiled at the end. The order of compilation of the other four tarballs can be obtained from the dependency graph. There is one rule: compilation order in vertical path direction must always be downwards. The order in horizontal direction is given by arrows, but there is some redundancy in the graph, which makes the graph a little bit bigger, but this avoids possible misunderstandings by ignoring the arrows. The vertical rule should be enough to have an intuitive understanding of the digraph character. And another point: explicit dependencies are explicit paths without an intermediate library, e.g. everything except npth depends on libgpg-error and can be reached from it by a path not meeting any other library, as shown in the graph.

Copy to clipboard
L0 libgpg-error | | | +---->----+---->----+--------->---------+---->----+ | | | | | | | | | | | | L1 npth | | | | | | | | | | | | | | | | | | | L2 | | libgcrypt | | | | | | | | | | | | | | | | | L3 | libksba +--------->---------+ libassuan | | | | | | | | | | | | | +---->----+ +----<----+ | | | | | | | | | | | | | | | | | | | | | +----<----+ +---->----+ | | | | | | | | | | | | L4 | | ntbtls +----<----+ | | | | | | | | | | | | | | | +---->----+---->----+---------<---------+ | | | | | | | L5 gnupg pinentry

Best Practice

There is no unique order fixed by the graph, thus parts of the order can be considered as suggestion or recommendation. If you use the order from the download page (see above) and move GnuPG (devel) to the end of the list, this order should work, too.

  1. libgpg-error
  2. npth
  3. libgcrypt
  4. libksba
  5. libassuan
  6. ntbtls
  7. gnupg
  8. pinentry

In the future libgpg-error will be renamed gpgrt.

To be continued...


Codeberg OOC.md

The Universe as Illusion? I/II

fmg Thursday April 17, 2025

Is our perception of the universe an illusion? Modern physics pushes the boundary between empirical science and philosophy in a challenging way. Is the net content (mass and energy) of the universe zero? Can it be created from nothing?

Lawrence Krauss - Illusion 1: A Universe from Nothing - Scientifically Informed Philosophy S1E1

Kinship Cafe
Jun 14, 2024

Compiling GnuPG XVI: Pinentry

fmg Tuesday April 15, 2025

Situation

Generating a public/private key pair requires a passphrase - at least it is strongly recommended not to use empty passphrases. When a key is generated with gpg --gen-key or gpg --full-gen-key the user is asked to enter the passphrase and confirm it to avoid typos. This part is handled by the program pinentry which is invoked by gpg-agent, which itself is a supporting daemon for gpg.

The Problem

When the self compiled version is installed in a non-default folder without self compiled pinentry, this process fails. The gpg binary doesn't evaluate the PATH and the lookup for pinentry is limited to the folder where it is invoked from.

Solution Methods

Self Compiled

We can compile pinentry with the same configuration prefix as gnupg.

Quick and Dirty

We can set a symlink to the distribution's version of pinentry.

Copy to clipboard
cd /tmp/canary/install/bin ln -s /usr/bin/pinentry pinentry

Configuration

We can define the configuration option pinentry-program /usr/bin/pinentry in the file gpg-agent.conf. But when the gpg-agent is running already, it doesn't know yet about the new configuration. It is possible to kill the gpg-agent, but in these cases you will lose all the settings handled by it, e.g. unlocked keys - this is quick and dirty. There is a better way.

Copy to clipboard
$ cat /tmp/canary/homedir/gpg-agent.conf pinentry-program /usr/bin/pinentry $ LD_LIBRARY_PATH="/tmp/canary/install/lib" $ cd /tmp/canary/install/bin $ ./gpg-connect-agent --homedir /tmp/canary/homedir reloadagent /bye $ ./gpg --homedir /tmp/canary/homedir --gen-key


The program gpg-agent knows about the command line option --pinentry-program ${whatsoever}, but gpg doesn't. Thus you cannot pass it by invoking the latter with this option.

Conclusion

The configuration solution method is the best choice, since it can be done on user level and it can be combined with the self compiled solution method. A user can switch between distribution's and self compiled pinentry at any time. And it doesn't matter whether pinentry is part of the self compiled suite when configured to use the distribution version.

To be continued...

GnuPG SHIMPS Signing Keys

fmg Friday April 11, 2025

Situation

Last December we started to provide GnuPG as Debian style packages with an additional external repository on software.shimps.net. The trust anchor is the repository signing key which must be deployed with

Copy to clipboard
cd /etc/apt/keyrings wget https://software.shimps.net/keys/gnupg/shimps-signing-2024.gpg


I published the fingerprint in a signed email on the gnupg-users mailing list. This way the trust anchor is shifted to the key I use to sign emails on that list. This key is available via WKD (as well as the signing keys are).

Another Key

The recommended package shimps-keyring is intended to simplify future key updates. Meanwhile there is a new signing key prepared, which is not used for the repository (or even in the keyring package) yet, but ATM intended to sign Git commits, e.g. to Codeberg diy-gnupg. It needs to be imported into the user's keyring if you want to verify the commits. Quick and dirty import:

Copy to clipboard
cd /etc/apt/keyrings wget https://software.shimps.net/keys/gnupg/shimps-signing-2025.gpg gpg --import /etc/apt/keyrings/shimps-signing-2025.gpg


Since this key will be shipped with the keyring package eventually, there is no need to deploy it below /etc/apt and you might want to import it via WKD:

Copy to clipboard
$ gpg -v --auto-key-locate clear,wkd,nodefault --locate-keys signing.2025@shimps.net gpg: using pgp trust model gpg: pub ed25519/52CAACDAA420187C 2025-04-09 Frank Guthausen (signing 2025) <signing.2025@shimps.net> gpg: key 52CAACDAA420187C: "Frank Guthausen (signing 2025) <signing.2025@shimps.net>" not changed gpg: Total number processed: 1 gpg: unchanged: 1 gpg: auto-key-locate found fingerprint E614303270D94B76EF285FFA52CAACDAA420187C gpg: automatically retrieved 'signing.2025@shimps.net' via WKD pub ed25519 2025-04-09 [SC] [expires: 2028-04-08] E614303270D94B76EF285FFA52CAACDAA420187C uid [ultimate] Frank Guthausen (signing 2025) <signing.2025@shimps.net> sub cv25519 2025-04-09 [E] [expires: 2028-04-08]

Fingerprints

Keep the trust anchor in mind. If you get the key from the website (download or WKD) you (and I) need to trust the provider to host and ship the correct key and you need to trust https encryption with an Let's Encrypt certificate.

December 2024

The signing key from December 2024 is RSA 3072.

Copy to clipboard
$ gpg -k signing.2024@shimps.net pub rsa3072 2024-12-17 [SC] [expires: 2026-12-17] 2BBD6FF068FEF7905A531348ECB53FD18ACCCF7C uid [ultimate] SHIMPS Signing Key 2024 <signing.2024@shimps.net> sub rsa3072 2024-12-17 [E] [expires: 2026-12-17]

or

Copy to clipboard
$ gpg --fingerprint --fingerprint --with-sig-list signing.2024@shimps.net pub rsa3072 2024-12-17 [SC] [expires: 2026-12-17] 2BBD 6FF0 68FE F790 5A53 1348 ECB5 3FD1 8ACC CF7C uid [ultimate] SHIMPS Signing Key 2024 <signing.2024@shimps.net> sig 3 ECB53FD18ACCCF7C 2024-12-17 SHIMPS Signing Key 2024 <signing.2024@shimps.net> sub rsa3072 2024-12-17 [E] [expires: 2026-12-17] B3E8 C9E5 48CC CDC4 1C70 0650 4D19 8A44 C9AE 8FA6 sig ECB53FD18ACCCF7C 2024-12-17 SHIMPS Signing Key 2024 <signing.2024@shimps.net>
April 2025

The signing key from April 2025 is an ECC key with curve ed25519. It is signed with the 2024 signing key to establish a chain of trust.

Copy to clipboard
$ gpg -k signing.2025@shimps.net pub ed25519 2025-04-09 [SC] [expires: 2028-04-08] E614303270D94B76EF285FFA52CAACDAA420187C uid [ultimate] Frank Guthausen (signing 2025) <signing.2025@shimps.net> sub cv25519 2025-04-09 [E] [expires: 2028-04-08]

or

Copy to clipboard
$ gpg --fingerprint --fingerprint --with-sig-list signing.2025@shimps.net pub ed25519 2025-04-09 [SC] [expires: 2028-04-08] E614 3032 70D9 4B76 EF28 5FFA 52CA ACDA A420 187C uid [ultimate] Frank Guthausen (signing 2025) <signing.2025@shimps.net> sig 3 52CAACDAA420187C 2025-04-09 Frank Guthausen (signing 2025) <signing.2025@shimps.net> sig ECB53FD18ACCCF7C 2025-04-09 SHIMPS Signing Key 2024 <signing.2024@shimps.net> sub cv25519 2025-04-09 [E] [expires: 2028-04-08] 45F2 E58A 454A 8FFA DE16 11EE A3F2 65E6 7497 B0AB sig 52CAACDAA420187C 2025-04-09 Frank Guthausen (signing 2025) <signing.2025@shimps.net>

Why a Gazillion Keys?

In principle it would be possible to work with one main key and several subkeys for different email addresses and purposes. At the end a choice has to be made. Dealing with only one key might be more convenient and less work here and there, but you cannot seperate roles on a fine grained level. Thoughts about data protection might occur, or it can become cumbersome to deal with subkeys. And finally it is a question of workflow, taste and/or personal preferences. There is no one size fits all solution.

First Anniversary

fmg Wednesday April 9, 2025

One year ago this blog started with Underpayment in Academia. There were eight blog posts published each week - distributed to three different blogs.

It's time to celebrate. Wednesday evening I attend the LUGA online Jitsi meeting (language is German).

There are still a lot of interesting scientific as well as computer topics. It is impossible to cover them all, thus I have to select how to spend the time. The major topic of the last month was compiling GnuPG on Debian. There were some pitfalls, but I guess the deed is done and the problems are understood. Building Debian packages will be a subsequent topic. ATM the Debian style SHIMPS packages of GnuPG 2.5 are still experimental.

Maybe the frequency of postings will decrease because there are a few other important things on the list - Que Sera, Sera (Whatever Will Be, Will Be).

Enjoy!

Compiling GnuPG XV: Environment II

fmg Saturday April 5, 2025

Situation

Last time we prepared the chroot-environment with debootstrap. This time we continue inside the chroot environment.

Copy to clipboard
chroot /mnt


Inside the chroot we create an user shimps and install aptitude for the other packages' installation process. YMMV.

Copy to clipboard
user="shimps" addgroup --gid 1000 ${user} adduser --gid 1000 --uid 1000 --disabled-password --gecos ${user},13,23,42,666 ${user} apt-get update apt-get install aptitude

Packages I: General

Next we do some basic preparation of the chroot, independent from the GnuPG build process later.

Copy to clipboard
aptitude install perl aptitude install libfile-fcntllock-perl aptitude install bzip2 aptitude install xz-utils aptitude install libdpkg-perl aptitude install bash-completion aptitude install git aptitude install libldap-common aptitude install libsasl2-modules aptitude install publicsuffix aptitude install openssl aptitude install ca-certificates aptitude install openssh-client aptitude install xauth aptitude install patch aptitude install etckeeper aptitude install vim update-alternatives --config editor select-editor aptitude install systemd-sysv- sysvinit-core aptitude install psmisc aptitude remove systemd aptitude install libsystemd0- libelogind0 aptitude install lsof aptitude install colordiff aptitude install wget aptitude install curl aptitude install rsync aptitude install gnupg

Packages II: Build Process

Now we install packages required for compiling GnuPG.

Copy to clipboard
aptitude install gcc aptitude install libc6-dev aptitude install libc-devtools aptitude install manpages aptitude install manpages-dev aptitude install make aptitude install zlib1g-dev aptitude install libldap-dev aptitude install libreadline-dev aptitude install libsqlite3-dev aptitude install pkgconf aptitude install gawk aptitude install libbz2-dev aptitude install bzip2-doc aptitude install gpgrt-tools aptitude install libgnutls28-dev aptitude install libtasn1-doc

Drop Privileges

Now we switch to a normal user, root privileges aren't needed anymore.

Copy to clipboard
su - ${user}

Clone Repository

As user shimps we clone the diy-gnupg repository from Codeberg and prepare the source code for compilation:

Copy to clipboard
mkdir -p codeberg/fmg cd codeberg/fmg git clone https://codeberg.org/fmg/diy-gnupg.git diy-gnupg/self-compile/bin/fetch-source.sh diy-gnupg/self-compile/bin/unpack-source.sh mkdir -p /tmp/canary/install

Compile Libraries

Now things are almost straightforward, similar to what was described earlier in Compiling GnuPG VIII: Dependencies I, but the order has changed.

Copy to clipboard
cd /tmp/canary/compile/npth-1.8 ./configure --prefix="/tmp/canary/install" make make install cd ../libgpg-error-1.51 ./configure --prefix="/tmp/canary/install" make make install cd ../libassuan-3.0.2 ./configure --prefix="/tmp/canary/install" make make install cd ../libksba-1.6.7 ./configure --prefix="/tmp/canary/install" make make install cd ../libgcrypt-1.11.0 ./configure --prefix="/tmp/canary/install" make make install

Compile GnuPG

Now we are close to run into problems with yat2m. This didn't happen before when the package pkgconf wasn't installed, but without this package it wasn't possible to build GnuPG with Sqlite3 support either. The solution is adjusting the PATH variable and to use the new compiled version of yat2m.

Copy to clipboard
PATH="/tmp/canary/install/bin:${PATH}" cd ../gnupg-2.5.5 ./configure --prefix="/tmp/canary/install" make make install LD_LIBRARY_PATH="/tmp/canary/install/lib" gpg --version

Comparison

Original
Copy to clipboard
$ ldd /usr/bin/gpg linux-vdso.so.1 (...) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (...) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (...) libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (...) libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (...) libreadline.so.8 => /lib/x86_64-linux-gnu/libreadline.so.8 (...) libassuan.so.0 => /lib/x86_64-linux-gnu/libassuan.so.0 (...) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (...) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (...) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (...) libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (...) /lib64/ld-linux-x86-64.so.2 (...)
Self Compiled
Copy to clipboard
$ LD_LIBRARY_PATH="/tmp/canary/install/lib" ldd /tmp/canary/install/bin/gpg linux-vdso.so.1 (...) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (...) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (...) libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (...) libgcrypt.so.20 => /tmp/canary/install/lib/libgcrypt.so.20 (...) libreadline.so.8 => /lib/x86_64-linux-gnu/libreadline.so.8 (...) libassuan.so.9 => /tmp/canary/install/lib/libassuan.so.9 (...) libnpth.so.0 => /tmp/canary/install/lib/libnpth.so.0 (...) libgpg-error.so.0 => /tmp/canary/install/lib/libgpg-error.so.0 (...) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (...) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (...) libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (...) /lib64/ld-linux-x86-64.so.2 (...)

Thanks

Many thanks to Andreas for pointing me to the missing pkgconf package problem on the gnupg-devel mailing list.

To be continued...

Compiling GnuPG XIV: Environment I

fmg Thursday April 3, 2025

Situation

Compiling GnuPG from the Upstream vanilla sources can lead to several surprises depending on the environment. Setting up a controlled, defined and reproducible environment seems to be mandatory to get reproducible results. One of the requirements to make the environment reproducible is the possibility to have a script doing this, and the seed method is chosen to be debootstrap. Even with Debian trixie at the horizon we stick with Debian bookworm since this release doesn't provide all the libraries in modern versions needed to compile the GnuPG devel version 2.5 tree and therefore it is a suitable laboratory. The preparation requires root privileges and we claim the namespace /srv/shimps to build the environment.

Debootstrap

Some redundant variables are introduced to keep the command line short and make it better readable. And we make a local copy of the vanilla debootstrap for later usage. Initializing the debootstrap from a local copy is much faster than network download.

Copy to clipboard
mkdir -p /srv/shimps/debootstrap/debian/bookworm mkdir -p /srv/shimps/laboratory/gnupg/bookworm mount --bind /srv/shimps/laboratory/gnupg/bookworm /mnt CODENAME="bookworm" CN=${CODENAME} ARCH="amd64" AR=${ARCH} MIRROR="http://ftp.debian.org/debian" MI=${MIRROR} LOG="/mnt/debootstrap.log" L=${LOG} { date; time debootstrap --arch ${AR} ${CN} /mnt ${MI}; date; } 2>&1 | tee -a ${L} rsync -a /mnt/ /srv/shimps/debootstrap/debian/bookworm/

Preparing apt

I consider it a bad habit to install recommended packages by apt* automatically. This hides things which might help to learn something. Therefore we switch to an explicit control setup.

Copy to clipboard
mkdir -p /mnt/etc/apt/apt.conf.available touch /mnt/etc/apt/apt.conf.available/shimps--no-recommended cd /mnt/etc/apt/apt.conf.d ln -s ../apt.conf.available/shimps--no-recommended shimps--no-recommended

The content of this file (use an editor for c&p):

Copy to clipboard
$ cat /mnt/etc/apt/apt.conf.available/shimps--no-recommended APT::Cache-Limit "67108864"; APT::Install-Recommends "0"; APT::Install-Suggests "0"; Aptitude::Recommends-Important "false";

Preparing chroot

We need awareness of the system inside the chroot environment.

Copy to clipboard
mount --bind /dev /mnt/dev mount --bind /dev/pts /mnt/dev/pts mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys

The next part is due to SysV init. You might want to read zless /usr/share/doc/init-system-helpers/README.policy-rc.d.gz. Create an executable file with touch /mnt/usr/sbin/policy-rc.d, chmod +x /mnt/usr/sbin/policy-rc.d and content as shown in the next box. Some background is provided in the article ~jpetazzo/Use policy-rc.d to prevent services from starting automatically.

Copy to clipboard
$ cat /mnt/usr/sbin/policy-rc.d # shellcheck disable=SC2148 PATH="${PATH}:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" RL=$( runlevel ) if [ "${RL}" = "unknown" ] ; then exit 101 else exit 0 fi

If you are unsure, you may omit this step since we are not going to install any daemons which need to be prevented from being started automatically. But I consider it a good habit to prepare the chroot in an universal and complete manner.

It might be a good idea to prepare /mnt/root/.bashrc for bash-completion and maybe /mnt/root/.bash_logout and /mnt/root/.ssh/authorized_keys if you want to have a test environment in a virtual machine later, but this is not required. The latter one will require to have sshd configured for root login, which in itself might raise security issues.

The preparation files regarding apt and policy-rc.d are available in the Codeberg diy-gnupg repository.


Upcoming next time: we jump into the chroot and continue the preparation from inside.

To be continued...

Compiling GnuPG XIII: Libraries IV

fmg Tuesday April 1, 2025

Situation

Recently I compiled with bzip2 and gnutls support. The TLS stuff is important for dirmngr, Today I compare what is going on. However, this data set was collected before last Saturday. It indicates some problems with the environment I used to compile. It worked (in a way) for a version with GnuTLS, but it didn't work for a version with Sqlite3. I'll come back to this problem another time.

Distribution dirmngr

Copy to clipboard
$ ldd /usr/bin/dirmngr linux-vdso.so.1 (...) libassuan.so.0 => /usr/lib/x86_64-linux-gnu/libassuan.so.0 (...) libksba.so.8 => /usr/lib/x86_64-linux-gnu/libksba.so.8 (...) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (...) libnpth.so.0 => /usr/lib/x86_64-linux-gnu/libnpth.so.0 (...) libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (...) libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 (...) libldap-2.5.so.0 => /usr/lib/x86_64-linux-gnu/libldap-2.5.so.0 (...) liblber-2.5.so.0 => /usr/lib/x86_64-linux-gnu/liblber-2.5.so.0 (...) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (...) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (...) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (...) libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (...) libunistring.so.2 => /usr/lib/x86_64-linux-gnu/libunistring.so.2 (...) libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (,,,) libnettle.so.8 => /usr/lib/x86_64-linux-gnu/libnettle.so.8 (...) libhogweed.so.6 => /usr/lib/x86_64-linux-gnu/libhogweed.so.6 (...) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (...) /lib64/ld-linux-x86-64.so.2 (...) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (...) libffi.so.8 => /usr/lib/x86_64-linux-gnu/libffi.so.8 (...)

This is the reference to compare with.

Compiled without GnuTLS

For the next test the package libgnutls28-dev has to be deinstalled. But in this case dirmngr is not created. The ldd test seems to show dirmngr to be the only binary to link against gnutls.

Classic Compiled with GnuTLS

Copy to clipboard
$ LD_LIBRARY_PATH="/tmp/canary/install/lib" ldd /tmp/canary/install/bin/dirmngr linux-vdso.so.1 (...) libassuan.so.9 => /tmp/canary/install/lib/libassuan.so.9 (...) libksba.so.8 => /tmp/canary/install/lib/libksba.so.8 (...) libgpg-error.so.0 => /tmp/canary/install/lib/libgpg-error.so.0 (...) libnpth.so.0 => /tmp/canary/install/lib/libnpth.so.0 (...) libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (...) libgcrypt.so.20 => /tmp/canary/install/lib/libgcrypt.so.20 (...) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (...) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (...) libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (...) libunistring.so.2 => /usr/lib/x86_64-linux-gnu/libunistring.so.2 (...) libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (...) libnettle.so.8 => /usr/lib/x86_64-linux-gnu/libnettle.so.8 (...) libhogweed.so.6 => /usr/lib/x86_64-linux-gnu/libhogweed.so.6 (...) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (...) /lib64/ld-linux-x86-64.so.2 (...) libffi.so.8 => /usr/lib/x86_64-linux-gnu/libffi.so.8 (...)

Native Compiled with ntbTLS

Copy to clipboard
$ ldd /tmp/canary/native/bin/dirmngr linux-vdso.so.1 (0x00007ffc6ad49000) libassuan.so.9 => /tmp/canary/native/bin/../lib/libassuan.so.9 (...) libksba.so.8 => /tmp/canary/native/bin/../lib/libksba.so.8 (...) libgpg-error.so.0 => /tmp/canary/native/bin/../lib/libgpg-error.so.0 (...) libnpth.so.0 => /tmp/canary/native/bin/../lib/libnpth.so.0 (...) libntbtls.so.0 => /tmp/canary/native/bin/../lib/libntbtls.so.0 (...) libgcrypt.so.20 => /tmp/canary/native/bin/../lib/libgcrypt.so.20 (...) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (...) /lib64/ld-linux-x86-64.so.2 (...)

We've got running software, but it can be improved. Setting up the environment and digging deeper into the compiling process will be the topic for another day.

To be continued...

Compiling GnuPG XII: Libraries III

fmg Friday March 28, 2025

Situation

Last time we compared the distribution binary with the self compiled one and noticed missing libraries. Now we need the packages libbz2-dev and libgnutls28-dev to be installed. To trigger usage of GnuTLS, the configuration needs to be invoked with environment variables set.

Copy to clipboard
cd /tmp/canary/compile/gnupg-2.5.5 LIBGNUTLS_CFLAGS="-I /usr/include/gnutls" LIBGNUTLS_LIBS="-L /usr/lib/x86_64-linux-gnu -l gnutls" ./configure --prefix=/tmp/canary/install make make install

The install procedure is odd. Something is wrong with the doc folder, and some kind of recursion warning is given as output message. But this is not the topic to focus on today...

The Improved Binary

Copy to clipboard
$ LD_LIBRARY_PATH="/tmp/canary/install/lib" ldd /tmp/canary/install/bin/gpg linux-vdso.so.1 (0x00007ffc86d51000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (...) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (...) libgcrypt.so.20 => /tmp/canary/install/lib/libgcrypt.so.20 (...) libassuan.so.9 => /tmp/canary/install/lib/libassuan.so.9 (...) libnpth.so.0 => /tmp/canary/install/lib/libnpth.so.0 (...) libgpg-error.so.0 => /tmp/canary/install/lib/libgpg-error.so.0 (...) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (...) /lib64/ld-linux-x86-64.so.2 (...)

The libbz2 support is visible. Support for GnuTLS is not visible. There is a replacement option with ntbTLS. This library is offered by GnuPG upstream, but there is the warning NOT WELL TESTED on the page. It is even unclear whether GnuTLS is expected to appear or not. There are a lot of questioins remaining open for further investigation.

To be continued...

Compiling GnuPG XI: Libraries II

fmg Wednesday March 26, 2025

Situation

Last time we showed information related to dynamic libraries. This time we continue and show more to compare. Again: let's see which libraries are used by the compiled binaries (some irrelevant hex numbers are removed from the output):

Distribution Compiled
Copy to clipboard
$ ldd /usr/bin/gpg linux-vdso.so.1 (...) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (...) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (...) libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 (...) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (...) libreadline.so.8 => /lib/x86_64-linux-gnu/libreadline.so.8 (...) libassuan.so.0 => /usr/lib/x86_64-linux-gnu/libassuan.so.0 (...) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (...) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (...) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (...) libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (...) /lib64/ld-linux-x86-64.so.2 (...)

This is considered to be the reference output.

Native Compiled & Location Changed
Copy to clipboard
$ mkdir /tmp/newlocation $ rsync -a /tmp/canary/native/ /tmp/newlocation/ $ ldd /tmp/newlocation/bin/gpg linux-vdso.so.1 (...) libz.so.1 => /tmp/newlocation/bin/../lib/libz.so.1 (...) libgcrypt.so.20 => /tmp/newlocation/bin/../lib/libgcrypt.so.20 (...) libassuan.so.9 => /tmp/newlocation/bin/../lib/libassuan.so.9 (...) libnpth.so.0 => /tmp/newlocation/bin/../lib/libnpth.so.0 (...) libgpg-error.so.0 => /tmp/newlocation/bin/../lib/libgpg-error.so.0 (...) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (...) /lib64/ld-linux-x86-64.so.2 (...)

This looks good - the only thing missing for usage is the path change in the file gpgconf.ctl. We have something portable, but there are things missing.

The libsqlite3 isn't listed in the self compiled versions. But in the native compiled lib/ folder it is available. This is odd. Does this mean it is used? Or just provided? Does the native compile method need additional configuration? The libbz2 is missing, too. Maybe this can be fixed by installing the distribution package libbz2-dev.

The testing part is quite time consuming since there are some things handled by configuration options and other things by environment variables.

To be continued...

Compiling GnuPG X: Libraries I

fmg Monday March 24, 2025

Situation

Last time we compiled GnuPG in a different and more portable way. However, the library path problem isn't resolved completely. Let's see which libraries are used by the compiled binaries (some irrelevant hex numbers are removed from the output):

Classic Compiled - Wrong Way
Copy to clipboard
$ ldd /tmp/canary/install/bin/gpg linux-vdso.so.1 (...) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (...) libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 (...) libassuan.so.9 => not found libnpth.so.0 => /usr/lib/x86_64-linux-gnu/libnpth.so.0 (...) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (...) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (...) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (...) /lib64/ld-linux-x86-64.so.2 (...)

Oups...

Classic Compiled LD_LIBRARY_PATH
Copy to clipboard
$ LD_LIBRARY_PATH="/tmp/canary/install/lib" ldd /tmp/canary/install/bin/gpg linux-vdso.so.1 (...) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (...) libgcrypt.so.20 => /tmp/canary/install/lib/libgcrypt.so.20 (...) libassuan.so.9 => /tmp/canary/install/lib/libassuan.so.9 (...) libnpth.so.0 => /tmp/canary/install/lib/libnpth.so.0 (...) libgpg-error.so.0 => /tmp/canary/install/lib/libgpg-error.so.0 (...) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (...) /lib64/ld-linux-x86-64.so.2 (...)

Good...

Native Compiled
Copy to clipboard
$ ldd /tmp/canary/native/bin/gpg linux-vdso.so.1 (...) libz.so.1 => /tmp/canary/native/bin/../lib/libz.so.1 (...) libgcrypt.so.20 => /tmp/canary/native/bin/../lib/libgcrypt.so.20 (...) libassuan.so.9 => /tmp/canary/native/bin/../lib/libassuan.so.9 (...) libnpth.so.0 => /tmp/canary/native/bin/../lib/libnpth.so.0 (...) libgpg-error.so.0 => /tmp/canary/native/bin/../lib/libgpg-error.so.0 (...) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (...) /lib64/ld-linux-x86-64.so.2 (...)

Even better...

Remarks

As we can see, the libraries are found as intended. This is just a snapshot of the work done so far. I'll come back to this and keep it this time short.

To be continued...