3 ms·

I agree that gpg did not age well. If we compare it to a different project with similar history: curl, it's apparent that gpg chose wrong on several fronts. It

I agree that gpg did not age well. If we compare it to a different project with similar history: curl, it's apparent that gpg chose wrong on several fronts. It should be a library first instead of a cli tool. Funny part is that even the library of gpg (gpgme) is internally calling the binary. I've played around with designing a higher level library to OpenPGP once (https://pypi.org/project/pysequoia/ https://pypi.org/project/pysequoia/) and personally I think it yields more readable, faster and secure code.

im3w1l 3y ago
> Funny part is that even the library of gpg (gpgme) is internally calling the binary. Sounds like a great way to transition things in a saner direction. You know it will be bug-for-bug compatible with calling the gpg-binary. Having one blessed text-parser with a lot of eyes on it is much better than everyone rolling their own. Getting people used to depending on a library instead of shelling out also means it becomes possible to move the library to independent implementations.