We update condig.{guess,sub} only when needed. In the past we had cases with regressions on some rare platforms.

It is because you don't have ${prefix}/bin in your PATH.
Please build having /var/tmp/bin in your PATH.

I'm going to bring newest m4/iconv.m4 from original (gettext), which apparently fixed file descriptor leaks.

Thanks for your report.

An FYI... Once we cleared the earlier findings GnuPG tested OK under Asan. GnuPG itself had no findings, and it did not cause any dependent libraries to generate findings.

Thanks for the tests. I just fixed this one and will do replace some code in master, soon.

I often put an extra nul byte at the end of binary data so that accidental printing the data (e.g. in gdb) assures that there is a string terminator. But right, it should not go out to a file.

That type of variadic macro is GCC extension, see https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html

This patch tested OK.

Hello again - can I ask about the status? Or should I consider this as a no-fix? Anything I can assist with?

The second and third arguments passed to xgcry_control seem to be lost when calling gcry_control.

Here are the next two failures I am seeing while testing libgrcypt. It appears to be related to GCRYCTL_INIT_SECMEM.

I'm still seeing a few odd outputs from make check, but I have not investigated them yet.

Maybe cleaner option for mpi/mpiutil.c would be to statically allocate the constants

Maybe cleaner option for mpi/mpiutil.c would be to statically allocate the constants

Here's a couple of awful hacks that get me through make check. Feel free to restate how awful they are; I know it is a bad thing to do.

I also did a base64 < "$GNUPGHOME/private-keys-v1.d/".key at the end of a different run of that script, and it produced this output, if you'd like to inspect the actual S-expression stored:

I ran the example script from T4490 on an s390x machine, and got the following output:

This might be related to T4490, since it's the same sort of key generation process.

I was trying to use the above technique to be able to generate an OpenPGP transferable secret key in an ephemeral homedir. Ephemeral directories are recommended in the GnuPG info page's "unattended usage" section, but they do not work here.

It looks like this patch clears this finding:

It looks like this patch clears this finding:

We fixed this bug already in the repo. See T4459.

It looks like Solaris only needs CFLAGS+=-std=c99. It was added for all programs and libraries listed at https://www.gnupg.org/download/index.html.

It appears this issue was first identified and triaged in 2016: T2879
The subkey deletion feature also showed up in other issues since then:

i'm thinking that if the algo parameter to --quick-add-key is a keygrip, then it would find the key directly in the existing keyring(s) and attach it as a new subkey.

Thanks for the explanation.

If the ASN.1 is not from an RFC, then the AUTHORS file should not claim that it is from an RFC.

As this update lists multiple issues and following fixes for them, maybe it was resolved by Microsoft?

Diffs downloaded from the revisions don't include commit messages for some reason. Here are all the commits I submitted for review as patch files with messages:

@werner could you review the patches posted here by @matheusmoreira ? This looks concretely useful, and i would like to have this fixed.

SPARC T4 has crypto instruction set for AES, GCM, SHA1, SHA256, SHA512, Camellia and DES, that can be used from user-space too.

Isn't the Sparc crypto instruction set only available in kernel mode?

As I want to keep this tracker clean I would say this is a Wontfix at least until someone (DKG?) provides an argument what would be gained and why we should do this.

That is not a functional feature request and I see no value in chnaging data structures just for being up to the latest RFC. Actually the ASN.1 is not from an RFC but from a specific X.509 profile. For CMS most parsing is anyway done with handcrafted code.