On 2/27/2012 4:26 PM, Charles Wilson wrote:
On 2/27/2012 8:56 AM, marco atzeri wrote:
I will give a look.
Any preference between 1.4.12 and 2.0.18 ?
I made an attempt about two years ago to port gnupg 2.x. It has
additional dependencies beyond those of 1.4.x, so I added all of those
to the distro.
However, I ran into a problem (related to pth/pthread support) such
gnugp's analog to ssh-agent could not be queried, so you always had to
type in your passphrase. That was obviously unacceptable, so I didn't
actually post my version of gnupg-2.x
The problem was basically this:
1) gnupg requires threading support via pth, NOT pthreads. This is
because the gnupg folks consider "real" threads to provide a larger
"attack surface" for security -- too large to adequately secure on all
supported platforms -- so they require the use of the pth library. (pth
provides a pseudo-thread interface that "kinda" works like pthreads, but
the "threads" are actually all cooperatively managed as part of a single
"native" thread.)
2) The pth library doesn't/didn't work on cygwin because of missing
support for pth+fork. In any case, pth needed support for a facility
that was, at the time, missing from cygwin (standard posix
sigstack/sigaltstack approach):
http://cygwin.com/ml/cygwin/2009-10/msg00467.html
This was on cgf's post-1.7 TODO list, but I don't recall if it ever
happened. If it did, then I have a "ported" pth package (un-ITP'ed) that
should work.
3) So, I heavily patched gnupg to use pthreads instead. But this had a
side effect that gpg-agent didn't work as expected. IIRC, this had
(something) to do with cygwin's missing support for passing open file
descriptors between threads (briefly mentioned on the main list last
week; obviously passing open filedes between *pseudo-threads* that are
actually part of the same *real* thread, as in pth, is not a problem. If
we were actually using pth.
I suspect, if (a) cygwin has sigstack/sigaltstack, and (b) my ported pth
works ok, then a version of gnupg-2.x with my pthread patches reverted
should be "almost there".
--
Chuck
Thanks for status,
I was just wondering why most of the dependencies
where present but a bit old.
I will leave (a) to cgf.
for the time being we stay with gnupg-1.4
Regards
Marco