rail

Configuring Token2 security key for PGP and SSH

rail — Fri, 24 Jul 2026 00:00:00 +0000

Note: I’m not an expert in cryptography and while I believe this blog post shouldn’t contain any gross factual errors, I do not give you any warranty that described procedure is secure. Please do your own research for real-life security-sensitive situations. </div>
A while ago I bought myself a pair of Token2 FIDO2 security keys – honestly I can recommend them, they’re great. They offer most of the same functionality as YubiKeys while being less than half the price, it’s really awesome.
For all that time though I’ve been massively underutilizing my keys, only setting them up for hardware-based 2FA and occasional passwordless login on those few services that allow it.
Not a long time ago I set up my own email server and started using new email addresses for different services, which prompted me to reconsider my use of PGP keys. This is where the idea was born to look at the on-device cryptography features of my Token2 keys.
Take a fair warning, this is going to be a long, comprehensive read about a lot of things you can do with PGP on your hardware token ^^
The Basics</h2>
Version of the key that I own (Token2 PIN+ Release3.3 USB-C) supports several OpenPGP algorithms including RSA4096 and ed25519, various embedded cryptographic algorithms and ecdsa-sk & ed25519-sk SSH keys. Support may vary depending on exact hardware revision and product type but in general, it should be more or less the same with any modern Token2 key.
In practical terms it basically means that in addition to FIDO2 functionalities, that Token2 key is also a PGP smart-card which is a solid basis for achieving two goals:

Storing my PGP keys on the token itself so I can always have them with me on the go regardless of what device I use; and</li>
Using my token for SSH pubkey authentication for waow ultra secure remote access to very important things. I’ll be honest here, this is pretty overkill and in most situations this kind of setup will probably just end up getting in the way but I did it anyway just to have fun with it.</li> </ol>
Using GPG to configure your keys</h2>
The tool I used for setting up everything on my token was the gpg</code> binary from GnuPG suite and the embedded command-line interface.
Technically most of the same things can be done with standard OpenPGP and CCID combo but that approach felt more wonky and less out-of-the-box for me so I decided not to use it.
Usage of GPG for setting up a smartcard doesn’t seem to be documented very well and there are some things that are just left for you to figure out so I will try to do my best of describing the process here.
Let’s begin with reading some information about our token with the following command:
$ gpg --card-status Reader ...........: 0000:0000:X:0 Application ID ...: 00000000000000000000000000000000 Application type .: OpenPGP Version ..........: 3.4 Manufacturer .....: Token2 Serial number ....: 00000000 Name of cardholder: [not set] Language prefs ...: [not set] Salutation .......: URL of public key : [not set] Login data .......: [not set] Signature PIN ....: forced Key attributes ...: rsa2048 rsa2048 rsa2048 Max. PIN lengths .: 127 127 127 PIN retry counter : 3 0 3 Signature counter : 0 KDF setting ......: off UIF setting ......: Sign=off Decrypt=off Auth=off Signature key ....: [none] Encryption key....: [none] Authentication key: [none] General key info..: [none]</code></pre>Step 1: Change PIN</h3> PGP smartcards use PINs (user and admin PIN) for confirming operations such as creation of keys, changes of data or signing stuff. These PINs are different from the FIDO2 part of your token and you set them up separately. It’s good to start by changing them. Factory defaults: User PIN: 123456</code></li> Admin PIN: 12345678</code></li> </ul> To do that, we need to enter GPG command-line interface on the token: $ gpg --card-edit</code></pre> And unlock admin-space commands: gpg/card> admin</code></pre> Then proceed to the PIN management menu: gpg/card> passwd gpg: OpenPGP card no. 00000000000000000000000000000000 detected 1 - change PIN 2 - unblock PIN 3 - change Admin PIN 4 - set the Reset Code Q - quit Your selection?</code></pre> Pick option 3</code>, which will prompt you to change admin PIN. Then use option 1</code> to change user PIN, and Q</code> to exit PIN change menu. Step 2: Configuring cryptography</h3> PGP on the token will generate 3 keys: primary Signing and Certifying key [SC]</code>, Authentication sub-key [A]</code> and Encryption sub-key [E]</code>. Default algorithm for all of these keys is rsa2048</code>, which is a safe bet for compatibility with everything, but it’s definitely not the best modern option. Command used to create keys will not prompt you to select algorithm, you need to select those first using the following command: gpg/card> key-attr</code></pre> Which will then prompt you to select algorithm and elliptic curve for each of the keys to be generated. For a widely supported modern setup, pick ECC</code> and Curve 25519</code> in every case. Once that’s done you can run the following command to verify that changes have been made to your token’s configuration: gpg/card> list . . . Key attributes ...: ed25519 cv25519 ed25519 . . .</code></pre>Step 3: Generating keys</h3> With that out of the way, we can actually generate our set of keys! gpg/card> generate</code></pre> Note: This section is important as it will determine your ability to create a clone of your token’s PGP keys. Please read carefully! </div> You will be asked if you want to make an off-card backup of the encryption key. For maximum security it’s best to select N, because the default action Y will save the key to your computer and then copy it to the token, defeating the purpose of storing keys in isolation on dedicated hardware. But it also means that once the keys are generated they cannot be exported so no backup copy can be made. I describe an alternative procedure for creating an exact clone of two tokens in another section</a>. After that you will be prompted to authenticate with PIN and select standard options for your key such as expiration time and your identity. You will be able to change your UID or add more than one later on. After picking all the options and accepting them, it’s done. Your Token2 security key now holds a set of PGP keys that you can use for all the standard things that these keys are used for, such as encrypting your emails, creating encrypted backup archives, signing git commits and many more. PGP is a beautifully standard solution in the computer world. You can run the list</code> command once more to verify that your keys have been generated correctly: gpg/card> list . . . Signature key ....: A3D6 FF6F 7A89 3043 763F 5168 3AEB 1058 B661 2722 created ....: 2026-07-23 18:32:29 Encryption key....: CB88 B08E CD20 8F68 EB05 5938 1F94 F58E 4B03 9FF8 created ....: 2026-07-23 18:32:29 Authentication key: 4CD3 8306 5841 664A BE68 685A 3F40 606D 8586 A4F0 created ....: 2026-07-23 18:32:29 General key info..: pub ed25519/3AEB1058B6612722 2026-07-23 test <test@example.com> sec> ed25519/3AEB1058B6612722 created: 2026-07-23 expires: never card-no: 0000 00000000 ssb> ed25519/3F40606D8586A4F0 created: 2026-07-23 expires: never card-no: 0000 00000000 ssb> cv25519/1F94F58E4B039FF8 created: 2026-07-23 expires: never card-no: 0000 00000000</code></pre> And the following command outside the GPG environment on your computer to verify that private key stubs have been correctly loaded into your local keyring: $ gpg --list-secret-keys . . . sec> ed25519 2026-07-23 [SC] A3D6FF6F7A893043763F51683AEB1058B6612722 Card serial no. = 0000 00000000 uid [ultimate] test <test@example.com> ssb> ed25519 2026-07-23 [A] ssb> cv25519 2026-07-23 [E]</code></pre> Note the ></code> symbol next to keys. It indicates that the keys is stored on a token, not on your computer. Changes to that key can be made the standard GPG way of using gpg --edit-key KEY_FINGERPRINT</code> command. That can be useful to add extra identities with different email addresses for example. Step 4: Import keys on other computers</h3> One thing that I noticed basically none of the guides on the internet is talking about is loading keys from your token into the local keyring so you can actually use them. During initial key s setup public keys are imported and private key stubs are added to the keyring, but if you want to use the same already configured token on a different device or if you changed your operating system, you need to set a few more things to be able to do that easily. GPG’s built-in card environment includes fetch</code> command which does exactly that, but for it to work properly you need to configure a URL on the internet from which your public keys will be imported. I genuinely don’t understand why this can’t be simply done locally since all the keys are literally there, but that’s the way it’s done 🤷 If I’m actually wrong here and there’s a better way, please let me know. But alas, for this step you need to export your public key and put it online (which is fine! public keys are meant for sharing!). You can use a well-established public PGP key server such as keys.openpgp.org</a> for example, but I just uploaded mine to my website</a>. Here’s a command to export your public key in a plaintext readable format: $ gpg --export --armor KEY_FINGERPRINT</code></pre> Output should look like this: -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEamJjmBYJKwYBBAHaRw8BAQdAqTghyjm+5ajp71X4Z7wwfbVoD+dQllE5 uIh+y/gq3XHNF3Rlc3QgPHRlc3RAZXhhbXBsZS5jb20+wowEEBYKAD4Fgmpi Y5gECwkHCAmQyhE0EsNnUPADFQgKBBYAAgECGQECmwMCHgEWIQRDMznItGnQ 7ciFoFPKETQSw2dQ8AAA/zUA/3tx7GNTsdR1VDAvu/+H6T4z05Iyx2Z1+vlF /w71qFAUAP9y01ZJc0GT5PlpXcYUNaKnw9Ppviok3mu5GgLaigrIDM44BGpi Y5gSCisGAQQBl1UBBQEBB0BWTiDR/eDmQzpalzQ2CiygNpPxDRtgHmsznHy/ SCurJQMBCAfCeAQYFgoAKgWCamJjmAmQyhE0EsNnUPACmwwWIQRDMznItGnQ 7ciFoFPKETQSw2dQ8AAAvgwBAMNi62VPYmYmcpGmzvK0kdFQKJXyjCbKl/Dd 6du6d1BXAQDazFUtOA1Zn8lK5YHZjoOL7xQZsyUIEl12WwQUxXd/Ag== =WUWn -----END PGP PUBLIC KEY BLOCK-----</code></pre> You can either paste it into an online key server or save it as a file with .asc</code> extension and host somewhere. Once you do that, you can go back to the GPG environment on your key and set up key fetching: gpg/card> url URL to retrieve public key:</code></pre> You need to enter a full URL from which your public key can be obtained, for me it’s going to be https://flufftech.net/pgpkey.asc</code>. And it’s done! You can set up some other extra settings that are mostly unimportant (such as name</code> or salutation</code> which are mostly used with an actual card-format smartcards) or type quit</code> to exit the GPG shell, since you’re set up now. Now when you connect your token to a new computer, you can import your keys into the local keyring in seconds by using this procedure: $ gpg --card-edit gpg/card> fetch</code></pre> And your keys are ready to use. Step 5: Setting up SSH key</h3> An extra feature of this setup is that it you use your PGP key as your SSH key. Note: This is different from generating ed25519-sk</code> or ecdsa-sk</code> type keys with ssh-keygen</code>, as that will generate a special type of dedicated SSH private key that uses FIDO functionality of your token to access. If you don’t want to use PGP features of the token or you have a FIDO-only U2F device without PGP support, that might be a great alternative for you! </div> But since I have all my keys on the token, we’re going to use them together with gpg-agent</code> to use them for SSH. Note: The following section assumes you don’t already use gpg-agent</code> as your SSH agent. If you do, I’m sure you can figure it out. </div> To do this, you need to edit your ~/.gnupg/gpg-agent.conf</code> file and add the following config options to it: enable-ssh-support write-env-file</code></pre> enable-ssh-support</code> is pretty self-explanatory, it enables support for SSH keys in gpg-agent</code> – it will automatically load SSH key from your PGP keys. write-env-file</code> is used to share agent information with other processes and sessions as a file so they can always access it. Another option I really recommend you set up is pinentry-program</code>, which will be used to help you with PIN/password prompts. On GNOME the best choice is /usr/bin/pinentry-gnome3</code>, if you run KDE use /usr/bin/pinentry-qt</code>. If you use GNOME, there is a decent chance that GNOME Keyring will interfere with this so it’s best to disable the SSH agent feature of it. That’s usually done by stopping and disabling gcr-ssh-agent.socket</code> and gcr-ssh-agent.service</code> systemd units with systemctl</code> command. The last step is to reload gpg-agent</code>: $ gpg-connect-agent reloadagent /bye</code></pre> And set SSH_AUTH_SOCK</code> env variable for your session. I use fish</code> shell so I added the following 2 lines into my ~/.config/fish/config.fish</code>: set -gx SSH_AGENT_PID "" set -gx SSH_AUTH_SOCK "$XDG_RUNTIME_DIR/gnupg/S.gpg-agent.ssh"</code></pre> If you use bash</code>, add this into your ~/.bashrc</code>: unset SSH_AGENT_PID if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)" fi</code></pre> Make sure to reload your session for this to take effect. Assuming everything worked out the way it should, this should be enough to automatically load SSH key from your token whenever you plug it in. You can verify that by running this command: $ ssh-add -L ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFYX3suL5yb0099HU5jIz+ttx8Q8VMFRKtzLsrZu0ikX cardno:0000_00000000</code></pre> If the output you see is similar to the above, with standard SSH key and a comment including your token’s serial number, it’s all good. If there’s nothing, it means something is wrong with the gpg-agent</code> configuration to appending your SSH key into ~/.gnupg/sshcontrol</code> file. You can fix that manually by finding the keygrip of your [A]</code> subkey from the token: $ gpg --list-keys --with-keygrip . . . sub ed25519 2026-07-23 [A] Keygrip = F635631A0BD254172DA068AED25E8C0B74BB40D5</code></pre> Then add the keygrip value (here it’s F635631A0BD254172DA068AED25E8C0B74BB40D5</code>) into ~/.gnupg/sshcontrol</code> manually and reload the agent. That should do the trick. Alternative key generation for token backup</h2> As I mentioned before, generating keys on the token is safer, but has its downsides in the form or losing the ability to create backup of private keys. Oddly enough, GPG doesn’t let you know about this limitation. Attempting to export your private key stored on a token with a command like this: $ gpg --export-private-keys -a KEY_FINGERPRINT > private.key</code></pre> Will result in an export of a private key stub which is effectively garbage. It really should result in an error instead but it doesn’t and this behavior can be really confusing. A solution to this problem can be generating a set of keys locally on your computer and then copying them over to your token. In terms of security this is worse, as private keys aren’t isolated entirely inside the token, but this will let us have two tokens with the exact same set of keys for backup. Step 1: Temporary keyring</h3> For this process we will create a temporary GnuPG home directory in our computer’s RAM so none of the sensitive data makes it to storage. Let’s start by verifying that local /tmp</code> directory is actually on physical hardware RAM. It usually is but now always. $ df -h . . . tmpfs 12G 21M 12G 1% /tmp</code></pre> If you see a line like this including tmpfs</code> next to your mounted /tmp</code> directory, you’re good to go. If it’s anything else, stop right here and get yourself a tmpfs</code> working directory for this purpose. So now we can switch GnuPG to a temporary working space: $ export GNUPGHOME="$(mktemp -d)"</code></pre> And verify it succeeded by running: $ gpg --list-secret-keys</code></pre> It should be empty Note: Remember that this $GNUPGHOME</code> override is specific to your currently open shell, avoid doing any of those operations in a different shell session from now on. </div> Step 2: Local key generation</h3> Now let’s create our keys: $ gpg --full-generate-key</code></pre> Follow the usual options for key generation, with the default ECC (sign and encrypt)</code> & Curve 25519</code> combo being a good option. GPG will be very unhappy with you when you decide to make a key without a password, but for this purpose it’s actually okay to do it this way since key on the token will be protected by PIN for all sensitive operations. The default key generation process creates only [SC]</code> primary key and [E]</code> encryption subkey. We have to create an additional [A]</code> authentication subkey manually: $ gpg --expert --edit-key KEY_FINGERPRINT</code></pre> Once in expert edit mode, let’s add a subkey: gpg> addkey Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (10) ECC (sign only) (11) ECC (set your own capabilities) (12) ECC (encrypt only) (13) Existing key (14) Existing key from card Your selection?</code></pre> Select 11</code>. The default will be a signing [S]</code> subkey. Possible actions for this ECC key: Sign Authenticate Current allowed actions: Sign (S) Toggle the sign capability (A) Toggle the authenticate capability (Q) Finished Your selection?</code></pre> First select A</code> to allow authenticate, then S</code> to disable sign feature. Then Q</code> to save. Select the default Curve 25519</code> curve, your preferred expiration and skip setting a password again. Output should look like this: sec ed25519/8BC55E989F30E234 created: 2026-07-23 expires: never usage: SC trust: ultimate validity: ultimate ssb cv25519/CA1E4DF2A5758FEB created: 2026-07-23 expires: never usage: E ssb ed25519/DF08FED94A66B8FB created: 2026-07-23 expires: never usage: A [ultimate] (1). test <test@example.com></code></pre>Step 3: Moving keys to the token</h3> Now we can begin copying our keys to both tokens. A few notes: keytocard</code> command can only move one key or subkey at a time, so for each token you need to use it 3 times.</li> Be careful to not use save</code> command before all keys are moved to both tokens, as it will remove the locally stored key after keytocard</code> command it used.</li> After adding keys to the first token, swapping tokens will confuse GPG and it will not be able to do anything. Use quit</code> command and re-enter the --edit-key</code> environment.</li> </ol> Moving primary key: gpg> keytocard Really move the primary key? (y/N) y Please select where to store the key: (1) Signature key (3) Authentication key Your selection?</code></pre> Select y</code> and then 1</code> To move the [E]</code> subkey first copy it’s fingerprint from the list, then select it: gpg> key E_SUBKEY_FINGERPRINT gpg> keytocard Please select where to store the key: (2) Encryption key Your selection?</code></pre> Select 2</code> Now to move the [A]</code> subkey you first need to un-select the previous key, select [A]</code> key and only then you can proceed: gpg> key E_SUBKEY_FINGERPRINT gpg> key A_SUBKEY_FINGERPRINT gpg> keytocard Please select where to store the key: (3) Authentication key Your selection?</code></pre> Select 3</code> and type quit</code> Verify that all keys have been moved: $ gpg --card-status . . . Signature key ....: E6F9 C957 0C88 42FA 0BE7 8FE5 8BC5 5E98 9F30 E234 created ....: 2026-07-23 20:53:48 Encryption key....: 30C7 7655 B800 09A2 7C18 7BBB CA1E 4DF2 A575 8FEB created ....: 2026-07-23 20:53:48 Authentication key: A187 B940 5D19 F956 0D6F 3C81 DF08 FED9 4A66 B8FB created ....: 2026-07-23 21:03:39 General key info..: pub ed25519/8BC55E989F30E234 2026-07-23 test <test@example.com> sec ed25519/8BC55E989F30E234 created: 2026-07-23 expires: never ssb cv25519/CA1E4DF2A5758FEB created: 2026-07-23 expires: never ssb ed25519/DF08FED94A66B8FB created: 2026-07-23 expires: never</code></pre> If the output looks something like this, congrats, the move has worked! You can now swap the tokens, re-enter --edit-key</code> environment and repeat the exact same procedure. Note: It’s best to export public key for the fetch</code> functionality on the token before you delete local copy of all keys because otherwise --full-generate-key</code> can import private key stubs from token but only one at a time. Using fetch</code> grabs them all. </div> Once you’re done doing that, you can actually quit edit environment using save</code>, which will remove local copy of all affected keys. Wow that was pretty long</h2> If you reached this far wow I’m proud of you, you’re such a massive nerd, you deserve a medal 🏅 I have a few words to end this post with, mostly that it was a really interesting journey that tought me some cool things and overall made me more comfortable with handling PGP keys. It was definitely worth it and I sincerely recommend you play with it yourself. A bonus piece of information I have for you is that this entire project was much funnier for me considering that the entire time I’ve been setting up cryptography stuff on my collar :3 </picture> </a> This cool accessory is like 1000x cooler now :3</div> </figcaption> </figure> </div> Now I literally can SSH into my servers with my collar and it’s genuinely perfect. If you have any questions or want to share your thoughts, feel free to send me an email or reach me on the Fediverse ^^

Scanning a (literal) trashcan roll of photographic film rail — Sat, 13 Jun 2026 00:00:00 +0000 Today I’m going to tell you a short story of a negative I found near a trashcan a while ago. Yes, seriously. I still don’t know how this happened and why would anyone throw film away but here we are. The negative itself</h2> Let’s start with the main character here – the negative. After I found it and did a quick field inspection, it turned out to definitely contain images and be somewhat damaged. It later turned out the damage was mostly local and not too bad. </picture> </a> Negative as it was found</div> </figcaption> </figure> </div> The obvious next step was to investigate it further, clean it and attempt to retrieve images from it. It turns out the film used was Konica VX200, a color film that was manufactured until 2007 as far as I know. This fact was the first hint that the negative is old but let’s not get ahead of ourselves. Concentrated isopropyl alcohol did just fine cleaning the negative, but that was the end of obvious solutions. My only option to get images out of it in home environment was DSLR scanning, a procedure that is effectively taking a photo of the frame on the negative with a digital camera and processing it digitally from there. Properly executed DSLR scanning is about the cheaper and most accessible way of scanning film at home (dedicated drum scanners for photographic film tend to be very expensive), but it still requires some hardware. Mostly a good quality backlight and a bracket to hold the film in place. Sadly, I don’t have any of those things, so I had to improvise with what I had on hand. The (stupid) method</h2> Due to a lack of either a backlight or a bracket, I decided to go at it redneck style and use whatever I had, knowing full well the tools will be suboptimal, and the results won’t be nearly as good as they could’ve been with proper equipment. But given the way I got the negative to begin with and the potential to have fun, sure, let’s go. My trusty Pixel 7 phone set to max brightness with HDR took the role of backlight – a solution that works just fine except for one tiny issue. You can see the LED matrix in every image, making it basically impossible to get all the detail from the image. Effective resolution goes down a lot. And instead of a bracket, I grabbed two hex keys and put them at the edges of the frame 👍️ </picture> </a> The scanning setup I used was a little bit suboptimal, let’s say</div> </figcaption> </figure> </div> With that setup ready, it’s time to grab a camera and get to “scanning”! </picture> </a> A very professional work environment</div> </figcaption> </figure> </div> I used my Nikon D3200 with a Sigma 18-35mm f/1.8 AF lens. It’s not a micro lens, another less-than-ideal thing in this setup, but it was able to focus just close enough to make it work with some fair bit of cropping later in editing. </picture> </a> Negative image opened in Lightroom – cropped and perspective adjusted</div> </figcaption> </figure> </div> Once all frames were individually photographed, I got to work. My RAW editing software of choice is Adobe Lightroom, 2015 version ran through Wine on Linux. That’s a whole other topic I should probably write about, but alas. It was only during this project when I realized working with the RGB levels curve is very annoying and buggy in this setup, so I decided to split the editing procedure into two steps: Lightroom: Crop, perspective correction and other RAW-level small fixes to the photos</li> GIMP: Inverting and color-correcting exported JPEG files</li> </ol> Your browser does not support the video tag. Download the video here</a>. </video> It turns out GIMP is actually really good for inverting negatives</div> </figcaption> </figure> </div> The second step turned out to be actually surprisingly simple and quick. As it happens, GIMP is very competent at doing exactly this task without any complicated procedures. Inverting color channels is as simple as clicking one menu option, and the buil-in automatic color equalization tool was plenty good enough for the purpose of this project. The end results were definitely much better than I expected when starting this project! The result and findings</h2> Now I want to take a moment to talk about the final results and findings about the content of the roll once I was able to take a proper look at it. Let’s start by addressing something that some of you may think – no, there are no nudes on that film. There is nothing spicy or inappropriate. Actually, looking at the photos, it feels like someone’s early adventures with photography. Images include photos people, house pets, architecture and (I think) some documentary of a trip, school trip it looks like. An interesting part of this is also that judging by the way people are clothed, the design of interiors and a very old-school bus in one of the photos, I think these pictures were taken around 1990s or early 2000s – old stuff. I was able to recover 33 frames out of the roll. The rest was either underexposed to a point of being unrecoverable or just blank. Actually, the way there are blank spaces in the middle of the film makes me think the camera used might’ve been one of the Zenit Soviet-made SLRs. The one I own (Zenit TTL) can sometimes get “stuck” in a way that allows film to be advanced without shots being taken. I had that exact issue before. Either way, I found the experience of working on this negative quite fascinating. There is a feeling of uncovering a mystery, and ultimately working with photos that were taken by a stranger, capturing moments they spent with family or friends is oddly intimate, like entering that person’s life and observing it with a degree of insight that wouldn’t be possible any other way. That ultimately is the reason why I won’t share most of what I found, but I am going to include a few photos just to give you a taste of what I discovered. </picture> </a> A cat photo, ofc :3</div> </figcaption> </figure> </div> </picture> </a> </figure> </div> </picture> </a> One of the prettiest images of the roll</div> </figcaption> </figure> </div> </picture> </a> Vibes…</div> </figcaption> </figure> </div> </picture> </a> </figure> </div> </div> And one last thing that I got out of this adventure is an even stronger desire to get the hardware and do proper DSLR scanning of my own film in the future, heh. Cheers! This website is now using Zola rail — Sun, 11 May 2025 00:00:00 +0000 After writing the last blog post</a> it became obvious to me that migrating to a proper static site generator with templates and all the fancy stuff is necessary, so that’s what I’ve been working on for the past few days. Historically this website has always been just raw HTML with a bunch of CSS thrown at it. That had it’s benefits like me being able to just tinker with everything and maintain a sense of absolute minimalism (which to be honest was completely fine back when it used to be just a front page), but as the site grew a bit, it became a massive chore and a pain in the ass every time I wanted to change or add anything. So anyways, my choice was mostly limited to Hugo</a> (written in Go) and Zola</a> (written in Rust). Ultimately I decided to give Zola a go and stuck with that choice. I still decided to not use any of the publicly available templates and just re-created the whole layout of my original page with some changes, because why not. In this post I will yap a little bit about my experience with this transition, what improvements happened, what it means for this blog and which things annoyed me in the process. Enjoy. Changes</h2> For the starters, while migrating to Zola i decided to make some changes to the website. Some content got dropped. It may come back at some point in a slightly different form but my photography showcase and a somewhat already outdated “my hardware” pages are gone. This is not an accident. Also, the about me</a> page has been refreshed. Go give a look if you want. Lastly, the theme while mostly unmodified (not without trying, I wanted to give the color scheme a refresh but hit a creative wall) has some more-or-less minor changes too. Honestly I like it better now :3 Benefits for me and (maybe) for you</h2> So, why do I even bothered so much? Well, mainly because I wanted to write more blogs for a while and one of the things stopping me (besides ADHD) has been the painstaking process of manually working with HTML to post anything and then very carefully verifying that everything works. In a sense, every blog post means writing a website from the scratch 🥴 Now I can work with a regular markdown</a> to write content which is way faster and less annoying, so you can (maybe! pls don’t hold me liable here!) expect more posts coming in the foreseeable future. In addition to that the Atom/RSS feed</a> is now automatically generated, so the chance of me forgetting to update it when I publish new content drastically drops ^^ Also finally I decided to publish the source code of this site publicly now that it’s a bit less of a hot mess – it’s available here</a> on the Forgejo</a> instance hosted by my partner</a> :3 Why the switch was a little annoying</h2> Some things with getting into static site generators with their own templating engines are a bit annoying. Honestly what made me struggle a lot here especially at the very beginning was the documentation. I’m mostly mentioning it here at all to remind those of you reading this about something I find very important while writing good docs. Please, for the love of gods, make sure you don’t write it for yourself, actually Zola’s documentation in many aspects strikes me as a text written by the developers for themselves, without even realizing that. It makes a lot of assumptions about the knowledge of the reader that for many (most?) of them won’t be true. It’s very hard to find basic information about the syntax of templating language and how different elements of the site interact with each other, and those bits that mention it are very technical in a way that might be difficult to understand for many people. Summary</h2> So yeah to end this too-long-for-its-own-good blog, I had fun. And now my site is better and easier to deploy new content. I will probably make some updates to it and improve it further soon, but for now I’m satisfied enough to show it to the world. Cya! Running Signal desktop app natively on Wayland rail — Sun, 04 May 2025 00:00:00 +0000 Signal, the private messaging app, ships an Electron-based desktop application available for Windows, Mac and Linux computers. The Linux version by default does not support Wayland natively and will run through XWayland in a Wayland environment despite generally accepted system-wide configuration that should cause a different behavior. That is not without a reason. Signal desktop for Linux ships its own packaged Electron build which does not respect $HOME/.config/electron-flags.conf</code> configuration nor has any custom -flags.conf</code> file to pull configuration from. I can speculate this behavior is due to (understandable) security concerns that would come from using external system-wide Electron and its configurations. In this post I will summarize my journey into configuring Signal to work natively on Wayland and issues I encountered along the way. Making Signal not use XWayland</h2> Note: At the beginning of writing this blog, I was not aware of Signal actually respecting an environment variable and wanted to suggest a different, more complicated solution. The things you get to know ^^ </div> Setting ELECTRON_OZONE_PLATFORM_HINT</code> environment variable to "auto"</code> will make Signal start without using XWayland. This behavior didn’t use to be the case in the past, and since Signal doesn’t respect Electron flags set in a config file, the only option of making it run on Wayland was adding command-line flags directly into the .desktop</code> file. That obviously had its implications for example for window managers such as Sway, because they don’t use those files to start applications. Usually the easiest way to set up an environmental variable for your system is by creating a file in ~/.config/environment.d/</code> folder. I will assume you never set it up before, so here is what you need to do: $ mkdir ~/.config/environment.d/ $ echo 'ELECTRON_OZONE_PLATFORM_HINT="auto"' >> ~/.config/environment.d/variables.conf</code></pre> Note: This solution only works for distributions using systemd. If you don’t use one of those, I’m sure you know best how to set up env variables on your system! </div> After variables from the configuration file are loaded, Signal (and other Electron applications) should start without using XWayland. You can verify that by running xlsclients</code> (signal-desktop</code> should not appear there). However, this does not mean there are no issues… Problems ahead</h2> There are some problems^{[1]</a> with running Signal natively on Wayland. I will only cover some of them here, consult GitHub if you encounter different ones.} Problem 1: Starting minimized</h3> Note: Check if GitHub issue #6368</a> hasn’t been fixed at the time of reading. Maybe you don’t need to do anything! </div> Trying to run Signal, you may notice it seems to not work initially, or only starts in system tray, not launching the window and you need to start the application twice or more to actually get it running. This might not be a desired behavior and does not normally happen under X11. This problem can be approached in a few different ways. Solution 1: JSON config</h4> The first solution is changing the maximized</code> key within ~/.config/Signal/ephemeral.json</code> file from false</code> to true</code>. But this does not fully solve the issue, as contents of ~/.config/Signal/ephemeral.json</code> are overwritten by Signal on every startup. To solve this, you may need to create a script that will be run every time the app is closed or before it is started, setting the window maximization key to true</code> every time. Solution 2: .desktop</code> file</h4> Note: If you use a window manager, ignore this section entirely and skip to the section below</a> instead. </div> Another solution is less elegant and involves modifying the .desktop</code> file used to run the application in a desktop environment. That file controls entries in the application list! First, you need to copy a system-wide .desktop</code> file and make a local copy of it. Then open it using a text editor: $ cp /usr/share/applications/signal-desktop.desktop ~/.local/share/applications/ $ nano ~/.local/share/applications/signal-desktop.desktop</code></pre> Once you have the file opened, find a line starting with Exec=</code>. It should be somewhere in the upper half of the file. Replace it with: Exec=signal-desktop & sleep 1 && signal-desktop</code></pre> After saving, you need to update the database of .desktop</code> files: $ update-desktop-database ~/.local/share/applications/</code></pre> That should result in the Signal application being called twice, once to start it minimized and once more to make it show up. Solution 3: Patched build</h4> Third way of fixing this is, if available on your distribution, installing signal-desktop-fix-sway</code></a> build of Signal. It does fix this issue. Said package is available for example on Arch Linux through AUR. Problem 2: Visual glitches</h3> Running Signal on Wayland not through XWayland may also cause a bunch of different visual glitches such as visual stuttering, glitchy shadows around the window or blurriness (e.g. with UI fractional scaling enabled). Unfortunately I do not know a way of fixing those. We probably need to wait for the developers to fix this :/ If you have any questions, feel free to reach out to me on the fediverse – you can find me there under @rail@flufftech.net</code></a>.

Summary</h2>
So yeah to end this too-long-for-its-own-good blog, I had fun. And now my site is better and easier to deploy new content. I will probably make some updates to it and improve it further soon, but for now I’m satisfied enough to show it to the world.</p>
Cya!</p>

Solution 3: Patched build</h4>
Third way</strong> of fixing this is, if available on your distribution, installing `signal-desktop-fix-sway</code></a> build of Signal. It does fix this issue. Said package is available for example on Arch Linux through AUR.</p>`

rail

Configuring Token2 security key for PGP and SSH

Scanning a (literal) trashcan roll of photographic film

This website is now using Zola

Running Signal desktop app natively on Wayland

rail

Configuring Token2 security key for PGP and SSH

Step 5: Setting up SSH key</h3> An extra feature of this setup is that it you use your PGP key as your SSH key.</p>

Scanning a (literal) trashcan roll of photographic film

The negative itself</h2> Let’s start with the main character here – the negative. After I found it and did a quick field inspection, it turned out to definitely contain images and be somewhat damaged. It later turned out the damage was mostly local and not too bad.</p>

This website is now using Zola

Summary</h2> So yeah to end this too-long-for-its-own-good blog, I had fun. And now my site is better and easier to deploy new content. I will probably make some updates to it and improve it further soon, but for now I’m satisfied enough to show it to the world.</p> Cya!</p>

Running Signal desktop app natively on Wayland

Summary</h2>
So yeah to end this too-long-for-its-own-good blog, I had fun. And now my site is better and easier to deploy new content. I will probably make some updates to it and improve it further soon, but for now I’m satisfied enough to show it to the world.</p>
Cya!</p>