On Fri, 2021-02-19 at 20:24 +0200, Jarkko Sakkinen wrote: > On Wed, Jan 27, 2021 at 11:06:12AM -0800, James Bottomley wrote: > > v15: fix 0day sign issue and add reviews and testeds > > > > General cover letter minus policy bit: > > > > This patch updates the trusted key code to export keys in the ASN.1 > > format used by current TPM key tools (openssl_tpm2_engine and > > openconnect). The current code will try to load keys containing > > policy, but being unable to formulate the policy commands necessary > > to > > load them, the unseal will always fail unless the policy is > > executed > > in user space and a pre-formed policy session passed in. > > > > The key format is designed to be compatible with our two openssl > > engine implementations as well as with the format used by > > openconnect. > > I've added seal/unseal to my engine so I can use it for > > interoperability testing and I'll later use this for sealed > > symmetric > > keys via engine: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/ > > > > James > > > > --- > > > > James Bottomley (5): > > lib: add ASN.1 encoder > > oid_registry: Add TCG defined OIDS for TPM keys > > security: keys: trusted: fix TPM2 authorizations > > security: keys: trusted: use ASN.1 TPM2 key format for the blobs > > security: keys: trusted: Make sealed key properly interoperable > > This is online again in the master branch. > > I've mangled the commits as follows: > > 1. Fixed my emails to jarkko@xxxxxxxxxx. > 2. Adjusted the Makefile, i.e. separate lines for each entry. > 3. Fixed the checkpatch issues. > > I guess we could potentially re-consider this to rc2 pull? With all > the mangling required, did not make sense to include this to the > first pull. The way I usually do this in SCSI, because stuff always happens immediately before the merge window that causes some pull material to be held over, is an early push, which you've done followed by a late push on the Friday before the merge window closes of the rest of the stuff. This is an example from the last but one merge window: https://lore.kernel.org/linux-scsi/fdee2336d2a7eada3749e07c3cc6ea682f8200b3.camel@xxxxxxxxxxxxxxxxxxxxx/ https://lore.kernel.org/linux-scsi/4affd2a9c347e5f1231485483bf852737ea08151.camel@xxxxxxxxxxxxxxxxxxxxx/ Linus seems to be happy with this pattern as long as it's well explained. James
