Discussion
We report: last week, we stood outside at night for hours on end during the peak of the Perseids. Tonight, the sky is even clearer, and we would do it again - had the temperature not dropped by half since. Even our jacket feels a little flimsy after a few minutes of staring up.
@encthenet i really appreciated @astraleureka helping me to realize how difficult the block-level encryption problem is even if you allow yourself to have extra data per block somehow. i had especially been hoping to have distinct keys/key schedules used across the fs somehow, but i was quickly convinced that there's really no way to incorporate an additional trust root when the filesystem is the source of truth.
my entire purpose (which i believe merits both a filesystem and a kernel) is to make filesystem visibility into an analogue of virtual memory, i.e. processes live in their own chroot by default (all i/o is scoped to a named synchronization domain) and extending POSIX to incorporate structured mechanisms for explicit data flow (mostly in the form of "i/o transactions"). after write(), an i/o transaction call can progress the state machine (blocking or nonblocking) to synchronize the written data with another domain and/or to persist it to disk.
in particular i think separating the act of persistence from normal writes and shared file visibility offers an opportunity to employ cryptographic keys, as a way to serialize access to some sort of runtime capability. of course, if a cryptographic key to access secret data is written to disk in any form, then it is visible to an attacker--so that key can be encrypted with another key, making use of the structured supervisor hierarchy.
to answer your question:
What do you do when the key to your data leaks? How do you rotate it? How do you make sure that data encrypted with the old key is deleted?
i don't at all have the answers to this yet, but i think separating writes and visibility from persistence is a really important step. consider my (less difficult) case above, where a cryptographic key is used to encode access to some sort of runtime capability in a way that persists across shutdown. in that particular case, every time the process starts up, it can exchange its key for the capability, and then it can atomically regenerate a new key and ensure that one is persisted.
i'm obviously cheating and handwaving to an immense degree here, but i think that a graph of recursive supervisor processes (down from init) which can locate their persisted state and transform it into runtime state upon startup can define a tree of trust relationships which avoids deep structural dependence upon a particular cipher or master key
@encthenet @astraleureka that's a bit more of a long-term idea, but shorter-term i definitely plan to incorporate checksum and parity information for persisted data separately from the filesystem block layer as well. but that's mostly because i also really want filesystem subgraph snapshots to be serializable and i would like persistence to just take the form of serializing the in-memory filesystem representation
Yes. Totally. Back in the 1970s, when I was at school, it might have been ok for boys to learn to type. Perhaps. Although I never heard of anyone doing so.
In my academic girls' school, learning to type was definitely off the agenda. Because that suggested going on to secretarial/administrative work, rather than the professional careers we were expected to achieve, in which someone else would type for us.
@regordane @ai6yr @cavyherd @gannet It's interesting how that's changed, in only a few decades. Today, executives have secretaries and assistants, but typing is a minimal part of what they do, and high-speed, ultra-accurate typing (as taught 50 years ago in secretarial schools) isn't a particularly valuable skill. But executives now need to be able to type reasonably well themselves.
Are there current skills that now mark you as an "assistant" the way typing once did?
So, the evidence emerging is that the trade deal with Canada got nuked because at the last minute, Trump insisted the US control Canada's other trade agreements. Like "break your treaties with China or there's no deal" kinda shit.
Which Canada simply cannot do. You have to understand that part - if you do that, you might as well get ready for the annexation party.
HomePad code suggests it’ll act like a giant Apple Watch https://9to5mac.com/2026/08/19/homepad-code-suggests-itll-act-like-a-giant-apple-watch/?utm_source=dlvr.it&utm_medium=mastodon
@9to5Mac ugh, if this is the case then I’ll pass
The proper way to correct antivaxxers 
Kirkus calls it "very strange and strangely satisfying." Publishers Weekly says it is "as bizarre as it is meticulous." They're talking about my new novel, A WALL IS ALSO A ROAD. It's coming 10/6/26. Pre-order it: https://us.macmillan.com/books/9781250228031/awallisalsoaroad/
Plus: a teaser trailer! https://youtu.be/gHLnJQuyQQo?si=C-81S3QKV-iPuyO6
@hipsterelectron
You'll actually find soon that doing the symmetric part is easy. The hard part is key management including key rotation.
What do you do when the key to your data leaks? How do you rotate it? How do you make sure that data encrypted with the old key is deleted?
The recent ceph issue was partly they hadn't put together a plan on how to have users migrate to a new encryption scheme.
And having been around, encryption agility (switching ciphers) sounds great and is fine if your just interoperating with yourself, but throw in another implementation, and things get a lot more painful when you can't control which bad ciphers they choose to implement (see TLS cipher defaults in most web servers were [are?] terrible).
@encthenet i really appreciated @astraleureka helping me to realize how difficult the block-level encryption problem is even if you allow yourself to have extra data per block somehow. i had especially been hoping to have distinct keys/key schedules used across the fs somehow, but i was quickly convinced that there's really no way to incorporate an additional trust root when the filesystem is the source of truth.
my entire purpose (which i believe merits both a filesystem and a kernel) is to make filesystem visibility into an analogue of virtual memory, i.e. processes live in their own chroot by default (all i/o is scoped to a named synchronization domain) and extending POSIX to incorporate structured mechanisms for explicit data flow (mostly in the form of "i/o transactions"). after write(), an i/o transaction call can progress the state machine (blocking or nonblocking) to synchronize the written data with another domain and/or to persist it to disk.
in particular i think separating the act of persistence from normal writes and shared file visibility offers an opportunity to employ cryptographic keys, as a way to serialize access to some sort of runtime capability. of course, if a cryptographic key to access secret data is written to disk in any form, then it is visible to an attacker--so that key can be encrypted with another key, making use of the structured supervisor hierarchy.
to answer your question:
What do you do when the key to your data leaks? How do you rotate it? How do you make sure that data encrypted with the old key is deleted?
i don't at all have the answers to this yet, but i think separating writes and visibility from persistence is a really important step. consider my (less difficult) case above, where a cryptographic key is used to encode access to some sort of runtime capability in a way that persists across shutdown. in that particular case, every time the process starts up, it can exchange its key for the capability, and then it can atomically regenerate a new key and ensure that one is persisted.
i'm obviously cheating and handwaving to an immense degree here, but i think that a graph of recursive supervisor processes (down from init) which can locate their persisted state and transform it into runtime state upon startup can define a tree of trust relationships which avoids deep structural dependence upon a particular cipher or master key
On the way to see BTS. Extremely tempted to pretend I got confused on the way to the Ed Sheeran show.
@lavaeolus @histodons Ah, figures, the year of the Dutch constitution! https://nl.wikipedia.org/wiki/Grondwetsherziening_van_1848
@djoerd
https://nl.wikipedia.org/wiki/1848 - a long year in a very long century.
@lavaeolus @histodons
Sacht ma, ist kuscheln ein Kink? 🤔
@Fischblog Trägst du dabei ein Pokemonkostüm?
A journalist wanted to go to a Flock Safety convention.
Flock cancelled their registration AND got the hotel to cancel their room.
Enter Benn Jordan and *some equipment*, 😉.
I haven't had that much fun with a YouTube short in a while.
:freebsd: #BSD accounts to follow:
@netbsd - NetBSD Foundation
@bsdfund - Fund supporting BSD software, hardware, events
@openbsdnow - Unofficial OpenBSD news
@bsd - Unofficial bot posting the latest BSD security advisories
@bsdcan - Canadian BSD conference
@EuroBSDCon - European BSD conference
@tpid98 - BSD group posting videos from BSD conferences
🧵 1/2
I've watched it all the way through at least 4 of 5 times
@TheBreadmonkey Whoa, must be pretty decent if you keep coming back to it!
Not Found.
Install bonfire.cafe
Get the full app experience
![Chris [list of emoji]](https://nfts.freeradical.zone/accounts/avatars/109/127/168/397/951/576/original/e8a0b6da977923a8.jpeg "Chris [list of emoji]")
