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.

Mmh no. This needs to go into the resolver. If autoresolve is disabled we also want to have that functionality. Having the ca config in libkleo would also help to use the same values in Kleopatra for a CSR.

This should resolve it.

Well there is nothing specially pythonic about it, it just includes the dirs and not the files:

Argh, that Python specific stuff Ben used is weird and does not fit into the autotools model. Someone(tm) need to have a closer look at it.