chore(deps): upgrade goproxy 1.7.0

[thisislawatts]

Pull Request Submission Checklist

• Follows CONTRIBUTING guidelines
• Includes detailed description of changes
• Contains risk assessment (Medium)
• Highlights breaking API changes (if applicable)
• Links to automated tests covering new functionality
• Includes manual testing instructions (if necessary)
• Updates relevant GitBook documentation (PR link: ___)

What does this PR do?

• chore(deps): upgrade goproxy to latest
• fix: do not include extra certs in proxy certificate

This change indicates that the system now only keeps the original self-signed certificate in the PEM block while still adding additional CA certificates to the certificate pool via rootCAs.AddCert(). This is a more efficient approach since:

• The proxy only needs the self-signed certificate for MITM operations
• The additional CA certificates are still available in the root CA pool for verification
• It prevents the potential OpenSSL excessive message size issue by keeping the PEM block smaller

This aligns with the behaviour implemented in goproxy up until this change

How should this be manually tested?

You will need:

• openssl available on your machine for the certificate bundle
• an opensource manifest file. An empty but valid package.json is fine.

Instructions assume MacOS, adjust for your platform as required.

Original bug as seen with v1.1295.1

1. curl --compressed https://downloads.snyk.io/cli/v1.1295.1/snyk-macos -o ~/snyk-1.1295.1
2. export NODE_EXTRA_CA_CERTS='/usr/local/etc/openssl@3/cert.pem'
3. ~/snyk-1.1295.1 test .
4. Observe write EPROTO 0052E60602000000:error:0A000098:SSL routines:read_state_machine:excessive message size:../deps/openssl/openssl/ssl/statem/statem.c:621:

Verify the fix

1. You should have openssl available on your machine.
2. Assuming MacOS, run export NODE_EXTRA_CA_CERTS='/usr/local/etc/openssl@3/cert.pem'
3. ./binary-releases/snyk-macos test .
4. ✨ Success

Reference: CLI-658

[github-actions]

	Warnings
⚠️	There are multiple commits on your branch, please squash them locally before merging!

Generated by 🚫 dangerJS against 462983c

[cmars]

Looks good so far! So if I understand correctly, in InitCA,

• rootCAs are the trusted root certs that the proxy needs to make outbound connections on behalf of the proxied CLI
• certPEMBlock is the self-signed proxy CA that holds the root of trust for the proxied CLI

So it makes sense that the proxy's CA wouldn't need the extra CA certs -- the CLI already trusts the self-signed one! Great catch!

For a test, I would suggest re-creating two scenarios if you want to be really bulletproof here. Both will require a standalone test TLS server with its certificate issued by a self-signed CA -- but a completely separate one from the proxy's CA.

• In one scenario, add the test CA cert (that issued the test TLS server's cert) to the cert pool. It's currently x509.SystemCertPool, which will affect all tests running in the same process, so you might want to patch a separate pool for this test if this becomes a problem.
• In another scenario, add the test CA cert (that issued the test TLS server cert) to the file at SNYK_CA_CERTIFICATE_LOCATION_ENV.

In both scenarios, it should be possible to interact with the test TLS server (simple GET request is fine) through the proxy without disabling cert verification.

[PeterSchafer]

Question: Is this really correct to do? Since the test fails I would say no.

[thisislawatts]

In discussion we are going to split the certPEMBlock, at the moment we are using this artefact for two purposes.

• Configuring the Node.js
• Setting up the proxy

[PeterSchafer]

This now looks better now! Let's think a bit more about extending the test cases. Maybe we can create one that would have triggered the bug we are fixing now.