Hide Forgot
p11-kit list-modules should show my yubikey, but doesn't. Registering with p11-kit solves this problem.
I actually realized we didn't have a formal guideline for auto registering PKCS#11 modules with p11-kit. I've created one. Comments welcome. https://fedoraproject.org/wiki/PackagingDrafts/Pkcs11Support
Created attachment 1228467 [details] dist-git patch The draft explains quite widely the problem, but does not explain a lot of details: * Specific path for the modules: %{_datadir}/p11-kit/modules/ykcs11.module * Preferred location and naming of the PKCS#11 modules: %{_libdir}/pkcs11/libykcs11.so (should say about the pkcs11 directory) * According to packaging guidelines, unversioned *.so are in the -devel subpackage. Should the symlink from pkcs11/ directory point to the unversioned or latest versioned .so? Should the PKCS#11 .so objects come into non-devel package? Should the fedora-review tool be updated accordingly? * Explaining the conflicts (showing the same objects got using different modules) According to the thread on fedora-devel mailing list [1], something is wrong with the pkcs11 module and it lists the objects multiple times, which would be nice to debug before bringing this into the p11-kit (avoid spamming the outputs). I am getting the duplicated keys only in p11tool (not in pkcs11-tool). I am getting a lot of invalid slots using C_GetSlotList() when I investigate the behavior using pkcs11-spy -- will take it upstream. Attaching proposed patch to add the module (so far with the module in devel subpackage which should probably change if we want that by default). Other comments welcomed. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IVNMUJUJCKB63CVWYO2VNGTLHWM5XZWS/#K6ONIYLNVDPFXGAPQ4WMZEHF6CS7E4ND
(In reply to Jakub Jelen from comment #2) > Created attachment 1228467 [details] > dist-git patch > > The draft explains quite widely the problem, but does not explain a lot of > details: > > * Specific path for the modules: > %{_datadir}/p11-kit/modules/ykcs11.module > > * Preferred location and naming of the PKCS#11 modules: > %{_libdir}/pkcs11/libykcs11.so > (should say about the pkcs11 directory) Thanks. updated. > * According to packaging guidelines, unversioned *.so are in the -devel > subpackage. Should the symlink from pkcs11/ directory point to the > unversioned or latest versioned .so? Should the PKCS#11 .so objects come > into non-devel package? Should the fedora-review tool be updated accordingly? I don't think you need a devel package. There is an exception for plugins such as pkcs11 modules. See "In these cases, the unversioned shared objects do not need to be placed in a -devel package." > * Explaining the conflicts (showing the same objects got using different > modules) I'm not sure if that should get in the packaging guidelines. It could get in the rationale section too. If you have some text in mind, feel free to modify:https://fedoraproject.org/wiki/User:Nmav/Pkcs11Status > According to the thread on fedora-devel mailing list [1], something is wrong > with the pkcs11 module and it lists the objects multiple times, which would > be nice to debug before bringing this into the p11-kit (avoid spamming the > outputs). I am getting the duplicated keys only in p11tool (not in > pkcs11-tool). I am getting a lot of invalid slots using C_GetSlotList() when > I investigate the behavior using pkcs11-spy -- will take it upstream. In my todo list as well.
> > * According to packaging guidelines, unversioned *.so are in the -devel > > subpackage. Should the symlink from pkcs11/ directory point to the > > unversioned or latest versioned .so? Should the PKCS#11 .so objects come > > into non-devel package? Should the fedora-review tool be updated accordingly? > > I don't think you need a devel package. There is an exception for plugins > such as pkcs11 modules. See "In these cases, the unversioned shared objects > do not need to be placed in a -devel package." Well ... they are now, because the yubico-piv-tool was not intended (to my understanding) as a standalone pkcs11 library, but as a tool, which is using this library internally. Even their guides recommend using the OpenSC as a PKCS#11 library [1] > > According to the thread on fedora-devel mailing list [1], something is wrong > > with the pkcs11 module and it lists the objects multiple times, which would > > be nice to debug before bringing this into the p11-kit (avoid spamming the > > outputs). I am getting the duplicated keys only in p11tool (not in > > pkcs11-tool). I am getting a lot of invalid slots using C_GetSlotList() when > > I investigate the behavior using pkcs11-spy -- will take it upstream. > > In my todo list as well. At this point, I don't consider the ykcs11 module mature enough to be registered by default. There are several issues, as pointed out in the previous email [2], when the module is misbehaving (some of them not yet solved upstream) so as Nikos pointed out, it is probably not the time to include it in the k11-kit yet. [1] https://developers.yubico.com/PIV/Guides/SSH_with_PIV_and_PKCS11.html [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PSTG5RNIOCJCMJXJED5AJGV64OPTY3H2/
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.