Bug 1401621

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.