On Mon, 23 Jun 2025 20:22, Guido Trentalancia said: > The best way to achieve protection is obviously by calling prctl() > during the cryptographic application startup and this is precisely what > the gnupg patch does: > https://lists.gnupg.org/pipermail/gnupg-devel/2025-May/035904.html
Right. I replied with If that is a misfeature it needs to be fixed at the pläce where it was introduced and not just in a single binary. If this code is really needed it would first of all be useful in Libgcrypt only then then you should put it into gnupg/common/init.c:early_system_init. Specific Linux code is in general not a good idea, if that is required, please write a proper configure test for this feature and use a dedicated macro. A more detailed explanation of the pro and cons would also be appreciated. But you did not came up with a fixed patch but instead you wrote A test in the autoconf-generated "configure" script is not needed, because the patch automatically detects whether the glibc and kernel versions support disabling those vulnerabilities. and refused my above advise. If you don't want to write the respective autoconf checks you may also add a configure option to enable your code. I would also suggest to use an environemnt variabale to activate the tests. For example, for signature verification the whole code is superflous. An envar let the admin decide whether it is worth to do that. One may also want to extend ld and ld.so to process a dedicated ELF segment to enable linking in that code. This way a library can demand the use of this code. > However it is not possible to foresee all the other applications using > libgcrypt, so another preventive patch has been submitted so that > prctl() is also called by the cryptographic library and this is what > the libgcrypt patch does: > https://lists.gnupg.org/pipermail/gcrypt-devel/2025-May/005856.html > By applying the companion libgcrypt patch we offer some kind of > protection to applications other than gnupg, even though the level of > protection is not the same as if prctl() was called at application > startup. > Please note that calling prctl() twice in gnupg and then in libgcrypt > has no side-effects. > The fact that other cryptographic libraries such as openssl do not do > the same only means that they are vulnerable those cryptographic > information disclosure vulnerabilities. > Regards, > Guido > On Mon, 23/06/2025 at 19.58 +0200, Werner Koch wrote: >> On Mon, 23 Jun 2025 13:57, Guido Trentalancia said: >> > It does not change the property of the system, it only changes the >> >> Sorry, with "system" I meant the process with its main application >> and >> all other libraries. Libgcrypt is a library usally linked at runtime >> and thus it would be surprising if it changes such process >> properties. >> >> >> Salam-Shalom, >> >> Werner >> > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel@gnupg.org > https://lists.gnupg.org/mailman/listinfo/gcrypt-devel > -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein
openpgp-digital-signature.asc
Description: PGP signature
_______________________________________________ Gcrypt-devel mailing list Gcrypt-devel@gnupg.org https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
