About a decade ago I presented a hardware-based password calculator called calc.pw which generates passwords based on a single strong password and a service-dependent information, thus allowing you to use individual passwords for each of your services without having to care for a password database. I even presented it at a few conferences.
In the meantime much better microcontrollers have become available and my understanding of cryptography and password generation have improved as well. That is why I have kicked-off the reimplementation of calc.pw! 😃
Last year I got myself a PineBook Pro to have a look into ARM-based devices and ARM development in general. Thanks to the optional NVMe adapter board I was able to add an SSD to the device as well. One of the first things I always do after receiving new hardware is to fully re-install the operating system, because you should never trust a default installation. I used the manjaro-arm-installer as Manjaro currently seems to provide the best support for the Rockchip hardware.
Unfortunately, the installer did not provide the type of installation that I wanted to have.
Every once in while I get asked if a certain backup scheme is a good idea and oftentimes the suggested backup solution is beyond what I would use myself. Duplicity, its simplification Duply or the not-so-dissimilar contenders Borg and Restic are among those solutions that are mentioned most often, with solutions like Bacula and its offspring Bareos coming much later.
Unfortunately, I would not trust any of these tools further than I could throw a harddrive containing a backup created with them.
Nearly a year ago I wrote that I had an extensive look into the server side encryption that is provided by the Default Encryption Module of Nextcloud. I also mentioned that I have written some helpful tools and an elaborate description for people that have to work with its encryption.
What I did not write about at that time was that I had also discovered several cryptographic vulnerabilities.
A few weeks ago I wrote about the new cryptographic basis of the Shared-Secrets service. What I did not write about was that one user asked if a file-sharing option could be added. I declined because sharing files is nothing that the service is meant to be there for. But I tried whether sharing files would be possible.
About 3 years ago I wrote about a tool called Shared-Secrets that I had written. It had the purpose of sharing secrets through encrypted links which should only be retrievable once. Back then I made the decision to base the application on the GnuPG encryption but over the last couple of years I had to learn that this was not the best of all choices. Here are some of the problems that I have found in the meantime:
At the beginning of the year we ran into a strange problem with our server-side encrypted Nextcloud installation at work. Files got corrupted when they were moved between folders. We had found another problem with the Nextcloud Desktop client just recently and therefore thought that this was also related to synchronization problems within the Nextcloud Desktop client. Later in the year we bumped into this problem again, but this time it occured while using the web frontend of Nextcloud.
Ever since I built up my own Mastodon instance and created my own account I wanted to be able to cross-post messages between the two platforms. I searched for different solutions like IFTTT but I never got them to work properly - until I found dlvr.it which worked right out of the box for me. Well, at least at the beginning...
35 years ago the IETF defined special IPv4 addresses in RFC 1597 to be used solely in private intranets and with that created the separation between internal networks and the internet. 5 years later they proceeded to define special-use top-level domains like
.test in RFC 2606. However, the IETF did not reserve a top-level domain to be used within the private intranets that they had introduced before. This lead to confusion with administrators that still persists to the current day.
Im letzten Artikel hatte ich erklärt, weshalb ich mich dazu entschieden habe, von der Domain "weizenspr.eu" hin zur Domain "yahe.sh" zu wechseln. Hintergrund ist der Fokus der Webseite, der sich in den letzten fast 10 Jahren von Alltagserfahrungen hin zu technischen Themen gewandelt hat. Mit dem Wechsel des Themenfeldes geht jedoch auch ein Wechsel des Zielpublikums einher.
In der IT ist Englisch die Sprache der Wahl, um ein möglichst großes Publikum zu erreichen. Daher habe ich mich nach langem Ringen dazu entschlossen, auch diesen Blog zukünftig auf Englisch zu führen. Meine Hoffnung ist, dass die Leute, die auch bisher schon meine technischen Inhalte gelesen haben, der englischen Sprache mächtig sind. Zumindest in meinem Bekanntenkreis stellt der Sprachwechsel kein Problem dar, eröffnet mir jedoch die Möglichkeit einer internationalen Leserschaft.
Daher bleibt mir an dieser Stelle nur noch zu sagen: Welcome to Yahe.sh!