Category Archives: Allgemein

On deprecating dynamic properties

Yesterday the RFC regarding Deprecating Dynamic Properties went into voting phase and it currently looks like the overwhelming majority supports the RFC.

But nevertheless the discussions yesterday started in the wider PHP community whether that is a good idea or not.

To summarize the RFC in very short terms: Currently PHP allows to assign values to a class property that was not previously declared. The RFC proposes to remove this implicit feature in PHP9. It will still be available as an explicit feature when the creator of the class adds an Annotation [AllowDynamicProperties] on the class level.

To prepare for that, in the next minor version of PHP – PHP 8.2 – whenever one assigns a value to an undeclared property there will be a deprecation notice raised.

So the proposal is – in essence – about moving from implicitness to explicitness. Which is in my opinion a very good move.

So what is the discussion that I was talking about previously all about? After all that sounds like a good move, doesn’t it?

Continue reading On deprecating dynamic properties

Farewell Enigmail

Thunderbird has End-to-End encryption right built into it’s very core. But at a price that was annoying to me. So I decided to keep the old 68 Version together with the enigmail plugin.

Until my system recently did an update and replaced the old thunderbird with the shiny new version 78. Which comes with its very own implementation of Pretty Good Privacy – better known as PGP.

Short recap: The Enigmail plugin used a system-installed GnuPG installation (Open Source PGP-Implementation). Thunderbird on the other hand uses a library called RNP.

This has 2 drawbacks. One is, that it is a bit harder to setup my current workflow which uses a private key located on a Yubikey that I have to unlock. The setup was not as easy as it was described in some of the descriptions on the internet. But that was mainly due to my own fault. A configuration setting that did work with Enigmail but didn’t with the new Version of Thunderbird.

The main issue is that RNP currently does not support hardware tokens. But luckily there is a flag that can delegate tasks that require private keys to a third party app. So I could setup the default GnuPG to handle the signing and the decryption process. One additional advantage is that I do not need to expose private keys to Thunderbird where they need to be secured by a single master password. But that is a different story.

RNP is not GnuPG

The – for me – more annoying part is, that RNP does not use the systemwide GnuPG keychain but its own one. So for me that means that I have to maintain two keychains with public keys.

I found that a bit awkward. So I looked for a way to automatically keep the two keychains in sync. And after a bit of digging I figured, that Thunderbird keeps a GnuPG compatible public keychain right in Thunderbirds profile folder. So all I have to do is write a cron-job that exports all the public keys from one keychain and moves them over to the respective other one. Already existing keys will not be imported, missing ones will be imported though.

So this is what I now have installed as cron-job:

gpg --no-default-keyring \
    --keyring=$THUNDERBIRD_PROFILE/pubring.gpg \
    --export \
    --armor | gpg --import --no
gpg --export --armor | gpg \
    --no-default-keyring \
    --keyring=$THUNDERBIRD_PROFILE/pubring.gpg \
    --import \

Optimization will follow soon by replacing the hard-coded path to the profile folder with a command that reads that from thunderbirds profile.ini file. But that is a different story.

The only drawback I have seen so far is that Thunderbird needs to be restarted after the script has actually imported one or more keys into the thunderbilrd keychain. Otherwise the new keys are not recognized.

But that is much less of a hassle and drawback than not being able to sign my outgoing email or decrypt my incoming mails.

inspecting docker-networks

Or how not to handle a non-responsive docker container


Handle “Cannot start service XY: driver failed programming external connectivity on endpoint XY (ContainerID): Bind for failed: port is already allocated” by inspecting dockers network stack and force-disconnect containers from the network.

The Problem

Today we had a non-responsive docker container that we couldn’t restart. docker-compose stop and such didn’t work. The container was still running and – especially nasty – also not responding. The website it usually provides only returned a 503 – Gateway not responding.

What to do?

Well… not what we did!
Continue reading inspecting docker-networks

what and where to .gitignore

I stumbled over a tweet of a friend of mine that sums up my feelings about what to add to a .gitignore file pretty well.

And then a debate spun up from that with the core-message that people need to know about the different ways to ignore files from automated inclusion in git-commits.

So let’s have a look at that.

git allows us to use three different ways to ignore files:

Project-specific gitignore-file

The probably best known way is by adding the filename to a file named .gitignore within the project. You can even use more than one .gitignore-File by adding one to different folders (though for obvious reasons you can only use one file per folder). Whether to use one or multiple .gitignore-files is a different discussion altogether.

This is the file the whole discussion spun around. This file should (note the conjunctive here) only be used for files that are related to your project. To give you an example imagine that you have a file .env.dist that contains a template of a .env file. Each contributor creates the .env file by copying the .env.dist and then editing it by adding credentials etc. Those credentials should never be added to the repo. So you can add the .env fiel to the projects .gitignore-file to make sure that git ignores that file. As the gitignore-file is committed it will be distributed to every contributor.

Project-specific exclude-file

Additionally you can add files to a file .git/info/exclude. That file is inside your git-folder and will therefore not be committed. So this is the best place to add files that you personally might need for your contributions but that are not relevant to everyone else. I usually have some executables in it that I created for the project but that are specific to my personal workflow. I don’t want anyone else to use them as they are hacky automation stuff but they are specific to the project.

Global gitignore-file

And finally there is a global .gitignore-file. To check where your global gitignore-file is located run this command:

git config core.excludesfile

Usually it is something like ~/.gitignore but it can be anything. Sometimes it can even be none which means that it is not configured. In that case feel free to consult your favourite search engine to find a tutorial on how to setup a global gitignore file.

This global gitignore-file is important to be able to automatically ignore all the files that are special to your personal setup but not project-specific. What files could that be, you might ask yourself now. Well: For example Apples feared .DS-Store files. Or your editors configuration files. Or your editors temporary or lock files. There are so many different possibilities. To get a general idea, you might want to have a look at – and the fact that there is a SAAS to generate gitignore-files shows how complicated it can be…

The great thing about this global gitignore-file is, that it applies in every git-project on your machine! So once configured it will work in every git-folder. Even in new projects that do not yet have a local .gitignore-file. And you can now safely commit code without fear that special files from your personal setup are accidentally committed.

Why all this fuss?

Well. One can of course add all the possible (and impossible?) files that certain IDEs or Editors add to your project to the project-specific .gitignore-file. But that means either having a very large file as you need to take all possibilities into account. Or it means (and that can also happen with a huge .gitignore-file) that you possibly miss something.

And imagine an editor-vendor renaming their config-setup. Or a new Editor starts to become en vogue. Now everyone needs to modify their .gitignore-files in their projects as someone might be able to commit a wrong file.

One way to make sure that no unwanted files enter a projects git-repo is to do code-reviews. Automation can help with spotting unwanted files, but it will never be able to spot all possibilities. Make sure that your code-review process spots those unwanted files.

And as a committer I will always need to be careful when committing! So before committing I should always check, that only files that I actually want to commit are committed! So I either have a look at the documentation of my Editor/IDE/Git-GUI or I use the CLI to specifically add the files. And I love git add -p – but that’s probably another blog-post.

For more infos have a look at the official documentation. And here and here are examples of project-specific .gitignore-files.

Enigmail and the YubiKey


If you can’t sign/decrypt with a YubiKey and Thunderbird/Enigmail you might want to add --pinentry-mode=ask to the “additional parameters for GnuPG” in the Enigmail configuration

The Story

After setting up all the cool Encryption stuff using a YubiKey I was so happy that everything worked.

And then I set up using the YubiKey for SSH as well as described in the documents I linked in the last blogpost. It took a reboot for everything to work out as I wanted it, but I was happy. Until I wanted to send a signed Email using Thunderbird/Enigmail.

Continue reading Enigmail and the YubiKey