GnuPG 2.3 Beta

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

GnuPG 2.3 Beta

GnuPG - Dev mailing list
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.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

GnuPG - Dev mailing list
>    * 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!


_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

OpenPGP_signature (243 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

GnuPG - Dev mailing list
In reply to this post by GnuPG - Dev mailing list
Hi Werner,

Werner Koch via Gnupg-devel <[hidden email]> 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


_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

0x8777461F2A074EBC480D359419CC1C9E085B107A.asc (1K) Download Attachment
attachment1 (355 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

GnuPG - Dev mailing list
In reply to this post by GnuPG - Dev mailing list
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.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

GnuPG - Dev mailing list
In reply to this post by GnuPG - Dev mailing list
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.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

Marco Ricci
In reply to this post by GnuPG - Dev mailing list
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



_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

OpenPGP_signature (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

Marco Ricci
In reply to this post by GnuPG - Dev mailing list
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




_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

OpenPGP_signature (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

GnuPG - Dev mailing list
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.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

GnuPG - Dev mailing list
In reply to this post by Marco Ricci
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.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

Marco Ricci
In reply to this post by GnuPG - Dev mailing list
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


_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

OpenPGP_signature (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

Marco Ricci
In reply to this post by GnuPG - Dev mailing list
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



_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

OpenPGP_signature (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

GnuPG - Dev mailing list
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.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

GnuPG - Dev mailing list
In reply to this post by Marco Ricci
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.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

GnuPG - Dev mailing list
In reply to this post by GnuPG - Dev mailing list
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.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

Marco Ricci
In reply to this post by GnuPG - Dev mailing list
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


_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

OpenPGP_signature (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

GnuPG - Dev mailing list
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.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

GnuPG - Dev mailing list
In reply to this post by GnuPG - Dev mailing list
On Tue, Feb 23, 2021 at 12:26 PM Werner Koch via Gnupg-devel
<[hidden email]> 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
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

GnuPG - Dev mailing list
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.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

Marco Ricci
In reply to this post by GnuPG - Dev mailing list
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


_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

OpenPGP_signature (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuPG 2.3 Beta

GnuPG - Dev mailing list
In reply to this post by GnuPG - Dev mailing list
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
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
12