This is referenced from https://nvd.nist.gov/vuln/detail/CVE-2022-3219 for CVE-2022-3219. Can this please be fixed?

This is referenced from https://nvd.nist.gov/vuln/detail/CVE-2022-3219 for CVE-2022-3219. Can this please be fixed?

Same as https://dev.gnupg.org/T5277, thanks for the note.

Thank you very much! This is working quite well now.

No, I don't have a smartcard. Perhaps it misdetects one?

I'm confused. I've just now retested, and I get further with BSD make (there is another problem when importing the keys into the test keyring, where it the error is ignored with GNU make but the build fails with BSD make) but that is not what I want to focus on.

For qt: adding /usr/pkg/qt5/bin to the path makes the build succeed. I think you should take a look at the build rules though, since it seems that it wants to execute the header file if "moc" is not found.

Using BSD make on git head of gpgme, I see

Thank you. I think you can update the comment below the implementation now ("/* FIXME: Implement this when we have the specification for it. */) and the #error line.

I built gnupg 2.2.1 with the patch from D450, but that didn't help.
I even got an additional error:

In T2919#102889, @stbuehler wrote:

I think bad.trace is very similar in the errors (chan_9 instead of chan_7); the difference is probably that the "bad mail" is not using a detached signature (possibly even encrypted), so mutt cannot find the body without actually decoding the message through gpgsm; the "good mail " is using a detached signature, and the body is the first part of a multi-part message which mutt can decode itself; it still can't verify the signature.

Sure: http://netbsd.gw.com/cgi-bin/man-cgi?getenv_r++NetBSD-current

Sure. Here's the stdout and stderr for gpgme-1.9 with GPGME_DEBUG=9 and

In T2919#102001, @stbuehler wrote:

I just had a look at good.trace and it seems gpgsm --server exits instantly (chan_7 <- [eof]). The path seems to be correct though (/usr/pkg/bin/gpgsm), and /usr/pkg/bin/gpgsm --version reads (the first 79 bytes):

gpgsm (GnuPG) 2.1.18
libgcrypt 1.7.6
libksba 1.3.5
Copyright (C) 2017 Free Soft

The --version call passes the full path in argv[0] (but the full path is always passed as first argument to execv, so it shouldn't make a difference).

Sadly it seems there is no error message from gpgsm, and also the exit code isn't shown. Maybe you could try running gpgsm --server manually; it should greet you with OK GNU Privacy Guard's S/M server * ready. An strace log might provide more insight why gpgsm --server fails.

I'd prefer a 2.2 release.

I've since tried neomutt-20170707 which includes stbuehler's patch, but I see the same error cases as before.

I've updated to gpgme-1.8.0 and tried again.
I have one mail that I'll call "bad" which gives me in mutt:

Thank you. I just tried:

autoreconf -fiv && ./configure && make && make check
...
Making check in src
Making check in tests
make  check-TESTS
PASS: t-mutex
PASS: t-thread
PASS: t-fork
==================
All 3 tests passed
==================

on NetBSD-7.99.67/amd64.

Thanks for working on this.
I can't seem to find a link to the repository for testing, can you please point me in the right direction?

I just tried this, but this doesn't disable the detection, and if that fails, the configure script stops:

checking for swig... /usr/pkg/bin/swig
checking for a Python interpreter with version >= 2.7... python2.7
checking for python2.7... /usr/pkg/bin/python2.7
checking for python2.7 version... 2.7
checking for python2.7 platform... netbsd7
checking for python2.7 script directory... ${prefix}/lib/python2.7/site-packages
checking for python2.7 extension module directory... ${exec_prefix}/lib/python2.7/site-packages
checking for python2.7... (cached) /usr/pkg/bin/python2.7
checking for a version of Python >= '2.1.0'... yes
checking for the distutils Python package... yes
checking for Python include path... -I/usr/pkg/include/python2.7
checking for Python library path... -L/usr/pkg/lib -lpython2.7
checking for Python site-packages path... /usr/pkg/lib/python2.7/site-packages
checking python extra libraries... -lutil -lm
checking python extra linking flags... -Wl,--export-dynamic
checking consistency of all components of python development environment... no
configure: WARNING:
  Could not link test program to Python. Maybe the main Python library has been
  installed in some non-standard library path. If so, pass it to configure,
  via the LDFLAGS environment variable.
  Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib"
  ============================================================================
   You probably have to install the development version of the Python package
   for your distribution.  The exact name of this package varies among them.
  ============================================================================

Oh, to make it clear - I was testing the pkgsrc version with the additional patches used by pkgsrc, see http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/security/gpgme/patches/

NetBSD has its own pthread library (different from OpenBSD and FreeBSD), so I
think this would be a good idea.

Right now it seems to be complaining about an expired key.
(Could be that this is a different error than originally reported because it's
been some time...)

I've run mutt as suggested on the troublesome email; the resulting log is attached.

Ibraheem very kindly tested again. However, it is still not working completely.
He writes:

It's still core dumping... Out of curiosity, I explicitly defined

'USE_DOUBLE_FOR_ALIGNMENT 1' and the checks were passing on Solaris with no more
core dumps. I guess that means they're on the right track, just have to get the
preprocessor directives right for gcc and Solaris.

Full details are in
https://mail-index.netbsd.org/pkgsrc-users/2016/03/01/msg023078.html

I'm working on pkgsrc, which is a portable packaging system origination on
NetBSD. I myself work mostly on NetBSD.

However, we have patches for non-NetBSD platforms in pkgsrc, and this patch was
worked on by the two people mentioned earlier. Since I can not test on Solaris,
I asked them to test on Solaris, and Ibraheem did that.

I hope that clears it up.

Thank you for the patch.
I don't have the environment, but I asked the original reporter to test.
Sadly, his reply is negative, see:

https://mail-index.netbsd.org/pkgsrc-users/2016/02/27/msg023071.html

sevan@NetBSD.org just reported that it is needed on Solaris 10, otherwise
linking libgcrypt.so fails with:

Undefined first referenced

symbol in file

__udiv_qrnnd ./.libs/libgcrypt.so

ld: fatal: symbol referencing errors. No output written to .libs/mpicalc

collect2: ld returned 1 exit status

So please apply the change after all.

I've contacted jmmv and he wrote:
"This was a long time ago and I don't remember. The newly proposed patch sounds
good though."
So please go ahead with your version.

I was using 2.0.25 at the time. I've just retried, and 2.0.26 indeed fixes this
problem. Thanks for the hint!

I didn't find anyone.
I've just removed this patch from pkgsrc.
We can come back to this later if someone shows interest and can test it.

Well, it was added as a bugfix for Solaris 9, not NetBSD.
http://gnats.netbsd.org/26815

I'll try finding someone who can provide more input if the patch is still needed
or not.

D240: 476_patch-src_visibility.h

D239: 475_patch-ad

D238: 474_patch-ab