Best viewed with

openssl s_client -connect funnies.maurycyz.com:443 2>/dev/null < /dev/null | sed -n /BEGIN/,/END/p | grep --color=yes -z "[B]"

Base64 is somewhat limiting for ASCII art, but I present a quantum proof™ RSA certificate:

Check out my new TLS certificate: yes, Let's Encrypt signed this and yes, it works.

By the way, if you're looking for a clear description of the Alpine linux SSH bug, this is the official advisory: https://www.alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/

It's much clearer and to-the-point than the LLM written blog post that's been circulating on link aggregators.

Looks good to me

Animated jpeg test. Might need throttling and ctrl-shift-r:

Regarding the recent windows affair, you should probobly not use TPM based disc encryption (like default bitlocker)

Password based disc encryption works like this: the computer boots up, prompts you for a password, and uses that to decrypt your data. If someone steals the computer, it's mathematically impossible for them to see any of that data. However, if the computers breaks, you can plug the drive into another computer and decrypt it using your password.

TPM based encryption uses a chip in your computer which watches the boot process. If it's satisfied that the OS is unmodified, it sends the key to the processor.

This is bad for two reasons:

First, it does not actually protect your data if the machine is stolen: since the attacker can full boot it up without a password, any vulnerability in the OS will let them steal the data. This includes exploits that haven't been found yet, since the attackers can just keep the machine offline to prevent it from updating.

... also, the chip can't detect hardware tampering: it's possible to use a logic analyzer to intercept it's communication and read out the key.

Second, it will cause dataloss if your computer or operating system breaks. Since the key is stored in hardware, the drive cannot be unlocked from another computer, even if you need to do so. A live USB environment won't work either because the TPM will see that the boot chain is different and refuse to provide the key.

(Microsoft will of course insist that you are using it wrong, and didn't write down the 48 digit recovery key... but I've yet to see someone actually do that.)

TLDR; This configuration provides minimum security while maximizing the risk of dataloss.

Ok, so I was able to borrow some tungsten wire, but it's like 50 microns thick. It seals nicely, but it turns out that invisible wire = invisible shorts.

I'll either have to figure out a way to handle it or buy something thicker.

Homemade glow lamp: it's borosilicate glass melted with a oxy-propane torch. The outer diameter is 11mm.

The vacuum from my rotary vane pump isn't perfect, and there's a lot of residual air left over (that's what's glowing), but it should still be good enough for a triode or small CRT.

... although I haven't figured out a good way to do glass-to-metal seals yet. This one has copper plated steel wire (CTE=~10 um/[m*K]) passing through borosilicate glass (CTE=~3 um/[m*K]), which aren't close enough to stop thermal expansion from breaking the bond: The tube only worked for a few hours.

Might have to buy some tungsten wire (CTE=~4 um/[m*K]) or figure out a graded seal: soda lime glass bonds to the wire quite well, but it's is very annoying to work with.

A Sony FD-30A with it's 4.5cm diagonal "lolipop" CRT.

Whole unit is roughly the size of a modern cell phone, although quite a bit thicker.