Issue 518: Enabling CRLSets

[jumde]

fixes brave/brave-browser#518

Submitter Checklist:

• Submitted a ticket for my issue if one did not already exist.
• Used Github auto-closing keywords in the commit message.
• Added/updated tests for this change (for new code or code which already has tests).
• Verified that these changes build without errors on
  • Windows
  • macOS
  • Linux
• Verified that these changes pass automated tests (npm test brave_unit_tests && npm test brave_browser_tests) on
  • Windows
  • macOS
  • Linux
• Ran git rebase master (if needed).
• Ran git rebase -i to squash commits (if needed).
• Tagged reviewers and labelled the pull request as needed.
• Request a security/privacy review as needed.
• Add appropriate QA labels (QA/Yes or QA/No) to include the closed issue in milestone

Test Plan:

On Windows and Linux:

1. Open Brave Browser
2. Verify the crl-sets exist in the data directory - <DATA-DIR>/CertificateRevocation/<ver>/crl-set
3. Navigate to revoked.badssl.com - Should show a certificate error.

Reviewer Checklist:

• New files have MPL-2.0 license header.
• Request a security/privacy review as needed.
• Adequate test coverage exists to prevent regressions
• Verify test plan is specified in PR before merging to source

[bbondy]

Forwarding review here to @bridiver

[bridiver]

this doesn't seem like it is used?

[jumde]

Needed for demand_updater:

brave-core/browser/extensions/brave_component_extension.h

Line 14 in a76b249

class ComponentsUI {

[bridiver]

#include "chrome/browser/browser_process.h" for g_browser_process
we only need the brave version to access brave-specific methods

[kjozwiak]

Denying approval for uplift to 0.56.x after deliberating with @srirambv and @rebron. Reasoning:

We've had several issues in the past of security fixes landing 1-2 days before a release which ended up causing a lot of problems which required prompt hotfixes. If we end up uplifting this, we'll have ~a day or less of bake time which in my opinion, isn't enough time for a change that can have serious implications if something goes wrong. If we did uplift this and required a prompt hotfix, it would also put the muon migration schedule at risk.

[kjozwiak]

Clearing the uplift-request/0.57.x-Beta flag. As per process, please re-submit for approval once this has landed in master and requires uplift into 0.57.x.

[diracdeltas]

@kjozwiak this has landed in master now so i'm re-adding the uplift request

[kjozwiak]

Because we're planning on migrating muon users during the 0.57.x release and security issues like these tend to be a bit more riskier as any regression(s) that might spawn from this will most likely require an immediate hotfix. This might complicate things during the muon migration. I proposed skipping 0.57.x and getting this into 0.58.x which will be released on Dec 20th. I double checked and made sure @diracdeltas was okay with this as well.

@jumde can you merge this into 0.58.x before Dec 4th so it gets included when 0.58.x moves into beta? BTW, there's no approval needed to land things into the dev channel for now 👍.

[jumde]

0.58.x - 4a1a3b6

[bbondy]

FYI only smallest version it is merged inside of should be there for labels. Thanks.

[bbondy]

master: 92e9424

[jumde]

Reverted: #986 (master and 0.58.x)