5 ms·

I've always found it annoying that there isn't a properly supported python package for gnupg. There were like two or three forks that were maintained properly b

by zikohh 5y ago

I've always found it annoying that there isn't a properly supported python package for gnupg. There were like two or three forks that were maintained properly but each one had its "time". It's very confusing for people to begin with using PGP since you have to understand which one to use and the history and why they all exists. A lot of fuss if you ask me.

ArchOversight 5y ago
Most of the Python packages for GPG just shell out to gnupg, which is not really the greatest API.
- tptacek 5y ago
  We can use stronger terms here --- whatever else you think of PGP, the shell-out stdio "api" for PGP is dangerous (GnuPG will release unauthenticated ciphertext to "callers" of that API, with a warning you need to catch). This API was responsible for the Efail bugs --- which were horrible --- a few years ago. Don't ever do this.
  - zikohh 5y ago
    Agreed, but the problem here isn't provided by the caller, but it's by the python package that claims it's an api to GnuPG.
  - franga2000 5y ago
    How is that any more dangerous than a "real" library doing the same? Your code would still have to check whether the message passed the integrity check or not, just like it has to look for the warning on stderr. I can't imagine why doing a stream search for i.e. "WARNING: Verification failed!" is any less secure than checking result.verificationPassed (assuming the CLI messages won't change, which they won't since they're basically an API).
    - tptacek 5y ago
      Real libraries wouldn't do the same thing.
      - franga2000 5y ago
        You could just as easily say a "real" command line interface wouldn't do the same thing. Of course, it might make more sense for a library, "real" or not, to default to raising an exception with no output, not just a warning - especially for a security-critical application. But it's not like we've never seen unsafe defaults in a library before, even a crypto one. Then again, it does make sense from a UX standpoint: I'd rather see "message could not be verified", followed by the decrypted content anyways, rather than not get any output. I know not to trust it, so knowing what it says is useful in terms of threat identification. This is really not a CLI vs DLL issue - it's a default settings issue. And in this specific case, the unsafe option actually follows the standard more closely - it does not, after all, mandate integrity checking. Mybe it should, but that's a different conversation.
        solarkraft 5y ago
        (Disclaimer: I'm not very knowledgeable with GPG, I assume that the warning means that the message hasn't been properly signed.) > I'd rather see "message could not be verified", followed by the decrypted content anyways, rather than not get any output. I know not to trust it, so knowing what it says is useful in terms of threat identification. You would know not to trust it, but it would be very easy for a novice user without an understanding of the implications to assume that it's just a minor error ("tech sometimes throws errors, but it works anyway, so why worry?"). But it damn sure is not! My suggestion would be to print an elaborate and strong warning about the implications and provide an option to look at the message if you really know that it should not be trusted in the slightest. This is how browsers handle TLS certificate issues and I'd call it a lot safer than showing the website anyway and displaying a small warning with some technical jargon.
- zikohh 5y ago
  That's the exact problem. They claim to provide an API but at the end of the day under the hood, thats what's being done. It really annoys me.
jarrell_mark 5y ago
There's a package called PGPy. It's a python implementation of PGP. BSD-3-Clause licensed. https://github.com/SecurityInnovation/PGPy https://github.com/SecurityInnovation/PGPy When testing it out GnuPG compatibility, I just had to add the --rfc4880 when encrypting with GnuPG. Then PGPy could decrypt it using the private key generated by GnuPG. PGPy supports key generation and encryption too.

by zikohh 5y ago

ArchOversight 5y ago

Most of the Python packages for GPG just shell out to gnupg, which is not really the greatest API.

tptacek 5y ago
We can use stronger terms here --- whatever else you think of PGP, the shell-out stdio "api" for PGP is dangerous (GnuPG will release unauthenticated ciphertext to "callers" of that API, with a warning you need to catch). This API was responsible for the Efail bugs --- which were horrible --- a few years ago. Don't ever do this.
- zikohh 5y ago
  Agreed, but the problem here isn't provided by the caller, but it's by the python package that claims it's an api to GnuPG.
- franga2000 5y ago
  How is that any more dangerous than a "real" library doing the same? Your code would still have to check whether the message passed the integrity check or not, just like it has to look for the warning on stderr. I can't imagine why doing a stream search for i.e. "WARNING: Verification failed!" is any less secure than checking result.verificationPassed (assuming the CLI messages won't change, which they won't since they're basically an API).
  - tptacek 5y ago
    Real libraries wouldn't do the same thing.
    - franga2000 5y ago
      You could just as easily say a "real" command line interface wouldn't do the same thing. Of course, it might make more sense for a library, "real" or not, to default to raising an exception with no output, not just a warning - especially for a security-critical application. But it's not like we've never seen unsafe defaults in a library before, even a crypto one. Then again, it does make sense from a UX standpoint: I'd rather see "message could not be verified", followed by the decrypted content anyways, rather than not get any output. I know not to trust it, so knowing what it says is useful in terms of threat identification. This is really not a CLI vs DLL issue - it's a default settings issue. And in this specific case, the unsafe option actually follows the standard more closely - it does not, after all, mandate integrity checking. Mybe it should, but that's a different conversation.
      - solarkraft 5y ago
        (Disclaimer: I'm not very knowledgeable with GPG, I assume that the warning means that the message hasn't been properly signed.) > I'd rather see "message could not be verified", followed by the decrypted content anyways, rather than not get any output. I know not to trust it, so knowing what it says is useful in terms of threat identification. You would know not to trust it, but it would be very easy for a novice user without an understanding of the implications to assume that it's just a minor error ("tech sometimes throws errors, but it works anyway, so why worry?"). But it damn sure is not! My suggestion would be to print an elaborate and strong warning about the implications and provide an option to look at the message if you really know that it should not be trusted in the slightest. This is how browsers handle TLS certificate issues and I'd call it a lot safer than showing the website anyway and displaying a small warning with some technical jargon.
zikohh 5y ago
That's the exact problem. They claim to provide an API but at the end of the day under the hood, thats what's being done. It really annoys me.

jarrell_mark 5y ago

There's a package called PGPy. It's a python implementation of PGP. BSD-3-Clause licensed. https://github.com/SecurityInnovation/PGPy https://github.com/SecurityInnovation/PGPy When testing it out GnuPG compatibility, I just had to add the --rfc4880 when encrypting with GnuPG. Then PGPy could decrypt it using the private key generated by GnuPG. PGPy supports key generation and encryption too.