1. 6
  1.  

  2. 4

    Pretty eager to see this project move out of beta.

    1. 3

      If you think a command-line interface is not an API, then you are ignoring the millions of lines of shell scripts that keep the Internet running. You are wrong. Please consult your nearest sysadmin for an attitude readjustment.

      No U. There are indeed millions of shell scripts - and I have never seen one that wasn’t a disaster waiting to happen. Remember that bash function expansion bug? Particularly in a security context, any use of shell scripts for production systems is simply terrible engineering. I am genuinely angry that someone would try to defend it.

      Heartbleed and many other vulnerabilities are direct results of crypto and keys living the same process space as protocol and application logic.

      No, they’re a direct result of using non-memory-safe languages. Any Heartbleed attacker could have achieved arbitrary code execution, at which point process separation doesn’t offer much in the way of protection - if the attacker controls the process that talks to the process that handles the key, then they can still use the key to e.g. sign their own nefarious messages.

      That said, there is some value in process separation. But it’s much less than the cost of parsing a text interface. If you want to do process separation then great, but use shared memory or protobuf or heck JSON if you have to (a suggestion the original post did make).

      We looked at the libraries, encountered an apalling lack of documentation and hoped the command-line interface would be nicer to work with.

      Sure, I understand the pragmatic business decision here. But as I said, this makes you part of the problem. If all the companies that have wrapped GPG over the years had instead put that effort into either a) the JSON format interface to GPG the article talks about or b) a well-documented library, we would have solved these problems many times over. But as long as it’s marginally easier for each individual company to maintain a horrible wrapper, the tragedy of the commons continues.

      Treat the command-line interface of gpg as if it were an API; keep it stable and machine friendly. There should be command-line alternatives to all of the interactive dialogs.

      This is the wrong approach. GPG must have the freedom to make its interface more user-friendly, or we’ll never get anywhere. One binary can’t serve two masters; by all means write a tool that offers GPG functionality in a stable, machine-friendly interface, but make it a different tool from gpg itself.

      To reiterate and expand the suggestion I made on the HN thread:

      • Pick up one of the libraries and bring it up to production quality. Alternately, split GPG itself into library and UI. Compare something like ffmpeg or ImageMagick, which offers ffmpeg-the-frontend-tool but is mostly used as a backend for other programs that link to it as a library. (And yes, ffmpeg has a stable set of command line arguments, but it’s not an interactive program. gpg should be the equivalent of e.g. superadduser or, hell, openssl).
      • If you want a separate process that communicates via JSON then great, make a gpgme-tool or similar that uses this library as a backend.
      1. 5

        A lot of Unix programs, dare I say, most programs intended for Unix, are explicitly written expecting their CLI to also be their API. It’s part of the reason why git’s CLI has to stay the way it is, weird and inconsistent, because its CLI is used as an API. It’s explicitly part of Mercurial’s compatibility rules, and bear in mind that hg was built by the same group of kernel hackers who built Linux and git. (There may also be such explicit rules for git, but I don’t know their dev community as well, so I don’t know where to find them. I do know that Linus yells very loudly if people break userspace in Linux, so I assume a similar attitude carries over to git.)

        Having worked with Mercurial development, I can tell you: it’s annoying to have to make sure the CLI is stable-as-an-API, but I guarantee that it’s part of the reason why hg hasn’t completely died out. People using it in 2008 as part of some bigger contraption still use hg in 2015, thanks to this stability. GnuPG would do well to start treating its CLI as an API as well.

        1. 2

          Quoting from Werner’s reply to the first Mailpile post about GnuPG:

          GnuPG output. I have dutifully read, memorized chunks of, and bookmarked this file for posterity. It is immensely helpful. For example, it gives […] Now here comes issue the first: this is essentially a colon separated value (CSV!) data structure, but the data being provided is a) inconsistent, and b) structured.

          You mean that there is no top-down design? Right that is how life is.

          GnuPG stated as a PGP 2 replacement and soon I figured that a machine readable interface is useful to avoid problems with localization and changing output intended for humans. Over the years more and more status information has been added to this interface - in a compatible way. This makes it a bit hard to use but it does not break existing applications. If you can start from scratch, you can do a nice API design but we were not able to do that.

          So it seems that Werner is already well aware of the fact that GnuPG’s CLI is used as an API and consequently must remain stable.

          Edit to add: thanks for the link to the Mercurial compatibility rules. I really like that explicit documentation.

        2. 5

          No U. There are indeed millions of shell scripts - and I have never seen one that wasn’t a disaster waiting to happen. Remember that bash function expansion bug? Particularly in a security context, any use of shell scripts for production systems is simply terrible engineering. I am genuinely angry that someone would try to defend it.

          Bash having security issue is a separate issue than if a CLI is an API. There are other shells out there and most non-shell programs call other programs directly, bypassing any shell.

          1. 1

            A shell script implies a shell; the article defends not just calling a shell program directly but using shell scripts as part of a production system.

        3. 1

          I’m glad to see more projects that make use of GnuPG starting to participate on the mailing list. (GPGTools is another that recently started participating in discussion there.)

          I’ve been following the list for the past year or two, and I’ve been surprised how infrequently issues and complaints I hear about elsewhere actually make it on to the list – let alone the bug tracker.

          I’m hopeful that better communication between projects will result in better integrations and overall safer software systems.