Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Steps to a stable 7.0.0 #290

Closed
16 tasks done
ionut-arm opened this issue Nov 15, 2021 · 19 comments
Closed
16 tasks done

Steps to a stable 7.0.0 #290

ionut-arm opened this issue Nov 15, 2021 · 19 comments
Labels
large Effort label

Comments

@ionut-arm
Copy link
Member

ionut-arm commented Nov 15, 2021

Since we're currently in an alpha release (yet again) it would be good to know what we'd like to achieve before we can tag a stable release. Our focus right now is to remove all not-abstracted FFI types from the tss-esapi interface, replacing them with types that we have more control over.

FFI types still present in the Context interface (not going to link to where they appear, a simple search through the repo should be enough for that):

Another type that currently uses other FFI types in its interface is CapabilityData. The types:

Other bits of work:

I was also wondering about changing a few other things, please list any other ideas/concerns below:

  • Some key-bits types seem redundant, for example Sm4KeyBits can only have one value. I wonder if it wouldn't be better to just remove the type completely and have a "default" implementation that produces the correct FFI values wherever they're needed to replace the current conversions
  • For structures that can be built using ...Builder structures, we should either document this or create a method on the type to get a new builder, something like pub fn builder() -> ... ( Add builder methods and move NvPublic #316 )
@ionut-arm ionut-arm added the large Effort label label Nov 15, 2021
@ionut-arm ionut-arm pinned this issue Nov 16, 2021
@ionut-arm
Copy link
Member Author

@rshearman - Do you require any specific features in the upcoming release (more specifically, TPM2_Certify)? We can, of course, release extra functionality in a future minor release, but I'm not sure if that's relevant to you at all (i.e. if you use crates.io for dependency management, or if git dependencies are good enough).

@rshearman
Copy link
Contributor

It would be good to have TPM2_Certify in the upcoming release, but I'm decoupled from the tss-esapi release cycle. In other words, it would also be fine to have this in a future minor release.
There's nothing else I can think of that I would need in the near future.

@ionut-arm
Copy link
Member Author

@Superhepper - have you, by any chance, started working on TPM2B_SENSITIVE? Plan on starting that tomorrow, if you're not already on it.

@Superhepper
Copy link
Collaborator

Nah I have not started any work on it. I plan to work on the issue with tagged PCR property list

@ionut-arm
Copy link
Member Author

Cool, I've raised #306 to cover the TPM2B_SENSITIVE stuff. I'll have a look at places where we could change references to full ownership in method interface.

@ionut-arm
Copy link
Member Author

@Superhepper - CapabilityData still has TPM2_ECC_CURVE and TPMA_CC to abstract, are you looking at either of them?

@Superhepper
Copy link
Collaborator

Right now I am working with TPMA_CC.

@ionut-arm
Copy link
Member Author

Will do the ECC_CURVE then. I assume that's the last of it? Have you seen anything else?

@Superhepper
Copy link
Collaborator

No, I usually add stuff if a find things a long the way.

@ionut-arm
Copy link
Member Author

After #316 is merged are we clear to release a 7.0.0, or is there some other stuff to be done?

@Superhepper
Copy link
Collaborator

I maybe want to add the compilation bug for PcrSlot. But if people need a released major version rather soon. I think we can make a release without it.

@ionut-arm
Copy link
Member Author

If we can get that fix in next week that would be nice, but otherwise it's not a breaking change, I think, so we can release it as a bugfix update, not even a minor bump.

@Superhepper
Copy link
Collaborator

Yeah, just say the release will come on Friday next week. If it makes it, it makes it otherwise it will be added later.

@ionut-arm
Copy link
Member Author

@puiterwijk @lkatalin @rshearman
Please be advised, we're planning to release a new stable version of the tss-crate soon. If you'd like to test any parts of the crate, or to give any feedback on the interface please do so within the next few days.

@lkatalin
Copy link

lkatalin commented Feb 3, 2022

Thanks for the heads up @ionut-arm ! I just ran a test and it seems fine for us with Keylime.

@ionut-arm
Copy link
Member Author

I've released a 7.0.0-beta.1 version of the tss-crate, the stable release will go out next week if no issues are reported until then!

@rshearman
Copy link
Contributor

I've updated our application to use 7.0.0-beta.1 and in the course of that I ran into #322. The only other thing I noticed is that it would be nice if EccCurveIdentifier derived Hash, but that's something that can be easily done later.

@ionut-arm
Copy link
Member Author

ionut-arm commented Feb 8, 2022

I've just released and tagged tss-esapi-7.0.0-beta.2 with the changes requested above by @rshearman

@ionut-arm
Copy link
Member Author

ionut-arm commented Feb 15, 2022

The 7.0.0 stable version has been released and tagged! 🎉 Please let us know if any issues surface, so we can fix them right away!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
large Effort label
Projects
None yet
Development

No branches or pull requests

4 participants