FWIW, we can and should run our test suite under valgrind from time to time
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
May 11 2021
Sorry, it's my fault.
Fixed in rGac731dbbbd21: gpg: Fix allocation for EXTRAHASH..
On Windows, smartcard is also used by logon/logout and certificates handling. Those may be related.
Please note that we don't use lock in apdu_dev_list_start/finish any more.
Use of lock is narrowed, only within apdu_open_reader function.
May 10 2021
(I disabled the account of this boor)
(I disabled this boor and restored the state)
GnuPG (more precisely gpg-agent) does cache the password for some time in memory. The default is 10 minutes. Add
default-cache-ttl n
where n is the number of seconds to cache the password, to ~/.gnupg/gpg-agent.conf.
I don't think that it is --pcsc-shared related; Andre reported that he noticed such a behaviour before we introduced this.
We should add a comment at the caller side, that this takes a lock in apdu.c.
Make the lock holding narrower, and it allows no exposing reader_table_lock.
Exposing reader_table_lock would be better.
I found a dead-lock condition when apdu_close_reader is called during apdu_dev_list_start/finish.
I wonder if PCSC_SHARE_SHARED is related or not.
And if the coding style of hiding mutex_lock/mutex_unlock inside different functions matters, we can expose the mutex to its user.
Last commit will be:
The second commit is replacing a use case of close_pcsc_reader by clearing pcsc.rdrname and calling release_pcsc_context.
This makes the use of close_pcsc_reader to its original purpose only (== closing PC/SC reader as a method of close_reader).
OK. As I pointed out a commit having multiple things may make analysis difficult, I should have been careful.
So, let me fix the problem by multiple commits.
May 9 2021
May 8 2021
May 7 2021
Ah, great. Thanks!
You are welcome.
run-genkey is working fine in my test environment as well.
Keeping the lock over the call to the function does not look very robust to me. This is why I removed it. And since then PC/SC worked on Windows for me. Modulo this:
All these changes don't tackle the real problem that windows gets struck in a removed-card state.
Technical commentary on smartcard operation and/or Windows is going to be over my head, so I can't help (just in case you're looking for anything from me). But always happy to drive-test another build. (I've still had no issues, personally, with the build above.) I'll assume you don't need me unless you link another binary build to test or tag me. Thanks again, all.
The problem is accesses to reader_table by
(1) scanning reader(s) to open new one
(2) closing reader
I'm testing D531: Keep holding READER_LOCK_TABLE and make clear distinction among close/releasing_PCSC_context/nullify_rdrname, but I'm not sure about the impact on Windows.
The commit rGbb8e3996e44f: scd: Fix problem with reader list becoming empty. removed READER_TABLE_LOCK holding between apdu_dev_list_start and apdu_dev_list_finish, that opens possible stale resource access for CCID driver: reader_table[slot].ccid.handle
Thank you for your report.
May 6 2021
I am also a MacOS Big Sur user who recently upgraded to 2.3.1 and had problems after upgrading. In my use case, I use the yubikey as the authentication for pass password manager which uses gpg under the hood.
This revision was committed with rM276187f6b62a: core: Extend gpgme_key_sig_t with trust signature members.