4 ms·

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 m

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.
      - eugenejen 13y ago
        I misread you sentences. I thought you meant Python and Java fails memory management than OS. That caused me to ask the question. Thank you for getting back to me.
e1ven 13y ago
Cool. Maybe our definitions of scrape are what's causing the disagreement. Sorry about that! When I look at the code that calls the GPG binary, in the python lb at https://code.google.com/p/python-gnupg/ https://code.google.com/p/python-gnupg/ it seems to be reading/writing stdout/stdin. It doesn't appear to be using a socket connection, or any other non-typical way of accessing it. return Popen(cmd, shell=True, stdin=PIPE, stdout=PIPE, stderr=PIPE) def _read_response(self, stream, result): Internal method: reads all the stderr output from GPG, taking notice # only of lines that begin with the magic [GNUPG:] prefix. etc In trying to gpg in my apps, having a library which lets me generate a pgp key in memory, read it in to a string, write it out to a string, and sign/encrypt strings or binaries would be optimal. I don't want to have to worry about where the .gnupg home directory is being created.. I don't want any files stored. I don't want to access any keyservers, I'm doing all the key verification through other channels. Essentially, I'd like to be able to use GPG more like NaCL/Libsodium.
- mkesper 13y ago
  Nobody should ever use shell=True. A saner approach would be to build upon gpgme.

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.
    - eugenejen 13y ago
      I misread you sentences. I thought you meant Python and Java fails memory management than OS. That caused me to ask the question. Thank you for getting back to me.

e1ven 13y ago

Cool. Maybe our definitions of scrape are what's causing the disagreement. Sorry about that! When I look at the code that calls the GPG binary, in the python lb at https://code.google.com/p/python-gnupg/ https://code.google.com/p/python-gnupg/ it seems to be reading/writing stdout/stdin. It doesn't appear to be using a socket connection, or any other non-typical way of accessing it. return Popen(cmd, shell=True, stdin=PIPE, stdout=PIPE, stderr=PIPE) def _read_response(self, stream, result): Internal method: reads all the stderr output from GPG, taking notice # only of lines that begin with the magic [GNUPG:] prefix. etc In trying to gpg in my apps, having a library which lets me generate a pgp key in memory, read it in to a string, write it out to a string, and sign/encrypt strings or binaries would be optimal. I don't want to have to worry about where the .gnupg home directory is being created.. I don't want any files stored. I don't want to access any keyservers, I'm doing all the key verification through other channels. Essentially, I'd like to be able to use GPG more like NaCL/Libsodium.

mkesper 13y ago
Nobody should ever use shell=True. A saner approach would be to build upon gpgme.