Open dwmw2 opened 6 years ago
@jejb What do you think about this idea ? I don't want to name-clash without us both agreeing...
Downside is of course that you cannot work with both simultaneously...
@dwmw2 @jejb What shall we do about the engine name ? I want to ship the first release soon, so I need this final.
Use "tpm2". Didn't I already start pointing out applications that work with that, and never try "tpm2-tss"?
How do we do this in a backwards compatible way ?
Should Just Work™ since right now, any application which wants to get this right, at the moment, needs to try both tpm2tss
and tpm2
as engine names anyway.
e.g.
tpm2tss
anyway)Hm, curl still doesn't have TPMv2 support. Must go poke at that again....
I was wondering if/how we can make the transition easy for people that use tpm2tss as engine in a config file such as nginx.
Will they have to edit their config files or will it just work (tm) ?
An how does @jejb feel about this ?
You could experiment with making it work with both engine names, perhaps using a symlink and then internally registering two engines? I wouldn't bother though.
Any software that ever relied on the user/admin hard-coding an engine name in a config file like that was Doing It Wrong. The code should have spotted the PEM headers for the TPM keys and invoked the engine automatically, like the examples I showed above. And right now, should be trying both engine names.
It will take some days before I have time to experiment with this though...
Let's not tell applications that if they have a PEM file with
-----BEGIN TSS2 PRIVATE KEY-----
they need to try bothtpm2
andtpm2tss
engines to see which one happens to be present.Let's instead just make them both install as
tpm2
. Distributions can use "alternatives" to allow for one or the other to take that engine name, as they see fit.