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
This has led to rather a lot of failures when it comes to GPG's integration with MUAs
1
6
CLI brings the issue of serialization / deserialization from strings and generally it's an ad-hoc, poorly documented format rather than something structured. It's also often not a stable API. It would have to be specifically designed for automated use and use something like JSON.
1
4
libgit2 exists largely because it's horrible dealing with a bunch of of ad-hoc, inconsistent and badly documented CLI interfaces and formats. You have to serialize and deserialize to/from strings. Can build it into a wrapper library but why not just provide that from the start?
1
1
Git could have been designed as CLI tools based around libraries, with those libraries eventually defining a slowly evolving versioned API usable by other applications. This is how nearly all of LLVM is built and is a major reason for it being so broadly adopted everywhere.
1
3
A neat example of this is libcurl + curl where you can pass "--libcurl output.c" as a parameter to turn your curl commands into code using the library. From there, you can properly integrate it into code without parsing CLI command output, hacking together async support, etc.