laysakura / serde-encrypt

🔐 Encrypts all the Serialize.
Apache License 2.0
175 stars 6 forks source link

integration with serde-sgx #14

Closed laysakura closed 3 years ago

laysakura commented 3 years ago

https://github.com/mesalock-linux/serde-sgx/

laysakura commented 3 years ago
[dependencies]
serde = {version = "1.0", default-features = false}

[dev-dependencies]
#serde = {version = "1.0", default-features = false, features = ["derive", "alloc"]}# alloc for Vec, String
serde = {package = "serde", git = "https://github.com/mesalock-linux/serde-sgx.git", default-features = false, features = ["derive"]}

error: failed to parse manifest at `/Users/sho.nakatani/.ghq/src/github.com/laysakura/serde-encrypt/Cargo.toml`

Caused by:
  Dependency 'serde' has different source paths depending on the build target. Each dependency must have a single canonical source path irrespective of build target.
The terminal process "cargo 'test', '--package', 'serde-encrypt', '--test', 'feat_serde_sgx', '--', 'test_serde_sgxprimitive_type_fixed_len', '--exact', '--nocapture'" terminated with exit code: 101.
laysakura commented 3 years ago

serde-encrypt relies on serde::{Serialize, Deserialize} as an interface.

If the user of the library is using serde_sgx::{Serialize, Deserialize} because they are using SGX, then the interface that depends on serde_sgx::* must also be exposed.

If we include serde-sgx in your dependencies and compile, we will get the alloc::AllocRef problem, and then we have to use old rustc.

Then I think the dependency on serde-sgx must be separated from serde-encrypt itself, otherwise the maintenance cost for sgx will be high (e.g. --all-features will not be available).

It seems to be a good idea to create the following dependency.

serde-encrypt-core  ----+----> serde-encrypt (SGX free)
                        |
                        +-----> serde-encrypt-sgx (separate workspace to keep --all-features healty)