parse certificates with pure rust #6147
Conversation
reaperhulk
force-pushed
the
rust-cert
branch
12 times, most recently
from
d5f04e3 to
8b2f8b5
Compare
reaperhulk
force-pushed
the
rust-cert
branch
2 times, most recently
from
060f0b6 to
0ebdc04
Compare
| ) -> pyo3::PyResult<bool> { | ||
| match op { | ||
| pyo3::class::basic::CompareOp::Eq => { | ||
| Ok(self.raw.borrow_data() == other.raw.borrow_data()) |
There was a problem hiding this comment.
Mmm, is comparing by bytes always correct, or are there ever cases where different bytes are really the same?
There was a problem hiding this comment.
OpenSSL generates a hash and verifies that the "encoding" hasn't changed. Digging through the layers it looks like byte for byte comparison probably is fine? It's also the case that the only bytes that could ever be different would be the ones outside of tbsCertificateBytes of course.
|
Hi! I since the changelog drew attention to it, I just happened to read the API stability and versioning doc:
However, this change breaks "the behavior of existing APIs" with no warning. And I don't think it's a "security" fix either -- while stricter validation can improve security, that reasoning would be a slippery slope by which all sorts of undue API breaks could be justified. What's the cryptography project's opinion on this? It seems to me that the document is simply overpromising on stability. Maybe it's time to change the stability claims? |
|
Stricter and looser validation are properties that we have historically flexed on (sometimes due to our own dependency changing its behavior, sometimes for other reasons). I'm not sure how to capture the reality of our policy without making it sound like we break APIs frequently rather than "we have changed an unusual parsing/serialization edge case that 99.99% of our callers will never see". |
No description provided.