v8.0.0 stabilization work

[ionut-arm]

This is a placeholder issue for all work that remains to be done towards a v8 release of tss-esapi.

• [x] TpmsContext will be moved into structures and have it's name changed to SavedTpmContext. #507
• [ ] Update Rust edition to 2021 and update all dependencies. #516
• [ ] Update minimum supported Rust version.
• [x] Make serde an optional dependency. #525
• [ ] Fix doc build issue

Please report below any requests for changes or features.

[Superhepper]

Increase minimum supported Rust version Increase minimum supported tpm2-tss version (To at least 3.0 but ideally I would like to see something greater. Because this goes hand in hand with a the work with TpmsContext but it requires a type added in 3.1.0).

[Superhepper]

Make serde an optional dependency.

[wiktor-k]

I'm not sure if it's tracked somewhere else independently but I had to use generate bindings feature to get the first alpha to compile in my crate: https://github.com/wiktor-k/tpm-box/blob/main/Cargo.toml#L18

It'd be nice to fix that before releasing 8.0.

[Superhepper]

I'm not sure if it's tracked somewhere else independently but I had to use generate bindings feature to get the first alpha to compile in my crate: https://github.com/wiktor-k/tpm-box/blob/main/Cargo.toml#L18

It'd be nice to fix that before releasing 8.0.

That will probably be fixed when #505 is merged.

[wiktor-k]

That will probably be fixed when #505 is merged.

Hm... it doesn't seem so from my tests:

1. clone tpm-box
2. change the dep line to: tss-esapi={ version = "8.0.0-alpha", git ="https://github.com/parallaxsecond/rust-tss-esapi", rev = "refs/pull/505/head" }
3. cargo check

It gives me:

    Checking tss-esapi v8.0.0-alpha (https://github.com/parallaxsecond/rust-tss-esapi?rev=refs/pull/505/head#1451c519)
error[E0432]: unresolved import `crate::tss2_esys::TPMU_SENSITIVE_CREATE`
   --> /home/wiktor/.cargo/git/checkouts/rust-tss-esapi-acac77377da9bd28/1451c51/tss-esapi/src/structures/buffers.rs:364:17
    |
364 |             use crate::tss2_esys::TPMU_SENSITIVE_CREATE;
    |                 ^^^^^^^^^^^^^^^^^^---------------------
    |                 |                 |
    |                 |                 help: a similar name exists in the module: `TPMS_SENSITIVE_CREATE`
    |                 no `TPMU_SENSITIVE_CREATE` in the root

The commit referenced in the output is the same as in your PR... or maybe I'm holding it wrong somehow? :thinking:

[Superhepper]

Hrmm that is not what I expected. Well we can rather easily determine where the problem lies by looking at the generated code and see if the type exists.

[wiktor-k]

It's interesting that the build works on the PR-level but fails here... totally not something I expected :/

[Superhepper]

It can be that I made a mistake so it always generates the bindings even when it should not. I will have to look into this.

[wiktor-k]

Thank you :pray:

[Superhepper]

Yup it is my mistake. Because I forgot to change a parameter in the test script that determines what flags to enable. So it will always generate bindings and never use the ones commited.

[wiktor-k]

Yup it is my mistake. Because I forgot to change a parameter in the test script that determines what flags to enable. So it will always generate bindings and never use the ones commited.

Well... then it's quite funny because appending features = ["generate-bindings"], in my Cargo.toml makes it work on my end :sweat_smile:

[Superhepper]

Yup it is my mistake. Because I forgot to change a parameter in the test script that determines what flags to enable. So it will always generate bindings and never use the ones commited.\n\nWell... then it's quite funny because appending features = [\"generate-bindings\"], in my Cargo.toml makes it work on my end 😅

No, that is expected. Because in that PR all that is tested is that "generate-bindings" works. The code is never tested using the committed bindings due to my mistake.

[Superhepper]

Yup it is my mistake. Because I forgot to change a parameter in the test script that determines what flags to enable. So it will always generate bindings and never use the ones commited.\n\nWell... then it's quite funny because appending features = ["generate-bindings"], in my Cargo.toml makes it work on my end 😅

No, that is expected. Because in that PR all that is tested is that "generate-bindings" works. The code is never tested using the committed bindings due to my mistake.

This should be fixed now. Please try again @wiktor-k

[wiktor-k]

I've updated via cargo update:

Updating tss-esapi v8.0.0-alpha (https://github.com/parallaxsecond/rust-tss-esapi?rev=refs/pull/505/head#1451c519) -> #8ab0de2f
    Updating tss-esapi-sys v0.5.0 (https://github.com/parallaxsecond/rust-tss-esapi?rev=refs/pull/505/head#1451c519) -> #8ab0de2f

And it still fails:

error[E0432]: unresolved import `crate::tss2_esys::TPMU_SENSITIVE_CREATE`
   --> /home/wiktor/.cargo/git/checkouts/rust-tss-esapi-acac77377da9bd28/8ab0de2/tss-esapi/src/structures/buffers.rs:364:17
    |
364 |             use crate::tss2_esys::TPMU_SENSITIVE_CREATE;
    |                 ^^^^^^^^^^^^^^^^^^---------------------
    |                 |                 |
    |                 |                 help: a similar name exists in the module: `TPMS_SENSITIVE_CREATE`
    |                 no `TPMU_SENSITIVE_CREATE` in the root

Interesting that it's just a one letter "typo" (S <-> U). :/

[Superhepper]

Hrmm I need to investigate this further. Why is this not failing in vi then. They use the committed bindings. What version is installed on the system you build?

[wiktor-k]

$ pkg-config --modversion tss2-esys
4.0.1

Are you able to reproduce building tpm-box locally using these instructions? Maybe it's something on my end but previous versions worked fine :thinking:

[Superhepper]

I am not sure when I will have time to look at it. But I will investigate.

[wiktor-k]

I am not sure when I will have time to look at it. But I will investigate.

Wait a minute let me ask some people that for sure have plenty of time :smirk: : @ionut-arm, @tgonzalezorlandoarm could you help check if you also get the same error as I do? Just follow this simple 3 step instruction: https://github.com/parallaxsecond/rust-tss-esapi/issues/495#issuecomment-1963563114

[tgonzalezorlandoarm]

@wiktor-k I'll take a look today :)

[tgonzalezorlandoarm]

@wiktor-k @Superhepper

So, I took a look:

1. I think "version" was missing for "package" on the Cargo.toml of tpm-box. I put a dummy version.
2. I got your error.
3. I then realized that the TPMU_SENSITIVE_CREATE failure was being triggered when TSS_VERSION > 4.0.0 as indicated in here and here.
4. And the bindings were generated TSS_VERSION = 3.2.2 as indicated here.
5. So basically it was a matter of the TSS_VERSION on the docker image I was using.
6. I was building the docker image as imposed by the ci.yml here, which uses TSS_VERSION > 4.0.0.

I was able to have a successful build with:

1. rust-tss-esapi$ docker build -t ubuntucontainer tss-esapi/tests/ --build-arg TPM2_TSS_VERSION=3.2.2 --file tss-esapi/tests/Dockerfile-ubuntu
2. tpm-box$ docker run -v $(pwd):/tmp/tpm-box -w /tmp/tpm-box -it ubuntucontainer
3. cargo clean (This is just in case you have abn old build there that would cause issues).
4. cargo check

Hope this helps?

[ionut-arm]

I'm adding a new task for the stabilization work: fixing the failing doc build.

[Superhepper]

I'm adding a new task for the stabilization work: fixing the failing doc build.

That thing is really strange. If I have understood things correctly then the DEP_ environment variables are produced by cargo when the sys crate prints out link-information (e.g. println!("cargo:rustc-link-lib={}", lib_name);). So it seems as the build script in the sys crate have not been run at all.