Pei, I think Matt’s point is on the situation if you want to separate this project as an individual project.
So, for this tool, I think the question is whether to put it in the `apache/incubator-mesatee` repo or a new `apache/incubator-mesatee-xxx` repo. Does this explanation clear to you? > On Dec 4, 2019, at 2:57 PM, Wang Pei <[email protected]> wrote: > > Matt, > > Thanks for the thoughtful comments. > > There shouldn't be any problem with licensing. Regarding your other > concerns, I have some more information. It's a very tiny tool (about 1300 > lines of Rust). It provides very limited functionality, and only works with > a particular version of the Rust compiler (the exact version specified by > Teaclave and its dependencies). In this sense, releasing it as a separate > tool seems a bit overkill. Indeed, it's a bit isolated in terms of > development since it's a rustc plugin rather than anything directly related > to Teaclave. However, I don't think we will need to actively develop it as > we do for the rest part of Teaclave. There is no plan to expand its > functionality, although it does need maintenance because every time > Teaclave updates its toolchain version the internal APIs of rustc change. > > With all that said, I do see a point in making the tool as a separate > project. More discussions are welcome! > > Pei > > On Wed, Dec 4, 2019 at 1:46 PM Matt Sicker <[email protected]> wrote: > >> Whether you'd like to make this part of the project here or externally >> really depends on a few things: >> >> * Licensing: if it's Apache licensed, then not an issue. >> * Community: if it's a tool being developed by only one of the >> committers, then it's fairly difficult for the rest of the community >> to vote on releases for it. >> * Releases: is it released on its own cycle from other repos? If so, >> note what I mentioned about community which can cause releases to get >> delayed waiting for enough votes. >> >> I suspect this component is appropriate to put here. Whether we'd like >> it in its own git repo or not is another question. >> >> On Wed, 4 Dec 2019 at 14:08, Wang Pei <[email protected]> wrote: >>> >>> One of the features MesaTEE (now renamed as Teaclave) promised when it >> was >>> initially open-sourced is the so-called "Non-bypassable gateway." >>> Basically, we would like to show that all interactions between the TEE >> and >>> the untrusted outside world are properly sanitized in our implementation. >>> >>> As a first step towards this goal, I have implemented a tool that can >>> extract the dependency graph of the crates built by Cargo. It's >>> instrumentation to rustc that analyzes the Rust IR and stores information >>> with an embedded DB such that it can gather information collected by >>> multiple rustc invocations. >>> >>> The tool provides three custom attributes: require_audit, audited, and >>> entry_point. These attributes can annotate any item-like entities in Rust >>> code, including ADT, functions, traits, and impl blocks. Starting from >> each >>> entry_point, the tool traverses the dependency graph with DFS and emits a >>> warning whenever it encounters an item marked by require_audit unless >>> another item marked by audited presents along the traversal path. >>> >>> The attributes have no effects on code generation and can be safely >> ignored >>> by anyone that does not care about code auditing. >>> >>> About how to publish the tool, there are two options. It can be part of >>> mesatee-sgx, the fundamental dependency of the mesatee project. Or it can >>> be released as a standalone tool. In theory, it can be used to audit >> other >>> Rust projects, but I wonder how attractive that would be. Either way, we >>> have to annotate a lot of code in mesatee-sgx and mesatee to make the >> tool >>> acutally useful. >>> >>> Let me know your thoughts. >>> >>> Pei >> >> >> >> -- >> Matt Sicker <[email protected]> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
