Bug 255058 - [NEW PORT] security/pkcs11-tools: a set of tools for managing objects on PKCS11 cryptographic tokens.
Summary: [NEW PORT] security/pkcs11-tools: a set of tools for managing objects on PKCS...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Yuri Victorovich
URL: https://github.com/Mastercard/pkcs11-...
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-14 16:39 UTC by Eric Devolder
Modified: 2021-04-20 18:38 UTC (History)
3 users (show)

See Also:


Attachments
the attachment contains the addition to the ports tree. (4.75 KB, patch)
2021-04-14 16:39 UTC, Eric Devolder
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Devolder 2021-04-14 16:39:58 UTC
Created attachment 224110 [details]
the attachment contains the addition to the ports tree.

pkcs11-tools is a toolkit containing a bunch of small utilities to perform key management tasks on cryptographic tokens implementing a PKCS#11 interface. It features a number of commands similar to the unix CLI utilities, such as ls, mv, rm, od, and more. It also has specific commands to generate keys, generate CSRs, import certificates and other files, in a fashion compatible with most implementations, including both IBM and Oracle JVMs.
Comment 1 Daniel Engberg freebsd_committer 2021-04-15 15:16:36 UTC
Is there a reason why we can't use upstream release archive as suggested by Porters Handbook?
https://github.com/Mastercard/pkcs11-tools/releases/tag/v2.3.0
Comment 2 Eric Devolder 2021-04-16 03:52:06 UTC
(In reply to daniel.engberg.lists from comment #1)

Hi Daniel,

The archive can't be used directly as is, because the project depends on git submodules, that are not included when using the upstream archive directly (the upstream archive on GitHub is not a git project).

That's why I had to use GH_TUPLE instead, and add some post-extract rules in the Makefile to ensure that submodules are fetched along.

I took examples from several other ports, but let me know if anything seems wrong or should be laid out differently.
Comment 3 Yuri Victorovich freebsd_committer 2021-04-19 00:23:34 UTC
Committed with some changes.
Changes are to use currently chosen OpenSSL implementation.

Thank you for your contribution.
Comment 4 commit-hook freebsd_committer 2021-04-19 00:24:22 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=a6d0c2f4e2167b4da1607f0b018a0e3985b7e729

commit a6d0c2f4e2167b4da1607f0b018a0e3985b7e729
Author:     Yuri Victorovich <yuri@FreeBSD.org>
AuthorDate: 2021-04-19 00:21:30 +0000
Commit:     Yuri Victorovich <yuri@FreeBSD.org>
CommitDate: 2021-04-19 00:23:37 +0000

    New port: security/pkcs11-tools: Tools for managing PKCS11 cryptographic tokens

    PR:             255058
    Submitted by:   Eric Devolder <eric.devolder@gmail.com>

 security/Makefile                                  |  1 +
 security/pkcs11-tools/Makefile (new)               | 40 ++++++++++++++++
 security/pkcs11-tools/distinfo (new)               |  7 +++
 .../pkcs11-tools/files/patch-configure.ac (new)    | 56 ++++++++++++++++++++++
 security/pkcs11-tools/pkg-descr (new)              |  8 ++++
 security/pkcs11-tools/pkg-plist (new)              | 27 +++++++++++
 6 files changed, 139 insertions(+)
Comment 5 Eric Devolder 2021-04-20 04:11:36 UTC
Hi Victor,

thanks a lot for the commit, and the incorporation into the ports!

I am however a bit concerned with the patch that is removing port dependency upon OpenSSL 1.1.1e, and disables dynamic linking towards ports-installed OpenSSL. It was specifically added to the Makefile to ensure that the linking error you met does not happen:

# fails to find symbol in the shared library: ld: error: undefined symbol: EVP_PKEY_meth_get_digestsign

I have never tested the toolkit against LibreSSL and cannot guarantee it works.

- is there a specific policy that forbid restricting, in the port, to one specific flavour/version of OpenSSL?
- the resulting binary is statically linked to libcrypto, is that also a common practice?
- When building on my system (FreeBSD 13, not from Poudriere), It seems that the package is using libcrypto from the base system (instead of the port version). Is this intentional?


Kind regards,
Comment 6 Yuri Victorovich freebsd_committer 2021-04-20 04:28:22 UTC
(In reply to Eric Devolder from comment #5)

Hi Eric,

openssl port can't be directly linked to because only one OpenSSL can be installed on one machine, and this id defined in /etc/make.conf

The only available option is to work with the base OpenSSL.

> - is there a specific policy that forbid restricting, in the port, to one specific flavour/version of OpenSSL?

No, but such limiting should be done based on the evidence that it fails with this specific implementation.

> - the resulting binary is statically linked to libcrypto, is that also a common practice?

There should be no practical difference between linking to a static and a shared library. In this case there was some issue with linking due to symbol visibility, and static library allows to work around this problem.

> - When building on my system (FreeBSD 13, not from Poudriere), It seems that the package is using libcrypto from the base system (instead of the port version). Is this intentional?

Yes, only base SSL can be used.

Hope this helps.

Best,
Yuri
Comment 7 Eric Devolder 2021-04-20 09:41:15 UTC
Hi Yuri,

Thanks a lot for your kind reply, and for setting the context. I didn't realize the issue with alternatives to OpenSSL.


I have checked if I could build the toolkit against LibreSSL (I guess that's the only alternative to OpenSSL?). It definitely fails:

$ make
Making all in gl
make  all-recursive
Making all in lib
make  all-am
  CC       libp11_la-pkcs11_cat.lo
pkcs11_cat.c:94:7: error: use of undeclared identifier 'EVP_PKEY_X25519'
        case EVP_PKEY_X25519:
             ^
pkcs11_cat.c:95:7: error: use of undeclared identifier 'EVP_PKEY_ED25519'
        case EVP_PKEY_ED25519:
             ^
pkcs11_cat.c:99:7: error: use of undeclared identifier 'EVP_PKEY_X448'
        case EVP_PKEY_X448:
             ^
pkcs11_cat.c:100:7: error: use of undeclared identifier 'EVP_PKEY_ED448'
        case EVP_PKEY_ED448:
             ^
4 errors generated.


As far as I can see, LibreSSL has no support for Edwards curves. Strictly speaking, it means that LibreSSL cannot be used by the toolkit as support for Edwards curves is required - is this sufficient to justify the restriction I put, that you lifted?

For future releases of pkcs11-tools, I'll anyway see if it can support LibreSSL as well, with the limitation of dropping support for Edwards curves.

You shouldn't have encountered the linking issue, that's kind of worrisome. This function is normally present on OpenSSL 1.1.1e and above. Any possibility that the .so version is different from the .a on your host/jail (unlikely on the base system, but something you could check anyway?) How could I reproduce that issue on my side?

I guess my overall concern is to have to rely on the base packages and libraries instead of those from the port, for the crypto.


Thank you,
Comment 8 Yuri Victorovich freebsd_committer 2021-04-20 09:58:46 UTC
(In reply to Eric Devolder from comment #7)

Eric,

I restored the restriction for libressl.

As far as the link issue with the shared library - I will look again tomorrow in-depth. This is possibly a bug in the base OpenSSL.


Yuri
Comment 9 Eric Devolder 2021-04-20 11:40:49 UTC
Thank you, Yuri.

Not sure if you have committed your changes yet to the repository. I haven't checked out the tree yet, I'm assuming you don't post all your patches in the ticket.

I have received a couple of failed builds notifications from the package build server, on top of 11.4 ( amd64 and i386). These are all related to the version of OpenSSL available on the base system (likely <1.1.1e). Restoring to the initial setup should allow the build to pass, hopefully.

http://beefy10.nyi.freebsd.org/data/114i386-default/338d8ba0f777/logs/pkcs11-tools-2.3.0.log

http://beefy9.nyi.freebsd.org/data/114amd64-default/338d8ba0f777/logs/pkcs11-tools-2.3.0.log

Regards,

Eric
Comment 10 Yuri Victorovich freebsd_committer 2021-04-20 18:17:25 UTC
(In reply to Eric Devolder from comment #9)

I'll take things one by one.

There is a bug in the base SSL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255277 (Base OpenSSL is missing the symbol EVP_PKEY_meth_get_digestsign in /usr/lib/libcrypto.so) that affected the port.

The workaround line in the port should correct the problem for the port.
Comment 11 Yuri Victorovich freebsd_committer 2021-04-20 18:38:17 UTC
(In reply to Eric Devolder from comment #9)

> I have received a couple of failed builds notifications from the package build server, on top of 11.4 ( amd64 and i386).

I marked the port broken on 11 with base OpenSSL because required symbols are missing.

Unfortunately switching to the port OpenSSL is not an option due to policy restriction.

11 is old and people should migrate to newer versions anyway.


Please let me know if you have any further concerns.


Regards,
Yuri