46 bytes, text/x-phabricator-request
|Details | Review|
https://searchfox.org/mozilla-central/rev/29aea2a2a3bd0f5e25ce0b60a76053fb25ba5149/security/certverifier/NSSCertDBTrustDomain.cpp#585 It's valid to get an empty 200 response.
Note that this happens with socket process isolation patches (larch project branch) and patch from bug 1484751 applied. In the in log I can also see another request being made to this host (apparently another OCSP request) with 400 response: https://www.janbambas.cz/moz/logan/?https%3A//www.janbambas.cz/moz/logs/1497258.log#%7B%22show%22%3A%5B%7B%22name%22%3A%22nsHttpTransaction%22%2C%22on%22%3A11%2C%22clr%22%3A%22%23bebada%22%7D%5D%7D Hence, we may be sending something wrong in the request POST data as the socket process isolation patches are pretty much work in progress.
In reimplementing the OCSP fetching code in bug 1456489, we improperly translated an assertion that relied on the nullness of a pointer to rely on the length of a data structure that was populated by reference. It turns out that this made the assertion invalid because we could return a successful result and have filled the data structure with zero-length data and it still would be valid to operate on (the decoding code returns a malformed input result in this case). To fix this, we can simply remove the assertion. This patch also adds a test to exercise this case.
10 months ago
Assignee: nobody → dkeeler
Priority: -- → P1
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/9efc67c28c94 remove unsound OCSP assertion from NSSCertDBTrustDomain::CheckRevocation r=mayhemer
You need to log in before you can comment on or make changes to this bug.