> I found that you introduce some headers, what's the purpose? They are in LGPL > license which are not accepted [1] by the Apache projects. > > [1] https://www.apache.org/legal/resolved.html >
They are system headers. The common/inc folder misses some of the definitions. They could be trimmed to meet the licensing requirement? (I am not an expert with Licensing) > I don't think this can be included in Teaclave SGX SDK as samples. > > * The purpose of samples in Teaclave SGX SDK is to demonstrate the usages of > SDK or the benefits of using Rust. However, most of the code are written in > C. I'm not convinced to include this in the samples. I use the upstream sqlite c source code with an addition of about 30 lines of code to resolve symbols. To avoid the amount of c code from preventing review, it could be simplified to a fetch and sed. > * The license issue should be addressed. As I said, I found some LGPL headers > which are not accepted. Also, you mentioned that this sqlite implementation > is from another project, we also need to make sure the license are accepted. My phrases were a little too loose. As I mentioned above, mostly is upstream with 30 lines of additions. > * This PR introduce a lot of code which are hard to audit/review. Also, most > of code are not related with the SDK itself. Although this is sample code, we > still need to ensure the security in case other people grab it without > auditing it. IIRC, there was a peer-reviewed paper include a bug in our > sample code as their findings. > Yea, I remember that paper, <TeeRex> right. Yea, totally agreed. It would be easy to audit if it is changed to a fetch and sed. Although we need to trust upstream sqlite for this case (I find this a reasonable assumption?). > Overall, I hope you can understand my concerns. > Sure, totally understood. I am closing this PR. > BTW, it's totally okay to provide it as a separate project instead of merging > into this repo. You can create a new repo by yourself and open source it. Or, > we have an organization called Secure Computing Community > (https://github.com/sccommunity), which hosts related (experimental) projects > and third-party libraries around Teaclave. I think that's a good place to put > your contribution. > > Feel free to comment if you have different ideas. Thanks. I think in general, this is a good learning experience of Rust SGX SDK for me. And now I have a deeper understanding of how most of intel sgx sdk is not fully rewritten in Rust but linked to by FFI. And how the parts are piled together. But I do think by limiting the enclave programming language to Rust, and not trusting any external battlefield-tested library (sqlite in this case) would limit the scope of this project. I assume for a long time, there would not be a full Rust rewrite for sqlite. I think letting people know Rust SGX SDK not only allows embedded Rust crates but also can incorporate external code is important (Since in the current state, Rust has not yet rewritten everything, hopefully in the future, it would :D). And I do think arguing for better security by limiting the addition of new functionality shall be reconsidered. Since a better way could be to enforce strong auditing on the added code (tls-client or sqlite in this case). For example, we could audit the changes to upstream sqlite (Sorry for not making it easy to review!). And we could argue for the security boundary, e.g., not responsible for bugs in external libraries. Anyway, thank you so much for your time and great comments! They make a lot of sense and much appreciated! -- 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/pull/274#issuecomment-715317912
