IDEA COLLECTION: security features

[Jan9103]

Warning: this is mostly a idea dump right now.

Numng has a bunch of "security" features (checking that packages don't try to write a linkin outside of their package, allow_build_commands, etc).
But all this is absolutely useless since any package can just do anything it wants within a build_command, shell_config snippet, or within the library code.

Considering the nature of numng the argument can be made that the enduser will just have to validate all packages themselves and nothing can be done about it. but i hope to find a few things to do.

approach 1: restricting the features of a package

approach 1.1: disable package-features

• shell_config, nu_plugin, build_command
• depends, linkin
• etc

but what does it do then? if it provides a library that can still contain a virus

approach 1.2: domain-specific package formats

Examples:

• shell-theme contains a json, which gets read into $env.config.theme (or whatever)

Pro: No need to check some packages for viruses each time they update
Con: More complex package-format

approach 2: auditing

approach 2.1: marking within repos

it would be possible to add a "audited": true for versions within a registry and add a base-package variable "require_audit": true.
This would make it possible to just trust 1 person.
But the question is how far should the audit go? just checking that there is no rm -rf / or bash -c "$(curl virus)" is one thing, but what about security-vulnerabilities (and what is one? caching ssh keys?). and what about external programs or cargo-dependencies a package depends on?
Also how much work would that be? right now i could probably keep up with new packages on my own, but hopefully nu will become more successful.

approach 2.2: audit repositories

A seperate audit-repo would also be possible. I would suggest to "just" have a bunch of "trusted" git-commit-hashes in a list (newline seperated file?) and post-git-clone check it against it.
This way the audit-work could be distributed.
But this would cause issues if the auditor is slower than the registry.

approach 3: builtin anti-virus

and this is impossible. no anti-virus has a 100% success rate (unless it just marks everything as virus or is a audit-repo). and since everyone will be using the exact same opensource anti-virus it wont catch anything (unless a virus dosn't get updates and numng adds a detection for that specific one)

approach 4: help the user with auditing

• display build commands pre build
  • Problem: make can do anything, cargo build can have a custom build-script, etc.
  • Solution: additionally drop the user into a shell within the package before the build-command runs
• display a git-diff pre-update and ask for approval

approach 5: use gpg

if the last commit in a repo is gpg-signed by someone with trustlevel x in the endusers gpg keyring it gets marked as trusted.

this won't work on its own, but might be a nice addition to a repo-audit-flag or similar feature.