From ludovic.rousseau at free.fr Wed May 11 12:42:59 2022 From: ludovic.rousseau at free.fr (Ludovic Rousseau) Date: Wed, 11 May 2022 12:42:59 +0200 Subject: SCardListReaders: Conditional jump or move depends on uninitialised value(s) Message-ID: <3d312267-89b9-77fd-9a4b-e968f4eddb1e@free.fr> Hello I hope it is the correct way to report bugs and patches. GnuPG is not using the PC/SC API correctly. With the function SCardListReaders() the last parameter (size of the readers buffer) is a in/out parameter. i.e. the value MUST be initialized before calling. According to the API documentation https://pcsclite.apdu.fr/api/group__API.html#ga93b07815789b3cf2629d439ecf20f0d9 SCardListReaders() LONG SCardListReaders ( SCARDCONTEXT hContext, LPCSTR mszGroups, LPSTR mszReaders, LPDWORD pcchReaders ) If *pcchReaders is equal to SCARD_AUTOALLOCATE then the function will allocate itself the needed memory. Use SCardFreeMemory() to release it. In the GnuPG code the value of pcchReaders is not initialized and that generates a log reported by valgrind: ==35605== Thread 2: ==35605== Conditional jump or move depends on uninitialised value(s) ==35605== at 0x58BCFAE: SCardListReaders (in /usr/lib64/libpcsclite.so.1.0.0) ==35605== by 0x11D78A: apdu_dev_list_start (apdu.c:2031) ==35605== by 0x1245EF: select_application (app.c:817) ==35605== by 0x117AFF: open_card_with_request (command.c:281) ==35605== by 0x117AFF: cmd_serialno (command.c:358) ==35605== by 0x4A20839: ??? (in /usr/lib64/libassuan.so.0.8.5) ==35605== by 0x4A20C28: assuan_process (in /usr/lib64/libassuan.so.0.8.5) ==35605== by 0x11854C: scd_command_handler (command.c:2521) ==35605== by 0x114C03: start_connection_thread (scdaemon.c:1202) ==35605== by 0x4A2F49D: ??? (in /usr/lib64/libnpth.so.0.1.2) ==35605== by 0x4ABD3E9: start_thread (pthread_create.c:442) ==35605== by 0x4B3F0DF: clone (clone.S:100) ==35605== The patch is very simple: diff --git a/scd/apdu.c b/scd/apdu.c index 574697cc1..e83815ba5 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -2015,7 +2015,7 @@ apdu_dev_list_start (const char *portstr, struct dev_list **l_p) #endif { /* PC/SC readers. */ long r; - pcsc_dword_t nreader; + pcsc_dword_t nreader = 0; char *p = NULL; if (!pcsc.context) I found the problem because of https://github.com/LudovicRousseau/PCSC/issues/125 and https://dev.gnupg.org/T5963 Thanks -- Dr. Ludovic Rousseau From eric at bktus.com Thu May 19 11:34:18 2022 From: eric at bktus.com (Saturneric) Date: Thu, 19 May 2022 17:34:18 +0800 Subject: GnuPG and macOS App Sandbox Message-ID: <79D9BD42-0161-45D0-B3BC-DC493FA97EEF@bktus.com> Hi, Is there any way to put GnuPG into a macOS App Bundle? Or has anyone already tried it? Especially the macOS App Bundle, when the security sandbox mechanism is on, access to executable files or resources outside the App Bundle is prohibited. Also, I am concerned that even if it is possible to wrap gpg into a macOS App Bundle, it may need access to some additional resources, which is not allowed in the sandbox. -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick at enigmail.net Sat May 21 10:48:20 2022 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 21 May 2022 10:48:20 +0200 Subject: GnuPG and macOS App Sandbox In-Reply-To: <79D9BD42-0161-45D0-B3BC-DC493FA97EEF@bktus.com> References: <79D9BD42-0161-45D0-B3BC-DC493FA97EEF@bktus.com> Message-ID: Saturneric via Gnupg-devel wrote on 19.05.2022 11:34: > Hi, Is there any way to put GnuPG into a macOS App Bundle? Or has anyone > already tried it? Especially the macOS App Bundle, when the security > sandbox mechanism is on, access to executable files or resources outside > the App Bundle is prohibited. > > Also, I am concerned that even if it is possible to wrap gpg into a > macOS App Bundle, it may need access to some additional resources, which > is not allowed in the sandbox. I that it's not possible to put GnuPG into a macOS App Bundle. GnuPG works with absolute paths for its helper tools and daemons. Even though the default installation location for Apps on macOS is in /Applications, a macOS App Bundle may be installed or started from anywhere in the file system. This collides with the absolute paths of GnuPG. -Patrick From kloecker at kde.org Sat May 21 17:08:42 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sat, 21 May 2022 17:08:42 +0200 Subject: GnuPG and macOS App Sandbox In-Reply-To: References: <79D9BD42-0161-45D0-B3BC-DC493FA97EEF@bktus.com> Message-ID: <2243387.ElGaqSPkdT@breq> On Samstag, 21. Mai 2022 10:48:20 CEST Patrick Brunschwig wrote: > Saturneric via Gnupg-devel wrote on 19.05.2022 11:34: > > Hi, Is there any way to put GnuPG into a macOS App Bundle? Or has anyone > > already tried it? Especially the macOS App Bundle, when the security > > sandbox mechanism is on, access to executable files or resources outside > > the App Bundle is prohibited. > > > > Also, I am concerned that even if it is possible to wrap gpg into a > > macOS App Bundle, it may need access to some additional resources, which > > is not allowed in the sandbox. > > I that it's not possible to put GnuPG into a macOS App Bundle. GnuPG > works with absolute paths for its helper tools and daemons. Even though > the default installation location for Apps on macOS is in /Applications, > a macOS App Bundle may be installed or started from anywhere in the file > system. This collides with the absolute paths of GnuPG. This isn't true anymore. GnuPG works perfectly well as part of an AppImage which is mounted at a different path on each start. The AppImage uses a wrapper script to set up the necessary environment variables. For the App Bundle a similar wrapper script may be needed. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: