Repository navigation
Problem when using a library that uses debug in Deno #981
Description
I use jsdom in a project in Deno. jsdom uses debug as a dependency:
└─┬ jsdom@25.0.1
├─┬ http-proxy-agent@7.0.2
│ ├─┬ agent-base@7.1.1
│ │ └── debug@4.3.7 deduped
│ └── debug@4.3.7
└─┬ https-proxy-agent@7.0.5
└── debug@4.3.7 deduped
Deno asks for permission for access to environment variables. Unfortunately debug accesses process.env directly and on requiring the module itself which leads to the following request by Deno.
┏ ⚠️ Deno requests env access.
┃ ├─ Object.toObject (ext:runtime/30_os.js:134:12)
┃ ├─ Object.ownKeys (ext:deno_node/_process/process.ts:54:40)
┃ ├─ Function.keys (<anonymous>)
┃ ├─ Object.<anonymous> (file:///home/krlwlfrt/work/krlwlfrt/calendar/node_modules/debug/src/node.js:124:30)
┃ ├─ Object.<anonymous> (file:///home/krlwlfrt/work/krlwlfrt/calendar/node_modules/debug/src/node.js:267:4)
┃ ├─ Module._compile (node:module:745:34)
┃ ├─ loadMaybeCjs (node:module:770:10)
┃ ├─ Object.Module._extensions..js (node:module:755:12)
┃ ├─ Module.load (node:module:662:32)
┃ └─ Function.Module._load (node:module:534:12)
┠─ Learn more at: https://docs.deno.com/go/--allow-env
┠─ Run again with --allow-env to bypass this prompt.
┗ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all env permissions) >
This goes against the principle of least privilege. Denying the request leads to an exception, because the code can't handle a rejection of that request with Deno's API.
Long story short: Could you please change the behaviour of your library, so that the process.env is not accessed on module load?
Activity
Qix- commentedon Dec 1, 2024
Er, No sorry. The whole point is that debug uses the environment to configure itself. Very common thing for logging libraries to do.
krlwlfrt commentedon Dec 1, 2024
Yes, sure. I get that. Totally valid point. I'm just asking if you could change it, so that the acccess to
process.envdoes not happen on module load and rather on a function/method call.Or that you access the variables that you need in
process.envdirectly - likeprocess.env.NODE_ENVor similar. And then parse the wholeprocess.envwhen it is needed for debugging purposes.Deno starts scripts without any permissions and then grants permissions as needed which is a huge security benefit. This is completely negated when I have to grant permission to access all environment variables.
Qix- commentedon Dec 1, 2024
I'm not quite sure what the difference is; environment variables are still being accessed. How does delaying their access provide any security benefit?
krlwlfrt commentedon Dec 2, 2024
I'm not completely certain on how your module works, but I can see from glancing over the code, that
inspectOpts, which contains the variables ofprocess.env, is only accessed when certain functions are called.I assume that these some/most of these functions are only called when the developer of a module that wants to debug it enables a the debug mode (via environment variable). When I changed the code to
inspectOpts = {}, JSDOM worked completely fine.So maybe it would only be necessary to access the full
process.envwhen it is needed... Or you could build inspectOpts only when one of the referencing functions is called instead of on module load.Deno is designed in a way, that the end user, who is running the script can grant access per environment variable, which is useful if you have data in your ENV that you don't want exposed to potentially thousands of node modules that might be installed in a project. If a module access
process.envinstaed ofprocess.env.VARIABLEthe end user has to grant access to all variables at once.Node.js is the complete opposite, where I/O, access to network, environment variables, etc. is unrestricted and any node module could do harmful things, without the end user even noticing.
I'm not sure if I'm able to communicate clearly, what I mean...
Qix- commentedon Dec 6, 2024
I mean I'm not really sure that anything I do is going to fix Deno's case. There are still millions of packages that will never upgrade to the latest version. This will always be a problem. It's also a questionable way to achieve security, if you ask me.
krlwlfrt commentedon Dec 8, 2024
Valid point.
I get that it's not that important to you. Would you consider it, if I'd open a PR with the changes I'm proposing?
Qix- commentedon Dec 8, 2024
It really depends on the changes but sure, I can take a look.
eikowagenknecht commentedon Dec 18, 2024
This would probably also solve another problem I'm encountering:
I'm running a Node.js application bundled by Vite and want to configure debug logging for the
grammylibrary (which usesdebuginternally) based on runtime configuration. Currently, I setprocess.env.DEBUGright after startup when my config is parsed, but this doesn't work after bundling - likely because the env var is read during import, and the bundler hoists all imports to the top.The proposed delayed loading would be a great solution for this use case, since it would allow setting the debug configuration before the actual environment variable reading happens.
Jobians commentedon Jun 3, 2025
This package requesting access to
envin Deno, how to disable it