[PATCH] build: Increase libassuan min version to 2.5.0

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

[PATCH] build: Increase libassuan min version to 2.5.0

Kristian Fiskerstrand-6
Subject: [PATCH] build: Increase libassuan min version to 2.5.0

--
assuan_sock_set_system_hooks is used unconditionally in gnupg since
commit 9f641430dcdecbd7ee205d407cb19bb4262aa95d, and as such it requires
libassuan 2.5.0 (function introduced in
commit 90dc81682b13a7cf716a8a26b891051cbd4b0caf)
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Varitatio delectat
Change pleases

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

0001-build-Increase-libassuan-min-version-to-2.5.0.patch (908 bytes) Download Attachment
signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] build: Increase libassuan min version to 2.5.0

Werner Koch
On Wed, 20 Dec 2017 21:25, [hidden email]
said:
> Subject: [PATCH] build: Increase libassuan min version to 2.5.0

Ooops.  No release without glitches.

We had to use that new libassuan function to fix a hang on Windows.  I
am not 100% sure whether Unix is also affected; @gniibe: can you enlight
us?

Does this new requirement pose a problem for Linux distros?  If so we
should see whether we can do something about it.  


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

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] build: Increase libassuan min version to 2.5.0

Kristian Fiskerstrand-6
On December 21, 2017 9:02:38 AM GMT+01:00, Werner Koch <[hidden email]> wrote:

>On Wed, 20 Dec 2017 21:25, [hidden email]
>said:
>> Subject: [PATCH] build: Increase libassuan min version to 2.5.0
>
>Ooops.  No release without glitches.
>
>We had to use that new libassuan function to fix a hang on Windows.  I
>am not 100% sure whether Unix is also affected; @gniibe: can you
>enlight
>us?
>
>Does this new requirement pose a problem for Linux distros?  If so we
>should see whether we can do something about it.  
>
>
>Salam-Shalom,
>
>   Werner

New requirement doesn't pose a problem for Gentoo at least.
--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP certificate at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] build: Increase libassuan min version to 2.5.0

Daniel Kahn Gillmor-7
In reply to this post by Werner Koch
On Thu 2017-12-21 09:02:38 +0100, Werner Koch wrote:

> On Wed, 20 Dec 2017 21:25, [hidden email]
> said:
>> Subject: [PATCH] build: Increase libassuan min version to 2.5.0
>
> Ooops.  No release without glitches.
>
> We had to use that new libassuan function to fix a hang on Windows.  I
> am not 100% sure whether Unix is also affected; @gniibe: can you enlight
> us?
>
> Does this new requirement pose a problem for Linux distros?  If so we
> should see whether we can do something about it.  
when i'm thinking about backporting GnuPG for older debian releases, i
typically assume i'll need to backport a set of GnuPG-specific
dependencies as well.  It shouldn't be particularly painful to include
assuan in that list.  If i find it's painful, i'll let you know, but for
the moment, please don't prioritize it for my sake.

    --dkg

PS what i'd really *like* in terms of dependency creep is a new release
   of libgpg-error that includes yat2m and gpgscm, so i can make it a
   build-dependency of gnupg itself, and get the gnupg package out of
   the business of building these mainly orthogonal tools. :)

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

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

Re: [PATCH] build: Increase libassuan min version to 2.5.0

NIIBE Yutaka
In reply to this post by Werner Koch
Werner Koch <[hidden email]> writes:
> We had to use that new libassuan function to fix a hang on Windows.  I
> am not 100% sure whether Unix is also affected; @gniibe: can you enlight
> us?

The change is not needed for Unix.  Let me explain.

The problem is about the initialization of nPth (the thread library),
the use of libassuan, and UNIX domain socket emulation on Windows.

We use nPth library for cooperative threads.  When a thread of an
application calls a system call which may block, the thread should
release the "execution right" (which is only given to a single thread at
a time) and then, after the system call, it should acquire the right.
This way, an application doesn't cause any hang, and execution is done
by single thread, cooperatively.  Libassuan uses hooks for this
mechanism for its calls of usleep, read, write, recvmsg, sendmsg,
waitpid, connect, and close.

We want to defer the nPth initialization, to be done after fork(2) on
Unix, because forking a process of multiple threads may open a can of
worms (of undefined/undocumented things).  gpg-agent prepares listing
sockets, forks, and then, it comes nPth initialization.

On the other hand, before nPth initialization (forking on Unix),
gpg-agent uses libassuan to check if another gpg-agent is available or
not.  This use of libassuan is done by non-threaded mode (it blocks on
connect/read/write).

There are two access mode in use of libassuan: by assuan_sock_*
functions with standard sock_fd, and by assuan context of
type assuan_context_t CTX.

Before the fix, use of assuan_sock_* by libassuan had the setting of
non-threaded mode, because of the order of initialization (nPth
initialization is done after fork).

This worked well on Unix, because all the things done by assuan_sock_*
are things by listening socket and checking nonce before
start_command_handler.  After checking nonce (which is null on Unix), it
uses the assuan context.

Things done by listening sockets are: poll on new connection by its own
call of nPth function (npth_select), accept (by npth_accept), and create
a new thread to work with the connection.  No problem, even if
non-threaded mode of libassuan.

On Windows, UNIX domain socket emulation does checking nonce (by read
and write), and it was done in non-threaded mode of libassuan.  This
caused a race condition, where the entire gpg-agent process might hang.


The fix is that we provide an API (assuan_sock_set_system_hooks) to
initialize, for the accesses by assuan_sock_* functions (along with
assuan_set_system_hooks).  Before the fix, the accesses by assuan_sock_*
functions only inherited the setting by assuan_set_system_hooks.  Now,
it can be done independently.  Thus, on Windows, checking nonce is now
done in threaded-mode, which can avoid hang.
--

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] build: Increase libassuan min version to 2.5.0

Werner Koch
In reply to this post by Daniel Kahn Gillmor-7
On Thu, 21 Dec 2017 22:28, [hidden email] said:

> dependencies as well.  It shouldn't be particularly painful to include
> assuan in that list.  If i find it's painful, i'll let you know, but for
> the moment, please don't prioritize it for my sake.

Okay.

> PS what i'd really *like* in terms of dependency creep is a new release
>    of libgpg-error that includes yat2m and gpgscm, so i can make it a
>    build-dependency of gnupg itself, and get the gnupg package out of

I am slowly working in it but gpgscm has a lot og gnupg dependencies;
Some need to be ported to libgpg-error and other may better be
re-written in scheme as part of the gnupg test suite.

If it is really urgent I could soon do a release with yat2m but without
gpgscm.


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

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] build: Increase libassuan min version to 2.5.0

Daniel Kahn Gillmor-7
On Fri 2017-12-22 09:53:21 +0100, Werner Koch wrote:

> On Thu, 21 Dec 2017 22:28, [hidden email] said:
>> PS what i'd really *like* in terms of dependency creep is a new release
>>    of libgpg-error that includes yat2m and gpgscm, so i can make it a
>>    build-dependency of gnupg itself, and get the gnupg package out of
>
> I am slowly working in it but gpgscm has a lot og gnupg dependencies;
> Some need to be ported to libgpg-error and other may better be
> re-written in scheme as part of the gnupg test suite.
>
> If it is really urgent I could soon do a release with yat2m but without
> gpgscm.

it's not really urgent, but i would hope that transitioning to a
standard form of yat2m would not block on the changes needed by gpgscm.

         --dkg

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