Is currently not enabled, sorry. Use git:// ot the mirror here at dev.gnupg.org. Note that we sign all our commits using a token and as such it is a stronger security prove than a just an arbitrary TLS connection.

Sorry, we have nothing do to with this pypi thing even if that file claims " The GnuPG hackers".

The debug/workaround option works: When the option is checked, opening the msg file will not change its date.

With VS-Desktop-3.1.90.246-Beta I can not import the secret part of the edward.tester@demo.gnupg.com.p12 Testkey (ECC brainpool).
I do not see any error message.

works: installed VS-Desktop-3.1.90.246-Beta with

Questions:

• What does "not certified" mean? Not certified by the user exporting the certificates (use case: I'm the "CA" for the exported group.)? Or not fully valid (i.e. not certified by a trusted certificate) (use case: I want to give some certificates to my co-workers and certification is centralized)?
• What about expired, revoked, or otherwise invalid certificates?

I have created T6766: Kleopatra: On export, inform user about uncertified user IDs for points 3 and 4 of T6469#174361.

Yes, it consists of libkleo DocAction actions which are invisible unless they find the document which they would open. I expect that I can somehow find the menu element and then hide it. But a patch against KXMLGui to hide empty submenus automatically might be a better use of our time. So I put this in the backlog and if someone wants to pick it up in some downtime feel free to fix this :)

The submenu is empty because the referenced actions don't exist outside of VSD builds, right?

it was decided to write the encrypted archive with ending .part and only rename it at the end. In this way the users can't think they have a valid encrypted archive

Thanks, what should I look out for? I don't think I can provide the .p12 directly because it is from a production provider that I do not have full access. I can provide the log and x509 public certificate again using the firefox generated one.

Needed changes in Kleopatra are tracked in T6761.

I am pretty sure that we have done everything in gnupg. Now if we only had a workboard for kleopatra.

Yes, apparently I confused uint8_t and unsigned char here because the former appears in Simon's comments. We also kept to the use of unsigned char* in our implementations (that is even part of the GNU coding guidelines if I remember correctly).

Funny error description from macOS. Looks that there is no device - your PC/SC test programs confirms this. Thus I don't think this is a bug in scdaemon.

Recent Mozilla again changed some things. Please see T6752. Can you please provide a sample in case this is not the same problem as in T6752?

Actually we never use uint8_t* because that is c99 and very uncommon except for some MCU projects. Instead we use unsigned char *. The use of void* is often used because this allows to pass arbitrary types to a function without requiring ugly and error-prone casting at the caller site.

The installation parameter for this is documented in our installation instructions. What is new with the next version is that for all files when you open them after installation of GnuPG VS-Desktop for the very first time you will be asked if Kleopatra should be used and have the option to make this permanent.

Since @ebo did not really know how to test I just checked that it is passed to gpg to resolve this issue.

You don't need a library but just one object file.

The issue mentioned in T6469#176392 is fixed.

OK, fine, however, in order to be able keep an overview of our tasks I would still keep track of them in our GitHub, where I can create a sub-issue from the list of tasks with one click. But we will post our comments and results here as well as far relevant for the purpose of documentation. I think most of the points Jussi raised are more or less clear to me anyway.

With respect to the function signatures, I see the following issues with the API you reference via the provided link:

@fse: Github is not an option here. We don't use it and thus everything relevant to Libgcrypt needs to be documented here and not at some external platform.

Some time ago, I have checked and hopefully fixed all usage of time_t in Kleopatra and GpgME to make sure we always use unsigned 32-bit integer arithmetic. Dates entered by the users are capped to some date in 2106 (a few days before the overflow date).

For length information, we can find that Simon's patch (let me call it v1) has length argument:
https://gitlab.com/jas/libgcrypt/-/commit/3af635afca052a9575912b257fe7518a58bfe810

Sure it does not. That is the whole point of the loopback thing.

Hi Jussi,

• There's many functions that use buffers on stack. Do those contain secrets? Should those buffers be wiped before returning from function (with wipememory())? For example, "mlkem_check_secret_key" has two buffers "shared_secret_1" and "shared_secret_2" which are not wiped.
• mlkem.c: mlkem_check_secret_key: "memcmp" is used to compare shared secrets. Should this use constant time comparison instead?
• mlkem-common.c: _gcry_mlkem_mlkem_shake256_rkprf:
  • _gcry_md_hash_buffers_extract can be used here instead of _gcry_md_open&write&extract&close.
• mlkem-symmetric.c: _gcry_mlkem_shake256_prf:
  • _gcry_md_hash_buffers_extract can be used here instead of _gcry_md_open&write&extract&close. Temporary buffer usage can be avoided by passing input buffers through two IOV to _gcry_md_hash_buffers_extract.

Few comments on the patches.

Well I have looked at this ticket and posted a comment. We should talk about if there is anything left to do or not. I suspect that the gpg side is done and I should open one (or probably better several) ticket(s) for the kleopatra side.

Ah nevermind missing icons were related because I also removed the highcolor icons for testing.

works now with VS-Desktop-3.1.90.246-Beta

Mmh, on further checking I notice that some icons are missing though. Need to investigate where they went. I basically just took the inst-breeze.nsi file, and removed all the NSIS things and did a sort -u on it to create the list of icons.