News for hackers. Stuff that matters.
Re:Sequoia-PGP – A new OpenPGP implementation in Rust by zaarn on Thursday August 02, 2018 @04:02AM (#17669930)
GPG is largely just this toString output parsing.

Which has been the source of a number of bugs in various GPG clients in the past (a few even on the HN frontpage for a few moments) and probably will into the future until GPG is no longer used.

tbh, GPG should just provide an RPC option so applications can securely pass data back and forth and receive proper error messages and codes. But I bet this won't happen because GNU fears that sort of things considering they won't split up the GCC compiler.

Re:Sequoia-PGP – A new OpenPGP implementation in Rust by scandox on Thursday August 02, 2018 @04:30AM (#17670033)
Well there is GPGME: https://gnupg.org/software/gpgme/index.html

But yes I mostly parse colon separated text.

Re:Sequoia-PGP – A new OpenPGP implementation in Rust by admax88q on Thursday August 02, 2018 @12:39PM (#17672880)
> But I bet this won't happen because GNU fears that sort of things considering they won't split up the GCC compiler.

That's unfounded, there are plenty of GNU projects that have an API.

Re:Sequoia-PGP – A new OpenPGP implementation in Rust by zaarn on Friday August 03, 2018 @03:10AM (#17677817)
It's not unfounded. The GCC compiler isn't splitting up because they fear someone would build a proprietary compiler using either backend or frontend API if they did it.

I can see that the same reasoning here would be valid; someone could write a proprietary GPG frontend.

Re:Sequoia-PGP – A new OpenPGP implementation in Rust by admax88q on Thursday August 09, 2018 @11:15PM (#17730439)
You have one example of a project not providing an API, however there are tons of other GNU projects which do.

Furthermore the GCC decision is well documented in mailing list posts, have you ever seen anyone involved in GPG development claim that they won't allow a library/frontend split for fear of someone writing a proprietary frontend?