GNOME Bugzilla – Bug 791401
pkcs11: drop pkcs11 module
Last modified: 2021-06-18 10:40:03 UTC
It doesn't work well in multithreaded environments, and it overlaps with better maintained options like OpenHSM.
Created attachment 365261 [details] [review] pkcs11: drop pkcs11 module
see https://bugzilla.redhat.com/show_bug.cgi?id=1173279#c4 and https://src.fedoraproject.org/rpms/gnome-keyring/pull-request/1
i'm not expecting anyone to show up to review this so i'll probably just push it in a couple of days unless Cosimo, or Stef, or jjelen or someone wants to take a look.
Review of attachment 365261 [details] [review]: I am not against the removal, but in order to hide this module from the default listing, wouldn't it be sufficient to remove the .module file as requested in the original request (no need to remove the .so file). Also nit: by OpenHSM, do you mean SoftHSM?
(In reply to Daiki Ueno from comment #4) > Review of attachment 365261 [details] [review] [review]: > > I am not against the removal, but in order to hide this module from the > default listing, wouldn't it be sufficient to remove the .module file as > requested in the original request (no need to remove the .so file). Is there some benefit to installing the .so? I guess if it's not used, we might as well delete all the code, right?
thanks for chiming in daiki. in the downstream bug Stef expressed a desire for the code to get dropped.
I know you mean: https://bugzilla.redhat.com/show_bug.cgi?id=1173279#c4 Removal of the .so also means to make the server (the pkcs11 component of gnome-keyring) useless, because there would be no compatible client implementation at the moment. That would remove the way to salvage data from the old database. If we want to remove the .so file, I would suggest to do the following as well: - make the server protocol compatible with p11-kit - stop installing autostart file of the pkcs11 component - add proper documentation about migration
Created attachment 368478 [details] [review] pkcs11: Don't install p11-kit module configuration It doesn't work well in multithreaded environments, and it overlaps with better maintained options like SoftHSM. To avoid any confusion, stop installing the p11-kit configuration for that module so that it is not registered by default. -- So basically, while I am in favor of applying the subset of the patch like this, I would like to do the actual code removal a bit more gradually.
Comment on attachment 368478 [details] [review] pkcs11: Don't install p11-kit module configuration Attachment 368478 [details] pushed as 5d8326e - pkcs11: Don't install p11-kit module configuration
Apologies for the drive-by comment, but I'm trying track down why GCR is getting an error checking pinned certificates in Geary all of a sudden for Fedora 28 users: Bug 736640 From that bug, users are reporting the following: > Gck-Message: 14:41:59.890: couldn't open session on module while enumerating objects: The device is write protected > Gck-Message: 14:41:59.890: couldn't open session on module while enumerating objects: The device is write protected > > (geary:1361): Gck-CRITICAL **: 14:41:59.890: gck_modules_token_for_uri: assertion 'uri != NULL' failed Could commit 5d8326e have started causing this?
That's indeed true; I have filed a PR in p11-kit so it can provide an alternative to the user's certificate store: https://github.com/p11-glue/p11-kit/pull/155/commits/85c2d6ef0eb188b47b93138a03d7e7d672ba9910
(In reply to Daiki Ueno from comment #11) > That's indeed true; I have filed a PR in p11-kit so it can provide an > alternative to the user's certificate store: > https://github.com/p11-glue/p11-kit/pull/155/commits/ > 85c2d6ef0eb188b47b93138a03d7e7d672ba9910 I realized that this doesn't solve the original issue, because the GCR API uses the old trust assertion objects which p11-kit-trust rejects to create: https://p11-glue.github.io/p11-glue/doc/pkcs11-trust-assertions/ I think the ideal solution would be to switch the API to use the new trust policy: https://p11-glue.github.io/p11-glue/doc/storing-trust-policy/ although that might require the change of the API, because the trust policy doesn't have the concept of pinned EE certificates. A workaround without having to revive the gnome-keyring.module would be to allow p11-kit-trust to create trust assertion object through the PKCS#11 API, under certain conditions.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/ Thank you for your understanding and your help.