Dependency Security

[slayernominee]

I tried stylix out today and came to an issue? I'm somewhat concerned about. The flake introduces quite a lot of dependencies, some of these dependencies have quite little attention like:

Repo	Stars	Last Update
tomyun/base16-fish	37	5y ago
SenchoPens/fromYaml	3	2y ago

and that in itself is no problem at all, but it just means, if these dependencies end up for some reason compromised, and the flake lock is updated as a whole, these changes might go unnoticed and end up in the stylix project (not necessarily executed, but might be possible if the respective modules are used) which could be kinda disastrous.

So imo it should be an aim to reduce the dependencies by a lot, incorporating the respective code into stylix itself (obviously in accordance with their project licenses). As there seem to be anyway little updates to the 2 repos i mentioned as example this doesn't seem like a big problem to me.

[slayernominee]

please let me know your thoughts about this, I'm not sure if this really is a concern for the project, but for me it seems at least somewhat like a potential attack vector, that isn't totally obvious.

[0xda157]

if these dependencies end up for some reason compromised, and the flake lock is updated as a whole, these changes might go unnoticed and end up in the stylix project (not necessarily executed, but might be possible if the respective modules are used) which could be kinda disastrous.

yes, this is a risk of including dependencies. note that the vast majority of our public flake inputs do not import any nix code, which is much lower risk.

So imo it should be an aim to reduce the dependencies by a lot, incorporating the respective code into stylix itself

if you're up for maintaining them, feel free to bring in-tree some of the base16-*/tinted-* flake inputs. we (the Stylix core team) currently have very limited resources and other things higher on the priority list.

[slayernominee]

Okay, I'm gonna work on this and once ready make a PR

[trueNAHO]

some of these dependencies have quite little attention like:

Repo	Stars	Last Update
tomyun/base16-fish	37	5y ago
SenchoPens/fromYaml	3	2y ago

and that in itself is no problem at all, but it just means, if these dependencies end up for some reason compromised [...] these changes might go unnoticed

One could argue that compromises are much easier to hide in highly active projects, making inactive projects more reliable and easier to vet.

if these dependencies end up for some reason compromised, and the flake lock is updated as a whole, these changes might go unnoticed and end up in the stylix project (not necessarily executed, but might be possible if the respective modules are used) which could be kinda disastrous.

yes, this is a risk of including dependencies.

I regularly review updated dependency revisions for suspicous pulled commits and whether the updated revisions and hashes match the upstream target and not a maliciously dangling PR commit, which GitHub sadly allows.

Nevertheless, there are IMHO much easier ways to transitively compromise Stylix users through for example Nixpkgs and Home Manager.

note that the vast majority of our public flake inputs do not import any nix code, which is much lower risk.

So imo it should be an aim to reduce the dependencies by a lot, incorporating the respective code into stylix itself

if you're up for maintaining them, feel free to bring in-tree some of the base16-*/tinted-* flake inputs.

IMHO, vendoring these inputs for false security is not worth it.

For example, pulling more code in-tree goes against #2289 whose main purpose is

to drastically reduce the in-tree code size and complexity

-- #892 (comment)

FYI, replacing most external inputs with in-house implementations is already planned to resolve functional limitations, which merely coincidentally resolves your "security" concern.

[slayernominee]

IMHO, vendoring these inputs for false security is not worth it.
For example, pulling more code in-tree goes against #2289 whose main purpose is

well a lot of these also simplify the codebase imo, like having just the mustache file makes it easier to read, as well as installing the firefox addon via group policy instead of as a nur package.

in the pr i'm preparing i try to keep these inclusions minimal, often its only a single relevant file which stylix uses in these repos.

there will be a few more files, but an additional theme file is imo worth having one less dependency. if not, i can also make a pr for only the firefox addon, which can be easier installed via group policy instead of the nur package.