Let's decide how this should be handled after SDK 1.10 release. On Wed, Dec 4, 2019 at 3:16 PM Matt Sicker <[email protected]> wrote:
> There are two things: having a separate git repo (or not), and having it > part of the project or 3rd party. We can have multiple git repos on > apache.org. > > On Wed, Dec 4, 2019 at 17:13 Mingshen Sun <[email protected]> wrote: > > > 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] > > > > -- > Matt Sicker <[email protected]> >
