This is the dependency graph:

While we have no way to express possible range of values in structure member, we can do something like this (which is not needed actually, if the gmtime function returns correct value).

Here is the warning:

../../libgpg-error/doc/yat2m.c: In function 'isodatestring':
../../libgpg-error/doc/yat2m.c:373:29: warning: '%02d' directive writing between 2 and 11 bytes into a region of size between 4 and 11 [-Wformat-overflow=]
       sprintf (buffer,"%04d-%02d-%02d",
                             ^~~~
../../libgpg-error/doc/yat2m.c:373:23: note: directive argument in the range [-2147483647, 2147483647]
       sprintf (buffer,"%04d-%02d-%02d",
                       ^~~~~~~~~~~~~~~~
../../libgpg-error/doc/yat2m.c:373:7: note: 'sprintf' output between 11 and 36 bytes into a destination of size 16
       sprintf (buffer,"%04d-%02d-%02d",
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                1900+tp->tm_year, tp->tm_mon+1, tp->tm_mday );
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Apparently, it is not the bug of gpg, but you just specified wrong line in your /etc/apt/souces.list.d/skypeforlinux.list, where filename extension .gpg is irrelevant.

Done for libgpg-error.
Will extend to other software.

Applied to master: rE91bcb2c7d824: gpg-error-config: Support "auto", architecture independent script.

there should be clearer labelling of smartcards so that users can tell them apart more easily

I did a small update to D467: Enable dynamically defining pkg_config_libdir for multiarch. The name is changed to "auto" (was: "unknown"). It now support other cases where CC is not a kind of gcc.

Support the case when CC is the one of clang.

@werner, I think that the scope is different. The bug reporters' claim were basically "GnuPG's cross building is different (for them), why?". They didn't claim GnuPG were unable to be cross-build.

This patch D467: Enable dynamically defining pkg_config_libdir for multiarch, enables multiarch dynamic PKG_CONFIG_LIBDIR support.

Done for libgcrypt, finally.

ntbtls adopts the way from the beginning.

Here are more links, which are basically Debian specific:

Please check your ld.so (dynamic linker) setting (/etc/ld.so.conf and/or LD_LIBRARY_PATH).

Done for gpgme.

Interaction will be something like this:

Priority is high, because Gnuk Token requires this feature for testing its implementation.

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

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

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.

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/