Hector Martin

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.

Sure, I agree. I just don't think *this* is the bug we should be pointing at to make that point. You didn't check retcodes, you dun goofed. Even a Rust API with streaming support won't save you from that one.

You may not get to return streaming data in any safe API. That might just be a weakness in OpenPGP. You might have to chunk like everything else. Isn’t there chunking support in all this complexity?