hobbyist sysadmin and tech support person, still occasionally seen on IRC
interests: windows 98, macos 9/8, plan9, systemd, athena, x.25, all kinds of 80s-00s "retro" computing & networking
✨︎ no, I really don't have a good profile picture ✨︎
| Location | https://nullroute.lt |
| Location | Lithuania |
… I forgot to provide a link, didn't I? See, that's why I prefer to avoid relying on my own memory. 'xafter' is available from my miscellaneous utilities page (also including 'after' and lots of other unrelated things): https://www.chiark.greenend.org.uk/~sgtatham/utils/
Discord keeps dying mid-raid so we're trying out the built-in voice chat in WoW and it feels like we're dusting off a feature nobody has used in decades
I mean it works quite well (aside from the UI being five kinds of glitchy) but kinda has the vibe of going back to Win98 NetMeeting
@famfo sometimes I catch myself being defensively verbose (when posting on SO/StackExch. in particular), like "this is an important thing I want to drive home and if you just skim the post and miss the first time it was mentioned maybe the second time will work"
(I don't like overusing bold or <h2> like a bunch of others tend to)
@jpmens I don't really think it needs to be mutually exclusive with a Yubikey... e.g. I have a TPM key for SSH on one system *and* a Yubikey as a portable carrier *and* an eToken 5110 inside another system – and the rest of my security is still "yolo" level, really, but there are some things that the portable Yubikey isn't authorized to directly access while the laptop's key is, for example.
The `ssh` taking 1 second longer might be a hardware difference. On my ThinkPad it's 0.5s in total when using a TPM-backed RSA2048 key (it's not EC for silly reasons but I can't imagine EC being much slower).
Might also be a difference in which parent TPM key that SSH key was created under. Tradition carried over from TPM1 era is to generate a persistent root key (SRK) and store it in the TPM, so my test key is stored using the rough equivalent of "ssh-tpm-agent --parent-handle 0x81000001" (which is the agreed default handle for a SRK). At some point systemd-cryptsetup used a transient ECDSA SRK that it would generate deterministically each and every time. I'm not sure what ssh-tpm-agent does exactly, but I wonder if it might be using a transient parent key or something, which adds to the time needed to load the child key?...
there's *spectrograms* (p77)
https://eepublicdownloads.blob.core.windows.net/public-cdn-container/clean-documents/Publications/2025/iberian-blackout/Final%20Report%20on%20the%20Grid%20Incident%20in%20Spain%20and%20Portugal%20on%2028%20April%202025.pdf#page=77
four pages of eventvwr.msc of it falling over in just two minutes (p116)
https://eepublicdownloads.blob.core.windows.net/public-cdn-container/clean-documents/Publications/2025/iberian-blackout/Final%20Report%20on%20the%20Grid%20Incident%20in%20Spain%20and%20Portugal%20on%2028%20April%202025.pdf#page=116
black start procedure (p339)
https://eepublicdownloads.blob.core.windows.net/public-cdn-container/clean-documents/Publications/2025/iberian-blackout/Final%20Report%20on%20the%20Grid%20Incident%20in%20Spain%20and%20Portugal%20on%2028%20April%202025.pdf#page=339