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.
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
(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.
Committed with some changes. Changes are to use currently chosen OpenSSL implementation. Thank you for your contribution.
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(+)
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,
(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
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,
(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
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
(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.
(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