The issues the author sees with npm is why I started refactoring and publishing modules under my own scoped org.
Npm needs help and I hope Github can figure something out. They also need to figure out how to deal with merging npm ane Github Packages. I tried to get the same scope I have on npm on Github but it’s occupied.
I suppose I could publish on Github Packages with a different name than the npm version but MEH.
I suggest that this is a social problem, more than a technical one.
About dependencies: There are tools to see the dependency tree and the total size of any npm library. Less dependencies is less inherited code, and less code is better. A little bit of code is better than a little dependency.
About the runtime: Some things can be done, like what Deno is doing: https://deno.land/
Secure by default. No file, network, or environment access, unless explicitly enabled.
Further than that, it’s Node’s runtime design flaws what makes it impossible to be really secure from the dependencies you choose. For example: Any dependency can re-assign methods from node’s stdlib https package, intercepting web requests that were supposed to be secure.
As a final suggestion to any Node developer out there: Write your own stuff more offen. Node’s stdlib is great.
If you’re a frontend developer, you’re doomed anyways.
Secure by default. No file, network, or environment access, unless explicitly enabled.
Now that leads to some interesting ideas: What if there was a dependency management and security system combined that let you specify packages to depend on, and you had to explicitly grant each package desired sub-permissions, such as access to files outside the project’s own files, env vars, network URLs it could communicate with, global-level variables it could touch, etc. Each package could have sub-package dependencies, but a permission could only be granted to a sub-package if the parent package had been granted it by the top-level project.
Maybe an option somewhere too for whether any package trying to do something it doesn’t have permissions for should blow up the program, or be silently black-holed.
I guess this would be tough to do with any existing dependency management system. But hey we can dream right?
Maybe this can be done if our imaginary runtime only gives access to “the outside” (disk, net, env, stdout/err…) to the main function. In an OOP world, let’s say those are unique, irreproducible instances of some classes.
Then if any other part of the program needs access to that, you need to pass it as parameters, or using some dependency injection, inversion-of-control containers, etc.
Maybe we even improve global testability with this.
This is more or less how I understand a least part of capability oriented programming to work. I think E and Monte are the current big instances of this in practice, though last I checked, Monte was still in alpha. @Corbin would know more about this space.
That’s pretty cool from a testability standpoint too. I was envisioning more strict restrictions, like only network requests to explicitly authorized URLs, disk to explicitly authorized paths, etc. Authorize your HTTP client to only talk to my-api-endpoint.com, and you’ll know for sure that there’s no sub-dependency secretly sending data to evil-server.com.
Those restricted accesses could be instances extracted from the “global instance”.
For example, the disk access instance can generate other instances that allow accessing a portion of the disk. For example, just the user’s home directory.
The issues the author sees with npm is why I started refactoring and publishing modules under my own scoped org.
Npm needs help and I hope Github can figure something out. They also need to figure out how to deal with merging npm ane Github Packages. I tried to get the same scope I have on npm on Github but it’s occupied.
I suppose I could publish on Github Packages with a different name than the npm version but MEH.
About dependencies: There are tools to see the dependency tree and the total size of any npm library. Less dependencies is less inherited code, and less code is better. A little bit of code is better than a little dependency.
About the runtime: Some things can be done, like what Deno is doing: https://deno.land/
Further than that, it’s Node’s runtime design flaws what makes it impossible to be really secure from the dependencies you choose. For example: Any dependency can re-assign methods from node’s stdlib
httpspackage, intercepting web requests that were supposed to be secure.As a final suggestion to any Node developer out there: Write your own stuff more offen. Node’s stdlib is great.
If you’re a frontend developer, you’re doomed anyways.
Now that leads to some interesting ideas: What if there was a dependency management and security system combined that let you specify packages to depend on, and you had to explicitly grant each package desired sub-permissions, such as access to files outside the project’s own files, env vars, network URLs it could communicate with, global-level variables it could touch, etc. Each package could have sub-package dependencies, but a permission could only be granted to a sub-package if the parent package had been granted it by the top-level project.
Maybe an option somewhere too for whether any package trying to do something it doesn’t have permissions for should blow up the program, or be silently black-holed.
I guess this would be tough to do with any existing dependency management system. But hey we can dream right?
Maybe this can be done if our imaginary runtime only gives access to “the outside” (disk, net, env, stdout/err…) to the
mainfunction. In an OOP world, let’s say those are unique, irreproducible instances of some classes.Then if any other part of the program needs access to that, you need to pass it as parameters, or using some dependency injection, inversion-of-control containers, etc.
Maybe we even improve global testability with this.
This is more or less how I understand a least part of capability oriented programming to work. I think E and Monte are the current big instances of this in practice, though last I checked, Monte was still in alpha. @Corbin would know more about this space.
That’s pretty cool from a testability standpoint too. I was envisioning more strict restrictions, like only network requests to explicitly authorized URLs, disk to explicitly authorized paths, etc. Authorize your HTTP client to only talk to my-api-endpoint.com, and you’ll know for sure that there’s no sub-dependency secretly sending data to evil-server.com.
Those restricted accesses could be instances extracted from the “global instance”.
For example, the disk access instance can generate other instances that allow accessing a portion of the disk. For example, just the user’s home directory.
Yes! Quantifiable metrics! Let’s do more!
Two things that leap out at me:
1.0.0