I use it for git commit signing.

If you ignore most of it, it's actually fine.

How could something designed for human communication be so utterly cumbersome and confusing ?

Several reasons, I guess?

1. The PGP (later, OpenPGP) protocol.

The proprietary PGP software, which was the initial implementation of the PGP protocol(s) also suffered from usability problems:

• 1998. Whitten, A., and Tygar, J. D. Usability of Security: a case study
• 1999. Whitten, A., and Tygar, J. D. Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0
• 2015. Atwater, E., Bocovich, C., Hengartner, U., Lank, E., & Goldberg, I. Leading Johnny to Water: Designing for Usability and Trust
• 2015. Ruoti, S., Andersen, J., Zappala, D., & Seamons, K. Why Johnny still, still can't encrypt: Evaluating the usability of a modern PGP client

2. GnuPG maintainers are implicitly using asymptotic software versioning

Donald Knuth was probably the most notable proponent of the idea that software packages should increasingly tend toward stability, with fewer and fewer patches needed. He used explicitly asymptotic version numbering for TeX and Metafont.

Some of the quotes in OP's video make imply GnuPG's maintainers are implicitly following a similar approach, e.g. the section about "Sequoia's need for churn".

With encryption software, there is an especially strong argument for being conservative about changes. Patches may have unforeseen consequences, adding subtle vulnerabilities.

However, the downside of this, as the gpg.fail team pointed out, is that it biases the GnuPG maintainers towards excessive rejection of patches. Especially patches that would improve usability. Arguably, TeX suffered from a similar bias; hence the development of LaTeX and newer TeX front-ends to improve usability.

3. Changing the interface would be effortful

Improving GnuPG's interface would require quite a lot of work in itself, both to the codebase and the documentation.

Releasing a version with those changes would also require fielding a lot of support queries for many years, because decades of software manuals all over the web were written for the traditional GnuPG interface, and aren't going to be updated overnight. Some of those manuals will surely never get updated, because they are no longer maintained even though they are still online and still used.

I can sympathise with the GnuPG maintainers for finding this daunting. But the improvements are needed. Thankfully, developers of tools like minisign, age, and sequoia are taking on much of this work; it's just a pity that the work had to be done in this fragmented way through third-party efforts, instead of in GnuPG itself.

The video, probably.

however would never trust "age" with what they did

What happened with age (or its devs?) that made you not trust it?

Bruce Schneier, who invented the term security theater, would perhaps disagree with you.

Follow up: I suppose the verification could be done in a container?

Cleatext signing (having the signature and data in the same file) is broken in many ways. It is possible to put unsigned data at the top of the file in a way that sha256sum will use it. Watch the 39c3 GPG talk if your interested in the gory details.

The solution is to use detached signatures (checksum.txt and checksum.txt.gpg to verify that). This makes sure that all of checksum.txt is actually covered by the signature.

Lexi Groves is quoting Fedora’s own mailing list irt social engineering. Both Fedora’s instructions are wrong, and the method to properly verify ISO, that to be brutal, should have been outdated decades ago, is “dangerously wrong.” It's a nice gibe.

Haskell

I'm learning OCaml right now and it's been pretty dang awesome so far.

I'm doing Advent of Code 2025 and have made it to day 7 part 2. I've never done an AoC where my first attempt to run the code was correct on both the sample input and real input so many times in a row. I'm in love with this language.