On Thu, 10 Jul 2025 12:41, Guido Trentalancia said: > I have tested the patch and the logging functions work as I would > expect. They might need to be initialized before early_system_init(),
That is a catch-22 - early_system_init is supposed to be the very first thing done after main(). If you want to catch errors, use abort() or store the the error and retrieve it after the logging has been enabled. This would be similar to the secmem handling done in GnuPG. It might even be useful to do the whole thing as part of the secmem thing - this is also a critical thing and we have quite some experience on how to get this right over all the components. > 2017, leaving the program vulnerable to data leaks for about 8 years ! It is not the gpg or actually gpg-agent process which leaks the data but it is a properly of the CPU. If you can mount such an attack on highly sensitive data, that CPU might not be the right rig for you. In particular I would strongly advise not to process such secrets on a VM. I would suggest to implement the whole stuff in the run-time loader and provide a way to configure which processes should do this. This way users can decide whether it is worth to disable these CPU-(mis)features mitigations. > That is the real problem !! The real problem is a over-complicated mitigation for a problem to be solved elsewhere. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein
openpgp-digital-signature.asc
Description: PGP signature
_______________________________________________ Gnupg-devel mailing list Gnupg-devel@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-devel
