We can use stronger terms here --- whatever else you think of PGP, the shell-out stdio "api" for PGP is dangerous (GnuPG will release unauthenticated ciphertext to "callers" of that API, with a warning you need to catch). This API was responsible for the Efail bugs --- which were horrible --- a few years ago. Don't ever do this.
How is that any more dangerous than a "real" library doing the same? Your code would still have to check whether the message passed the integrity check or not, just like it has to look for the warning on stderr. I can't imagine why doing a stream search for i.e. "WARNING: Verification failed!" is any less secure than checking result.verificationPassed (assuming the CLI messages won't change, which they won't since they're basically an API).
You could just as easily say a "real" command line interface wouldn't do the same thing.
Of course, it might make more sense for a library, "real" or not, to default to raising an exception with no output, not just a warning - especially for a security-critical application. But it's not like we've never seen unsafe defaults in a library before, even a crypto one.
Then again, it does make sense from a UX standpoint: I'd rather see "message could not be verified", followed by the decrypted content anyways, rather than not get any output. I know not to trust it, so knowing what it says is useful in terms of threat identification.
This is really not a CLI vs DLL issue - it's a default settings issue. And in this specific case, the unsafe option actually follows the standard more closely - it does not, after all, mandate integrity checking. Mybe it should, but that's a different conversation.
(Disclaimer: I'm not very knowledgeable with GPG, I assume that the warning means that the message hasn't been properly signed.)
> I'd rather see "message could not be verified", followed by the decrypted content anyways, rather than not get any output. I know not to trust it, so knowing what it says is useful in terms of threat identification.
You would know not to trust it, but it would be very easy for a novice user without an understanding of the implications to assume that it's just a minor error ("tech sometimes throws errors, but it works anyway, so why worry?"). But it damn sure is not!
My suggestion would be to print an elaborate and strong warning about the implications and provide an option to look at the message if you really know that it should not be trusted in the slightest.
This is how browsers handle TLS certificate issues and I'd call it a lot safer than showing the website anyway and displaying a small warning with some technical jargon.
