-
Notifications
You must be signed in to change notification settings - Fork 891
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
Conversation
cc: @riastradh-brave |
|
||
void BraveTorClientUpdater::InitExecutablePath( | ||
const base::FilePath& install_dir) { | ||
base::FileEnumerator traversal(install_dir, false, |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably in BraveBrowserMainExtraParts::PreMainMessageLoopRun
There was a problem hiding this comment.
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.
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. |
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? |
@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? |
@riastradh-brave I believe crx3 addresses some related packaging issues and is now required for chromium 70 |
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 ```
Fixes brave/brave-browser#724
Submitter Checklist:
git rebase -i
to squash commits (if needed).Test Plan:
Extension download and installation
0.0.0.0
Command-line switch to disable extension
--disable-tor-client-updater-extension
Reviewer Checklist: