Essentially, as long as we can still perform a release on it if needed, that’s the baseline. Say a security issue pops up or things like that. Documentation for others to make a release will certainly help there, but I think we probably need to do a release first before it can be effectively documented.
On Wed, Dec 4, 2019 at 16:58 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] > > > > > -- Matt Sicker <[email protected]>
