4 ms·

I've been working on using GPG behind-the-scenes, so I can speak to a few reasons why it might not be used more frequently. 1) GPG is -terrible- to use as a li

by e1ven 13y ago

I've been working on using GPG behind-the-scenes, so I can speak to a few reasons why it might not be used more frequently. 1) GPG is -terrible- to use as a library. There are a lot of wrappers for various languages. Almost most all of them call the gpg executable, and scrape it's input. This is crazy-town loony-toons. In theory, gpgme is supposed to be the solution.. But gpgme ends up calling the binary itself in many cases! 2) GPG assumes you want to use the whole ecosystem. GPG is sort of a mega-framework. It assumes you want to do everything the GPG way - Use gpg subkeys, keyservers, WOT, Import keys to a central keychain, etc. I've been able to go through with options flags and disable things I don't want, but it's all opt-out, not opt-in. 3) Because of 1 and 2, you can't run GPG entirely in memory. It writes a lot of files to the filesystem.. I've been bypassing this by running in ramdisks with ephemeral directories, but it's a PITA. 4) 2.1 has been in the works.. FOREVER. The first betas of gpg 2.1 were in 2010.. I understand they want to get this right, but that's a really really really log dev-cycle. I donated to the crowdfunding, and I hope it helps get gpg out sooner. GPG 2.1 is the first stable gpg release that includes ECC support (specifically, DJB's 25519). This is a really really big feature, that a lot of people have been waiting for. In any event, I like GPG, and I'm using GPG because it's been hardened, and I'm not smart enough to do my own crypto. But GPG doesn't make itself easy to integrate.

pyre 13y ago
> There are a lot of wrappers for various languages. Almost most all of them call the gpg executable, and scrape it's input. This is crazy-town loony-toons. > In theory, gpgme is supposed to be the solution.. But gpgme ends up calling the binary itself in many cases! I've heard of this many times, but is there a good reason behind this? Are there extra security considerations behind making this a shared library? Is it just "not the focus of development" much in the same way that changing the GIMP UI was always "off the table" for the longest time because the devs didn't want to do it?
- e1ven 13y ago
  One of the things that's insane to me is how poorly funded so many of these crucial internet projects are. To my understanding, the majority of gpg is implemented by Werner Koch.. He's amazing, but is only human. Tech Giants spend more money choosing the color of blue than they ever donate, and they seldom hire people to contribute code back upstream. :/
  - A_COMPUTER 13y ago
    Why does this guy not get more attention? I've used GPG for what, ten years, I have an issue I use the mailing list and Werner is there answering the question. I look at the commit log on a release and he's all over the place. GPG is a massively important piece of software. Would it exist without him? He is a borderline hero in my book.
  - pyre 13y ago
    I've always assumed that GPG must be the work of a team.
nwalfield 13y ago
Unfortunately, there are a couple of misunderstandings here. It is true that libraries call the gpg binary. This is a feature, not a bug. This architecture makes bugs in the applications less likely to affect the gpg code / data. For instance, it's a lot harder to dump the variable containing the secret key if it is in another process. The wrappers don't scrape the output. There is a well-defined protocol for interacting with the binary.
- tptacek 13y ago
  Being force to run the GPG program as a subsidiary process is not a feature; it is a bug in the design. It's bad enough that replacing the GPG binary itself with a new implementation would also be a worthy project; just don't muck with the cryptosystem itself, so we can constrain the audit target.
  - derleth 13y ago
    If anything, it's a bug in the language design: If the client is written in C or C++, a wild pointer could potentially point to any data in the process's memory space, including sensitive key information, and from there it's a small step to revealing that information in a core dump or similar. (Or, you know, printing it to stdout because something hinky was passed in to printf.) The solution is to make everyone only write code in languages which use a runtime that controls memory access better than the OS can. Python or Java, for example. Failing that, relying on the OS is the safest way, and the simplest, most secure way to do that is to keep GPG in its own process.
    - eugenejen 13y ago
      so as a digression, which language do you think has a runtime that controls memory access better than OS? I wonder can a language like Rust and Golang meet that criteria?
      - derleth 13y ago
        > so as a digression, which language do you think has a runtime that controls memory access better than OS? I mentioned two: Python and Java. In general, I mean any language where the runtime only hands programs valid pointers and the language doesn't allow pointer arithmetic. This means it's possible to guarantee that pointers will only point into objects that can be validly accessed by the code which holds those pointers. This is generally done to make garbage collection easier, but it can be done to implement security policy: Basically, if your security policy trusts a given runtime, you can use that runtime to enforce access policies on objects of all kinds, including memory.

by e1ven 13y ago

pyre 13y ago

> There are a lot of wrappers for various languages. Almost most all of them call the gpg executable, and scrape it's input. This is crazy-town loony-toons. > In theory, gpgme is supposed to be the solution.. But gpgme ends up calling the binary itself in many cases! I've heard of this many times, but is there a good reason behind this? Are there extra security considerations behind making this a shared library? Is it just "not the focus of development" much in the same way that changing the GIMP UI was always "off the table" for the longest time because the devs didn't want to do it?

e1ven 13y ago
One of the things that's insane to me is how poorly funded so many of these crucial internet projects are. To my understanding, the majority of gpg is implemented by Werner Koch.. He's amazing, but is only human. Tech Giants spend more money choosing the color of blue than they ever donate, and they seldom hire people to contribute code back upstream. :/
- A_COMPUTER 13y ago
  Why does this guy not get more attention? I've used GPG for what, ten years, I have an issue I use the mailing list and Werner is there answering the question. I look at the commit log on a release and he's all over the place. GPG is a massively important piece of software. Would it exist without him? He is a borderline hero in my book.
- pyre 13y ago
  I've always assumed that GPG must be the work of a team.

nwalfield 13y ago

Unfortunately, there are a couple of misunderstandings here. It is true that libraries call the gpg binary. This is a feature, not a bug. This architecture makes bugs in the applications less likely to affect the gpg code / data. For instance, it's a lot harder to dump the variable containing the secret key if it is in another process. The wrappers don't scrape the output. There is a well-defined protocol for interacting with the binary.

tptacek 13y ago
Being force to run the GPG program as a subsidiary process is not a feature; it is a bug in the design. It's bad enough that replacing the GPG binary itself with a new implementation would also be a worthy project; just don't muck with the cryptosystem itself, so we can constrain the audit target.
- derleth 13y ago
  If anything, it's a bug in the language design: If the client is written in C or C++, a wild pointer could potentially point to any data in the process's memory space, including sensitive key information, and from there it's a small step to revealing that information in a core dump or similar. (Or, you know, printing it to stdout because something hinky was passed in to printf.) The solution is to make everyone only write code in languages which use a runtime that controls memory access better than the OS can. Python or Java, for example. Failing that, relying on the OS is the safest way, and the simplest, most secure way to do that is to keep GPG in its own process.
  - eugenejen 13y ago
    so as a digression, which language do you think has a runtime that controls memory access better than OS? I wonder can a language like Rust and Golang meet that criteria?
    - derleth 13y ago
      > so as a digression, which language do you think has a runtime that controls memory access better than OS? I mentioned two: Python and Java. In general, I mean any language where the runtime only hands programs valid pointers and the language doesn't allow pointer arithmetic. This means it's possible to guarantee that pointers will only point into objects that can be validly accessed by the code which holds those pointers. This is generally done to make garbage collection easier, but it can be done to implement security policy: Basically, if your security policy trusts a given runtime, you can use that runtime to enforce access policies on objects of all kinds, including memory.