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

Implement Tor client updater as component extension #316

Merged
merged 4 commits into from
Aug 9, 2018
Merged

Conversation

emerick
Copy link
Contributor

@emerick emerick commented Aug 9, 2018

Fixes brave/brave-browser#724

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).
  • 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.

Test Plan:

  • Extension download and installation

    • Start with a clean profile
    • Launch Brave
    • Visit chrome://components
    • Verify that Tor Client Updater is listed and version number is not 0.0.0.0
    • Verify that name of component contains platform identifier (Windows/Mac/Linux)
  • Command-line switch to disable extension

    • Start with a clean profile
    • Launch Brave with --disable-tor-client-updater-extension
    • Visit chrome://components and verify that Tor Client Updater is not listed

Reviewer Checklist:

  • New files have MPL-2.0 license header.
  • Request a security/privacy review as needed.
  • Adequate test coverage exists to prevent regressions

@emerick emerick self-assigned this Aug 9, 2018
@emerick emerick requested a review from bbondy August 9, 2018 19:05
@emerick
Copy link
Contributor Author

emerick commented Aug 9, 2018

cc: @riastradh-brave

@emerick emerick changed the title Tor extension Implement Tor client updater as component extension Aug 9, 2018
@bbondy bbondy merged commit 7833d5c into master Aug 9, 2018
@bsclifton bsclifton deleted the tor-extension branch August 9, 2018 20:08

void BraveTorClientUpdater::InitExecutablePath(
const base::FilePath& install_dir) {
base::FileEnumerator traversal(install_dir, false,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be flagged for security audit. We shouldn't be using a wildcard here to find files, we need to look for a specific file and match the contents against a checksum cc @diracdeltas

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, good point. I implemented it like that because the Tor client embeds versioning and target platform information in its executable name (example: tor-0.3.3.8-win32-brave-5) and I didn't want to tightly couple the updater with a specific Tor client. I think one thing we can do here is to change the name of the Tor client to something a bit more generic when packaging it in the extension (e.g., brave-tor-client or something like that).

A checksum makes sense, but I think it would mean that we couldn't update the Tor client without also updating Brave. I think that's at least part of the problem the extension was meant to address.

cc: @riastradh-brave and @bbondy for any other thoughts here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we do validate the crx so the checksum can be included along with the exe

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for flagging, I am assigning to @riastradh-brave for retroactive security review.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would be perfectly fine with hard-coding a hash -- that's what we do currently. As I understand it, the only real specific motivation we have for doing a separate extension is to avoid antivirus software that is unhappy if Brave is bundled with a tor executable -- but even then, I'm not sure have any reports of antivirus software complaining that it's there; all the reports I'm aware of are complaints that it got executed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally, we put out updates more frequently than tor does anyway.

Copy link
Contributor

@riastradh-brave riastradh-brave Aug 24, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see what's going on here. @emerick Can we just use a fixed pathname at a fixed location in the extension's install directory for the executable file? The only reason the file that is published via S3 has a different name is that we are publishing several different files, one for each platform.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@riastradh-brave Yeah, I'll update the packager to use a more generic name for the executable and then we'll just look specifically for that.

const base::CommandLine& command_line =
*base::CommandLine::ForCurrentProcess();
if (!command_line.HasSwitch(switches::kDisableTorClientUpdaterExtension))
g_brave_browser_process->tor_client_updater()->Register();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need this in BraveBrowserProcess? Seems like it could just live here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My thinking here was that BraveBrowserProcess would be the owner of long-lived services like the Tor client updater and then we'd just access it here via its getter so that we can register the extension on startup.

Are you suggesting to move the Register function into BraveExtensionManagement (or even the entire updater)? I haven't followed the code paths all the way through, but it seems like that could work. My only concerns would be that the registration happens at the correct time at startup (I definitely had a few issues with this before I settled on having BraveBrowserProcess own them) and that the updaters are easily accessible to other parts of the code.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the tor client updater isn't a long-lived service, the component updater is the long-lived service and you are just registering things to be updated by it

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think maybe there is some confusion here because of the naming. I would use the WidevineCDMComponentInstaller as an example for this

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I see what you're saying about component updater. I did model this on some of the existing components (not specifically WidevineCDMComponentInstaller, but something similar). In our code, BraveComponentInstaller is fulfilling the same role as WidevineCDMComponentInstaller (i.e., it implements the installer policy and provides a register function).

It seems like making BraveComponentInstaller generic was a mistake; instead, it should be specific to this component and contain all of the logic that gets executed upon registration. Also, it seems like registration should occur in chrome_browser_main or somewhere similar. Is that the approach you're thinking of?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably in BraveBrowserMainExtraParts::PreMainMessageLoopRun

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw we'll want this opt in and not always registered. Installed first time switch is turned on in a private tab.
@cezaraugusto can you track this work and do the fix for the private tab UI? You could land a dead switch control any time.

@riastradh-brave
Copy link
Contributor

Is the security model of extensions documented anywhere? I gather that there is a public key for verifying signatures, but I'm interested in making sure that there's, e.g., no vector for rollback attacks with valid signatures.

@riastradh-brave
Copy link
Contributor

With apologies for asking a basic question after the work has already been done and merged... What is the advantage of using a component extension instead of simply downloading a file at a standard URL with a hard-coded hash, and updating the browser if we ever need to update tor? Are we worried about making sure users of old versions of Brave can update the tor daemon?

@bridiver
Copy link
Collaborator

bridiver commented Aug 27, 2018

@riastradh-brave the advantage is that we don't have to duplicate a bunch of code for checking updates, downloading, verifying and installing those updates. Is there some reason why we wouldn't want to use it?

@bridiver
Copy link
Collaborator

@riastradh-brave I believe crx3 addresses some related packaging issues and is now required for chromium 70

@drbh drbh mentioned this pull request Sep 8, 2018
11 tasks
@darkdh darkdh mentioned this pull request Sep 11, 2018
11 tasks
petemill added a commit that referenced this pull request Dec 11, 2018
Changes: https://github.com/brave/brave-ui/compare/5c2d8a0f669af2e9a68ce0fe38d49a116bc52315..861153d09e025ca98d6fae11bb51aa458c4d8519

```
* 861153d - (21 hours ago) Merge pull request #247 from brave/c71-clock-period — Pete Miller (HEAD -> brave-core-0.58.x, origin/brave-core-0.58.x)
*   4195647 - (2 hours ago) Merge pull request #316 from brave/sync-revert-58 — Pete Miller
|\
| * cad6678 - (2 hours ago) Revert "sync v2" — Cezar Augusto
| * d134401 - (2 hours ago) Revert "Merge pull request #308 from brave/sync_img" — Cezar Augusto
| * 52aef38 - (2 hours ago) Revert "allow string type for some siteBanner props" — Cezar Augusto
|/
* 5f4a8b1 - (3 hours ago) allow string type for some siteBanner props auditor: @ryanml - currentAmout, onAmountSelection and onDonate accept strings as well this is a temp fix only included in 0.58.x — Cezar Augusto
* f0569c8 - (4 days ago) do not count first letter if space in textareaclipboard — Cezar Augusto
* 69ef8be - (5 days ago) Merge pull request #308 from brave/sync_img — Cezar Augusto
* 854d181 - (3 weeks ago) sync v2 — Cezar Augusto
* b35662c - (4 days ago) update snapshot for walletSummary — Cezar Augusto
* a85206d - (5 days ago) Merge pull request #309 from brave/welcome_img — Pete Miller
```
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

Successfully merging this pull request may close these issues.

5 participants