DemesneGH commented on code in PR #221: URL: https://github.com/apache/incubator-teaclave-trustzone-sdk/pull/221#discussion_r2278714003
########## examples/tls_client-rs/ta/Cargo.toml: ########## @@ -17,38 +17,30 @@ [package] name = "ta" -version = "0.4.0" +version = "0.5.0" authors = ["Teaclave Contributors <dev@teaclave.apache.org>"] license = "Apache-2.0" repository = "https://github.com/apache/incubator-teaclave-trustzone-sdk.git"; description = "An example of Rust OP-TEE TrustZone SDK." edition = "2018" [dependencies] -libc = { path = "../../../rust/libc" } proto = { path = "../proto" } -optee-utee-sys = { path = "../../../optee-utee/optee-utee-sys" } -optee-utee = { path = "../../../optee-utee" } +optee-utee-sys = "0.4.0" +optee-utee = "0.4.0" -# use new ported version -rustls = { git = "https://github.com/DemesneGH/rustls-optee.git";, branch = "0.21.0-optee", features = ["dangerous_configuration"]} -ring = "=0.16.20" -webpki-roots = "0.21" -webpki = "=0.21.0" -sct = "=0.7.0" +rustls_provider = { path = "../../../crates/rustls_provider" } +rustls = { version = "0.23.12", default-features = false, features = ["std"] } +webpki-roots = "1" [build-dependencies] proto = { path = "../proto" } -optee-utee-build = { path = "../../../optee-utee-build" } +optee-utee-build = "0.4.0" [profile.release] panic = "abort" lto = false opt-level = 3 [patch.crates-io] -ring = { git = "https://github.com/DemesneGH/ring-optee.git";, branch = "0.16.20-optee" } - -# Patch optee-utee for rustls -[patch."https://github.com/apache/incubator-teaclave-trustzone-sdk.git";] -optee-utee = { path = "../../../optee-utee" } +getrandom = { git = "https://github.com/DemesneGH/incubator-teaclave-crates.git"; } Review Comment: I think both approaches make sense. I'd prefer the current "port getrandom" approach because: The migration from the current approach to a future upstreamed `getrandom` would require no code changes—developers would simply remove the patch section from `Cargo.toml`. > If possible, I’d like to demonstrate to developers that they can customize the upstream getrandom crate directly with SDK's randomness (with just a few lines of code) It's good to have such demonstration. However, in the OP-TEE context, developers often rely on the same RNG from OP-TEE APIs, I think the need to implement their own RNG is minimal. If there're indeed need for this, we can open a PR then. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@teaclave.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@teaclave.apache.org For additional commands, e-mail: dev-h...@teaclave.apache.org
