running MSDO behind the proxy

[osilberman]

provide a way to set a proxy in the devops task to avoid copying .npmrc manually to the account running pipeline on a self-hosted agent server

[davidknise]

Hi @osilberman, can you provide more details?

[davidknise]

I looked into this and realized eslint fails on my devbox due to a global @microsoft registry defined.

I've filed an item for the team to look into.

[osilberman]

Hi @davidknise thank you for your response. The reason of my question is this one (also filed here microsoft/security-devops-azdevops#56)

I receive below error running the task on windows self-hosted agent. The error appeared starting 16th of June:

Installing Microsoft Security DevOps Cli version: Latest
##[debug]packageName = Microsoft.Security.Devops.Cli.win-x64
##[debug]agentDirectory = C:\agt_work_msdo
##[debug]agentPackagesDirectory = C:\agt_work_msdo\packages
##[debug]agentVersionsDirectory = C:\agt_work_msdo\versions
##[debug]MSDO CLI version contains a latest quantifier: Latest. Continuing with install...
##[debug]MSDO_MICROSOFTSECURITYDEVOPSCLIWINX64_LATESTVERSION=undefined
##[debug]Fetching service index for: https://api.nuget.org/v3/index.json
##[debug]GET https://api.nuget.org/v3/index.json
##[debug]Error: Error calling url: Error: connect ECONNREFUSED 13.107.246.67:443
##[debug]MSDO_MICROSOFTSECURITYDEVOPSCLIWINX64_LATESTVERSION=undefined
##[debug]Fetching service index for: https://api.nuget.org/v3/index.json
##[debug]GET https://api.nuget.org/v3/index.json
##[debug]Error: Error calling url: Error: connect ECONNREFUSED 13.107.246.67:443
##[debug]MSDO_MICROSOFTSECURITYDEVOPSCLIWINX64_LATESTVERSION=undefined
##[debug]Fetching service index for: https://api.nuget.org/v3/index.json
##[debug]GET https://api.nuget.org/v3/index.json
##[debug]Error: Error calling url: Error: connect ECONNREFUSED 13.107.246.67:443
Exception occurred while initializing MSDO:
##[debug]task result: Failed
##[error]Error: Failed to install the MSDO CLI nuget package.
##[debug]Processed: ##vso[task.issue type=error;]Error: Failed to install the MSDO CLI nuget package.
##[debug]Processed: ##vso[task.complete result=Failed;]Error: Failed to install the MSDO CLI nuget package.

Does it have to do with your update? The agent version is the latest 2.218.1

Thank you!!

[exigopro]

Facing the same issue. I believe permitting access to api.nuget.org from your self-hosted agent might work. Will perform some testing.

[osilberman]

were you successful with your testing?

[CapG-SLeeke]

Hi,

I had the same issue and originally raised as incident here : Error: Failed to install the MSDO CLI nuget package while running behind proxy #59

I have tracked the issue down to a specific JS script : msdo-nuget-client.js

The ultimate issue is the msdo nuget client just doesnt handle a proxy.

is complete msdo has the tunnel library included so it is simple to update.

Add the below on line 37 :

const tunnel = __importStar(require("tunnel"));

the replace the function called resolveRequestOptions ( rough line 348 )

function resolveRequestOptions(accessToken) {
     // Add Proxy Support https over http
    let options = {
        method: 'GET',
        timeout: 2500,
        headers: {
            'Content-Type': 'application/json'
        }
	};			
    var tunnelineAgent = false;
	console.log(`## Info :: resolveRequestOptions :: Checking Proxy Env for Request Options`);
	if (process.env.http_proxy) {
		console.log(`## Info :: resolveRequestOptions :: Adding Proxy for Request Options`);
		try {
			const proxyurl = new URL(process.env.http_proxy);
	        tunnelineAgent = tunnel.httpsOverHttp({
                            proxy: {
                            host: proxyurl.hostname ,
                            port: proxyurl.port 
                            }
                        });
				options['agent'] = tunnelineAgent ;     
        } catch (error) {
	        console.log(`## warning proxy env variable malformed :: example http://proxyserver:8080 :: ${error}`);
		}
	} else {
		console.log(`## Info :: resolveRequestOptions :: No Proxy Env Request Options`);
    }
    if (!common.isNullOrWhiteSpace(accessToken)) {
	console.log(`## Info :: An accessToken is being used`);
        options['auth'] = `:${accessToken}`;
    } else {
	    console.log(`## Info :: No accessToken is being used`);
    }
    return options;
}

This then works a treat when having a proxy or not. This only really handles https over a http proxy though.

	        tunnelineAgent = tunnel.httpsOverHttp({
                            proxy: {
                            host: proxyurl.hostname ,
                            port: proxyurl.port 
                            }
                        });

it should really handle https over https it would be something like, but you need to use proxyurl.protocol == 'https:' to decide

	        tunnelineAgent = tunnel.httpsOverHttps({
                            proxy: {
                            host: proxyurl.hostname ,
                            port: proxyurl.port 
                            }
                        });

[DimaBir]

A fix for this is up in #272.

resolveRequestOptions in the vendored msdo-nuget-client.js returned request options with no agent, and both https.request call sites — the NuGet service-index lookup and the .nupkg download — inherited that. Node's https module does not read proxy environment variables on its own, so the CLI install reached the network directly regardless of HTTPS_PROXY being set, which is why it hung or failed behind an egress proxy.

The change adds a resolveProxyAgent(url) that reuses @actions/http-client's proxy resolution — so HTTPS_PROXY, https_proxy and NO_PROXY are all honored, including proxies with credentials — and assigns the resulting tunnel agent at both call sites. When no proxy is configured the agent stays unset and requests take exactly the path they take today.

Two things worth stating plainly:

• This lands in node_modules/@microsoft/security-devops-actions-toolkit/, which is committed in this repo, so it takes effect at runtime. It will be lost on the next toolkit bump, so the same fix needs to land upstream in microsoft/security-devops-actions-toolkit to be durable. That is being routed there.
• The upstream fix also covers the equivalent Azure DevOps extension reports, which share this download path.