Re: GPGME (for python) questions

2020-10-24 Thread Ingo Klöcker
On Freitag, 23. Oktober 2020 21:48:49 CEST Hammett, Rich via Gnupg-users 
wrote:
> Is there a guide anywhere for what versions of GnuPG are supported by what
> versions of GPGME?

Check the documentation of gpgme. The README of the current version reads
"For support of the OpenPGP and the CMS protocols, you should use the
latest version of GnuPG (>= 2.1.18) , available at:
https://gnupg.org/ftp/gcrypt/gnupg/.;

Note that GnuPG 2.1.x is no longer supported (even if it might still work with 
gpgme).

In general, old functionality in gpgme that worked with an old version of 
GnuPG should still work with the latest version of gpgme, but there are no 
guarantees. New functionality of gpgme usually is only developed to work with 
the current GnuPG release (because often the new gpgme API needs new internal 
API in GnuPG and its helpers).

So, if possible, use the most recent GnuPG 2.2 release with the most recent 
release of gpgme.
 
> I only need encryption and decryption as part of an automated software
> framework, and I’m trying to migrate from an existing toolset that uses
> GnuPG v1.4 and python-gnupg.

Note that gpgme now includes the Python bindings.

> We need to be able to pgp encrypt and decrypt
> without human interaction.  I’m working through the various ways to move up
> to more current software, and latest GPGME with latest GnuPG is probably
> the best, if I can figure out the python bindings and if GnuPG works with
> pinentry for automated decryption.

I suggest to check out the tests of the Python bindings, in particular,
t-decrypt.py and t-callbacks.py (for passphrase callbacks).

A common recommendation on this list is to use a passphrase-less secret key 
for automated decryption because this isn't really less secure than storing 
the passphrase in cleartext in some script file next to the secret key.

Another approach is to inject the passphrase into gpg-agent's passphrase cache 
with an unlimited (or near unlimited) expiration time. The latter approach 
requires human interaction (or scripted interaction from another system) for 
entering the passphrase into the cache after every restart of gpg-agent (e.g. 
after a system reboot) and is obviously much more error-prone than a 
passphrase-less key.

> Any tips, any good documents out there?  Are there archives of this list
> somewhere, or is that private for the same reason the subscribers’ list
> is?

The archive of this list is available via the link at the bottom of this 
message (which is added automatically by the mailing list).

Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Preserving public keyserver network (Re: Which keyserver)

2020-10-24 Thread Stefan Claas via Gnupg-users
If it is a technical challenge and Kristian as head (pool maintainer),
why does he not ask publicity
the hockeypuck author, dkg and the sequoia-team, for help?

As an example, if I would be Kristian I would do so, set-up with my
pool gang a hockeypuck
test-net (bootstrapped with a handful of pub keys) and work with the
programmer(s) on long
standing issues. Secondly I would give my gang a timeframe of a couple
of months to
gracefully shut down their SKS servers.

Would that have any disadvantages for GnuPG users worldwide, while we also have
Mailvelope and Hagrid?

On Sat, Oct 24, 2020 at 1:39 PM Andrew Gallagher  wrote:
>
>
> > On 24 Oct 2020, at 10:41, Stefan Claas via Gnupg-users 
> >  wrote:
> >
> > there can
> > be no consensus achieved between privacy loving EU citizens and (US
> > based) SKS operators
>
> Most SKS operators are (were?) based outside the US. This is primarily a 
> technical challenge, not a political one.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Preserving public keyserver network (Re: Which keyserver)

2020-10-24 Thread Andrew Gallagher


> On 24 Oct 2020, at 10:41, Stefan Claas via Gnupg-users 
>  wrote:
> 
> there can
> be no consensus achieved between privacy loving EU citizens and (US
> based) SKS operators

Most SKS operators are (were?) based outside the US. This is primarily a 
technical challenge, not a political one. 

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Preserving public keyserver network (Re: Which keyserver)

2020-10-24 Thread Stefan Claas via Gnupg-users
I can only speak for myself and see that when it comes to SKS that there can
be no consensus achieved between privacy loving EU citizens and (US
based) SKS operators, while Mailvelope and Hagrid respect the users wishes.

With that being said I am out and better let Mr Barr and Mr de Kerchove decide
what the SKS future will bring.

Last but not least I no longer need public SKS key servers.

Best regards
Stefan




On Fri, Oct 23, 2020 at 12:55 PM Bernhard Reiter  wrote:
>
> Am Samstag 19 September 2020 23:34:32 schrieb Stefan Claas:
> > I stand by my points that hockeypuck can solve the issues
>
> To me
> it makes sense to preserve a decentalised network of public keyservers [1].
>
> In my post
>  Preserving non-central and privacy with a "permission recording keyserver"
> [Reiter 2019-07 a]
>  https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034399.html
> there is a concept allowing for compatibility with strong privacy laws.
>
> Some ideas how we could conceptually preserve third party
> signature information on public servers:
>   Preserving third party signatures distribution [Reiter 2019-07 b]
>   https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034394.html
>
> So yes, I also believe that improvements to hockeypuck or a fresh
> implementation could step by step get the public keyserver network up again.
>
>
> Best Regards,
> Bernhard
> ps.: Because I believe funding more qualified dev time is part of the
> solution: You can become a sponsor for hockeypuck development, see
>   https://github.com/sponsors/cmars
> (my company Intevation is one, we also gave a small donation to KF Web running
>  https://sks-keyservers.net/).
>
>
> [1]
>   Web of Trust's usefulness [Reiter 2019-07 c]
>   https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034412.html
>
>   | as additional source of trust and history.
>
>   | Abandoning the web of trust common infrastructure works against usage
>   | models where there is anonymous usage, several identities, non-email use
>   | and offline usage. All those maybe not the majority case, they may even be
>   | niche models, but I think they are important to add diversity and
>   | resiliance against manipulations of mainstream players.
>(spelling improved)
>
> --
> www.intevation.de/~bernhard   +49 541 33 508 3-3
> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Seeking help.

2020-10-24 Thread Mike via Gnupg-users
Ok, thank you.

On Thu, Oct 22, 2020, 9:30 AM Werner Koch  wrote:

> On Wed, 21 Oct 2020 18:59, Mike said:
> > I had to recover gnupg file from a corrupted os. The contents of the
> gnupg
> > file are encrypted and are not in openpgp data. So when I try to import
> my
> > keys from 'private-keys-v1.d' nothing happens. Output says no openpgp
> data
> > found and 0 items processed.
>
> You simply restore the files from private-keys-v1. These are internal to
> gnupg and it is not possible or needed to importat them.  The format of
> the private key files is well specified and we take care to keep them
> compatible with all GnuPG 2 versions.
>
> To make the restored private keys actually work you also need the public
> keys.  Ask someone else or a keyserver to send you your public key if
> you don't have a backup.  With the private keys in place gpg will be
> able list them and be able to decrypt or sign data.
>
>
> Salam-Shalom,
>
>Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

GPGME (for python) questions

2020-10-24 Thread Hammett, Rich via Gnupg-users
Is there a guide anywhere for what versions of GnuPG are supported by what 
versions of GPGME?

I only need encryption and decryption as part of an automated software 
framework, and I’m trying to migrate from an existing toolset that uses GnuPG 
v1.4 and python-gnupg.  We need to be able to pgp encrypt and decrypt without 
human interaction.  I’m working through the various ways to move up to more 
current software, and latest GPGME with latest GnuPG is probably the best, if I 
can figure out the python bindings and if GnuPG works with pinentry for 
automated decryption.

Any tips, any good documents out there?  Are there archives of this list 
somewhere, or is that private for the same reason the subscribers’ list is?

Thanks!

Rich Hammett
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users