Opened 8 years ago
Closed 7 years ago
#52431 closed enhancement (wontfix)
opensc @0.16.0: add variant +tokend to install TokenD module
Reported by: | lbschenkel (Leonardo Brondani Schenkel) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.4 |
Keywords: | maintainer haspatch | Cc: | kurthindenburg (Kurt Hindenburg) |
Port: | opensc |
Description
I am submitting a patch that introduces a new +tokend
variant to enable building and installing the OpenSC TokenD module that allows macOS and the Keychain to interface with the smart cards.
The reason for this being a variant and not a new opensc-tokend
port dependent on opensc
(which would be nicer) is because OpenSC does not have a stable API/ABI so any mismatch of libopensc
and the version the TokenD has been built against is likely to cause runtime issues — which is extra disturbing given the fact that the TokenD is a module loaded by the macOS system and could cause system-wide instability.
I also asked in the opensc-devel
mailing list about how to best build TokenD (if as a separate package or not) and I got the following two replies so far (trimmed for brevity):
Frank Morgner:
libopensc's API and ABI has changed in every release I have seen in the past. That's why we are building both packages together https://github.com/OpenSC/OpenSC/blob/master/.travis.yml#L66 and I don't think it makes much sense decoupling them. Additionally, I suppose users are expecting the MacPorts package(s) to be identical to the download release on Github, which also implies building tokend together with libopensc.
Martin Paljak:
It better be +tokend in this wording. Think of OpenSC.tokend like out-of-tree PKCS#11 or Minidriver interface of OpenSC. It could also be bundled inside OpenSC code tree as well (but is not, for historical reasons).
Martin does mention that it is possible to build the TokenD as a separate package, however he still recommends the variant as a first choice.
Note that building them together is exactly how upstream is built, so I replicated the way that the upstream build script works. Since nobody else seems to be building them separately, I believe it is ill-advised to separate the two into different packages which are installed separately and risk making the MacPorts package being vulnerable to API/ABI changes when nobody else is.
I also took the opportunity and did some minor changes in the Portfile that don't affect the way it's built.
I'm not an expert on Portfile creation, so it's possible or even likely that the way I'm building the TokenD here could be improved or simplified. I'm open to any feedback to improve this patch.
Attachments (1)
Change History (5)
Changed 8 years ago by lbschenkel (Leonardo Brondani Schenkel)
Attachment: | opensc.patch added |
---|
comment:1 Changed 8 years ago by lbschenkel (Leonardo Brondani Schenkel)
comment:2 Changed 8 years ago by kurthindenburg (Kurt Hindenburg)
Cc: | khindenburg@… added |
---|
Hi, can you update the patch? The portfile was updated recently and your patch doesn't apply cleanly now.
comment:3 Changed 7 years ago by lbschenkel (Leonardo Brondani Schenkel)
I changed my mind about introducing this. TokenD is a deprecated technology which is likely to be removed. In case OpenSC introduces a new implementation based on CryptoTokenKit then I will consider adding it to MacPorts.
comment:4 Changed 7 years ago by lbschenkel (Leonardo Brondani Schenkel)
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Could somebody review this patch please?