Open ionut-arm opened 6 months ago
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).
Make serde an optional dependency.
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.
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#L18It'd be nice to fix that before releasing 8.0.
That will probably be fixed when #505 is merged.
That will probably be fixed when #505 is merged.
Hm... it doesn't seem so from my tests:
tss-esapi={ version = "8.0.0-alpha", git ="https://github.com/parallaxsecond/rust-tss-esapi", rev = "refs/pull/505/head" }
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:
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.
It's interesting that the build works on the PR-level but fails here... totally not something I expected :/
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.
Thank you :pray:
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.
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:
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.
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
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). :/
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?
$ 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:
I am not sure when I will have time to look at it. But I will investigate.
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
@wiktor-k I'll take a look today :)
@wiktor-k @Superhepper
So, I took a look:
TPMU_SENSITIVE_CREATE
failure was being triggered when TSS_VERSION > 4.0.0
as indicated in here and here.TSS_VERSION = 3.2.2
as indicated here.TSS_VERSION
on the docker image I was using.TSS_VERSION > 4.0.0
.I was able to have a successful build with:
rust-tss-esapi$ docker build -t ubuntucontainer tss-esapi/tests/ --build-arg TPM2_TSS_VERSION=3.2.2 --file tss-esapi/tests/Dockerfile-ubuntu
tpm-box$ docker run -v $(pwd):/tmp/tpm-box -w /tmp/tpm-box -it ubuntucontainer
cargo clean
(This is just in case you have abn old build there that would cause issues).cargo check
Hope this helps?
I'm adding a new task for the stabilization work: fixing the failing doc build.
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.
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.