Loading...
 

shimpsblog [en]

English blog at blog.shimps.org

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