Hector Martin

You can say it shouldn’t matter. But it really does. It’s nice to have Unix process management, it’s great to be able to lash things together with stringly types blobs, but eventually, we always move from pidgin to creole (to borrow phrasing from actual linguistics).

So how are process exit codes different from shared library return codes different, exactly? What makes it more likely that a stupid user will not check the former but will check the latter? Your argument is valid, but *this bug* is not a good example against processes and pipes

No, that’s what you’re not getting. It really is the fragility of the interface that gets you the “It returns content by default, hope you’re smart enough to check the error code, what do you mean nothing did” surprise not surprised dynamic

Arguably nobody wanted to add a —just-give-me-what-you-got command line (or —insecure).

This is a backwards compatibility argument. gpg was designed with streamability in mind. Sure, you could add an --unbuffered argument, but then you'd break many existing use cases. We both know "secure by default" choices are hard when your public interface is frozen.

They are. You tend to get to reset expectations with a major rev, which we do everywhere else every so often. libssh2 didn’t always exist.

This is harder with commandline apps (especially ones as dedicated to backwards compat as gpg) because people don't tend to introduce "gpg2" style "new interface here" breaks. It's a bigger change than library sonames (where you can at least install both at once).

But yes, would it be nice for gpg to have a different, more modern interface? Sure. I just don't think blaming this bug on that is fair or reasonable. Something to work towards perhaps, but not a Big Glaring Problem.