Note that this has also been ported to 2.4 and 2.2 and tested by looking at the status lines.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Wed, Apr 24
Mon, Apr 22
Mon, Apr 15
Thu, Apr 11
Mar 19 2024
Mar 14 2024
Thanks for reporting this. Returning error codes to upper layers is not always easy because the original logic is that we have a global error counter to decide whether an operation succeeded. My fix to check the error code before emitting the DECRYPTION_OKAY status,
Feb 23 2024
Jan 26 2024
Jan 22 2024
Dec 26 2023
Nov 27 2023
It's true that for KEYTOCARD command, there is optional argument for ECDH.
My point is that for PKDECRYPT command, it will be needed to add mechanism for getting such a parameter (when we use KEM API in gpg-agent).
We already have the ECDH parameters for OpenPGP in the gpg-agent API. The question is how large the data for PQC will be - likely we need to use an inquire already for this reason.
Considering the design of gpg-agent which focuses on private key operations and data, it would be better to enhance the gpg-agent protocol to inquire public key data of any format defined by the client (including ECDH KDF parameters of OpenPGP). I mean, instead of storing data in the key file (originally designed for private key + some additional data), we will enhance the protocol.
Nov 23 2023
Oct 28 2023
Please excuse my question but this issue has been WIP for 8 months. I think it was forgotten a bit. Especially since we are not shipping Okular for general signing of PDF documents this issue might help as a stopgap for Smartcards which we do not yet support natively and reduce the pressure a bit to add more PKCS#15 smartcards which can currently be used with Adobe and Mozilla NSS through their proprietary PKCS#11 modules. So I would like to raise the priority for this a bit. But I don't think high is appropriate. That would be for werner to decide.
Oct 26 2023
Sep 4 2023
Aug 29 2023
Aug 23 2023
Aug 17 2023
Sorry, I only now noticed that you used the --export-secret-ssh-key. Unfortunately commit
rGafe5fcda52e88438c7a7278117b2e03f510a9c1c states in the comment:
"Due to time constraints the code is not yet ready." Let's turn this into a feature request.
Aug 4 2023
assuan_sock_accept approach is taken in gnupg master.
gniibe/t6606 patches are all pushed into master.
Aug 3 2023
Aug 2 2023
In T6606#173044, @gniibe wrote:More care is needed to be perfect; There are places in GnuPG where assuan_sock_connect may be used before syscall clamp set up (after the first assuan_sock_bind failure).
Jul 25 2023
Applied to master.
Jul 24 2023
Applied the changes for libassuan T6487 into gniibe/t6606.
Pushed the change in gniibe/t6606 branch.
Jul 20 2023
Another approach would be:
- Use assuan_sock_accept which has consistent API with gnupg_fd_t
Jul 19 2023
On 64-bit Windows, the situation now is:
Jul 18 2023
Use of FD2INT for the first argument of select is semantically not good. It's the number of file descriptor. When we use FD2INT here, the type is converted to 64-bit integer, then implicitly demoted to 32-bit integer. We need new macro, say, FD2NUM to convert FD into 32-bit integer.
<--- done in: rGea1935252e28: commond: Introduce FD2NUM to express conversion to number of fds.
Here is a test program for 64-bit Windows to see how cast works:
#include <stdint.h> #include <stdio.h>
Jul 13 2023
Jul 5 2023
Jul 3 2023
The case in check_special_filename is fixed. So, there is no cases in GnuPG where the value of out of range is silently converted to wrong value.
Remaining places are:
Jun 29 2023
Except a case, all use cases of translate_sys2libc_fd_int is with a result of integer from command line argument.
Jun 28 2023
Changes are pushed.
Jun 27 2023
We need to keep the gpgtar part of commit in rG2756147e392c: gpg,sm,tools: Use string for option --*-fd..
The changes are intrusive to other implementations (POSIX and Windows 32-bit).
So, I revert the changes of replacing translate_sys2libc_fd_int.
Jun 26 2023
I don't argue about the technical necessity for the change. I agree the fact it works (without such changes).
Jun 23 2023
Just to clarify this change for readers not accustomed to Windows internals: This function was used to translate the file descriptor as passed to gpg (which is a HANDLE) to the libc file descriptor as used by stdio. Obviously we won't anymore work with stdio file descriptors in the future but use the Windows32 API (ReadFile et al). libc fds 0,1,2 are handled in a special way on Windows.
Fixed in master.
Jun 22 2023
The use cases are:
- oPassphraseFD for gpgsm, gpg
- oStatusFD for gpg-auth, gpg-wks-client, gpg-card, gpg-pair-tool, gpgtar, gpgconf, gpgsm, gpg, gpgv
- oLoggerFD for gpgsm, gpg, gpgv
- oAttributeFD for gpg
- oCommandFD for gpg
- oOverrideSessionKeyFD for gpg
Jun 8 2023
With the fix of T6523, make check goes all well (on Wine emulation and on Windows, for i686 and for x86_64).
Fixed in master.
I modified ffi.c, to have renamed process-spawn-io function doing I/O by C.
Jun 7 2023
Calling assuan_release before kbx_client_data_release is the best (and we join the thread).
Jun 5 2023
tests/openpgp/import.scm hangs with 4096*4.
Jun 2 2023
Test with Wine (i686) emulation, I encountered another hang at: Checking armored_key_8192
It looks like having the datastream_thread may be not worth.
One possibility is to implement synchronous read from pipe in kbx_client_data_wait, instead of datastream_thread.