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

v8.0.0 stabilization work #495

Open
2 of 5 tasks
ionut-arm opened this issue Feb 7, 2024 · 22 comments
Open
2 of 5 tasks

v8.0.0 stabilization work #495

ionut-arm opened this issue Feb 7, 2024 · 22 comments

Comments

@ionut-arm
Copy link
Member

ionut-arm commented Feb 7, 2024

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

Please report below any requests for changes or features.

@ionut-arm ionut-arm pinned this issue Feb 7, 2024
@Superhepper
Copy link
Collaborator

Superhepper commented Feb 7, 2024

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
Copy link
Collaborator

Make serde an optional dependency.

@wiktor-k
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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? 🤔

@Superhepper
Copy link
Collaborator

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
Copy link
Collaborator

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

@Superhepper
Copy link
Collaborator

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
Copy link
Collaborator

Thank you 🙏

@Superhepper
Copy link
Collaborator

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
Copy link
Collaborator

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 😅

@Superhepper
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

$ 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 🤔

@Superhepper
Copy link
Collaborator

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

@wiktor-k
Copy link
Collaborator

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 😏 : @ionut-arm, @tgonzalezorlandoarm could you help check if you also get the same error as I do? Just follow this simple 3 step instruction: #495 (comment)

@tgonzalezorlandoarm
Copy link
Member

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

@tgonzalezorlandoarm
Copy link
Member

@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
Copy link
Member Author

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

@Superhepper
Copy link
Collaborator

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.

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

No branches or pull requests

4 participants