Continuous Learning

This is where I share and save my findings for you and future me.

I think everyone had the the moment from time to time when you feel like you have been sleeping under a rock for one year or two, that happened me last night. Web Key Directory was the secret words, which made me to realize that I have been blind or just had so much other things to do the last year.

Share your public key with friends and strangers with ease. This article describe what Web Key Directory is for GnuPG.

Clients and e-mail providers are listed at GnuPG WKD had added support for Web Key Directory also known as WKD. GnuPG which is an implementation of OpenPGP which is a system for signing or encrypting messages, documents and files. Authentication to login on different systems with your keys.


There is two different encryption models on how you can unlock an encryption; Symmetric and Asymmetric which have its own applications and can also be combined for different actions.

In simple words Symmetric is when both sender and receiver must have the same key to encrypt and decrypt a message and everyone which get their hands on this shared key will also be able to read the messages.

Asymmetric is harder to understand how it works because the sender does not need to share any secret key to the receiver, the only thing she needs is a public key from the receiver which is not enough to decrypt any message, but it is well enough to encrypt with if the sender have its own private key which he will never share with anyone.

This means that every time you want to encrypt a message with some one new, you need to ask for the public key. To make it easier there exists some dictionaries like the old fashion yellow pages but digital OpenPGP keyserver, where people can chose to publish their contact information together with a public key. For many years the servers have been useful, but about a year ago some one decided to exploit a known vulnerability which made some of these key servers to crash. This have become a very critical infrastructure for many opensource projects who kept their public keys there to let users of their software verify that the software they are about to install is really released from the correct team.

So one of the solution of this is Web Key Directory which is a super simple way of how to distribute the centralization on not just one central point of failure but on every possible domain which is connected to an e-mail. It uses traditional http with SSL (https) and a folder structure with your public key stored in a file. The URL for reaching your public key will be like bellow.<hash e-mail prefix>
│           │          │          │   │
│           │          │          │   └ sha1 + z-Base-32 
│           │          │          └ Human use folder
│           │          └ openpgpkey folder, RFC Draft (1) 
│           └ RFC8615 Well-known folder for metadata
└ Domain name same as your e-mail


if you cannot use your primary naked domain record create a subdomain named openpgpkey and point it to a http server which can handle SSL and keep your .well-known folder safe. Se bellow how the URL shall look like.<hash e-mail prefix>

Files needed in the root of your web server for the domain

└── .well-known
    └── openpgpkey
        ├── hu
        │   └── im4cc8qhazwkfsi65a8us1bc5gzk1o4p
        └── policy

3 directories, 2 files

the policy file is for clients to check for Web Key Directory support. It is also used for different policy flags, as default this needs to be an empty file.

How to

To list your keys

gpg --list-keys --with-wkd

pub   rsa4096/0xFB12FB1BCB8D0713 2019-09-26 [SC]
      Key fingerprint = 9D1A 01CF C4C2 5B90 DA81  55D8 FB12 FB1B CB8D 0713
uid                   [ultimate] hello <>
sub   rsa4096/0x002C57D3FC48ABFB 2019-09-26 [E]

in this example the sha1 + z-Base-32 hash of hello is im4cc8qhazwkfsi65a8us1bc5gzk1o4p which will be the name of the file you place on your web server.

Export your public key where im4cc8qhazwkfsi65a8us1bc5gzk1o4p is the sha1 + z-Base-32 of your e-mail prefix, execute following command.

gpg --output\

Copy the file to the .well-known folder on your webserver place it under openpgpkey/hu

test your configuration

For downloading public keys with Web Key Directory gpg --auto-key-locate clear,nodefault,wkd --locate-keys

I find often that people have hard time to understand Git, they often get stuck in between the local repository and the remote repository where the local is detached and suddenly they end up in a merge conflict.

The conceptual idea of what Git is, is most of the time the main issue, and what shall be stored in Git. You cannot always blame the users when organizations force non-experienced developers to use a version-control system to store various things, without a thought of what shall be stored in Git.

In organizations there are a mixture of people in which does not always have a background in software development, they will more or less use Git as it was a network file system with some extra steps where you put things in to share with your peers.

What experienced developers do really bad is explaining Git with Git terms which will only make alot more confusing situation. The moment you trying to explain Git you will start pouring out words like, clone, commit, stage, branch, merge, merge conflict, resolve, push, pull, rebase.

When it is just the conceptual idea of how Git sees the world as a tree with snapshots which pointing to a parent snapshot, and how you can as a user change these links between the snapshots, then you can also explain why some commands need to be executed.

Otherwise it will end up in as XKCD #1597 explains which you can read above. So if you try to explain Git for some one please make sure you know whats happening with the graph tree, which Git is based on; DAG (Directed Acyclic Graph) which is in simple words a graph without loops, If you follow the relationships from one node you will never end up in the same one you started with. In Git every node in the graph is a commit, a snapshot of the code you working with.

The snapshots can be stored on your computer or on other computers, how you choose to transfer the state of your DAG is up to you, one way is to format patches with git format-patch give it you your friend and and then use git am to apply it, or you can send it by e-mail with git send-mail you can find a good tutorial of git send-mail here. Most common way is to setup a remote with git remote add URL and use the commands push and pull.

The way it is designed the only commit you will have to care about is the latest, because it will always point to a parent commit, and the parent commit will point to it's parent until the “initial commit”, so then you have the full history.

A commit can have many children which means it is branched. You can change the parent of a commit with the command rebase, this is useful if your local commit is behind the remote tree which is common if you have team mates which is faster than you to write and commit code to the repository. Simple solution is the command bellow:

git pull origin --rebase

That's how you most of the time can avoid merging every time there is a new commit on the remote. What git is doing it will apply your changes as new commits on top of the latest from the remote origin. This means that you can also delete commits your are not proud of, by adding git pull origin --rebase=i and you have options for each commit. You can also use rebase within branches git rebase a_branch_name

Want to play with rebase follow this tutorial


Enter your email to subscribe to updates.