Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. GnuPG>
  3. devel
GnuPG 2.3 Beta
gnupg-devel at gnupg
Feb 21, 2021, 11:50 PM
Post #1 of 22 (2013 views)
Permalink
Hi!

We plan to soon start with a GnuPG 2.3 series to slightly modernize
GnuPG. We will need a few releases to fix still open bugs and to learn
about new problems. Before we release 2.3.0 we consider it useful to
have a wider beta tests to catch build problems etc.

2.3 is GnuPG Git master and is regulary used at least by us. However,
building from Git is harder than building from a regular tarball or just
using a Windows installer. Thus here is our Beta:

https://gnupg.org/ftp/gcrypt/gnupg/unstable/gnupg-2.3.0-beta1598.tar.bz2
https://gnupg.org/ftp/gcrypt/gnupg/unstable/gnupg-2.3.0-beta1598.tar.bz2.sig

You need the latest version of Libgcrypt and libgpg-error to build it.
Windows users may want to try the installer at

https://gnupg.org/ftp/gcrypt/binary/unstable/gnupg-w32-2.3.0-beta1598_20210221.exe
https://gnupg.org/ftp/gcrypt/binary/unstable/gnupg-w32-2.3.0-beta1598_20210221.exe.sig

As usual no guarantee for not breaking things. As long as no new
options are used in the config files there should be no problem to move
back to 2.2.27.

Here is a list of new things which you do not find in 2.2.27:

* A new experimental key database daemon is provided. To enable it
put "use-keyboxd" into gpg.conf and gpgsm.conf. Keys are stored in
a SQLite database and make key lookup much faster. [.To test this
you need to export your public keys to a file, then put the option
into gpg.conf and gpgsm.conf and import the keys again.]

* New tool gpg-card as a flexible frontend for all types of
supported smartcards.

* New option --chuid for gpg, gpgsm, gpgconf, gpg-card, and
gpg-connect-agent.

* The gpg-wks-client tool is now installed under bin; a wrapper for
its old location at libexec is also installed.

* gpg: Switch to ed25519/cv25519 as default public key algorithms.

* gpg: Verification results now depend on the --sender option and
the signer's UID subpacket. [T4735]

* gpg: Do not use any 64-bit block size cipher algorithm for
encryption. Use AES as last resort cipher preference instead of
3DES. This can be reverted using --allow-old-cipher-algos.

* gpg: Support AEAD encryption mode using OCB or EAX.

* gpg: Support v5 keys and signatures.

* gpg: Support curve X448 (ed448, cv448).

* gpg: Allow use of group names in key listings. [e825aea2ba]

* gpg: New option --full-timestrings to print date and time.

* gpg: The legacy key discovery method PKA is no longer supported.
The command --print-pka-records and the PKA related import and
export options have been removed.

* gpgsm: Add basic ECC support.

* gpgsm: Support creation of EdDSA certificates. [#4888]

* agent: Allow the use of "Label:" in a key file to customize the
pinentry prompt. [5388537806]

* agent: Support ssh-agent extensions for environment variables.
With a patched version of OpenSSH this avoids the need for the
"updatestartuptty" kludge. [224e26cf7b]

* scd: Improve support for multiple card readers and tokens.

* scd: Support PIV cards.

* scd: Support the Telesec Signature Card v2.0

* scd: Support multiple application on certain smartcard.

* scd: New option --application-priority.

* dirmngr: Support a gpgNtds parameter in LDAP keyserver URLs.

* The symcryptrun tool, a wrapper for the now obsolete external
Chiasmus tool, has been removed.


Please send bug report to this list. See https://dev.gnupg.org/T4417
for some work items we still want to address.



Happy hacking.

Your GnuPG hackers.


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
gnupg-devel at gnupg
Feb 22, 2021, 8:03 AM
Post #2 of 22 (2013 views)
Permalink
> * A new experimental key database daemon is provided. To enable it
> put "use-keyboxd" into gpg.conf and gpgsm.conf. Keys are stored in
> a SQLite database and make key lookup much faster. [.To test this
> you need to export your public keys to a file, then put the option
> into gpg.conf and gpgsm.conf and import the keys again.]

This will make some of my workflow much easier. Thank you!

> * gpg: Switch to ed25519/cv25519 as default public key algorithms.

Also welcome.

> * gpg: Do not use any 64-bit block size cipher algorithm for
> encryption. Use AES as last resort cipher preference instead of
> 3DES. This can be reverted using --allow-old-cipher-algos.

Overdue. Happy to see it!

> * gpg: Support AEAD encryption mode using OCB or EAX.

Overdue. Also happy to see this. :)

Thank you for all your hard work!

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
gnupg-devel at gnupg
Feb 22, 2021, 8:15 AM
Post #3 of 22 (2013 views)
Permalink
Hi Werner,

Werner Koch via Gnupg-devel <gnupg-devel@gnupg.org> wrote:

>Before we release 2.3.0 we consider it useful to
>have a wider beta tests to catch build problems etc.
>
>2.3 is GnuPG Git master and is regulary used at least by us. However,
>building from Git is harder than building from a regular tarball or
>just using a Windows installer. Thus here is our Beta:
>
> https://gnupg.org/ftp/gcrypt/gnupg/unstable/gnupg-2.3.0-beta1598.tar.bz2
> https://gnupg.org/ftp/gcrypt/gnupg/unstable/gnupg-2.3.0-beta1598.tar.bz2.sig

OK, have installed it under Debian Buster. Created a new test key with
curve X448. Encrypt, verify and sign files in terminal works, the same
with e-mails (with Claws Mail 3.17). Searching and importing your key
over keyserver works. Works with Yubikey 4, Samhain HIDS, apt.

Passphrase caching with Claws Mail doesn't work, i have to give the
passphrase every time.

GnuPG v2.3.0-beta1598 has been configured as follows:
Revision: 54c1f2518 (21697)
Platform: GNU/Linux (x86_64-pc-linux-gnu)
OpenPGP: yes
S/MIME: yes
Agent: yes
Smartcard: yes (without internal CCID driver)
G13: no
Dirmngr: yes
Keyboxd: yes
Gpgtar: yes
WKS tools: yes
Protect tool: /usr/local/bin/gpg-protect-tool
LDAP wrapper: /usr/local/bin/dirmngr_ldap
Default agent: /usr/local/bin/gpg-agent
Default pinentry: /usr/local/bin/pinentry
Default scdaemon: /usr/local/bin/scdaemon
Default keyboxd: (default)
Default dirmngr: /usr/local/bin/dirmngr
Dirmngr auto start: yes
Readline support: yes
LDAP support:yes
TLS support: gnutls
TOFU support:yes
Tor support: yes

--
mlnl

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
gnupg-devel at gnupg
Feb 22, 2021, 10:39 AM
Post #4 of 22 (2013 views)
Permalink
On Mon, 22 Feb 2021 11:03, Robert J. Hansen said:

> This will make some of my workflow much easier. Thank you!

Take care, it is not yet well tested. I am using it for some time now,
though.

>> * gpg: Support AEAD encryption mode using OCB or EAX.
>
> Overdue. Also happy to see this. :)

Me too. Will take quite some time until keys with such preferences will
be widely used. This implements a draft but we have done interop tests
with 2 other implementations and thus I think it is safe to be used.

It even seems that Phil Rogaway stopped paying the fees to the PTO and
thus uncertainties over OCB mode should be void soon. So no need for
any implementations to only provide EAX mode.



Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
gnupg-devel at gnupg
Feb 22, 2021, 11:36 PM
Post #5 of 22 (2012 views)
Permalink
On Mon, 22 Feb 2021 17:15, mlnl said:

> OK, have installed it under Debian Buster. Created a new test key with
> curve X448. Encrypt, verify and sign files in terminal works, the same
> with e-mails (with Claws Mail 3.17). Searching and importing your key
> over keyserver works. Works with Yubikey 4, Samhain HIDS, apt.

Thanks for testing. What ist the Samhain HIDS - it does sound not like
an OpenPGP card so you used it with S/MIME?

> Passphrase caching with Claws Mail doesn't work, i have to give the
> passphrase every time.

That is strange because the caching is done in gpg-agent and independent
of the Pinentry or an application using GnuPG (via GPGME in the Claws
case). The most likely reason that it does not work is that the agent
has been stopped before the next operation was done. I don't know why
but sometimes systemd's removal of the /run/users/UID directory is a
problem.

Can you please add

log-file /somewhere/gpg-agent/log
verbose
debug ipc

into ~/.gnupg/gpg-agent.log, restart gpg-agent and try again. The log
file should give some clues what's going wrong. You may add "debug
cache" to trace the caching but I doubt that this is the case.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
m at the13thletter
Feb 23, 2021, 1:48 AM
Post #6 of 22 (2012 views)
Permalink
Hi.

Thus spoke Werner Koch:
> * A new experimental key database daemon is provided. To enable it
> put "use-keyboxd" into gpg.conf and gpgsm.conf. Keys are stored in
> a SQLite database and make key lookup much faster. [.To test this
> you need to export your public keys to a file, then put the option
> into gpg.conf and gpgsm.conf and import the keys again.]

Forgive my ignorance, but why exactly do you set up a new daemon for
this? Just based on the description of the feature, I would have rather
expected a shared library to be used for this, well, shared
functionality. Why use a daemon instead? What sort of background work
does the keybox daemon do that necessitates an unattended long-running
background process? At the very least, it seems pretty overkill to me.

Cheers,
Marco

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
m at the13thletter
Feb 23, 2021, 1:49 AM
Post #7 of 22 (2012 views)
Permalink
Hi.

Thus spoke Werner Koch:
>>> * gpg: Support AEAD encryption mode using OCB or EAX.
>>
>> Overdue. Also happy to see this. :)
>
> Me too. Will take quite some time until keys with such preferences
> will be widely used. This implements a draft but we have done interop
> tests with 2 other implementations and thus I think it is safe to be
> used.

Do these comments about interoperability/consensus apply to v5 keys,
signatures and the X448 curve as well? Or are those still true draft
features?

Cheers,
Marco

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
gnupg-devel at gnupg
Feb 23, 2021, 4:15 AM
Post #8 of 22 (2012 views)
Permalink
On Tue, 23 Feb 2021 10:49, Marco Ricci said:

> Do these comments about interoperability/consensus apply to v5 keys,
> signatures and the X448 curve as well? Or are those still true draft

X448 is too new and we have not done interop tests which we did for v5
keys and signatures (but less diligent than for AEAD).


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
gnupg-devel at gnupg
Feb 23, 2021, 4:24 AM
Post #9 of 22 (2012 views)
Permalink
On Tue, 23 Feb 2021 10:48, Marco Ricci said:

> Forgive my ignorance, but why exactly do you set up a new daemon for
> this? Just based on the description of the feature, I would have rather

We use SQLite and transactions are very expensive if more than one
process is accessing the DB. So what we do is what all other database
engines do: run a single process with exclusive access to the DB. There
is some overhead due to IPC but overall things are much faster.

The reason why several processes need to access the DB is that there are
often several gpg processes running and working on the same keyring.
This needs to be synchronized. Without the keyboxd we lock the keyring
and all other gpg and gpgsm processes need to wait until they can
continue even with a read. This multi-process serialization slows down
everything.

Try running Kleopatra with a large keyring with and without keyboxd. It
makes a huge difference.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
m at the13thletter
Feb 24, 2021, 3:06 AM
Post #10 of 22 (2012 views)
Permalink
Greetings.

Thus spoke Werner Koch:
> X448 is too new and we have not done interop tests which we did for v5
> keys and signatures (but less diligent than for AEAD).

Then let me ask directly: if I generate an Ed448 key (packet), an ECDH
X448 key (packet), or a general v5 key or v5 signature packet, using
GnuPG 2.3beta, can I assume that when exporting such keys/signatures
they (a) conform to RFC4880bis-10, and (b) they remain *valid* packets
even when RFC4880bis is finalized? Or is the format still experimental?

I took your previous commentary about AEAD to mean that EAX and OCB mode
are pretty much final, as far as RFC4880bis is concerned, and that
you're in the phase "we need multiple interoperable implementations in
the wild so that we can add this to the RFC, so now we're releasing one
such implementation". So what I'm actually wondering about is whether
this holds for the v5 keys/signatures and X448 formats as well.

Thanks, and cheers,
Marco

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
m at the13thletter
Feb 24, 2021, 3:06 AM
Post #11 of 22 (2012 views)
Permalink
Greetings.

Thus spoke Werner Koch:
> On Tue, 23 Feb 2021 10:48, Marco Ricci said:
>
>> Forgive my ignorance, but why exactly do you set up a new daemon for
>> this? Just based on the description of the feature, I would have rather
>
> We use SQLite and transactions are very expensive if more than one
> process is accessing the DB. So what we do is what all other database
> engines do: run a single process with exclusive access to the DB. There
> is some overhead due to IPC but overall things are much faster.

I see. This makes me really sad... even though I can see the temptation
to solve the performance issue this way.

> The reason why several processes need to access the DB is that there are
> often several gpg processes running and working on the same keyring.
> This needs to be synchronized. Without the keyboxd we lock the keyring
> and all other gpg and gpgsm processes need to wait until they can
> continue even with a read. This multi-process serialization slows down
> everything.

I grepped the current git HEAD -- I have no idea which commit the beta
is supposed to be, I couldn't find a tag or anything -- and saw that you
don't use SQLite's WAL mode [1], which is designed for better
reader/writer-concurrency than naive full file locking. Have you tried
that already? From what the documentation says, SQLite's native Unix and
Windows drivers can make use of shared-memory primitives on both
systems, so you wouldn't need to go the slower route of synchronizing
via full file locks... on Unix and Windows at least.

[1]: https://sqlite.org/wal.html

(I checked dev.gnupg.org, but couldn't find any mention of WAL mode.)

(Or is the design already at the WONTFIX stage?)

On that note: Both the beta and git HEAD require SQLite 3.7 in
configure/configure.ac. But in T4510 you started shipping (requiring?)
SQLite 3.28. Perhaps you need to update and/or re-evaluate which SQLite
version you require at a minimum? This might then be a good time to
check if requiring a newer SQLite and then using WAL mode solves your
performance problems.

Cheers,
Marco

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
gnupg-devel at gnupg
Feb 24, 2021, 12:58 PM
Post #12 of 22 (2011 views)
Permalink
On Wed, 24 Feb 2021 12:06, Marco Ricci said:

> I see. This makes me really sad... even though I can see the temptation
> to solve the performance issue this way.

The overhead is really minimal. For example I tried descriptor
forwarding instead of using inline data in the IPC. This did not make
much of a difference and thus the code is not anymore used.

> I grepped the current git HEAD -- I have no idea which commit the beta
> is supposed to be, I couldn't find a tag or anything -- and saw that you

gpgconf --show-versions | head -1

shows the commit.

> don't use SQLite's WAL mode [1], which is designed for better
> reader/writer-concurrency than naive full file locking. Have you tried
> that already? From what the documentation says, SQLite's native Unix

We use Sqlite for Tofu for quite some time and did some experiments.
Given that gpg is short-living process you don't get any advantage from
that. Really, a dedicted server process is the most robust and fastest
solution.

> (Or is the design already at the WONTFIX stage?)

We need this and it was a long standing plan to unify the database
storage. And we expected complains about yet another process ;-)

> configure/configure.ac. But in T4510 you started shipping (requiring?)
> SQLite 3.28. Perhaps you need to update and/or re-evaluate which SQLite

Yeah, we should eventually update our copy. We have a copy of sqlite on
our server due to our build process.

> version you require at a minimum? This might then be a good time to
> check if requiring a newer SQLite and then using WAL mode solves your

Long running daemons can cache, shor tunning processes can't.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
gnupg-devel at gnupg
Feb 24, 2021, 1:15 PM
Post #13 of 22 (2011 views)
Permalink
On Wed, 24 Feb 2021 12:06, Marco Ricci said:

> Then let me ask directly: if I generate an Ed448 key (packet), an ECDH
> X448 key (packet), or a general v5 key or v5 signature packet, using

I would not suggest to do this because there are to my knowledge no
other implementations which can use that. OTOH, cv25519/ed25519 support
is widely deployed and for example protonmail.com uses it for more than
a year by default.

BTW, for AEAD we have even read support in 2.2 so that if something goes
wrong with AEAD preferences 2.2 can still receive such messages.

> GnuPG 2.3beta, can I assume that when exporting such keys/signatures
> they (a) conform to RFC4880bis-10, and (b) they remain *valid* packets
> even when RFC4880bis is finalized? Or is the format still experimental?

I can't know for sure but there are at least 3 mainstream
implementations using this format (openpgp.js, rnp, gnupg).

> I took your previous commentary about AEAD to mean that EAX and OCB mode
> are pretty much final, as far as RFC4880bis is concerned, and that
> you're in the phase "we need multiple interoperable implementations in
> the wild so that we can add this to the RFC, so now we're releasing one

We do have these implementaions adn did interop tests several years
ago. There were just some disturbing actions in the WG so that the area
director decided to start from scratch.

> such implementation". So what I'm actually wondering about is whether
> this holds for the v5 keys/signatures and X448 formats as well.

We did fewer interop tests and the WG once had rough consensus.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
gnupg-devel at gnupg
Feb 24, 2021, 1:51 PM
Post #14 of 22 (2011 views)
Permalink
On Wed, 24 Feb 2021 21:58, Werner Koch said:
> Yeah, we should eventually update our copy. We have a copy of sqlite on
> our server due to our build process.

Oops, I misunderstood you. We actually use 3.28 but the configure does
not require 3.28. I guess will update this so that ppl are forced to
install a fixed copy on their system.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
m at the13thletter
Feb 25, 2021, 7:40 AM
Post #15 of 22 (2011 views)
Permalink
Greetings.

Another report on Debian/amd64.

I tried a couple of build variations from scratch, using GCC 9.3.0 and
all the latest tarballs from all dependencies (gnupg-2.3.0-beta1598,
libassuan-2.5.4, libgcrypt-1.9.2, libgpg-error-1.41, libksba-1.5.0,
npth-1.6, ntbtls-0.2.0 and sqlite-amalgamation-3340100). All
dependencies were installed per-user, not system-wide, and only in
a common build directory outside of /usr. SQLite 3.27.2 is also
available system-wide. All components were configured with
--with-libgpg-error-prefix=... etc. as applicable. GnuPG was further
configured with --with-capabilities.

* A normal (dynamically linked) build works just fine, for every
component. Just like for mlnl.

* A static build with LDFLAGS=-static works in all components except
GnuPG itself, where neither the linked in libsqlite3.a nor
libgpg-error.a can resolve the dlsym and pthread symbols.

* A normal build with musl-gcc may or may not work; I couldn't
properly test it due to the ntbtls issue below. I don't have clang
installed, so no idea about that either.

* Both the npth and gnupg configure scripts claim to support
--with-libksba-prefix=DIR. Using that option has no effect. Using
the option --with-ksba-prefix=DIR instead (i.e. without the "lib"
prefix) works, and has the desired effect.

* ntbtls configure claims to support --with-zlib=DIR. Using this has
no effect; zlib is required to be in the standard location, else the
build fails.

* gnupg configure does not support specifying an alternate sqlite3
location; there is no --with-sqlite3-prefix or similar. My example
build thus linked against SQLite 3.27 as provided by my system,
instead of SQLite 3.34 as intended by me.

Hope this helps.

Cheers,
Marco

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
gnupg-devel at gnupg
Mar 15, 2021, 10:40 AM
Post #16 of 22 (1998 views)
Permalink
On Thu, 25 Feb 2021 16:40, Marco Ricci said:

> * A static build with LDFLAGS=-static works in all components except
> GnuPG itself, where neither the linked in libsqlite3.a nor
> libgpg-error.a can resolve the dlsym and pthread symbols.

We need pthreads on Unix and also dlopen some functions (e.g. PC/SC).
Building statically has never been intended.

> * Both the npth and gnupg configure scripts claim to support
> --with-libksba-prefix=DIR. Using that option has no effect. Using
> the option --with-ksba-prefix=DIR instead (i.e. without the "lib"
> prefix) works, and has the desired effect.

Both should be supported but indeed we tweaked the build system some
time ago. Gniibe: would you mind to check whether we can fix this?

> * ntbtls configure claims to support --with-zlib=DIR. Using this has
> no effect; zlib is required to be in the standard location, else the
> build fails.

I need to check this but actually this is teh same code as in gpg.

> * gnupg configure does not support specifying an alternate sqlite3
> location; there is no --with-sqlite3-prefix or similar. My example
> build thus linked against SQLite 3.27 as provided by my system,
> instead of SQLite 3.34 as intended by me.

For our speedo build script we use our own hosted version of sqlite.
Actually you may want to use the speedo build method
(build-aux/speedo.mk) if you have many non-standard libraries.

Thanks for testing.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
gnupg-devel at gnupg
Mar 15, 2021, 3:06 PM
Post #17 of 22 (1998 views)
Permalink
On Tue, Feb 23, 2021 at 12:26 PM Werner Koch via Gnupg-devel
<gnupg-devel@gnupg.org> wrote:
>
> On Tue, 23 Feb 2021 10:48, Marco Ricci said:
>
> > Forgive my ignorance, but why exactly do you set up a new daemon for
> > this? Just based on the description of the feature, I would have rather
>
> We use SQLite and transactions are very expensive if more than one
> process is accessing the DB. So what we do is what all other database
> engines do: run a single process with exclusive access to the DB. There
> is some overhead due to IPC but overall things are much faster.
>
> The reason why several processes need to access the DB is that there are
> often several gpg processes running and working on the same keyring.
> This needs to be synchronized. Without the keyboxd we lock the keyring
> and all other gpg and gpgsm processes need to wait until they can
> continue even with a read. This multi-process serialization slows down
> everything.

I know many users of gpg are on single-user systems, but for systems
with more than one user, does this mean that each user will need to
start their own daemon, listening on their own ports? Or is there a
single process running as a different user?

Sorry to get caught up on one specific aspect. It's really good to
see the 2.3 branch.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: GnuPG 2.3 Beta [ In reply to ]
gnupg-devel at gnupg
Mar 16, 2021, 3:06 AM
Post #18 of 22 (1998 views)
Permalink
On Mon, 15 Mar 2021 22:06, Nicholas Cole said:

> I know many users of gpg are on single-user systems, but for systems
> with more than one user, does this mean that each user will need to
> start their own daemon, listening on their own ports? Or is there a

These are all per-user daemon. That is easier for security and
configration reasons.

Back in the 2.0 age we allowed to run the dirmngr as a syustem wide
daemon. Back then the primary task was to access to LDAP files and
foremost to load and cache CRLs. So with 100 users on a machine only
one CRL download was required. However, large multi user installations
are rare and are a permanent problem security wise. Thus with 2.2 we
dropped this feature and let each user configure the dirmngr to her own
needs.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
m at the13thletter
Mar 16, 2021, 3:26 AM
Post #19 of 22 (1998 views)
Permalink
Hi Nicolas.

Thus spoke Nicholas Cole:
> I know many users of gpg are on single-user systems, but for systems
> with more than one user, does this mean that each user will need to
> start their own daemon, listening on their own ports? Or is there
> a single process running as a different user?

Same as gpg-agent, dirmngr and scdaemon: one process per GnuPG homedir,
and communication via a socket S.keyboxd in the homedir. (Dunno about
Windows, but I assume it's similar.)

Cheers,
Marco

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
gnupg-devel at gnupg
Mar 16, 2021, 7:22 PM
Post #20 of 22 (1998 views)
Permalink
Nicholas Cole via Gnupg-devel wrote:
> does this mean that each user will need to
> start their own daemon, listening on their own ports?

The solution to that is very easy, at least on POSIX systems: an
AF_UNIX socket in the user's home directory, with the name including the
hostname on which the daemon is running to support environments where
home directories are shared on NFS or similar.


-- Jacob

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: GnuPG 2.3 Beta [ In reply to ]
gnupg-devel at gnupg
Mar 17, 2021, 5:58 AM
Post #21 of 22 (1998 views)
Permalink
On Tue, 16 Mar 2021 11:26, Marco Ricci said:

> Same as gpg-agent, dirmngr and scdaemon: one process per GnuPG homedir,
> and communication via a socket S.keyboxd in the homedir. (Dunno about
> Windows, but I assume it's similar.)

Right, Windows works the same. Except that we don't use a socket but a
plain file having the localhost TCP port number and a magic cookie.

gpgconf --list-dirs

shows the socket names also on Windows.

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Attached Files:

Re: GnuPG 2.3 Beta [ In reply to ]
gnupg-devel at gnupg
Mar 17, 2021, 6:02 AM
Post #22 of 22 (1998 views)
Permalink
On Tue, 16 Mar 2021 21:22, Jacob Bachmeyer said:

> The solution to that is very easy, at least on POSIX systems: an
> AF_UNIX socket in the user's home directory, with the name including

It should actually not be in the home directory but under
/var/run/user/<UID>/gnupg/
to avoid problems with remote file systems. ~/.gnupg is just a
fallback in case /var/run/user/<UID>/ does not exist.

If the homedirectory is changed (vis GNUPGHOME or --homedir) a specially
named subdirectory below the /var/run/ directory is used.
gpgconf --list-dirs
shows things.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Attached Files:

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal