Problems with creating new repos

[oddcoder]

According to tpm-rs/tpm-rs#79 we agreed to move the remaining unsafe{...} outside the main tpm-rs repository. We already have the last bit at oddcoder/safe-discriminant. I thought it would make sense to have as a separate repository under https://github.com/tpm-rs, in case someone wants to quickly make a modification to it in the future.
Normally I would send request to transfer repository, and github will notify tpm-rs to accept the new repository. But I cannot do that, and I am not fully sure why. When transferring repos from one person to another, it is normal that one account cannot create repositories in the other account. My guess is github is confused because I am also member of tpm-rs.

Also in the "select one of my organizations" option tpm-rs is disabled.
So some of the solutions can be enabling the creation of new repositories, or cloning https://github.com/oddcoder/safe-discriminant and pushing it to tpm-rs org.

[bradlitterell]

@oddcoder - permissions to create repositories in an organization like tpm-rs are reserved to the organization admins. Repos need to be approved by the steering committee and have maintainers designated. As noted in the subtext of the screenshot you can only transfer repositories to a place where you can create them.

I looked at safe-discriminant, and I have a question... The goal of removing the unsafe code is so the tpm-rs library doesn't have any unsafe code, or dependencies, in its core implementation. A TPM implementor or client library maintainer is expected to provide other libraries (such as crypto libraries) that might contain unsafe code, but we want tpm-rs not to have any unsafe dependencies to the extent we can.

This brings us to safe-discriminant. I noticed it uses the unsafe keyword, and I wasn't sure how to understand the implications of that. I don't think we want to create a scenario where someone could use it here in a way that is unsafe. I saw the comment in the safe discriminant repo that This trait is safe to derive and use but is unsafe to implement manually., but it needs to use an unsafe cast. It's not clear how anyone can be guaranteed to use that safely.

@tpm-rs/embedded-rust-mentors - opinions?

[oddcoder]

I will try to explain the problem and the motivation the best of my ability @bradlitterell @tpm-rs/embedded-rust-mentors .

Why do we need safe-discriminant

Previously, there was unsafe code in tpm-rs at marshal-derive/src/lib.rs#L149. This situation was tracked in tpm-rs/tpm-rs#79. There were two key issues to consider:

1. The attribute #![forbid(unsafe_code)] does not prevent unsafe code from being generated in the output of procedural macros. This limitation is currently being tracked by the Rust compiler team.
2. In this specific case, the use of unsafe code is actually recommended by Rust, as outlined in the documentation.

Since the use of unsafe code in tpm-rs is part of a macro, the macro needs to ensure that it only generates the unsafe case for the specific situation described in the Rust documentation. However, the marshaling macro was doing too many things at once, making it unclear where the checks were performed.

To address this, I isolated the unsafe cast into safe-discriminant, where I implemented all the necessary checks that were previously done in the marshaling process. We also conducted extensive testing to ensure that this single line of unsafe code remains well behaved.

During this process, we discovered an additional case that neither the marshaling macro nor safe-discriminant covered. This issue was identified with the help of the Rust compiler community after I requested a code review for safe-discriminant. We documented the case at oddcoder/safe-discriminant#1, fixed it, and added more tests. This problematic case arose from our use of macros, which had not been discussed in the Rust documentation.

Why do I prefer having safe-discriminant under tpm-rs organization

Right now, safe-discriminant is a dependency for tpm-rs because it was purpose built to move an unsafe cast out of tpm-rs (tpm-rs/tpm-rs#93 and tpm-rs/tpm-rs#94). This helped us uncover one hidden issue and ensure that our unsafe code in macros is well behaved. We cannot easily eliminate the unsafe code until Rust offers a proper solution, so I believe it makes sense to keep the repository here for two reasons:

1. The unsafe code gets more scrutiny.
2. Whenever needed, other maintainers would be able make changes without needing my personal approval.

If there are any other concerns, please let me know!

[bradlitterell]

Thank you for the write up. This makes sense, and I will document this with the steering committee and create a repo for it.