Cannot use "sfw npm" with the brave-browser repository

[fmarier]

sfw appears to be interfering with something we need in order to clone the Chromium repo:

$ mkdir temp-brave-browser
$ cd temp-brave-browser
$ git clone https://github.com/brave/brave-browser
Cloning into 'brave-browser'...
remote: Enumerating objects: 92926, done.
remote: Counting objects: 100% (290/290), done.
remote: Compressing objects: 100% (42/42), done.
remote: Total 92926 (delta 277), reused 253 (delta 248), pack-reused 92636 (from 6)
Receiving objects: 100% (92926/92926), 32.67 MiB | 30.39 MiB/s, done.
Resolving deltas: 100% (61939/61939), done.
$ git clone https://github.com/brave/brave-core brave-browser/src/brave
Cloning into 'brave-browser/src/brave'...
remote: Enumerating objects: 1378094, done.
remote: Counting objects: 100% (1906/1906), done.
remote: Compressing objects: 100% (645/645), done.
remote: Total 1378094 (delta 1584), reused 1262 (delta 1261), pack-reused 1376188 (from 4)
Receiving objects: 100% (1378094/1378094), 3.77 GiB | 42.54 MiB/s, done.
Resolving deltas: 100% (1000659/1000659), done.
$ cd brave-browser
$ npm install
Protected by Socket Firewall

added 6 packages, and audited 7 packages in 453ms

2 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

=== Socket Firewall ===

Warning: Socket Firewall did not detect any package fetch attempts

$ npm run init
Protected by Socket Firewall

> brave@1.85.35 init
> node ./scripts/init.js

Performing initial checkout of brave-core
------------------------------------------------------------------------------------------
/home/francois/temp-brave-browser/brave-browser/src/brave
> git rev-parse HEAD
brave-core repo at /home/francois/temp-brave-browser/brave-browser/src/brave is at commit ID 7df6a15466d8058afe9b0839eccb2097dd7b5d64
------------------------------------------------------------------------------------------
/home/francois/temp-brave-browser/brave-browser/src/brave
> npm install
------------------------------------------------------------------------------------------
/home/francois/temp-brave-browser/brave-browser/src/brave
> npm run sync -- --init

> brave-core@1.85.35 sync
> node ./build/commands/scripts/sync.js --init

install depot_tools...
------------------------------------------------------------------------------------------
/home/francois/temp-brave-browser/brave-browser/src/brave
> git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git /home/francois/temp-brave-browser/brave-browser/src/brave/vendor/depot_tools
Cloning into '/home/francois/temp-brave-browser/brave-browser/src/brave/vendor/depot_tools'...
fatal: unable to access 'https://chromium.googlesource.com/chromium/tools/depot_tools.git/': CONNECT tunnel failed, response 403
null
null
null
null

=== Socket Firewall ===

 - 22 packages fetched successfully

I installed sfw system-wide as root:

$ sfw --version
Socket Firewall Free, version 0.12.20

and have the following aliases:

$ grep sfw ~/.bash_aliases 
alias npm="/usr/bin/sfw npm"
alias pnpm="/usr/bin/sfw pnpm"
alias yarn="/usr/bin/sfw yarn"
alias pip="/usr/bin/sfw pip"
alias uv="/usr/bin/sfw uv"
alias cargo="/usr/bin/sfw cargo"

[divmain]

sfw works by establishing an HTTP proxy and passing down related configuration to subprocess through environment variables. This is transitive - so any process spawned by an sfw-wrapped npm will also inherit that configuration.

Additionally, sfw-free is configured to block-by-default if it does not recognize the hostname. This can indirectly protect against some of the clever mechanisms that malware uses to further compromise a system, though it is obviously circumventable.

We've been discussing and I think we're going to move away from block-by-default to warn-by-default, which would unblock unfamiliar registries, git dependencies, and non-package-manager subprocesses attempting to make requests. This will be less secure but, based on the feedback so far, it's probably what most people are going to prefer. (Enterprise users will be able to tune the behavior to their exact needs)

In the meantime, you could work around the issue by unsetting the HTTP_PROXY environment variable on subprocesses. That's inelegant but would probably unblock you in the short term.

I'll leave this issue open until the default behavior has changed. Thanks for reporting the issue!

[fmarier]

Thanks for the detailed explanation. I see the problem.

we're going to move away from block-by-default to warn-by-default

That would work, but another way to do it would be to create a configurable allowlist of hostnames that can be passed through.

[divmain]

Yes, we considered that option. Ultimately we decided to keep sfw free a no-config tool.