This change introduces a new function that populates an LMDB with revocation data from either staging or production OneCRL via the tool found at mozilla/OneCRL-Tools/one_crl_to_cert_storage. As a consequence, this change introduces a dependency on Rust (ideally 1.39 and above, although I am sure lower versions probably work).
The above tool was built to populate a Firefox's security_state/data.safe.bin directly. However, in order to fit in with the TLS-Canary's caching strategy, I thought it better to point this tool at the cache and let the caller move files into the right spot as necessary (E.G /path/to/cache/stage_cert_storage/security_state/data.safe.bin should go to /path/to/profile/security_state/data.safe.bin).
I believe that I successfully hooked this up end-to-end by swapping out the logic in basemode.py, but I admit that my Python setup is anemic, so the please do closely double check what I have done. Any pointers on how to do E2E testing would be greatly appreciated.
This change introduces a new function that populates an LMDB with revocation data from either staging or production OneCRL via the tool found at mozilla/OneCRL-Tools/one_crl_to_cert_storage. As a consequence, this change introduces a dependency on Rust (ideally 1.39 and above, although I am sure lower versions probably work).
The above tool was built to populate a Firefox's
security_state/data.safe.bindirectly. However, in order to fit in with the TLS-Canary's caching strategy, I thought it better to point this tool at the cache and let the caller move files into the right spot as necessary (E.G/path/to/cache/stage_cert_storage/security_state/data.safe.binshould go to/path/to/profile/security_state/data.safe.bin).I believe that I successfully hooked this up end-to-end by swapping out the logic in
basemode.py, but I admit that my Python setup is anemic, so the please do closely double check what I have done. Any pointers on how to do E2E testing would be greatly appreciated.