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