Yes, “distant state invariants” is indeed useful - although I tend to call it “locally correct code” (i.e. code which isn’t only correct, but where you can convince yourself it’s correct by just looking at the surrounding lines. Such code is much less likely to break under maintenance.)
Fix commit: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=512c0c75276949f13b6373b5c04f7065af750b08
Announcement: https://lists.gnupg.org/pipermail/gnupg-announce/2021q1/000456.html
Some meta commentary: https://twitter.com/FiloSottile/status/1355124205080240131
That’s a great Twitter thread.
I hadn’t seen the concept “distant state invariants” before, though it seems like a very useful concept!
Yes, “distant state invariants” is indeed useful - although I tend to call it “locally correct code” (i.e. code which isn’t only correct, but where you can convince yourself it’s correct by just looking at the surrounding lines. Such code is much less likely to break under maintenance.)
I am frightened by the behavior and development style of (some) principal gnupg/libbcrypt developers:
I really like to switch away from
gpgas fast as possible. Luckily there are already some alternatives, like https://sequoia-pgp.org/, emerging.I would also look at age: https://github.com/FiloSottile/age
This does not seem to be OpenPGP based, which rules it out as gpg replacement.