Sho Nakatani

Similarly cannot detect `#![cfg_attr(all(not(feature = "std"), not(test)), no_std)]` https://github.com/mvdnes/spin-rs/blob/master/src/lib.rs#L1

@alcore Thank you. I thought XChaCha20 nonce is large enough so that; > the probability can be astronomically low but > The point is to guarantee that a reused nonce...

https://libsodium.gitbook.io/doc/padding

such test are difficult to write. Close in favor of #50

re-open E2E test with artifact will do. See: https://github.com/apllodb/apllodb/blob/main/.github/workflows/fuzzing-test.yml Don't forget to rm TODO comment: https://github.com/laysakura/serde-encrypt/blob/0c8ddf9c33aefe21ba6a4a53b93ab9f8dd539238/tests/feat_serde_encrypt_public_key_different_cipher_from_same_plain.rs#L38:L38

https://github.com/LayerXcom/anonify/issues/612 と方針にコンフリクトがある。 mainマージの際のCIが軽くなるし、azure認証不要になるという意味では #612 に軍配。 一方で anonify repo と base-* との関連性の薄さから、疎結合にするという意味では別repoが良いと思う。 別repoでかつGHCRならlooks ｶﾝﾍﾟｷ

[serde-encrypt](https://github.com/laysakura/serde-encrypt) と [serde-encrypt-sgx](https://github.com/laysakura/serde-encrypt-sgx) を作って得た知見 ## TL;DR - Rust SGX SDKでビルドするcrate（以下、「SGXなcrate」）はリポジトリを分けたほうが良い。ただし path 依存しかしない（git依存不要）な場合は同一リポジトリで [cargo workspace から exclude](https://doc.rust-lang.org/cargo/reference/workspaces.html#the-workspace-section) する方式でも良い。 - いずれにせよSGX固有のコードはcrateが分かれるので、 `sgx` feature flag は不要。 - 「SGXなcrateから使われるcrate」は、 `#![no_std]` で作っておいて、Rust SGX SDKでのビルドもCIしておく。SGX以外からも使われるなら `std`...

> sgx/stdが共通のコードベース使っている部分どうするか これは、共通のコードベースを非SGXなcrateとして > 「SGXなcrateから使われるcrate」は、 #![no_std] で作っておいて、Rust SGX SDKでのビルドもCIしておく。SGX以外からも使われるなら std feature flag を提供して #![cfg_attr(not(feature = "std"), no_std)] してもOK。 の状態にしておくとよきだと思います。 > sgx/stdにまたがるPRどうすべきか（std側のテストsgxに依存しpush&cargo updateしないとテスト試せないなど まず、個人的にはsgxなクレートはだいぶ疎結合に作っておくべきだと思っています。sgxなクレートだけが入ったリポジトリで、結合試験まできっちりやる。その後で非sgxなクレートを書き始める、という形。 これが結構苦しいのであれば、git subtreeを使う形ならcargoのgit依存の制約も突破しつつ同一PRで一緒くたに見れるかもしれません。自信はない。

あーstd使うかsgx_tstdを使うかでやってるってことですね。 その場合は自分の提案的には SGXなクレートとして別リポに逃がす ことになってしまい、非SGXなクレートからはかなり使いづらくなってしまいますね。 実際にコード見て、本質的にはstd使わずに頑張れるものは頑張っていくという対応がありえますが、頑張れるものの割合次第ですね。 幸い最近no_std職人力が上がってきたので、時間あるときに見てみます。 --- subtreeは新卒の職場でやってたのですが、git操作が複雑になりそれはそれでストレスだしオペミス増えるんですよね... やはりおすすめは、非SGXな部分は「SGXか何か知らんけどこういうインターフェイスで計算してくれるもの」ってノリのtraitに依存して、テストコードではmock実装する形です。 参考までに、serde-encrypt-core というクレートはSGXにも通常のserdeにも非依存で切り出していて、シリアライザブル的なtraitにめちゃ依存してます。 そのtraitを実装しているのが、普通のserde依存の serde-encrypt.と、serde-sgx に依存した serde-encrypt-sgx です。 serde-encrypt-core 層のテストでは、新たにmockを作ることなく、serde-encrypt 層からテストしています。 これはたまたま、非SGXなインプリがモックではなく直接ユースケース持っていたからですね。

@gitmalong Not directly supported. You may achieve it by the following workaround, for example. ```rust struct DatabaseConfig { hostname: String, user: String, password: EncryptedMessage, // https://docs.rs/serde-encrypt/latest/serde_encrypt/struct.EncryptedMessage.html } #[derive(Serialize, Deserialize)] struct...