Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document our safety "ethos" #482

Closed
joshlf opened this issue Oct 9, 2023 · 1 comment
Closed

Document our safety "ethos" #482

joshlf opened this issue Oct 9, 2023 · 1 comment

Comments

@joshlf
Copy link
Member

joshlf commented Oct 9, 2023

One of zerocopy's target user bases comprises users who are especially concerned with reliability, safety, soundness, trust, etc. Quoting from #98:

On the other end of the spectrum, many of our users come from domains which generally have a high bar for correctness - kernels, hypervisors, cryptography, security hardware, etc. These users are extremely wary of taking external dependencies, and only take dependencies when they absolutely need to or when they have a high degree of trust in an external software artifact.

In order to reach users in this camp, we must:

  • Hold ourselves to a high standard for correctness and soundness
  • Articulate this standard concisely but in sufficient technical detail that a user in this camp can come away from our docs comfortable with taking a dependency on zerocopy

In a comment on that issue, @briansmith confirmed that this characterization is accurate, at least for him and for the crate he maintains, ring (emphasis added):

These users are extremely wary of taking external dependencies, and only take dependencies when they absolutely need to or when they have a high degree of trust in an external software artifact.

@joshlf made a PR for ring that shows how zerocopy benefits ring by reducing its unsafe code that's duplicative of zerocopy. And zerocopy has a higher bar for documenting and validating its correctness than my more informal approach in my own code. OTOH zerocopy is so large that I pretty much just have to take it on faith that y'all care so much about getting all the details right that I don't need to bother looking through it, because I can't (don't have time).

This relationship - in which the user trusts that the crate was authored with a high emphasis on quality but does not audit the code themselves - is inevitable for most projects. It's the relationship that even the largest institutions have with projects like the Rust compiler and standard library. We can do our best to make our code readable and easy to understand, but at the end of the day, most users will be choosing between either a) trusting that we've done the work or, b) not using zerocopy. For most users, there's no c) audit the code.

For that reason, we should double down on what's described in #98: document our approach to soundness so that users who have a high bar for trust feel comfortable that zerocopy is developed to a quality standard that satisfies their needs.

@joshlf
Copy link
Member Author

joshlf commented Oct 10, 2023

This was closed in #405

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant