You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 24, 2020. It is now read-only.
... this is just deciding to build with TPM based on whether the header is present; I'm wondering if we should instead make it a ./configure flag. (This arguably collapses into my question about error handling; if that degrades safely in the no-tpm-actually-present-on-running-system case, then maybe we should just ALWAYS build with TPM?)
I don't have strong feelings - I think there's maybe a stronger argument for a disable flag than an enable one?
Following our "secure by default" philosophy, I'm inclined to agree - we should consider making tpm the default build behaviour (requiring those libs, rather than autodetecting them), and providing an opt-out option to configure.
The text was updated successfully, but these errors were encountered:
Capturing discussion from #1775 (diff) - I wrote:
@mjg59 wrote:
Following our "secure by default" philosophy, I'm inclined to agree - we should consider making tpm the default build behaviour (requiring those libs, rather than autodetecting them), and providing an opt-out option to configure.
The text was updated successfully, but these errors were encountered: