The lack of any higher level crypto primitives in the Swift standard library seems to have resulted in people just deciding to shell out to openssl to generate a CSR, which feels like an important lesson
5
11
125
Conversation
Replying to
This feels like not *necessarily* the wrong implementation but I’d prefer the library that shells out to OpenSSL to be part of the Swift standard library
1
1
Involving unnecessary CLI interfaces and parsing in both directions is far worse than using it directly. It can be used in a separate process (which does not imply any isolation without further work) without involving the CLI interface if that was actually the goal.
1
11
I'm thinking about GPG and Git here as examples, although Git was specifically designed to operate this way and maybe GPG is not a great model for anything security-related
4
1
I feel like GPG would be a much better example of how to do security if so many things operated on it via library operations rather than shelling out, and I have a lot of the same problems with things that interoperate with Git repos.
1
2
gpgme is a library wrapping the CLI tools rather than a library used by the CLI tools. It's backwards.
It's far from one of GPG's biggest issues. It's a legacy hobby project rather than serious or modern cryptography. PGP is highly flawed and GPG is a really bad implementation.
So, forgive me, because I never seem to get a complete answer: aside from usability issues (which are obviously a big deal), what is horribly flawed about PGP? The fundamentals seem reasonably sound, but I assume I’m missing something.
1
PGP is massively overly complex with cryptography choices and usage that are considered insecure. Key fingerprints inherently SHA-1 and there's a whole bunch of legacy cryptography algorithms and misuse even when trying to use modern algorithms with it.
1
2
Show replies