- User Since
- Mar 27 2017, 4:47 PM (157 w, 5 d)
Fri, Apr 3
Pushed the changes.
OK. I reopen this ticket to collect information.
I think that it is compiler issue for AltiVec (now, VSX) support.
The usage is not ambiguous. It _is_ ambiguous in the header file.
Thansk for your report.
Thu, Apr 2
It runs like:
$ gpg-connect-agent "scd devinfo --watch" /bye S DEVINFO_START S DEVINFO_END S DEVINFO_STATUS new S DEVINFO_START S DEVICE generic D276000124010200F517000000010000 openpgp S DEVINFO_END S DEVINFO_STATUS removal S DEVINFO_START S DEVINFO_END OK $
Push the change to master.
Wed, Apr 1
The problem itself is fixed (in T4495: UBsan finding "certdump.c:695:3: runtime error: null pointer passed as argument 2"). The variable buffer cannot be NULL at memcpy.
Tue, Mar 31
genkey for Ed25519 works now with libksba in master.
For public key, it's done.
Mon, Mar 30
Fri, Mar 27
NIST P-256 key generation looks good.
Thu, Mar 26
Tue, Mar 24
There are two code paths to generate key: gpgsm_genkey and gpgsm_gencertreq_tty. Latter is partially supported with card key.
Firstly, I'm going to work for T4888.
I think that what you want is adding --batch option. In the gpg manual, we have:
--passphrase-file file Read the passphrase from file file. Only the first line will be read from file file. This can only be used if only one passphrase is supplied. Obviously, a passphrase stored in a file is of questionable security if other users can read this file. Don't use this option if you can avoid it.
This should work well with libksba master and gnupg/sm master.
The commits in 2019 (for libksba and gnupg/sm) handles the problem (of key generation using card).
For operations which require private key, it is needed to unlock private key.
Mon, Mar 23
- T4864: command processing implemented, what kind of information is provided and how should be decided
- libgcrypt constant-time invm: My work has been pushed to master and 1.8
Thu, Mar 19
You forwarded me an email, which said it went well.
Wed, Mar 18
Tue, Mar 17
Related the changes, before we did the changes, we received two independent reports.
It is my confusion. The API is available. I only looked for symbols in the library.
It is #define-d macro to pthread_cond_*.
For Windows, it is available. I don't know the reason why it has not been available for POSIX.