Re: Multithreading with GPGME Python Bindings
On Mon, 16 Jan 2023 07:55, Jan Girlich said: > Is the call to "gpgme_check_version" maybe done implicitly by the > Python bindings? Yes. See gpgme/lang/python/src/core.py # check_version also makes sure that several subsystems are properly # initialized, and it must be run at least once before invoking any # other function. We do it here so that the user does not have to do # it unless she really wants to check for a certain version. check_version() > Do I have to call "gpgme-config --version" before to safely do No, this is a helper to compile against gpgme - it returns suggested compiler and linker flags. Make sure that one context object is only used by one thread at a time. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Multithreading with GPGME Python Bindings
(Please forgive the HTML email, sending from my phone)Given Python is effectively single-threaded through the global interpreter lock, this may turn out to be a total non-issue. Although I don't have an immediate answer for you I'd suggest starting by learning how Python's multi-threading support is more smoke and mirrors than reality. That may lead you to an answer to your question.On Jan 16, 2023 1:55 AM, Jan Girlich wrote:Hi, I want to use the GPGME Python bindings in a concurrent way. In the documentation of the Python bindings at http://files.au.adversary.org/crypto/gpgme-python-howto.html I find no mention of multithreading. In the GPGME documentation at https://www.gnupg.org/documentation/manuals/gpgme/Multi_002dThreading.html#Multi_002dThreading I find the note, that I need to call "gpgme_check_version" before doing any multithreaded operations. Then again I find only this section about version checking in the Python binding's documentation: http://files.au.adversary.org/crypto/gpgme-python-howto.html#gpgme-version-check In this section the version check is done via a subprocess call to "gpgme-config --version". Is the call to "gpgme_check_version" maybe done implicitly by the Python bindings? Do I have to call "gpgme-config --version" before to safely do multithreaded operations with the Python bindings? Thank you for any insights, Jan ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Multithreading with GPGME Python Bindings
Hi Robert, On Mon, 2023-01-16 at 11:53 -0500, Robert J. Hansen wrote: > I don't have an immediate answer for you I'd suggest starting by > learning how Python's multi-threading support is more smoke and > mirrors than reality. That may lead you to an answer to your > question. you seem to be quite new to the topic of Python and multi-threading, so let me give you the relevant basics relating to my question. Yes, the GIL is making cPython thread-safe and thus blocking threads. But only when processing Python bytecode. When an external operation runs, like gnupg encrypting something or I/O operations, the GIL is released and another thread can run. So multi-threading computationally intensive gnupg operations can have performance improvements. Also, the GIL is no issue with multi-processing, which is the constructive answer I prefer to "GIL is a problem", instead of "smoke and mirrors". I can recommend https://superfastpython.com/multiprocessing-pool-gil/ on this topic. Thank you, Jan > > On Jan 16, 2023 1:55 AM, Jan Girlich wrote: > > Hi, > > > > I want to use the GPGME Python bindings in a concurrent way. > > > > In the documentation of the Python bindings at > > http://files.au.adversary.org/crypto/gpgme-python-howto.html I find > > no > > mention of multithreading. > > > > In the GPGME documentation at > > https://www.gnupg.org/documentation/manuals/gpgme/Multi_002dThreading.html#Multi_002dThreading > > I find the note, that I need to call "gpgme_check_version" before > > doing > > any multithreaded operations. > > > > Then again I find only this section about version checking in the > > Python binding's documentation: > > http://files.au.adversary.org/crypto/gpgme-python-howto.html#gpgme-version-check > > In this section the version check is done via a subprocess call to > > "gpgme-config --version". > > > > Is the call to "gpgme_check_version" maybe done implicitly by the > > Python bindings? > > > > Do I have to call "gpgme-config --version" before to safely do > > multithreaded operations with the Python bindings? > > > > Thank you for any insights, > > Jan > > > > ___ > > Gnupg-users mailing list > > Gnupg-users@gnupg.org > > https://lists.gnupg.org/mailman/listinfo/gnupg-users > > > > (Please forgive the HTML email, sending from my phone) > > Given Python is effectively single-threaded through the global > interpreter lock, this may turn out to be a total non-issue. Although > I don't have an immediate answer for you I'd suggest starting by > learning how Python's multi-threading support is more smoke and > mirrors than reality. That may lead you to an answer to your > question. > > On Jan 16, 2023 1:55 AM, Jan Girlich wrote: > > Hi, > > > > I want to use the GPGME Python bindings in a concurrent way. > > > > In the documentation of the Python bindings at > > http://files.au.adversary.org/crypto/gpgme-python-howto.html I find > > no > > mention of multithreading. > > > > In the GPGME documentation at > > https://www.gnupg.org/documentation/manuals/gpgme/Multi_002dThreading.html#Multi_002dThreading > > I find the note, that I need to call "gpgme_check_version" before > > doing > > any multithreaded operations. > > > > Then again I find only this section about version checking in the > > Python binding's documentation: > > http://files.au.adversary.org/crypto/gpgme-python-howto.html#gpgme-version-check > > In this section the version check is done via a subprocess call to > > "gpgme-config --version". > > > > Is the call to "gpgme_check_version" maybe done implicitly by the > > Python bindings? > > > > Do I have to call "gpgme-config --version" before to safely do > > multithreaded operations with the Python bindings? > > > > Thank you for any insights, > > Jan > > > > ___ > > Gnupg-users mailing list > > Gnupg-users@gnupg.org > > https://lists.gnupg.org/mailman/listinfo/gnupg-users > > > ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Multithreading with GPGME Python Bindings
Hi, I want to use the GPGME Python bindings in a concurrent way. In the documentation of the Python bindings at http://files.au.adversary.org/crypto/gpgme-python-howto.html I find no mention of multithreading. In the GPGME documentation at https://www.gnupg.org/documentation/manuals/gpgme/Multi_002dThreading.html#Multi_002dThreading I find the note, that I need to call "gpgme_check_version" before doing any multithreaded operations. Then again I find only this section about version checking in the Python binding's documentation: http://files.au.adversary.org/crypto/gpgme-python-howto.html#gpgme-version-check In this section the version check is done via a subprocess call to "gpgme-config --version". Is the call to "gpgme_check_version" maybe done implicitly by the Python bindings? Do I have to call "gpgme-config --version" before to safely do multithreaded operations with the Python bindings? Thank you for any insights, Jan ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPGME python bindings query
(Redirecting to -users since that seems more appropriate) On 07/12/2018 10:42 PM, Ben McGinnes wrote: > On Tue, Jul 10, 2018 at 01:01:10PM -0400, Jacob Adams wrote: >> I would prefer to use the automatically generated certificate as it >> also comes with some useful explanation text, but the problem I'm >> having is that there is no way to trigger this generation from GPGME >> and it appears to happen whenever you generate your first subkey (or >> perhaps your first signing subkey, haven't dug that much into it). > > It's generated with the certification key and this comment indicates > there may be a little misunderstanding about the revocation > certificate. It's used to revoke an entire key, including subkeys and > it does this by the simple expedient of revoking the certification > key. Once the certification key is revoked, the certification > signatures can't be validated without throwing the disabled key errors > which prevent the subkeys from being used. > > So even if subkeys are added later, there are no additional revocation > certificates generated for the subkeys. Which is why you'll find .rev > files in $GNUPGHOME/openpgp-revocs.d/ directory matching the > fingerprint of the primary key, but nothing for the subkeys; while the > $GNUPGHOME/private-keys-v1.d/ is populated with multiple .key files > matching the keygrips for all the keys and subkeys generated. > Oh ok that makes a lot more sense now! Most of what I know about GPG is just picked up from random Internet tutorials of dubious quality so I end up with a very spotty understanding of how all this works. Thank you for the clear overview. >> and a random extra password prompt > > There are no random extra password prompts, they're all necessary for > a secure system. Sorry random was the wrong word here. I meant only that the generation of this revocation certificate seems to happen later than I would expect. (Actually I was entirely wrong here about the order of events anyway, see below.) > >> for the revocation certificate that I can't control doesn't really >> help there. If there's some way I could manually trigger this >> process that would be great. > > It should have already occurred when the key was first generated. The > only time it needs to be done manually is when issuing a specific > revocation certificate with a less generic revocation reason or if the > key was generated with an older version of GPG that did not generate > such a certificate by default. > When I don't generate my own revocation certificate, I get a second password prompt when generating the first subkey. I had been assuming that this was for the revocation certificate, but some testing confirms that the certificate already exists before this. I'm still not sure why I would be getting a second prompt however. Any ideas? Thanks, Jacob signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPGME Python bindings
On Thu, Dec 28, 2017 at 05:49:58PM -0500, Leo Famulari wrote:
> Hello,
>
> I'm working on downstream packaging of GPGME and GPGME's Python
> language bindings for GNU Guix. [0]
Cool.
> Because it was easier, we began packaging the GPGME Python bindings
> based on the PyPi release [1] of version 1.8.0.
>
> However, since that time, GPGME has had a few more releases, but the
> PyPi release has not been updated.
Nor is it likely to be at the moment, PyPi is ... one of the least
impressive aspects of Python, unfortunately.
> How should we interpret this? Does it mean that we should continue to
> package version 1.8.0 of Python bindings? Or should we try to build them
> from the latest GPGME source release?
The Python bindings are updated with each GPGME release and compiling
GPGME should result in the current bindings being built and installed
in the versions of Python 2 and 3 found on the system.
IIRC the bindings with GPGME 1.8.0 used the module name of gpgme, that
has since been changed to gpg. and current behaviour is very pythonic.
For example, here's about the simplest clear signing method (using the
default key of the user running the code):
import gpg
from gpg.constants.sig import mode
with gpg.Context() as c:
signed = c.sign(b"Test message", mode=mode.CLEAR)
afile = open("filename.txt.asc", "wb")
afile.write(signed)
afile.close()
Encryption and decryption don't require much more than that either.
Yes, you can encrypt data as a class and then import that upon
decryption if your intent is to securely store authentication tokens
as part of something else. In fact, that's what prompted what led to
these bindings being updated to Python 3 in the first place.
Regards,
Ben
signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
GPGME Python bindings
Hello, I'm working on downstream packaging of GPGME and GPGME's Python language bindings for GNU Guix. [0] Because it was easier, we began packaging the GPGME Python bindings based on the PyPi release [1] of version 1.8.0. However, since that time, GPGME has had a few more releases, but the PyPi release has not been updated. How should we interpret this? Does it mean that we should continue to package version 1.8.0 of Python bindings? Or should we try to build them from the latest GPGME source release? Sincerely, Leo [0] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnupg.scm?id=50c4d676ff65a2e26a5df5745733b8cc16b23bc6#n372 https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnupg.scm?id=50c4d676ff65a2e26a5df5745733b8cc16b23bc6#n445 [1] https://pypi.python.org/pypi/gpg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
