test should instead set up an https server to simulate the request:

https://github.com/npm/minipass-fetch/actions/runs/4009475310/jobs/6884876964

This fix is very useful, hope to see it on NPM soon.

Hey there!

I belong to an open source security research community, and a member (@Sampaguitas) has found an issue, but doesn’t know the best way to disclose it.

If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

Thank you for your consideration, and I look forward to hearing from you!

(cc @huntr-helper)

request to https://registry.npmjs.org/expo-template-blank failed, reason: unable to get local issuer certificate
FetchError: request to https://registry.npmjs.org/expo-template-blank failed, reason: unable to get local issuer certificate
at ClientRequest. (C:\Users<username>\AppData\Roaming\npm\node_modules\expo-cli\node_modules\minipass-fetch\lib\index.js:97:14)
at ClientRequest.emit (events.js:210:5)
at TLSSocket.socketErrorListener (_http_client.js:406:9)
at TLSSocket.emit (events.js:215:7)
at emitErrorNT (internal/streams/destroy.js:92:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)
at processTicksAndRejections (internal/process/task_queues.js:80:21)

tried all below

npm config set registry http://registry.npmjs.org/
npm config set strict-ssl false
NODE_TLS_REJECT_UNAUTHORIZED =0

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

I am running npm install, and my dependencies include a private github repo, configured via .npmrc as described.

I am on a corporate network that intercepts HTTPS traffic using a private CA, which I have configured as an environmental variable export NODE_EXTRA_CA_CERTS=/path/to/root_ca.pem.

I can't see that this is being picked up by minipass-fetch when it is run by npm, and installation fails with UNABLE_TO_GET_ISSUER_CERT_LOCALLY.

It would appear that some change could be made to pass through this extra certificate, if detected in the environment, similar to this PR: https://github.com/npm/minipass-fetch/pull/12/files

Expected Behavior

If NODE_EXTRA_CA_CERTS is configured, this should be used by minipass-fetch.

What / Why

The timeout option can shorten the timeout (e.g. timeout: 1000) but cannot increase the timeout beyond the default (e.g. timeout: 180000).

It would be helpful to be able to increase the timeout for slow internet connections.

When

Setting timeout to greater than 60000.

How

Current Behavior

• If a timeout above 60000 is used, it will always time out at 60000.

Steps to Reproduce

const fetch = require('minipass-fetch')
fetch('https://example.com:1234', { timeout: 180000 })
  .then(res => res.text())
  .then(body => console.log(body))

Expected Behavior

timeout should support values greater than 60000 and not time out earlier.

Who

• n/a

References

• n/a

What / Why

The dependency encoding appear as dependency and optionalDependencies whereas it seems to be used only in the tests.

Expected

It should be tagged as devDependencies (but maybe i miss something).

We are using minipass-fetch via make-fetch-happen in our implementation of apollo-gateway. Our downstream GraphQL services may return cookies in their response headers via the set-cookie header. According to the HTTP/Cookies spec, this header can appear multiple times in the response.

In the current implementation of Headers, get returns a comma-separated list of the values for a given header, and this is the only way (that I can see) to access those values. In a gateway/proxy kind of application, the downstream headers should be able to be passed through to the outgoing response without modification or combination. Specifically with cookies, we have seen issues where the combined comma-separated list of cookies is interpreted differently by browsers when attributes like HttpOnly are included in some of them.

The Fetch Standard defines a special method on Headers, getSetCookie, which is designed to handle this use case.

It would be nice if this implementation supported that method. As a workaround, we are using the raw() method of Headers to access the array-value for set-cookie from the map, but we would prefer not to rely on internals.

Hello!

I hope you are doing well!

We are a security research team. Our tool automatically detected a vulnerability in this repository. We want to disclose it responsibly. GitHub has a feature called Private vulnerability reporting, which enables security research to privately disclose a vulnerability. Unfortunately, it is not enabled for this repository.

Can you enable it, so that we can report it?

Thanks in advance!

PS: you can read about how to enable private vulnerability reporting here: https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository

What / Why

data: urls should be supported the "same" as fetched URLs, in the sense that they may be aborted, and should support any valid data: urls, whether base64 encoded or not.

const c = new AbortController()
fetch('data:text/plain;base64,SGVsbG8sIFdvcmxkIQ==', { signal: c.signal })
  .then(r => console.log(r), e => console.error(e))
c.abort()

Expect it to fail with an AbortError. Instead it works. (This mirrors node-fetch, but diverges from browser fetch.)

const urls = [
  'data:,Hello%2C%20World%21',
  'data:text/html,%3Ch1%3EHello%2C%20World%21%3C%2Fh1%3E',
  'data:text/html,<script>alert('hi');</script>',
]
Promise.all(urls.map(u => fetch(u)).then(() => console.log('it worked'))

Expect: load all data urls. Actual: fails because they are not base64 encoded.

Again, mirrors node-fetch, but not browser fetch.

The rejectUnauthorized property is fixed to true if it is not set. This will not respect the setting of the NODE_TLS_REJECT_UNAUTHORIZED environment variable.

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

It fails due to a self-signed certificate error, despite being told not to reject unauthorized certificates (my company can't get me the .pem file):

This prevents node-gyp and several other repos from being installed over npm for people such as me.

The workaround we've implemented is to edit your module and pass the option to not reject unauthorized:

Expected Behavior

To install the modules properly over npm, e.g.

Steps To Reproduce

1. In this environment...

Have a self-signed certificate in your certificate chain.

3. With this config...

export NODE_TLS_REJECT_UNAUTHORIZED=0

5. Run '...'

npm i node-gyp

or

npm i smartsheet

7. See error...

Environment

• npm: 8.8.0
• Node: 16.15.0
• OS: Windows 10 Enterprise
• platform: cygwin64

What

It seems that when the .size option is used, minipass-fetch expects the body size to be exactly equal to it, whereas node-fetch expects the body size to be lower.

This makes the option quite useless as it cannot be used to limit size. You can only use it if you know the exact body size in advance.

When

• Whenever .size is used in the options

Where

This is my config:

• Node.js v12.13.0
• minipass-fetch v1.2.1
• I use Windows, didn't test on Linux.

How

Steps to Reproduce

const fetch = require('minipass-fetch');

fetch('https://example.org', {
    size: 10000000
})
    .then(res => res.text())
    .then(console.log)
    .catch(console.error);

Current Behavior

FetchError: Invalid response body while trying to fetch https://example.org/: Bad data size: expected 10000000 bytes, but got 1256
    at C:\[...]\node_modules\minipass-fetch\lib\body.js:156:15
    at processTicksAndRejections (internal/process/task_queues.js:93:5) {
  code: 'EBADSIZE',
  expect: 10000000,
  found: 1256,
  errno: 'EBADSIZE',
  type: 'system'
}

Expected Behavior

If node-fetch is required instead, the source code of https://example.org is printed.

.size should be a size limit. minipass-fetch should accept smaller sizes and abort the download as soon as the limit is crossed.