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] > >
