Retiring TokenD in favor of Universal Binaries (ARM/Intel)

[frankmorgner]

Problem Description

We will need to support the new ARM-based silicon from Apple in the near future. This is best handled with universal binaries (a.k.a. fat binaries), that contain both, 64-bit Intel and ARM executables. We have some experience with this due to the change from 32 bit to 64 bit applications, so I don't expect any surprises. However, the new architecture requires building with Xcode 12.

Currently, the last working version of Xcode to build TokenD is 9.4 (specifically TokenD doesn't compile with Xcode 12). This would make building Universal binaries along with (non-universal) TokenD binaries quite complicated.

Proposed Resolution

I think the best way to handle this is to move forward and retire TokenD in favor of the CryptoTokenKit. This would raise the minimum requirement for macOS to 10.12.

As far as I know, Apple has ended the support of macOS 10.12 Sierra in October 2019. This means that all supported versions (10.13 and later) are capable of handling CryptoTokenKit. Hence, users with macOS that has not reached end of life should be fine with this change.

However, I'd like to know if there are some users that still need (a seperate?) build of TokenD for older versions...

[mouse07410]

Based on the posts on other forums, it appears that some users indeed still use MacOS older than Sierra.

I recommend keeping OpenSC.tokend as a separate build. It may need to pull a specific version/tag of OpenSC.

Speaking of CTK - I can successfully build OpenSC with CTK instead of PSCS, but the resulting executables like pkcs11_tool fail to even detect the tokens, let alone do anything useful with them. There's an open issue, at least a year old.

[frankmorgner]

I'm not sure what issue you're referring to, but rc1, rc2 and also the release I'm going to make today, does contain a CTK extension along with pkcs11-tool (/Applications/Utilities/OpenSCTokenApp.app/Contents/PlugIns/OpenSCToken.appex/Contents/MacOS/pkcs11-tool), which is working (note that it's statically linked to OpenSC to comply with app sandboxing). Maybe you have a codesigning problem. But let's keep this in a seperate ticket.

Back to the original question, let's be honest that using an outdated version of macOS with a security token makes no sense. Anyway, the last feedback I got was when 0.20.0 was released. Maybe we can get some update here.

[mouse07410]

You have a point regarding old OS and security tokens.

In any case, the existing build scripts and such should work with those OS...

So, retiring it from the current builds sounds reasonable. I stopped using Tokend since Mojave.

[rstocks]

As far as I know, Apple has ended the support of macOS 10.12 Sierra in October 2019. This means that all supported versions (10.13 and later) are capable of handling CryptoTokenKit. Hence, users with macOS that has not reached end of life should be fine with this change.

I think that gives you the answer: If all current supported OSX/macOS releases implement CryptoTokenKit, then CryptoTokenKit should be the way forward. If someone is still running >= 10.12, they'll just have to use a release of OpenSC that still supports TokenD.

[Jakuje]

@frankmorgner what is the status of this issue. There was recently related discussion in #2610, but I do not understand how things work in mac and if that PR solves also this issue, if it was already solved or if that is completely different issue.

[mouse07410]

I see no relation between retiring TokenD and building Universal binaries.

TokenD cannot be build with Xcode newer than v9, so it's "naturally" retired. Unless we want to support really old OS.

Universal binaries do not make sense, compared to building and packaging separate binaries for each platform. On x86 machine I don't care to waste my (limited!) disk space on ARM binaries. And vs. versa.

[frankmorgner]

We can close this issue. Time has shown that nobody seems to be using TokenD anymore. Nevertheless, it's nice to have the flexibility in the build scripts if it doesn't cost anything.