pkg-config support in libgpg-error: Fixes for *BSD... done

• FreeBSD 11.1: OK
• NetBSD 7.1: OK
• OpenBSD: BAD
• AIX: BAD
• Solaris11: BAD

We know that. And pinentry-gtk does like that.

Yes. It's up to GCR library in GNOME.

Last week:

• libgpg-error: pkg-config support is merged to master
• gnupg: In master, public key decryption change introduced memory leak, which is fixed

Thanks a lot.
By this report, I was able to fix more memory leaks.

Changes are included to master branch of gnupg.

secmem routines are installed into gniibe/secmem branch.
Please note that it's only secmem routines, not malloc_secure.

I confirmed: Now, all use cases of iobuf_get check against negative value or are using iobuf_get_eof.
So, closing.

• libgpg-error
  • gniibe/secmem branch is ready to be merged into master
  • gniibe/pkg-config-support works well for me. If everything is OK, we can manually merge it into master (the history in the branch is not needed to be merged).
• gnupg/dirmngr
  • hosttable requires (or is better to have) serialized access
  • -> My plan: introduce a lock for serializing hosttable access
  • I remember rGe175152ef751: agent: Fix double free.
    • It is true that the thread may surrender control to a different (Pthread's) thread calling allocator
      • (for example, when there is a thread which uses estream calling fread->malloc->getting malloc's internal lock and then syscall mmap)
    • (But I think that) it never occurs for a control to go to another nPth thread, while the original thread holding nPth's semaphore
    • well, it is possible a user uses special allocator (instead of system allocator) which calls npth_unprotect npth_protect pair.

Patch 0001 applied to master.

Thanks for your report. Applied.

I created gniibe/secmem branch for this.
https://dev.gnupg.org/source/libgpg-error/history/gniibe%252Fsecmem/

Perhaps, the missing length information in compressed data packet is confusing. The length is determined by the assumption of existence of 22-byte MDC packet.

Here is my understanding.

Closing.

Initial development finished.
Now, my plan is:

• a bit more tweaks for gpg-error-config-old to support new ways (such as --variable=*)
• testing on *BSD
• not including gpg-error-config-new to next libgpg-error 1.33
  • Possibly include new gpg-error.m4???
• After 1.33, merge the branch (not directly by "merge" but merging all changes with relevant commit logs) to master of libgpg-error. This means:
  • gpg-error-config-new
  • checking difference between old and new at build-time
  • "make check" tests difference between gpg-error-config(-new) and pkg-config (if available)
• 1.34 will have all new features
• Then, we will migrate other software of our GnuPG
  • libassuan
  • libgcrypt
  • libksba
  • libnpth
  • ntbtls
  • gpgme

I can see MDC packet of 22-byte (which starts by 0xd3 0x19, and then 20-byte SHA-1 hash), when SEIP data packet is decrypted.
I don't see your situation.
How about with no compression (-z 0)? I mean, compression is not applied to MDC packet.

gpg-error-config gpg-error '>=' 1.33 libgcrypt '>=' 1.9.5 libassuan '>=' 2.5.1

• Sorry for many commit logs. My experiment with shell was by trial-and-error.

The implementation by Bourne shell is not perfect. Parsing .pc file depends on glob pattern match, which would have unexpected behavior in some cases (e.g. when .pc has no variable definitions and it only has "Requires: somepackage >= 1.0", the line matches glob pattern of "*=*" which looks like variable definition).

By {rGfb1d0cd}, it supports version dependency handling.
While it's far from pkg-config replacement, I think that we can use the script for all GnuPG software with *.pc file.
I mean, this single script for all.

Today, I wrote a script:

Up to rEe0aecec6d040: Remove AC_CONFIG_COMMANDS for gpg-error-config., now it supports dependency of modules and multiple modules.
A single shell script can be same content (but only names differ).
It only supports features used by our *-config command, though. (Not support --static yet, for example)