One of the worst UI ever

Posted Jan 27, 2026 21:44 UTC (Tue) by cyperpunks (subscriber, #39406)
Parent article: A critical GnuPG security update

GnuPG is a real pain to use, the user interface is just horrible.

If the software logic is mirrored by the ui the internals must be a messy pile of cr*p.

It's impossible to trust such thing. Using archaic C to write software in 2026 should plain and simple be forbidden.

to post comments

One of the worst UI ever

Posted Jan 28, 2026 9:44 UTC (Wed) by lmartelli (subscriber, #11755) [Link] (4 responses)

GnuPG was first released 1997-12-20 (see https://www.gnupg.org/download/release_notes.html), when C/C++ was the obvious/default choice to start any software project like this.

One of the worst UI ever

Posted Jan 28, 2026 15:39 UTC (Wed) by Heretic_Blacksheep (subscriber, #169992) [Link] (3 responses)

But not the only choice in 1997. There were better languages and tooling even in 1997 like Ada, but tribal/religious arguments poopooed them similar to the nasty back and forth between C zealots and other systems oriented languages today.

One of the worst UI ever

Posted Jan 28, 2026 16:01 UTC (Wed) by anselm (subscriber, #2796) [Link]

To be fair, in 1997 gcc was very widespread but the Ada frontend to gcc wasn't. Irrespective of the relative merits of Ada vs. C as programming languages, if you wanted wide portability for a tool like GnuPG, then C was at least a very strong contender because C compilers were a lot easier to come by than Ada compilers.

One of the worst UI ever

Posted Jan 28, 2026 16:22 UTC (Wed) by farnz (subscriber, #17727) [Link]

Ada's major fault back in 1999 (when I looked at it for work purposes) was the lack of a decent, Free (or even cheap) compiler. GNAT didn't become a decent Ada compiler until 2004 or so.

It was literally priced out of the market at the time - Keil's C compiler for Infineon C16x, while awful, was the same price for a company-wide licence as the cheapest Ada compiler I could find, and that would have been an add-on to VxWorks.

One of the worst UI ever

Posted Jan 31, 2026 14:31 UTC (Sat) by apoelstra (subscriber, #75205) [Link]

The problem that leads many cryptography libraries to use C, even in modern times, is that C gives you tooling to write constant-time code -- no runtime, obscene pointer semantics that make it possible to prevent compiler assumptions about pointer access ordering or aliasing (and extensions for explicit fences and the like); the ability to write zero-heap-allocation code; low-level debuggers and dissemblers; and of course, inline assembler.

C is arguably awful at each individual thing I listed, but it has them all, and to the extent that some of them are a black art, there exist people with decades of experience working with popular compilers to achieve them.

Now, maybe gnupg could've written its core secret-data-handling crypto algorithms in C (or assembler) and used FFI bindings to use a nicer language for everything else. But then you'd need a language and toolchain that can mix well with C.

One of the worst UI ever

Posted Jan 28, 2026 13:40 UTC (Wed) by hmh (subscriber, #3838) [Link] (2 responses)

Please hold anything doing dependency-hell / supply-chain-hell to the same standard.

In both cases (C and dependency-hell language ecosystems), proper discipline (which DOES include strong linting and static checking, etc) goes a long way to avoid the pitfalls.

I do think "C" should be kept away from inexperienced, lazy, or vibe-coders though. And I certainly agree there are much better choices for new projects/greenfield, unless the requirements force you towards C/C++ (typically on small embedded).

One of the worst UI ever

Posted Jan 29, 2026 8:58 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

We should reconsider the use of the term "dependency hell", especially if people just use it as a synonym for "large number of dependencies" because a lot of languages with small numbers of dependencies have small numbers because the cost of starting a new dependency is high due to bad tooling and as a result each dependency is huge and contains a lot of code any given user of that dependency does not use and that nobody has touched for years.

This is just a worse way to structure the same amount of dependency code because we can't easily talk about individual parts of the code in dependencies.

One of the worst UI ever

Posted Jan 29, 2026 13:43 UTC (Thu) by ptime (subscriber, #168171) [Link]

I would consider having boost as your only dependency a great example of being in hell

One of the worst UI ever

Posted Feb 2, 2026 17:22 UTC (Mon) by cytochrome (subscriber, #58718) [Link] (1 responses)

"the internals must be a messy pile of cr*p." Have you looked at the internals? Do you have some examples you could share or constructive advice/PRs to provide to the developers?

One of the worst UI ever

Posted Feb 2, 2026 18:48 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

It's pretty much a certainty that any GNU C code written before 2010-s is a mess. GPG is no exception. E.g. look at this: https://github.com/gpg/gnupg/blob/987c6a398a9505399b2c25a...

Static buffers with manual length calculation, stpcpy, juggling pointers in security-critical code. What could possibly go wrong?