Random questions from someone who doesn't even know what PKCS#11 means:

Do you expect the value of 'pkg-config p11-kit-1 --variable p11_module_configs' to change? Can we get that into an RPM macro if so? Otherwise you'd just expect people to hardcode /usr/share/p11-kit/modules. (If there's a common -devel dependency that these packages have, that would be a good way to drop a macro definition into /usr/lib/rpm/macros.d.)

How does someone (a package reviewer) verify that a package actually does the three things listed under Client applications? I guess you can get the second from reading the documentation, maybe.

And about the second, what if it doesn't? It seems to me that patching the upstream source to do so runs the risk of introducing incompatibilities.

Also, please don't do a bug bombing run. Discuss on devel first and post lists of packages that need fixing along with all relevant info to devel-announce. File bugs later.

''(background on PKCS#''''''''''11...''

''PKCS#''''''''''11 is the API standard for crypto tokens. It defines an object store which contains keys and certificates — and which can do operations on those keys instead of just handing out the private key information willy-nilly.''

''Although the primary focus was hardware crypto devices, it's also used with "software tokens". NSS is designed around it; your certificate store that remembers which web site certificates you've manually accepted in Firefox is just another PKCS#11 module, for example.''

''The unified SSL trust architecture we deployed in F19 works by providing a 'p11-kit-trust' PKCS#11 token with the sysadmin-configured trust settings.)''

No, we don't expect the p11_module_configs location to change; hardcoding it would be acceptable. I was just trying to make it clear that the proposed packaging guideline wasn't the definitive source of that information.

Testing that a package uses PKCS#''''''''''11 sanely is fairly simple. Just test an operation that would usually use a client SSL certificate from a file. Use the seahorse GUI application to import the cert into a PKCS#''''''''''11 token — like the one offered by gnome-keyring in the default install. Then use it from there.

So where I might have tested my VPN client with a certificate from a file:
{{{
openconnect -c certificate.p12 vpn.example.com
}}}
... I can now test it with a certificate I imported into gnome-keyring (and found the URI with p11tool):
{{{
openconnect -c 'pkcs11:token=Gnome2%20Key%20Storage;object=Woodhouse%2c%20David vpn.example.com
}}}

Whether the packager wants to apply patches before they're accepted by upstream is of course up to them. The guideline is only asking that if it's possible to build and configure the package such that things work properly, the packager should do so. As noted, often that's as simple as building against the right crypto library and minor tweaks to the configuration. And if it isn't possible, hopefully, the packager can at least convey the feature request to the upstream developer(s).

As requested I'll not file more bugs but I'll continue the bombing run of supplying patches to upstream projects so that hopefully the next versions of various things (like the pkcs11-helper library that OpenVPN uses, and the OpenSSL ENGINE_pkcs11) Just Work. My patches to OpenVPN itself to make it default to using p11-kit-proxy.so also got acked today...

We discussed this at today's meeting (​http://meetbot.fedoraproject.org/fedora-meeting-1/2014-12-18/fpc.2014-12-18-17.01.txt):

• 480 Packaging guidelines for consistent PKCS#11 usage (geppetto,

  
  17:08:07)
• LINK: https://fedorahosted.org/fpc/ticket/480 (geppetto, 17:08:11)
• General concensus that this is desirable (geppetto, 17:24:25)
• ACTION: dwmw2 Add examples for common libraries/APIs, on the client
  applications. (geppetto, 17:24:25)

Just a friendly ping that we looked at this in today's meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-01-08/fpc.2015-01-08-17.01.txt) but still need the info.

Since it's been another month since the previous ping, I'm just going to close this. Please feel free to reopen if there's something we can consider.

Apologies for being slow with this. The PKCS#''''''''''11 URI specification was published this month as [https://tools.ietf.org/html/rfc7512 RFC7512] and I hope to get back to this shortly.

Looking at this now ''(again, apologies for the delay)'', I find I could do with a better idea of precisely what kind of "examples" we're looking for.

This kind of thing is fairly package-specific.

One simple example is that if a package conforms to RFC7512 and supports proper PKCS#''''''''''11 URIs when built with one crypto library ''(e.g. GnuTLS)'' but doesn't when built with another ''(e.g. OpenSSL)'', then we would prefer the package to be built with GnuTLS. That's true of the Open''''''''''Connect VPN client, for example.

For OpenVPN, all we really need to do now that it's fixed upstream is ensure that its Build''''''''''Requires include "pkgconfig(p11-kit-1)", since that means it'll find p11-kit-proxy.so and use that as the default provider.

I think wpa_supplicant doesn't need anything other than to be updated to v2.4 which was released in March, and contains my fixes.

I'm struggling to find ''generic'' examples which are actually going to be useful, other than just the advice to "''ask dwmw2''".

Basically we ask for examples or more explanation or whatever because we want to make sure that they answer the fundamental question:

Does my package, or the package I'm reviewing, meet the guidelines?

I see you've tried to answer that in the help section, though for most package reviewers I have a feeling that still isn't going to help too much. We were asking for examples because we'd hoped they might be instructive. If there's just isn't any generic example, then fine, but I suspect that a whole lot of this is going to come down to "ask dwmw2". I guess a tracker ticket that can be used to block reviews when there's a question might be useful.

Also, wasn't there this big effort to switch the entire distro over to NSS? I know it stalled out, but preferring gnutls over the other options now is a pretty big reversal.

I can try to put together a ''"how to test"'' based partly on the ''"how to use PKCS#''''''''''11"'' page at http://www.infradead.org/openconnect/pkcs11.html -- although I'll need to add instructions on how to generate/import a cert for testing. Which is painful since GNOME keyring seems to be broken in F22 for PKCS#''''''''''11 ''(as well as GPG and SSH)''.

As for NSS, that is entirely PKCS#''''''''''11-based anyway, so it can be fixed. We just need to make sure the right modules are being loaded, and add a function to make it parse the RFC7512 URIs.

I've updated ''(well, mostly rewritten)'' the draft at https://fedoraproject.org/wiki/PackagingDrafts/PKCS11 so it should hopefully be a lot more understandable.

It think it might also be useful to change the title to 'SSL Certificates' rather than 'PKCS#''''''''''11'.

I've also provided a first version of the 'how to test' wiki page, at https://fedoraproject.org/wiki/PackageMaintainers/PKCS11

As discussed at the meeting, the draft is renamed to https://fedoraproject.org/wiki/PackagingDrafts/SSLCertificateHandling

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-05-07/fpc.2015-05-07-16.01.txt):

• 480 Packaging guidelines for consistent PKCS#11 usage (geppetto,

  
  16:10:04)
• LINK: https://fedorahosted.org/fpc/ticket/480 (geppetto, 16:10:04)
• LINK: https://bugzilla.redhat.com/showdependencytree.cgi?id=PKCS11
  (dwmw2, 16:22:30)
• ACTION: Packaging guidelines for consistent PKCS#11 usage (+1:5,
  0:0, -1:0) (geppetto, 16:34:33)

Announcement text:

New guidelines for the consistent usage of SSL certificates by applications have been added.
* https://fedoraproject.org/wiki/Packaging:SSLCertificateHandling
* https://fedorahosted.org/fpc/ticket/480