From mg at fork.pl  Thu Sep  6 22:26:24 2018
From: mg at fork.pl (Marcin Gryszkalis)
Date: Thu, 06 Sep 2018 22:26:24 +0200
Subject: =?iso-8859-1?Q?gnupg=5Freopen=5Fstd_-_descriptor_state_problem?=
Message-ID: <707fc580-b13b-4a0b-a1c9-353c7063a00b@fork.pl>

Hi there

I have perl web application running on FreeBSD that calls gnupg. 
During tests I started getting an error:
fatal: unable to reopen standard input
from gnupg_reopen_std.

I did some ktrace-ing and it seems that stdin has unexpected state:
fstat(0) indicated EBADF but the desccriptor was not closed.
After EBADF gnupg_reopen_std assumes it is closed and tries to reopen it to 
/dev/null 
(and in my case it gets new descriptor):

54974 gpg2     CALL  fstat(0,0x7fffffffdf70)
54974 gpg2     RET   fstat -1 errno 9 Bad file descriptor	
54974 gpg2     CALL  openat(AT_FDCWD,0x4aac8a,0<O_RDONLY>,<unused>0)
54974 gpg2     NAMI  "/dev/null"
54974 gpg2     RET   openat 5 <-- we don't get 0 but 5 (new file opened)

54974 gpg2     CALL  fstat(0x1,0x7fffffffdf70) <-- for stdout it's ok
54974 gpg2     STRU  struct stat {dev=74, ino=2, mode=010000, nlink=0, 
uid=1004, gid=1003, rdev=0, atime=1536171587.677756000, 
mtime=1536171587.677756000, ctime=1536171587.677756000, birthtime=0, 
size=0, blksize=4096, blocks=0, flags=0x0 }
54974 gpg2     RET   fstat 0

I don't really know what happens to stdin - the perl application binds 
CGI.pm input 
to stdin so it may possibly reach eof (but it shouldn't cause EBADF I 
guess).

I made a simple patch adding close():

 562   if (fstat (STDIN_FILENO, &statbuf) == -1 && errno ==EBADF)
 563     {
           close(STDIN_FILENO); <<<--- here
 564       if (open ("/dev/null",O_RDONLY) == STDIN_FILENO)
 565     did_stdin = 1;
 566       else
 567     did_stdin = 2;
 568     }

and it seems to work properly:

57475 gpg2     CALL  fstat(0,0x7fffffffdf70)
57475 gpg2     RET   fstat -1 errno 9 Bad file descriptor <-- fstat returns 
EBADF
57475 gpg2     CALL  close(0)
57475 gpg2     RET   close 0 <-- close returns OK!
57475 gpg2     CALL  openat(AT_FDCWD,0x4abb5b,0<O_RDONLY>,<unused>0)
57475 gpg2     NAMI  "/dev/null"
57475 gpg2     RET   openat 0

when calling gpg with already closed stdin it behaves as expected:

$ ktrace gpg2 --version  <&-

17007 gpg2     CALL  fstat(0,0x7fffffffe3e0)
17007 gpg2     RET   fstat -1 errno 9 Bad file descriptor <-- fstat returns 
EBADF
17007 gpg2     CALL  close(0)
17007 gpg2     RET   close -1 errno 9 Bad file descriptor <-- close returns 
EBADF as well
17007 gpg2     CALL  openat(AT_FDCWD,0x4abb5b,0<O_RDONLY>,<unused>0)
17007 gpg2     NAMI  "/dev/null"
17007 gpg2     RET   openat 0 <-- reopened stdin


Now to the point: I would provide patch if you think that it can get 
accepted (would be 
useful no to remember to patch gpg :) ).

I can't see any problems additional close() could cause - but I'm not sure 
about all unix plaftorms. 
Any comments?

best regards
-- 
Marcin Gryszkalis, PGP 0xA5DBEEC7 http://fork.pl/gpg.txt



From gniibe at fsij.org  Fri Sep  7 04:58:04 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 07 Sep 2018 11:58:04 +0900
Subject: gnupg_reopen_std - descriptor state problem
In-Reply-To: <707fc580-b13b-4a0b-a1c9-353c7063a00b@fork.pl>
References: <707fc580-b13b-4a0b-a1c9-353c7063a00b@fork.pl>
Message-ID: <87va7iau9v.fsf@iwagami.gniibe.org>

Hello,

Marcin Gryszkalis <mg at fork.pl> wrote:
> I did some ktrace-ing and it seems that stdin has unexpected state:
> fstat(0) indicated EBADF but the desccriptor was not closed.
> After EBADF gnupg_reopen_std assumes it is closed and tries to reopen it to 
> /dev/null 
> (and in my case it gets new descriptor):
>
> 54974 gpg2     CALL  fstat(0,0x7fffffffdf70)
> 54974 gpg2     RET   fstat -1 errno 9 Bad file descriptor	
> 54974 gpg2     CALL  openat(AT_FDCWD,0x4aac8a,0<O_RDONLY>,<unused>0)
> 54974 gpg2     NAMI  "/dev/null"
> 54974 gpg2     RET   openat 5 <-- we don't get 0 but 5 (new file opened)
>
> 54974 gpg2     CALL  fstat(0x1,0x7fffffffdf70) <-- for stdout it's ok
> 54974 gpg2     STRU  struct stat {dev=74, ino=2, mode=010000, nlink=0, 
> uid=1004, gid=1003, rdev=0, atime=1536171587.677756000, 
> mtime=1536171587.677756000, ctime=1536171587.677756000, birthtime=0, 
> size=0, blksize=4096, blocks=0, flags=0x0 }
> 54974 gpg2     RET   fstat 0

Interesting.  Probably, the stdin is connected to the socket (which may
be already shutdown-ed), I don't know.

It seems that stdout is connected to named pipe, btw.

> I can't see any problems additional close() could cause - but I'm not sure 
> about all unix plaftorms. 
> Any comments?

I think that doing any operation on the fd (which retured EBADF) sounds
not healthy (even if it's close(2)).

I wonder if changes like following make sense to see if fd is valid or
not.  My theory is that fcntl is cheaper/simpler operation then fstat,
and might be better in this case.

diff --git a/common/sysutils.c b/common/sysutils.c
index 55a7ee9ec..899850403 100644
--- a/common/sysutils.c
+++ b/common/sysutils.c
@@ -552,13 +552,12 @@ void
 gnupg_reopen_std (const char *pgmname)
 {
 #if defined(HAVE_STAT) && !defined(HAVE_W32_SYSTEM)
-  struct stat statbuf;
   int did_stdin = 0;
   int did_stdout = 0;
   int did_stderr = 0;
   FILE *complain;
 
-  if (fstat (STDIN_FILENO, &statbuf) == -1 && errno ==EBADF)
+  if (fcntl (STDIN_FILENO, F_GETFD) == -1 && errno ==EBADF)
     {
       if (open ("/dev/null",O_RDONLY) == STDIN_FILENO)
 	did_stdin = 1;
@@ -566,7 +565,7 @@ gnupg_reopen_std (const char *pgmname)
 	did_stdin = 2;
     }
 
-  if (fstat (STDOUT_FILENO, &statbuf) == -1 && errno == EBADF)
+  if (fcntl (STDOUT_FILENO, F_GETFD) == -1 && errno == EBADF)
     {
       if (open ("/dev/null",O_WRONLY) == STDOUT_FILENO)
 	did_stdout = 1;
@@ -574,7 +573,7 @@ gnupg_reopen_std (const char *pgmname)
 	did_stdout = 2;
     }
 
-  if (fstat (STDERR_FILENO, &statbuf)==-1 && errno==EBADF)
+  if (fcntl (STDERR_FILENO, F_GETFD)==-1 && errno==EBADF)
     {
       if (open ("/dev/null", O_WRONLY) == STDERR_FILENO)
 	did_stderr = 1;
-- 


From mg at fork.pl  Mon Sep 10 10:30:43 2018
From: mg at fork.pl (Marcin Gryszkalis)
Date: Mon, 10 Sep 2018 10:30:43 +0200
Subject: gnupg_reopen_std - descriptor state problem
In-Reply-To: <87va7iau9v.fsf@iwagami.gniibe.org>
References: <707fc580-b13b-4a0b-a1c9-353c7063a00b@fork.pl>
 <87va7iau9v.fsf@iwagami.gniibe.org>
Message-ID: <62b960719f2200533be4a28453065240@fork.pl>

Hi

On 2018-09-07 04:58, NIIBE Yutaka wrote:
> Interesting.  Probably, the stdin is connected to the socket (which may
> be already shutdown-ed), I don't know.

That's possible.

> It seems that stdout is connected to named pipe, btw.
That's possible too.

>> I can't see any problems additional close() could cause - but I'm not 
>> sure
>> about all unix plaftorms.
> I think that doing any operation on the fd (which retured EBADF) sounds
> not healthy (even if it's close(2)).

I had similar feeling :)

> I wonder if changes like following make sense to see if fd is valid or
> not.  My theory is that fcntl is cheaper/simpler operation then fstat,
> and might be better in this case.

I'll test the patch and report - but I wonder why you decided to use 
F_GETFD (and
not for example F_GETFL?

best regards
-- 
Marcin Gryszkalis, PGP 0xA5DBEEC7
jabber jid:mg at fork.pl


From gniibe at fsij.org  Mon Sep 10 11:12:33 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 10 Sep 2018 18:12:33 +0900
Subject: gnupg_reopen_std - descriptor state problem
In-Reply-To: <62b960719f2200533be4a28453065240@fork.pl>
References: <707fc580-b13b-4a0b-a1c9-353c7063a00b@fork.pl>
 <87va7iau9v.fsf@iwagami.gniibe.org>
 <62b960719f2200533be4a28453065240@fork.pl>
Message-ID: <87ftyh4sxq.fsf@fsij.org>

Marcin Gryszkalis <mg at fork.pl> wrote:
> I'll test the patch and report - but I wonder why you decided to use 
> F_GETFD (and not for example F_GETFL?

I thought that it is the cheapest.  The result of F_GETFD is not related
to any meta data for file or socket.  The result can be determined by
kernel, only examining the object of the file descriptor.  That's my
theory.

And it's portable enough.
-- 


From mg at fork.pl  Mon Sep 10 11:31:48 2018
From: mg at fork.pl (Marcin Gryszkalis)
Date: Mon, 10 Sep 2018 11:31:48 +0200
Subject: gnupg_reopen_std - descriptor state problem
In-Reply-To: <87ftyh4sxq.fsf@fsij.org>
References: <707fc580-b13b-4a0b-a1c9-353c7063a00b@fork.pl>
 <87va7iau9v.fsf@iwagami.gniibe.org>
 <62b960719f2200533be4a28453065240@fork.pl> <87ftyh4sxq.fsf@fsij.org>
Message-ID: <8a10dc820f27abfbfbac79f3c098c25d@fork.pl>

On 2018-09-10 11:12, NIIBE Yutaka wrote:
> Marcin Gryszkalis <mg at fork.pl> wrote:
>> I'll test the patch and report - but I wonder why you decided to use
>> F_GETFD (and not for example F_GETFL?
> 
> I thought that it is the cheapest.  The result of F_GETFD is not 
> related
> to any meta data for file or socket.  The result can be determined by
> kernel, only examining the object of the file descriptor.  That's my
> theory.

On FreeBSD F_GETFD acquires lock whike F_GETFL doesn't - but I don't 
know why, it's too deep in the kernel internals for me.
Anyway - 3 calls per exec won't make real overhead.

best regards
-- 
Marcin Gryszkalis, PGP 0xA5DBEEC7
jabber jid:mg at fork.pl


From bjk at luxsci.net  Sat Sep 15 01:28:17 2018
From: bjk at luxsci.net (Ben Kibbey)
Date: Fri, 14 Sep 2018 16:28:17 -0700
Subject: [PATCH] Fix build with gcc < 4.6.
Message-ID: <1536967698-9704886.51986742.fw8ENSHQ9022838@rs146.luxsci.com>

Noticed this when building on an OpenBSD 6.3 box. Did some searching and
found others having the same problems when using gcc < 4.6.

-- 
Ben Kibbey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-build-with-gcc-4.6.patch
Type: text/x-diff
Size: 1046 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180914/91e24d94/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180914/91e24d94/attachment.sig>

From wk at gnupg.org  Sat Sep 15 12:46:03 2018
From: wk at gnupg.org (Werner Koch)
Date: Sat, 15 Sep 2018 12:46:03 +0200
Subject: [PATCH] Fix build with gcc < 4.6.
In-Reply-To: <1536967698-9704886.51986742.fw8ENSHQ9022838@rs146.luxsci.com>
 (Ben Kibbey's message of "Fri, 14 Sep 2018 16:28:17 -0700")
References: <1536967698-9704886.51986742.fw8ENSHQ9022838@rs146.luxsci.com>
Message-ID: <87a7ojujh0.fsf@wheatstone.g10code.de>

On Sat, 15 Sep 2018 01:28, bjk at luxsci.net said:
> Noticed this when building on an OpenBSD 6.3 box. Did some searching and
> found others having the same problems when using gcc < 4.6.

Okay, then we should revert Libgcrypt commit

e4dc458b0b7dc9b8417a2177ef17822d9b9064ec

because that changed it the version down to 4.2.  Ben, are you sure this
was gcc and not clang (which unfortunately claims to be gcc)?


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180915/0bb2954a/attachment-0001.sig>

From bjk at luxsci.net  Sat Sep 15 17:27:38 2018
From: bjk at luxsci.net (Ben Kibbey)
Date: Sat, 15 Sep 2018 08:27:38 -0700
Subject: [PATCH] Fix build with gcc < 4.6.
In-Reply-To: <87a7ojujh0.fsf@wheatstone.g10code.de>
References: <1536967698-9704886.51986742.fw8ENSHQ9022838@rs146.luxsci.com>
 <87a7ojujh0.fsf@wheatstone.g10code.de>
Message-ID: <1537025260-5978963.10273641.fw8FFRcYB012104@rs146.luxsci.com>

On Sat, Sep 15, 2018 at 12:46:03PM +0200, Werner Koch wrote:
> On Sat, 15 Sep 2018 01:28, bjk at luxsci.net said:
> > Noticed this when building on an OpenBSD 6.3 box. Did some searching and
> > found others having the same problems when using gcc < 4.6.
> 
> Okay, then we should revert Libgcrypt commit
> 
> e4dc458b0b7dc9b8417a2177ef17822d9b9064ec
> 
> because that changed it the version down to 4.2.  Ben, are you sure this
> was gcc and not clang (which unfortunately claims to be gcc)?

Yes because when CC=clang (5.0.1) it compiles fine.

-- 
Ben Kibbey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180915/b710296f/attachment.sig>

From Alexey.Brodkin at synopsys.com  Mon Sep 17 07:14:01 2018
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Mon, 17 Sep 2018 08:14:01 +0300
Subject: [PATCH libgpg-error] syscfg: Add ARC architecture
Message-ID: <20180917051401.11358-1-abrodkin@synopsys.com>

From: Mylene Josserand <mylene.josserand at bootlin.com>

DesignWare ARC Processors are a family of 32-bit CPUs from Synopsys.
This change allows us to build for and use libgpg-error on ARC cores.

These values were obtained from a test application executed on ARC
in simulation this way:

1. Instructions for cross-compilation used are here:
   http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=blob;f=README

2. Commands used on host:
   # build="$(build-aux/config.guess)"
   # ./configure --prefix=build/tmp-uclibc/sysroots/nsimhs/usr/ --host=arc-oe-linux-uclibc --build=$build
   # cd src
   # make gen-posix-lock-obj

3. Commands used on target:
   # ./gen-posix-lock-obj

Signed-off-by: Mylene Josserand <mylene.josserand at bootlin.com>
Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
---
 src/Makefile.am                               |  1 +
 .../lock-obj-pub.arc-unknown-linux-gnu.h      | 23 +++++++++++++++++++
 2 files changed, 24 insertions(+)
 create mode 100644 src/syscfg/lock-obj-pub.arc-unknown-linux-gnu.h

diff --git a/src/Makefile.am b/src/Makefile.am
index 380ea7c09c04..bd00961c2f27 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -47,6 +47,7 @@ lock_obj_pub = \
         syscfg/lock-obj-pub.aarch64-unknown-linux-gnu.h     \
 	syscfg/lock-obj-pub.aarch64-apple-darwin.h          \
         syscfg/lock-obj-pub.alpha-unknown-linux-gnu.h       \
+        syscfg/lock-obj-pub.arc-unknown-linux-gnu.h         \
         syscfg/lock-obj-pub.arm-unknown-linux-androideabi.h \
         syscfg/lock-obj-pub.arm-unknown-linux-gnueabi.h     \
 	syscfg/lock-obj-pub.arm-apple-darwin.h              \
diff --git a/src/syscfg/lock-obj-pub.arc-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.arc-unknown-linux-gnu.h
new file mode 100644
index 000000000000..3b1a8fadf8a7
--- /dev/null
+++ b/src/syscfg/lock-obj-pub.arc-unknown-linux-gnu.h
@@ -0,0 +1,23 @@
+## lock-obj-pub.arc-oe-linux-uclibc.h
+## File created by gen-posix-lock-obj - DO NOT EDIT
+## To be included by mkheader into gpg-error.h
+
+typedef struct
+{
+  long _vers;
+  union {
+    volatile char _priv[24];
+    long _x_align;
+    long *_xp_align;
+  } u;
+} gpgrt_lock_t;
+
+#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \
+                                    0,0,0,0,0,0,0,0, \
+                                    0,0,0,0,0,0,0,0}}}
+##
+## Local Variables:
+## mode: c
+## buffer-read-only: t
+## End:
+##
-- 
2.17.1



From wk at gnupg.org  Tue Sep 18 08:41:12 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 18 Sep 2018 08:41:12 +0200
Subject: [PATCH libgpg-error] syscfg: Add ARC architecture
In-Reply-To: <20180917051401.11358-1-abrodkin@synopsys.com> (Alexey Brodkin's
 message of "Mon, 17 Sep 2018 08:14:01 +0300")
References: <20180917051401.11358-1-abrodkin@synopsys.com>
Message-ID: <878t3ztiif.fsf@wheatstone.g10code.de>

On Mon, 17 Sep 2018 07:14, Alexey.Brodkin at synopsys.com said:
> From: Mylene Josserand <mylene.josserand at bootlin.com>
>
> DesignWare ARC Processors are a family of 32-bit CPUs from Synopsys.
> This change allows us to build for and use libgpg-error on ARC cores.

Thanks for the info.  The required object is actually identically to
i686-pc-linux-gnu so that we can use the alias table in the mkheader.c
tool.

config.sub knows about arc-oe-linux-uclibc (your value for --host) and
thus I will use that triplet becuase it seems to be more specific than
arc-unknown-linux-gnu.  Okay?


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180918/f31cf3a2/attachment.sig>

From Alexey.Brodkin at synopsys.com  Tue Sep 18 09:09:53 2018
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Tue, 18 Sep 2018 07:09:53 +0000
Subject: [PATCH libgpg-error] syscfg: Add ARC architecture
In-Reply-To: <878t3ztiif.fsf@wheatstone.g10code.de>
References: <20180917051401.11358-1-abrodkin@synopsys.com>
 <878t3ztiif.fsf@wheatstone.g10code.de>
Message-ID: <e563c80e70dd56fed924be3097a51370cb121868.camel@synopsys.com>

Hi Werner,

On Tue, 2018-09-18 at 08:41 +0200, Werner Koch wrote:
> On Mon, 17 Sep 2018 07:14, Alexey.Brodkin at synopsys.com said:
> > From: Mylene Josserand <mylene.josserand at bootlin.com>
> > 
> > DesignWare ARC Processors are a family of 32-bit CPUs from Synopsys.
> > This change allows us to build for and use libgpg-error on ARC cores.
> 
> Thanks for the info.  The required object is actually identically to
> i686-pc-linux-gnu so that we can use the alias table in the mkheader.c
> tool.

Ok I didn't know about that possibility so please go ahead and use
this alas table :)

> config.sub knows about arc-oe-linux-uclibc (your value for --host) and
> thus I will use that triplet becuase it seems to be more specific than
> arc-unknown-linux-gnu.  Okay?

Well I was under impression that config.sub typically doesn't care about
vendor field in the tuple, i.e. what makes sense is "arc-*".

And "oe" vendor (which is used for OpenEmbeddeed toolchains) is just
a corner case together with others (even more often used ones):
 - arc-buildroot-linux-uclibc-
 - arc-snps-linux-
 - arc-linux- etc.

That said I'd keep "arc-unknown-linux-" if possible.

Thanks for your prompt reply!

-Alexey

From wk at gnupg.org  Tue Sep 18 15:02:05 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 18 Sep 2018 15:02:05 +0200
Subject: [PATCH libgpg-error] syscfg: Add ARC architecture
In-Reply-To: <e563c80e70dd56fed924be3097a51370cb121868.camel@synopsys.com>
 (Alexey Brodkin's message of "Tue, 18 Sep 2018 07:09:53 +0000")
References: <20180917051401.11358-1-abrodkin@synopsys.com>
 <878t3ztiif.fsf@wheatstone.g10code.de>
 <e563c80e70dd56fed924be3097a51370cb121868.camel@synopsys.com>
Message-ID: <8736u7t0vm.fsf@wheatstone.g10code.de>

On Tue, 18 Sep 2018 09:09, Alexey.Brodkin at synopsys.com said:

> And "oe" vendor (which is used for OpenEmbeddeed toolchains) is just
> a corner case together with others (even more often used ones):
>  - arc-buildroot-linux-uclibc-
>  - arc-snps-linux-
>  - arc-linux- etc.

I reviewed how we use the vendor field and changed the system so that we
always use "unknown" for the vendor field if a CPU-VENDOR-KERNEL-SYSTEM
"triplet" is given.  We don't dothis for CPU-VENDOR-OS triplet.  The
effect is that all triplets matching the glob pattern

  arc-*-linux-uclibc

will work.  I have kept the uclibc at the end because that seems to be
important.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180918/497da3b8/attachment.sig>

From Alexey.Brodkin at synopsys.com  Tue Sep 18 16:29:28 2018
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Tue, 18 Sep 2018 14:29:28 +0000
Subject: [PATCH libgpg-error] syscfg: Add ARC architecture
In-Reply-To: <8736u7t0vm.fsf@wheatstone.g10code.de>
References: <20180917051401.11358-1-abrodkin@synopsys.com>
 <878t3ztiif.fsf@wheatstone.g10code.de>
 <e563c80e70dd56fed924be3097a51370cb121868.camel@synopsys.com>
 <8736u7t0vm.fsf@wheatstone.g10code.de>
Message-ID: <4de08347a84dabdab577e02bf3702dc8c9eb769b.camel@synopsys.com>

Hi Werner,

On Tue, 2018-09-18 at 15:02 +0200, Werner Koch wrote:
> On Tue, 18 Sep 2018 09:09, Alexey.Brodkin at synopsys.com said:
> 
> > And "oe" vendor (which is used for OpenEmbeddeed toolchains) is just
> > a corner case together with others (even more often used ones):
> >  - arc-buildroot-linux-uclibc-
> >  - arc-snps-linux-
> >  - arc-linux- etc.
> 
> I reviewed how we use the vendor field and changed the system so that we
> always use "unknown" for the vendor field if a CPU-VENDOR-KERNEL-SYSTEM
> "triplet" is given.  We don't dothis for CPU-VENDOR-OS triplet.  The
> effect is that all triplets matching the glob pattern
> 
>   arc-*-linux-uclibc
> 
> will work.  I have kept the uclibc at the end because that seems to be
> important.

But what about "arc-*-linux-gnu" (i.e. Glibc-based tools)?
And another question is about big-endian ARC flavors i.e. arceb-xxx -
will it work as well?

-Alexey

From wk at gnupg.org  Tue Sep 18 17:50:09 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 18 Sep 2018 17:50:09 +0200
Subject: [PATCH libgpg-error] syscfg: Add ARC architecture
In-Reply-To: <4de08347a84dabdab577e02bf3702dc8c9eb769b.camel@synopsys.com>
 (Alexey Brodkin's message of "Tue, 18 Sep 2018 14:29:28 +0000")
References: <20180917051401.11358-1-abrodkin@synopsys.com>
 <878t3ztiif.fsf@wheatstone.g10code.de>
 <e563c80e70dd56fed924be3097a51370cb121868.camel@synopsys.com>
 <8736u7t0vm.fsf@wheatstone.g10code.de>
 <4de08347a84dabdab577e02bf3702dc8c9eb769b.camel@synopsys.com>
Message-ID: <87sh26st3i.fsf@wheatstone.g10code.de>

On Tue, 18 Sep 2018 16:29, Alexey.Brodkin at synopsys.com said:

> But what about "arc-*-linux-gnu" (i.e. Glibc-based tools)?

Is that really the same object?  It depends on the pthread
implementation.  I guess for Linux it is the same but I am not sure.  If
you can confirm that they use the same ABI related to the locks we can
alias them.

> And another question is about big-endian ARC flavors i.e. arceb-xxx -
> will it work as well?

Initialization might be different; creating a syscfg header for
comparing would be useful.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180918/5116125d/attachment.sig>

From Alexey.Brodkin at synopsys.com  Tue Sep 18 21:23:25 2018
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Tue, 18 Sep 2018 19:23:25 +0000
Subject: [PATCH libgpg-error] syscfg: Add ARC architecture
In-Reply-To: <87sh26st3i.fsf@wheatstone.g10code.de>
References: <20180917051401.11358-1-abrodkin@synopsys.com>
 <878t3ztiif.fsf@wheatstone.g10code.de>
 <e563c80e70dd56fed924be3097a51370cb121868.camel@synopsys.com>
 <8736u7t0vm.fsf@wheatstone.g10code.de>
 <4de08347a84dabdab577e02bf3702dc8c9eb769b.camel@synopsys.com>
 <87sh26st3i.fsf@wheatstone.g10code.de>
Message-ID: <45de4a5495aa029bc6299b63452889ce829a82bf.camel@synopsys.com>

Hi Werner, Vineet,

On Tue, 2018-09-18 at 17:50 +0200, Werner Koch wrote:
> On Tue, 18 Sep 2018 16:29, Alexey.Brodkin at synopsys.com said:
> 
> > But what about "arc-*-linux-gnu" (i.e. Glibc-based tools)?
> 
> Is that really the same object?  It depends on the pthread
> implementation.
> I guess for Linux it is the same but I am not sure.  If
> you can confirm that they use the same ABI related to the locks we can
> alias them.

@Vineet could you please answer this question?

> > And another question is about big-endian ARC flavors i.e. arceb-xxx -
> > will it work as well?
> 
> Initialization might be different; creating a syscfg header for
> comparing would be useful.

I'll try to get the header sometime soon but for now it would be
good enough to proceed with little-endian for starters.

-Alexey

From marcelf at selfnet.de  Tue Sep 18 22:45:17 2018
From: marcelf at selfnet.de (Marcel Fest)
Date: Tue, 18 Sep 2018 22:45:17 +0200
Subject: hkp4py hkp|hkps bindings for python.
Message-ID: <7c28519a-6ea7-b705-f749-6ad0a6e74df7@selfnet.de>

Hey folks, hey Ben,

I have split up my project in to hkp4py and multivault.

The python2 support will be added in 1 or 2 days.

hkp4py is a simple library to get keys from the gpg/pgp keyservers via
the specified API.



The project gets available in the next days under MIT License on GitHub.


https://github.com/Selfnet/hkp4py


and later on pypi....


Best Regards

Marcel


PS: Ben I added proxy and header support for you.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180918/9cf86d8d/attachment.sig>

From wk at gnupg.org  Wed Sep 19 13:32:22 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 19 Sep 2018 13:32:22 +0200
Subject: [PATCH libgpg-error] syscfg: Add ARC architecture
In-Reply-To: <C2D7FE5348E1B147BCA15975FBA23075012B095AC0@us01wembx1.internal.synopsys.com>
 (Vineet Gupta's message of "Tue, 18 Sep 2018 19:34:45 +0000")
References: <20180917051401.11358-1-abrodkin@synopsys.com>
 <878t3ztiif.fsf@wheatstone.g10code.de>
 <e563c80e70dd56fed924be3097a51370cb121868.camel@synopsys.com>
 <8736u7t0vm.fsf@wheatstone.g10code.de>
 <4de08347a84dabdab577e02bf3702dc8c9eb769b.camel@synopsys.com>
 <87sh26st3i.fsf@wheatstone.g10code.de>
 <45de4a5495aa029bc6299b63452889ce829a82bf.camel@synopsys.com>
 <C2D7FE5348E1B147BCA15975FBA23075012B095AC0@us01wembx1.internal.synopsys.com>
Message-ID: <87musdsoxl.fsf@wheatstone.g10code.de>

On Tue, 18 Sep 2018 21:34, Vineet.Gupta1 at synopsys.com said:

> I'm not exactly clear what the question is ? What is specific in ABI related to
> locks ?

Libgpg-error abstracts the native lock interface and thus needs to get
some information on the actual implementation.  It can very well be the
case that the big-endian ABI is different from the little endian ABI.
In particular the static initialization may be different; this is
implemented in libgpg-error using a macro which may look like this

  #define GPGRT_LOCK_INITIALIZER {1,{{167,171,170,50,0,0,0,0, \
  0,0,0,0,0,0,0,0, \
  0,0,0,0,0,0,0,0, \
  0,0,0,0,0,0,0,0, \
  0,0,0,0,0,0,0,0, \
  0,0,0,0,0,0,0,0, \
  0,0,0,0,0,0,0,0, \
  0,0,0,0,0,0,0,0}}}

This is an memory image and we can't make use of C data types because
we don't know them.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180919/7b2cc275/attachment.sig>

From marcelf at selfnet.de  Wed Sep 19 13:47:47 2018
From: marcelf at selfnet.de (Marcel Fest)
Date: Wed, 19 Sep 2018 13:47:47 +0200
Subject: hkp4py hkp|hkps bindings for python.
In-Reply-To: <7c28519a-6ea7-b705-f749-6ad0a6e74df7@selfnet.de>
References: <7c28519a-6ea7-b705-f749-6ad0a6e74df7@selfnet.de>
Message-ID: <638a2c40-80d3-5331-4097-c97d99969ab8@selfnet.de>

Now on PyPI and AUR.

Am 18.09.18 um 22:45 schrieb Marcel Fest:
> Hey folks, hey Ben,
>
> I have split up my project in to hkp4py and multivault.
>
> The python2 support will be added in 1 or 2 days.
>
> hkp4py is a simple library to get keys from the gpg/pgp keyservers via
> the specified API.
>
>
>
> The project gets available in the next days under MIT License on GitHub.
>
>
> https://github.com/Selfnet/hkp4py
>
>
> and later on pypi....
>
>
> Best Regards
>
> Marcel
>
>
> PS: Ben I added proxy and header support for you.
>
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180919/669f48fa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180919/669f48fa/attachment.sig>

From Alexey.Brodkin at synopsys.com  Wed Sep 19 14:21:36 2018
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Wed, 19 Sep 2018 12:21:36 +0000
Subject: [PATCH libgpg-error] syscfg: Add ARC architecture
In-Reply-To: <45de4a5495aa029bc6299b63452889ce829a82bf.camel@synopsys.com>
References: <20180917051401.11358-1-abrodkin@synopsys.com>
 <878t3ztiif.fsf@wheatstone.g10code.de>
 <e563c80e70dd56fed924be3097a51370cb121868.camel@synopsys.com>
 <8736u7t0vm.fsf@wheatstone.g10code.de>
 <4de08347a84dabdab577e02bf3702dc8c9eb769b.camel@synopsys.com>
 <87sh26st3i.fsf@wheatstone.g10code.de>
 <45de4a5495aa029bc6299b63452889ce829a82bf.camel@synopsys.com>
Message-ID: <134ec042f1163f37049c1545ccb83ac6fee102a4.camel@synopsys.com>

Hi Werner,

I tried to cheery-pick your patch that among other things adds
ARC support on top of 1.32 release and now cannot compile it.

That's how libgpg-error is configured:
--------------------------->8----------------------------
../libgpg-error-1.32/configure --build=x86_64-linux --host=arc-oe-linux --target=arc-oe-linux --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --
sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --
includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules --disable-dependency-
tracking --with-libtool-sysroot=/SCRATCH/abrodkin/Projects/sources/oe/build/tmp-glibc/work/archs-oe-linux/libgpg-error/1.32-r0/recipe-sysroot --
enable-nls
...
        libgpg-error v1.32-unknown has been configured as follows:

        Revision: 0000000  (0)
        Platform: arc-oe-linux-gnu
--------------------------->8----------------------------

And that's how compilation fails pretty early:
--------------------------->8----------------------------
cp gpg-error-config gpgrt-config
cat ../../libgpg-error-1.32/src/gpg-error.def.in >_gpg-error.def.h
echo "/*dummy*/" > mkw32errmap.map.c
arc-oe-linux-gcc -E --sysroot=/SCRATCH/abrodkin/Projects/sources/oe/build/tmp-glibc/work/archs-oe-linux/libgpg-error/1.32-r0/recipe-sysroot  -mcpu=hs
-mll64 -mmpy-option=mpy -P  -P _mkerrcodes.h | grep GPG_ERR_ | \
               gawk -f ../../libgpg-error-1.32/src/mkerrcodes.awk >mkerrcodes.h
arc-oe-linux-gcc -E --sysroot=/SCRATCH/abrodkin/Projects/sources/oe/build/tmp-glibc/work/archs-oe-linux/libgpg-error/1.32-r0/recipe-sysroot  -mcpu=hs
-mll64 -mmpy-option=mpy -I. -I../../libgpg-error-1.32/src -I..   _gpg-error.def.h | \
  grep -v '^#' >gpg-error.def
rm _gpg-error.def.h
rm _mkerrcodes.h
gcc  -I. -I../../libgpg-error-1.32/src -o mkerrcodes ../../libgpg-error-1.32/src/mkerrcodes.c
./mkerrcodes | gawk -f ../../libgpg-error-1.32/src/mkerrcodes2.awk >code-from-errno.h
if test -f lock-obj-pub.native.h; then rm lock-obj-pub.native.h; fi
./mkheader linux-gnu arc-oe-linux-gnu  ../../libgpg-error-1.32/src/gpg-error.h.in \
                   ../config.h 1.32-unknown 0x012000 >gpg-error.h
../../libgpg-error-1.32/src/gpg-error.h.in:491: error including `../../libgpg-error-1.32/src/syscfg/lock-obj-pub.linux-gnu.h': No such file or
directory
make[2]: *** [gpg-error.h] Error 1
make[2]: Leaving directory `/SCRATCH/abrodkin/Projects/sources/oe/build/tmp-glibc/work/archs-oe-linux/libgpg-error/1.32-r0/build/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/SCRATCH/abrodkin/Projects/sources/oe/build/tmp-glibc/work/archs-oe-linux/libgpg-error/1.32-r0/build'
make: *** [all] Error 2
--------------------------->8----------------------------

Do I miss anything?

-Alexey

From Alexey.Brodkin at synopsys.com  Wed Sep 19 17:56:06 2018
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Wed, 19 Sep 2018 15:56:06 +0000
Subject: [PATCH libgpg-error] syscfg: Add ARC architecture
In-Reply-To: <134ec042f1163f37049c1545ccb83ac6fee102a4.camel@synopsys.com>
References: <20180917051401.11358-1-abrodkin@synopsys.com>
 <878t3ztiif.fsf@wheatstone.g10code.de>
 <e563c80e70dd56fed924be3097a51370cb121868.camel@synopsys.com>
 <8736u7t0vm.fsf@wheatstone.g10code.de>
 <4de08347a84dabdab577e02bf3702dc8c9eb769b.camel@synopsys.com>
 <87sh26st3i.fsf@wheatstone.g10code.de>
 <45de4a5495aa029bc6299b63452889ce829a82bf.camel@synopsys.com>
 <134ec042f1163f37049c1545ccb83ac6fee102a4.camel@synopsys.com>
Message-ID: <924e6e5d4b0dac6b20bb938f60e124db125228db.camel@synopsys.com>

Hi Werner,

On Wed, 2018-09-19 at 15:21 +0300, Alexey Brodkin wrote:
> Hi Werner,
> 
> I tried to cheery-pick your patch that among other things adds
> ARC support on top of 1.32 release and now cannot compile it.
> 
> That's how libgpg-error is configured:
> --------------------------->8----------------------------
> ../libgpg-error-1.32/configure --build=x86_64-linux --host=arc-oe-linux --target=arc-oe-linux --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --
> sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --
> includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules --disable-dependency-
> tracking --with-libtool-sysroot=/SCRATCH/abrodkin/Projects/sources/oe/build/tmp-glibc/work/archs-oe-linux/libgpg-error/1.32-r0/recipe-sysroot --
> enable-nls
> ...
>         libgpg-error v1.32-unknown has been configured as follows:
> 
>         Revision: 0000000  (0)
>         Platform: arc-oe-linux-gnu
> --------------------------->8----------------------------
> 
> And that's how compilation fails pretty early:
> --------------------------->8----------------------------
> cp gpg-error-config gpgrt-config
> cat ../../libgpg-error-1.32/src/gpg-error.def.in >_gpg-error.def.h
> echo "/*dummy*/" > mkw32errmap.map.c
> arc-oe-linux-gcc -E --sysroot=/SCRATCH/abrodkin/Projects/sources/oe/build/tmp-glibc/work/archs-oe-linux/libgpg-error/1.32-r0/recipe-sysroot  -
> mcpu=hs
> -mll64 -mmpy-option=mpy -P  -P _mkerrcodes.h | grep GPG_ERR_ | \
>                gawk -f ../../libgpg-error-1.32/src/mkerrcodes.awk >mkerrcodes.h
> arc-oe-linux-gcc -E --sysroot=/SCRATCH/abrodkin/Projects/sources/oe/build/tmp-glibc/work/archs-oe-linux/libgpg-error/1.32-r0/recipe-sysroot  -
> mcpu=hs
> -mll64 -mmpy-option=mpy -I. -I../../libgpg-error-1.32/src -I..   _gpg-error.def.h | \
>   grep -v '^#' >gpg-error.def
> rm _gpg-error.def.h
> rm _mkerrcodes.h
> gcc  -I. -I../../libgpg-error-1.32/src -o mkerrcodes ../../libgpg-error-1.32/src/mkerrcodes.c
> ./mkerrcodes | gawk -f ../../libgpg-error-1.32/src/mkerrcodes2.awk >code-from-errno.h
> if test -f lock-obj-pub.native.h; then rm lock-obj-pub.native.h; fi
> ./mkheader linux-gnu arc-oe-linux-gnu  ../../libgpg-error-1.32/src/gpg-error.h.in \
>                    ../config.h 1.32-unknown 0x012000 >gpg-error.h
> ../../libgpg-error-1.32/src/gpg-error.h.in:491: error including `../../libgpg-error-1.32/src/syscfg/lock-obj-pub.linux-gnu.h': No such file or
> directory
> make[2]: *** [gpg-error.h] Error 1
> make[2]: Leaving directory `/SCRATCH/abrodkin/Projects/sources/oe/build/tmp-glibc/work/archs-oe-linux/libgpg-error/1.32-r0/build/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/SCRATCH/abrodkin/Projects/sources/oe/build/tmp-glibc/work/archs-oe-linux/libgpg-error/1.32-r0/build'
> make: *** [all] Error 2
> --------------------------->8----------------------------

Ok so that's exactly what I was thinking about: xxx-uclibc vs xxx-glibc.

See what happens for "arc-oe-linux-gnu":
--------------------------->8----------------------------
# ./mkheader linux-gnu arc-oe-linux-gnu  ../../libgpg-error-1.32/src/gpg-error.h.in ../config.h 1.33-unknown 0x012100 > /dev/null
../../libgpg-error-1.32/src/gpg-error.h.in:491: error including `../../libgpg-error-1.32/src/syscfg/lock-obj-pub.linux-gnu.h': No such file or
directory
--------------------------->8----------------------------

...and for "arc-oe-linux-uclibc":
--------------------------->8----------------------------
# ./mkheader linux-gnu arc-oe-linux-uclibc  ../../libgpg-error-1.32/src/gpg-error.h.in ../config.h 1.33-unknown 0x012100 > /dev/null
../../libgpg-error-1.32/src/gpg-error.h.in:491: note: including '../../libgpg-error-1.32/src/syscfg/lock-obj-pub.i686-unknown-linux-gnu.h'
--------------------------->8----------------------------

Any thoughts how "gnu" case should be handled?

-Alexey


From marcelf at selfnet.de  Wed Sep 19 19:34:46 2018
From: marcelf at selfnet.de (Marcel Fest)
Date: Wed, 19 Sep 2018 19:34:46 +0200
Subject: hkp4py hkp|hkps bindings for python.
In-Reply-To: <20180919172929.ktlixlmu5ju7ksgl@adversary.org>
References: <7c28519a-6ea7-b705-f749-6ad0a6e74df7@selfnet.de>
 <20180919172929.ktlixlmu5ju7ksgl@adversary.org>
Message-ID: <96557dcc-cc5a-9bd3-9efa-df7a1ef5db4b@selfnet.de>

If you have any improvement suggestions,

PRs are always welcome.


Best Regards

Marcel

> Let's see:
>
> bash-4.4$ pip search hkp4py
> hkp4py (0.2.0.0)  - A Library to get Keys from a keyserver specified
> bash-4.4$ pip3 search hkp4py
> hkp4py (0.2.0.0)  - A Library to get Keys from a keyserver specified
> bash-4.4$ 
>
> This is all kinds of good work.  I'll include it in one or more of the
> HOWTO examples shortly.  Possibly even with one of the examples
> dealing with the cut down key server in use at ProtonMail.
>
>
> Regards,
> Ben
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180919/7dc02d7a/attachment.sig>

From ben at gnupg.org  Wed Sep 19 19:29:29 2018
From: ben at gnupg.org (Ben McGinnes)
Date: Thu, 20 Sep 2018 03:29:29 +1000
Subject: hkp4py hkp|hkps bindings for python.
In-Reply-To: <7c28519a-6ea7-b705-f749-6ad0a6e74df7@selfnet.de>
References: <7c28519a-6ea7-b705-f749-6ad0a6e74df7@selfnet.de>
Message-ID: <20180919172929.ktlixlmu5ju7ksgl@adversary.org>

On Tue, Sep 18, 2018 at 10:45:17PM +0200, Marcel Fest wrote:
> Hey folks, hey Ben,
> 
> I have split up my project in to hkp4py and multivault.
> 
> The python2 support will be added in 1 or 2 days.
> 
> hkp4py is a simple library to get keys from the gpg/pgp keyservers via
> the specified API.

Excellent work!  :)

> The project gets available in the next days under MIT License on GitHub.
> 
> 
> https://github.com/Selfnet/hkp4py
> 
> and later on pypi....

Let's see:

bash-4.4$ pip search hkp4py
hkp4py (0.2.0.0)  - A Library to get Keys from a keyserver specified
bash-4.4$ pip3 search hkp4py
hkp4py (0.2.0.0)  - A Library to get Keys from a keyserver specified
bash-4.4$ 

This is all kinds of good work.  I'll include it in one or more of the
HOWTO examples shortly.  Possibly even with one of the examples
dealing with the cut down key server in use at ProtonMail.


Regards,
Ben

-- 
|   Ben McGinnes   |    GNU Privacy Guard    |    ben at gnupg.org    |
| ---------------------------------------------------------------- |
|    GNU Privacy Guard Made Easy (GPGME) Python 3 API Maintainer   |
| GPG key: 0x321E4E2373590E5D http://www.adversary.org/ben-key.asc |
| GPG key fpr:  DB47 24E6 FA42 86C9 2B4E  55C4 321E 4E23 7359 0E5D |
| Web: https://www.gnupg.org/  Tor: http://ic6au7wa3f6naxjq.onion/ |
| ---------------------------------------------------------------- |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180920/e0f25cf7/attachment.sig>

From ben at gnupg.org  Wed Sep 19 22:13:29 2018
From: ben at gnupg.org (Ben McGinnes)
Date: Thu, 20 Sep 2018 06:13:29 +1000
Subject: hkp4py hkp|hkps bindings for python.
In-Reply-To: <96557dcc-cc5a-9bd3-9efa-df7a1ef5db4b@selfnet.de>
References: <7c28519a-6ea7-b705-f749-6ad0a6e74df7@selfnet.de>
 <20180919172929.ktlixlmu5ju7ksgl@adversary.org>
 <96557dcc-cc5a-9bd3-9efa-df7a1ef5db4b@selfnet.de>
Message-ID: <20180919201329.bmdjkq74tyxnxdjy@adversary.org>

On Wed, Sep 19, 2018 at 07:34:46PM +0200, Marcel Fest wrote:
> If you have any improvement suggestions,
> 
> PRs are always welcome.

There's one incoming already.  ;)

https://github.com/Selfnet/hkp4py/pull/5


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180920/c3c13c2f/attachment.sig>

From ben at adversary.org  Wed Sep 19 22:49:26 2018
From: ben at adversary.org (Ben McGinnes)
Date: Thu, 20 Sep 2018 06:49:26 +1000
Subject: hkp4py hkp|hkps bindings for python.
In-Reply-To: <20180919201329.bmdjkq74tyxnxdjy@adversary.org>
References: <7c28519a-6ea7-b705-f749-6ad0a6e74df7@selfnet.de>
 <20180919172929.ktlixlmu5ju7ksgl@adversary.org>
 <96557dcc-cc5a-9bd3-9efa-df7a1ef5db4b@selfnet.de>
 <20180919201329.bmdjkq74tyxnxdjy@adversary.org>
Message-ID: <20180919204926.ygrly3n2vtvnes3o@adversary.org>

On Thu, Sep 20, 2018 at 06:13:29AM +1000, Ben McGinnes wrote:
> On Wed, Sep 19, 2018 at 07:34:46PM +0200, Marcel Fest wrote:
> > If you have any improvement suggestions,
> > 
> > PRs are always welcome.
> 
> There's one incoming already.  ;)
> 
> https://github.com/Selfnet/hkp4py/pull/5

Also this one:

https://github.com/Selfnet/hkp4py/pull/6

Which will also find it''s way into the update(s) to the HOWTO.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180920/7ded9a1b/attachment.sig>

From Alexey.Brodkin at synopsys.com  Wed Sep 19 22:53:40 2018
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Wed, 19 Sep 2018 20:53:40 +0000
Subject: [PATCH libgpg-error] syscfg: Add ARC architecture
In-Reply-To: <C2D7FE5348E1B147BCA15975FBA23075012B095D12@us01wembx1.internal.synopsys.com>
References: <20180917051401.11358-1-abrodkin@synopsys.com>
 <878t3ztiif.fsf@wheatstone.g10code.de>
 <e563c80e70dd56fed924be3097a51370cb121868.camel@synopsys.com>
 <8736u7t0vm.fsf@wheatstone.g10code.de>
 <4de08347a84dabdab577e02bf3702dc8c9eb769b.camel@synopsys.com>
 <87sh26st3i.fsf@wheatstone.g10code.de>
 <45de4a5495aa029bc6299b63452889ce829a82bf.camel@synopsys.com>
 <C2D7FE5348E1B147BCA15975FBA23075012B095AC0@us01wembx1.internal.synopsys.com>
 <87musdsoxl.fsf@wheatstone.g10code.de>
 <C2D7FE5348E1B147BCA15975FBA23075012B095D12@us01wembx1.internal.synopsys.com>
Message-ID: <2291f4ecfaeb5db8119644c2c93e12208d1cceba.camel@synopsys.com>

Hi Vineet, Werner,

On Wed, 2018-09-19 at 18:46 +0000, Vineet Gupta wrote:
> On 09/19/2018 04:44 AM, Werner Koch wrote:
> > On Tue, 18 Sep 2018 21:34, Vineet.Gupta1 at synopsys.com said:
> > 
> > > I'm not exactly clear what the question is ? What is specific in ABI related to
> > > locks ?
> > 
> > Libgpg-error abstracts the native lock interface and thus needs to get
> > some information on the actual implementation.  It can very well be the
> > case that the big-endian ABI is different from the little endian ABI.
> > In particular the static initialization may be different; this is
> > implemented in libgpg-error using a macro which may look like this
> > 
> >   #define GPGRT_LOCK_INITIALIZER {1,{{167,171,170,50,0,0,0,0, \
> >   0,0,0,0,0,0,0,0, \
> >   0,0,0,0,0,0,0,0, \
> >   0,0,0,0,0,0,0,0, \
> >   0,0,0,0,0,0,0,0, \
> >   0,0,0,0,0,0,0,0, \
> >   0,0,0,0,0,0,0,0, \
> >   0,0,0,0,0,0,0,0}}}
> > 
> > This is an memory image and we can't make use of C data types because
> > we don't know them.
> 
> Well BE will certainly be different than LE.
> Back to the original discussion, was the question about glibc vs. uClibc pthread
> ABI ? Since they are different / independent implementations (even if uClibc is
> sort of copy over from glibc) we can't guarantee that these would the same so each
> would need a specific initializer I guess.

That's what I've got for glibc case:
-------------------------->8-------------------------
## lock-obj-pub.arc-buildroot-linux-gnu.h
## File created by gen-posix-lock-obj - DO NOT EDIT
## To be included by mkheader into gpg-error.h

typedef struct
{
  long _vers;
  union {
    volatile char _priv[24];
    long _x_align;
    long *_xp_align;
  } u;
} gpgrt_lock_t;

#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \
                                    0,0,0,0,0,0,0,0, \
                                    0,0,0,0,0,0,0,0}}}
##
## Local Variables:
## mode: c
## buffer-read-only: t
## End:
##
-------------------------->8-------------------------

I'd say it looks similar to uClibc version which is below
as a reference:
-------------------------->8-------------------------
## lock-obj-pub.arc-buildroot-linux-uclibc.h
## File created by gen-posix-lock-obj - DO NOT EDIT
## To be included by mkheader into gpg-error.h

typedef struct
{
  long _vers;
  union {
    volatile char _priv[24];
    long _x_align;
    long *_xp_align;
  } u;
} gpgrt_lock_t;

#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \
                                    0,0,0,0,0,0,0,0, \
                                    0,0,0,0,0,0,0,0}}}
##
## Local Variables:
## mode: c
## buffer-read-only: t
## End:
##
-------------------------->8-------------------------

-Alexey

From wk at gnupg.org  Thu Sep 20 10:01:46 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 20 Sep 2018 10:01:46 +0200
Subject: [PATCH libgpg-error] syscfg: Add ARC architecture
In-Reply-To: <924e6e5d4b0dac6b20bb938f60e124db125228db.camel@synopsys.com>
 (Alexey Brodkin's message of "Wed, 19 Sep 2018 15:56:06 +0000")
References: <20180917051401.11358-1-abrodkin@synopsys.com>
 <878t3ztiif.fsf@wheatstone.g10code.de>
 <e563c80e70dd56fed924be3097a51370cb121868.camel@synopsys.com>
 <8736u7t0vm.fsf@wheatstone.g10code.de>
 <4de08347a84dabdab577e02bf3702dc8c9eb769b.camel@synopsys.com>
 <87sh26st3i.fsf@wheatstone.g10code.de>
 <45de4a5495aa029bc6299b63452889ce829a82bf.camel@synopsys.com>
 <134ec042f1163f37049c1545ccb83ac6fee102a4.camel@synopsys.com>
 <924e6e5d4b0dac6b20bb938f60e124db125228db.camel@synopsys.com>
Message-ID: <87muscppg5.fsf@wheatstone.g10code.de>

On Wed, 19 Sep 2018 17:56, Alexey.Brodkin at synopsys.com said:

>> ../../libgpg-error-1.32/src/gpg-error.h.in:491: error including `../../libgpg-error-1.32/src/syscfg/lock-obj-pub.linux-gnu.h': No such file or

That looks like my patch was faulty.  I'll look at it and will do some
more tests.  Sorry, for the trouble and thanks for the test output.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180920/b2af01d3/attachment.sig>

From Alexey.Brodkin at synopsys.com  Thu Sep 20 17:01:11 2018
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Thu, 20 Sep 2018 15:01:11 +0000
Subject: [PATCH libgpg-error] syscfg: Add ARC architecture
In-Reply-To: <87muscppg5.fsf@wheatstone.g10code.de>
References: <20180917051401.11358-1-abrodkin@synopsys.com>
 <878t3ztiif.fsf@wheatstone.g10code.de>
 <e563c80e70dd56fed924be3097a51370cb121868.camel@synopsys.com>
 <8736u7t0vm.fsf@wheatstone.g10code.de>
 <4de08347a84dabdab577e02bf3702dc8c9eb769b.camel@synopsys.com>
 <87sh26st3i.fsf@wheatstone.g10code.de>
 <45de4a5495aa029bc6299b63452889ce829a82bf.camel@synopsys.com>
 <134ec042f1163f37049c1545ccb83ac6fee102a4.camel@synopsys.com>
 <924e6e5d4b0dac6b20bb938f60e124db125228db.camel@synopsys.com>
 <87muscppg5.fsf@wheatstone.g10code.de>
Message-ID: <d0567b316bb55f98c92d5046303a59ffc0f24b30.camel@synopsys.com>

Hi Werner,

On Thu, 2018-09-20 at 10:01 +0200, Werner Koch wrote:
> On Wed, 19 Sep 2018 17:56, Alexey.Brodkin at synopsys.com said:
> 
> > > ../../libgpg-error-1.32/src/gpg-error.h.in:491: error including `../../libgpg-error-1.32/src/syscfg/lock-obj-pub.linux-gnu.h': No such file or
> 
> That looks like my patch was faulty.  I'll look at it and will do some
> more tests.  Sorry, for the trouble and thanks for the test output.

Maybe we just need to add another alias for ARC gnu toolchain (given GPG headers are the same,
see my another email I sent yesterday)?

-Alexey

From marcelf at selfnet.de  Fri Sep 21 00:55:54 2018
From: marcelf at selfnet.de (Marcel Fest)
Date: Fri, 21 Sep 2018 00:55:54 +0200
Subject: hkp4py hkp|hkps bindings for python.
In-Reply-To: <20180919204926.ygrly3n2vtvnes3o@adversary.org>
References: <7c28519a-6ea7-b705-f749-6ad0a6e74df7@selfnet.de>
 <20180919172929.ktlixlmu5ju7ksgl@adversary.org>
 <96557dcc-cc5a-9bd3-9efa-df7a1ef5db4b@selfnet.de>
 <20180919201329.bmdjkq74tyxnxdjy@adversary.org>
 <20180919204926.ygrly3n2vtvnes3o@adversary.org>
Message-ID: <6e33e016-0802-6be2-83f1-b11b67a21f73@selfnet.de>

Hey, i have an issue with your Example.

As mentionend under the PR#6 my python-gpgme bindings wont like your
example.

https://github.com/Selfnet/hkp4py/pull/6


Testing your example results in the following issue.
File "/usr/lib/python3.7/site-packages/gpg/core.py", line 128, in *getattr*
func = getattr(gpgme, name)
AttributeError: module 'gpg.gpgme' has no attribute 'gpgme_key_import'

This was the main reason why I used |op_import| in the first place


Why is this happening?

I am using the latest bindings on ArchLinux from September this year.


Regards

Marcel

>> There's one incoming already.  ;)
>>
>> https://github.com/Selfnet/hkp4py/pull/5
> Also this one:
>
> https://github.com/Selfnet/hkp4py/pull/6
>
> Which will also find it''s way into the update(s) to the HOWTO.
>
>
> Regards,
> Ben
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180921/3822f4d5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180921/3822f4d5/attachment.sig>

From wk at gnupg.org  Fri Sep 21 14:38:08 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 21 Sep 2018 14:38:08 +0200
Subject: [PATCH libgpg-error] syscfg: Add ARC architecture
In-Reply-To: <2291f4ecfaeb5db8119644c2c93e12208d1cceba.camel@synopsys.com>
 (Alexey Brodkin's message of "Wed, 19 Sep 2018 20:53:40 +0000")
References: <20180917051401.11358-1-abrodkin@synopsys.com>
 <878t3ztiif.fsf@wheatstone.g10code.de>
 <e563c80e70dd56fed924be3097a51370cb121868.camel@synopsys.com>
 <8736u7t0vm.fsf@wheatstone.g10code.de>
 <4de08347a84dabdab577e02bf3702dc8c9eb769b.camel@synopsys.com>
 <87sh26st3i.fsf@wheatstone.g10code.de>
 <45de4a5495aa029bc6299b63452889ce829a82bf.camel@synopsys.com>
 <C2D7FE5348E1B147BCA15975FBA23075012B095AC0@us01wembx1.internal.synopsys.com>
 <87musdsoxl.fsf@wheatstone.g10code.de>
 <C2D7FE5348E1B147BCA15975FBA23075012B095D12@us01wembx1.internal.synopsys.com>
 <2291f4ecfaeb5db8119644c2c93e12208d1cceba.camel@synopsys.com>
Message-ID: <87va6znhzj.fsf@wheatstone.g10code.de>

On Wed, 19 Sep 2018 22:53, Alexey.Brodkin at synopsys.com said:

> I'd say it looks similar to uClibc version which is below
> as a reference:

Ack.  I added it to the list.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180921/dac2f7d0/attachment.sig>

From wk at gnupg.org  Fri Sep 21 14:43:19 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 21 Sep 2018 14:43:19 +0200
Subject: [PATCH libgpg-error] syscfg: Add ARC architecture
In-Reply-To: <924e6e5d4b0dac6b20bb938f60e124db125228db.camel@synopsys.com>
 (Alexey Brodkin's message of "Wed, 19 Sep 2018 15:56:06 +0000")
References: <20180917051401.11358-1-abrodkin@synopsys.com>
 <878t3ztiif.fsf@wheatstone.g10code.de>
 <e563c80e70dd56fed924be3097a51370cb121868.camel@synopsys.com>
 <8736u7t0vm.fsf@wheatstone.g10code.de>
 <4de08347a84dabdab577e02bf3702dc8c9eb769b.camel@synopsys.com>
 <87sh26st3i.fsf@wheatstone.g10code.de>
 <45de4a5495aa029bc6299b63452889ce829a82bf.camel@synopsys.com>
 <134ec042f1163f37049c1545ccb83ac6fee102a4.camel@synopsys.com>
 <924e6e5d4b0dac6b20bb938f60e124db125228db.camel@synopsys.com>
Message-ID: <87o9crnhqw.fsf@wheatstone.g10code.de>

On Wed, 19 Sep 2018 17:56, Alexey.Brodkin at synopsys.com said:

> Ok so that's exactly what I was thinking about: xxx-uclibc vs xxx-glibc.

Meanwhile added.  See other mail.

> --------------------------->8----------------------------
> # ./mkheader linux-gnu arc-oe-linux-gnu  ../../libgpg-error-1.32/src/gpg-error.h.in ../config.h 1.33-unknown 0x012100 > /dev/null
> ../../libgpg-error-1.32/src/gpg-error.h.in:491: error including `../../libgpg-error-1.32/src/syscfg/lock-obj-pub.linux-gnu.h': No such file or
> directory
> --------------------------->8----------------------------

The problem here is that a lock-obj-pub.linux-gnu.h exists and mkheader
prefers that becuase it assumes it is a native build.  The Makefile
deletes such a file first but if you call mkheader directly it may still
exist.  To make this more explicit, I added an option --cross to disable
this feature.   I can now do

--8<---------------cut here---------------start------------->8---
 ./mkheader --cross arc-oe-linux-uclibc  ~/s/libgpg-error/src/gpg-error.h.in ../config.h 1.33-unknown 0x012100 >/dev/null
/home/wk/s/libgpg-error/src/gpg-error.h.in:491: note: including '/home/wk/s/libgpg-error/src/syscfg/lock-obj-pub.i686-unknown-linux-gnu.h'
--8<---------------cut here---------------end--------------->8---

and that works even if a native files exists.  Note that the first arg
to mkheader was removed becuase it is easier to derive it from the
triplet.  And -gnu works too:

--8<---------------cut here---------------start------------->8---
 ./mkheader --cross arc-oe-linux-gnu  ~/s/libgpg-error/src/gpg-error.h.in ../config.h 1.33-unknown 0x012100 >/dev/null
/home/wk/s/libgpg-error/src/gpg-error.h.in:491: note: including '/home/wk/s/libgpg-error/src/syscfg/lock-obj-pub.i686-unknown-linux-gnu.h'
--8<---------------cut here---------------end--------------->8---


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180921/23fc0000/attachment.sig>

From ben at adversary.org  Sat Sep 22 22:00:07 2018
From: ben at adversary.org (Ben McGinnes)
Date: Sun, 23 Sep 2018 06:00:07 +1000
Subject: hkp4py hkp|hkps bindings for python.
In-Reply-To: <6e33e016-0802-6be2-83f1-b11b67a21f73@selfnet.de>
References: <7c28519a-6ea7-b705-f749-6ad0a6e74df7@selfnet.de>
 <20180919172929.ktlixlmu5ju7ksgl@adversary.org>
 <96557dcc-cc5a-9bd3-9efa-df7a1ef5db4b@selfnet.de>
 <20180919201329.bmdjkq74tyxnxdjy@adversary.org>
 <20180919204926.ygrly3n2vtvnes3o@adversary.org>
 <6e33e016-0802-6be2-83f1-b11b67a21f73@selfnet.de>
Message-ID: <20180922200007.eyrvhxoc6jmfiatn@adversary.org>

I replied off list, mostly due to which filter I was reading and
hitting "r" instead of "L", but the long story short version of that
reply was that ...

On Fri, Sep 21, 2018 at 12:55:54AM +0200, Marcel Fest wrote:
> 
> Testing your example results in the following issue.
> File "/usr/lib/python3.7/site-packages/gpg/core.py", line 128, in *getattr*
> func = getattr(gpgme, name)
> AttributeError: module 'gpg.gpgme' has no attribute 'gpgme_key_import'
> 
> This was the main reason why I used |op_import| in the first place
>
>
> Why is this happening?

This is caused by this:

> I am using the latest bindings on ArchLinux from September this year.

Not that it's Arch's fault, it's not.  It's that the key_import
function was added after GPGME 1.11.1 was released.  The same is true
of the three export methods added around the same time.

Whereas I'm using the latest version in the master branch almost all
the time (for obvious reasons).  Anyway, the key_import, key_export,
key_export_minimal and key_export_secret functions will be available
to all when GPGME 1.12.0 is released very soon.  With the additional
key_blob response you added, I'll be able to include some more
detailed examples in the HOWTO for that release.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180923/01a0cdc4/attachment.sig>

From mg at fork.pl  Thu Sep 27 19:56:39 2018
From: mg at fork.pl (Marcin Gryszkalis)
Date: Thu, 27 Sep 2018 19:56:39 +0200
Subject: =?iso-8859-1?Q?gnupg=5Freopen=5Fstd_-_descriptor_state_problem?=
In-Reply-To: <87va7iau9v.fsf@iwagami.gniibe.org>
References: <707fc580-b13b-4a0b-a1c9-353c7063a00b@fork.pl>
 <87va7iau9v.fsf@iwagami.gniibe.org>
Message-ID: <edee3638-e2ba-4ac5-88a6-6341a73d9b14@fork.pl>

On Friday, September 7, 2018 4:58:04 AM CEST, NIIBE Yutaka wrote:
> I wonder if changes like following make sense to see if fd is valid or
> not.  My theory is that fcntl is cheaper/simpler operation then fstat,
> and might be better in this case.

I tested your patch:
 - in case of manually closing stdin, ie. gpg2 --version <&-

 44239 gpg2     CALL  fcntl(0,F_GETFD,<invalid>0xffffeb88)
 44239 gpg2     RET   fcntl -1 errno 9 Bad file descriptor
 44239 gpg2     CALL  openat(AT_FDCWD,0x4abb8b,0<O_RDONLY>,<unused>0)
 44239 gpg2     NAMI  "/dev/null"
 44239 gpg2     RET   openat 0
 44239 gpg2     CALL  fcntl(0x1,F_GETFD,0)
 44239 gpg2     RET   fcntl 0
 44239 gpg2     CALL  fcntl(0x2,F_GETFD,0)
 44239 gpg2     RET   fcntl 0

 - when calling from my app fcntl always returns 0 - and it's good. 
I prepared patch version that uses both tests (fcntl and fstat) and it 
behaves 
as expected (when called from the perl app):

 42591 gpg2     CALL  fcntl(0,F_GETFD,<invalid>0xffffe720)
 42591 gpg2     RET   fcntl 0 <=== fcntl is right
 42591 gpg2     CALL  fstat(0,0x7fffffffdf40)
 42591 gpg2     RET   fstat -1 errno 9 Bad file descriptor <=== fstat is 
wrong :)
 42591 gpg2     CALL  close(0)
 42591 gpg2     RET   close 0
 42591 gpg2     CALL  openat(AT_FDCWD,0x4abc1b,0<O_RDONLY>,<unused>0)
 42591 gpg2     NAMI  "/dev/null"
 42591 gpg2     RET   openat 0
 42591 gpg2     CALL  fcntl(0x1,F_GETFD,0)
 42591 gpg2     RET   fcntl 0
 42591 gpg2     CALL  fcntl(0x2,F_GETFD,0)
 42591 gpg2     RET   fcntl 0

So I guess you could merge the patch.
Thanks for help with this unusual case :)

best regards
-- 
Marcin Gryszkalis, PGP 0xA5DBEEC7 http://fork.pl/gpg.txt