seeking a better UX for permission management

[sramam]

I am new to deno, so this is somewhat of a mix between a noob-question and a feature request.
Hopefully an issue is the right way to start.

The security aspects of the deno runtime are particularly attractive to me.
However, so many of the modules I am exploring seem to default to a deno install -Afq ...

It's a bit disappointing to see that the first thing one does is to actually disable the security sandbox.

But then, looking at the current command line required to make this work with fine grained permissions, its clear
this is easier said than done. In general, the finer control one desires, the more unwieldy it becomes.

As a newcomer attracted to the security messaging, I'd like a better UX for

1. inspecting the permissions required by a dependency
2. auditing changes between versions of a dependency
3. reverse attribution of permission to a dependency
4. determining if a is permission optional or required for the working of a module (net access for analytics)

All of these look unwieldy if not impossible to accomplish with current tooling.

Wonder if any thought has been given to allowing the developer to register a permission at point of use
and then generate a list of permissions required as an auxiliary artifact - permissions.json or permissions.yml.
This would keep with the single file philosophy of deno but solve the manageability issues raised above.

Something along the lines of:

// within some file in a module that needs permissions,
import { registerPermission } from 'https://deno.land/std@0.99.0/permissions/mod.ts'

const required = true // controls optionality of the permission - allowing limited mode operation or not. 
registerPermission('env', ['VAR1', 'VAR2'], required)
// and so on.

And then from the cli

deno permissions
# or 
deno install

which would generate a white list required and append it to a permissions.json|yml file at point of use.
The file can then be used to provide the end consumer the UX desired - by the deno CLI or 3rd parties.

It seems deno is doing most of hard work of tracking and validating. Just that the end user has no insight,
resulting in deno install -Afq ...

[crowlKats]

inspecting the permissions required by a dependency

Not possible. Dependencies are checked at runtime; so either you have to run the dependency and see what it asks, or read through the codebase.

reverse attribution of permission to a dependency

What do you mean? Do you mean specific perms for a specific dependency?

determining if a is permission optional or required for the working of a module (net access for analytics)

again, not possible.

The whole registerPermission is not possible as well due to this being at runtime

[sramam]

Not possible. Dependencies are checked at runtime; so either you have to run the dependency and see what it asks, or read through the codebase.

again, not possible.

The whole registerPermission is not possible as well due to this being at runtime

My understading of Deno and it's eco system is very shallow and barely beyond the documentation pages.
Worry that I am on the wrong track here, hence the noob disclaimer. Please pardon my ignorance and indulge me a bit further.

It seems that pseudo-run is the term that would best meet my expectations.

Should it not be possible to break up the runtime validation into a 2-step for fine grained control and manageability?

deno install https://some-dependency-url`
# ...  more installs here

# the 2-step:
deno permissions --output ./permissions.json|yml
deno run --permissions ./permissions.json|yml ./main.ts

deno permissions is the pseudo-run that

• starts with an empty list of permissions,
• collects the permissions necessary just as the current run command does
• but instead of validating, dumps that list to a file for user benefit

The generated list can be inspected, modified as necessary, and used to run programs in the permissions regime the user deems acceptable.

For people who are happy with the current state of affairs, they can continue with deno install -Afq ....
Seat-belts are optional after all.

The install -Afq ... thing seems the natural outcome of current implementation. The worst of this is it becomes the "documented" way to install something.

For example, from nest.land installation guide,

Please make sure to use the -A flag to grant all permissions to eggs, so you can enjoy all features seamlessly.

Does it really get much worse than this? A package manager whose job it is to download and upload arbit blobs of code
is asking for a blanket waiver of all permissions - now and into the future.

To be fair, this is from a good citizen that is well-meaning and well-documented. In the next paragraph, they make permissions claims necessary.
However these have to be either be taken at face value or by auditing the code.

The "audit your dependencies" recommendation, much like a paper-raincoat, seems designed to fail.

Well technically, I can run the program without permissions, wait for the complaints and then grant them, but that's
why this issue was labelled title "UX improvements". It's unlikely I'll do it at the finest grain possible on a continual basis.

Am I alone here in feeling a bit naked from a security perspective?

---

reverse attribution of permission to a dependency

What do you mean? Do you mean specific perms for a specific dependency?

Yes - an ability to attribute "this permission" was requested from "that dependency".
If the permissions list can be generated, this should be easy enough I imagine.