Hi @xu-cheng , thanks for your report. I totally agree on every word you mentioned above.
maintain a bunch of forked crates can help us with (1) stability and (2) compatibility and (3) features, and something suffers a lot (1) freshness, (2) security. but overall I slightly intended to maintain an isolated ecosystem. and in production, i believe most products vendor their dependencies and then maintain their vendored sources. on the getrandom issue, i'd say the only doable way is to maintain a fork of getrandom. as you already know, quality of random number is **critical** to Intel SGX enclaves, while it may not mean much to many of other platforms. getrandom lays on the bottom of the entire crate dependency graph and i'd strongly recommend user to maintain their own fork. and i believe hashbrown is a very very special case: std has a built-in hashbrown (v0.9.0 as of today). and one principle you may know is "we should not have 2 different versions of the same library in the same dependency tree". so I'd say if you need hashbrown, first try if you can use the libstd's built-in one. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-teaclave-sgx-sdk/issues/326#issuecomment-800799978
