| 30 May 2021 |
 andi- | in other words: Being able to specify a single source code revision in which all of the dependencies of whatever system state are not affected by a defect. | 18:18:00 |
| andi- | kunrooted: being able to inspect the dependency graph of your builds for both build and runtime. | 18:18:49 |
 kunrooted | In reply to @andi:kack.it
in other words: Being able to specify a single source code revision in which all of the dependencies of whatever system state are not affected by a defect. hm, gonna research that | 18:19:58 |
| kunrooted | In reply to @andi:kack.it
kunrooted: being able to inspect the dependency graph of your builds for both build and runtime. in order to see what's used? | 18:20:15 |
| kunrooted | I mean, from what I can tell right now, atomic upgrades can be security nightmare | 18:20:37 |
| kunrooted | I also noticed the possibilities of supply chain attacks, especially if you use some weird NUR/Hydra things, not official ones | 18:21:11 |
| andi- | Oh yeah, if you run unstrusted builds (or worse software)... | 18:22:12 |
| andi- | * Oh yeah, if you run unstrusted builds (or worse: software)... | 18:22:19 |
| kunrooted | In reply to @andi:kack.it
in other words: Being able to specify a single source code revision in which all of the dependencies of whatever system state are not affected by a defect. so you mean like there's a package X and it was in version 1.0 and after update 1.1 it breaks something so you can easily take control over it and stick to 1.0 version and dependencies used by 1.0 without a need to upgrade? | 18:22:47 |
| kunrooted | asking to make it clear to me, I'm not a native English speaker and I'm feeling weird after first shot of Pfizer yesterday | 18:23:20 |
| kunrooted | In reply to @andi:kack.it
Oh yeah, if you run unstrusted builds (or worse: software)... exactly | 18:23:24 |
| andi- | Well for starters: are you a Nix user/hacker? Just so I pick the right words. | 18:23:56 |
| kunrooted | both I'd say | 18:24:10 |
| andi- | ok | 18:24:25 |
| kunrooted | I even tried making NixOS play nice in Bedrock but failed (for now only, I'll continue research in that matter) | 18:24:30 |
| andi- | So what I meant to say is: If we today encounter an issue with OpenSSL $version and we make a commit that bumps OpenSSL to $version+1 that is no longer affected by $heartbleed then we have a single git commit id that we can use to tell people: If you run anything >= $commit then you systems are not affected anymore. | 18:25:59 |
| andi- | And we can also say: If you run < $commit you are (very?) likely affected | 18:26:15 |
| kunrooted | In reply to @kunrooted:matrix.org
I even tried making NixOS play nice in Bedrock but failed (for now only, I'll continue research in that matter) https://github.com/bedrocklinux/bedrocklinux-userland/issues/221
link related | 18:26:23 |
| kunrooted | In reply to @andi:kack.it
So what I meant to say is: If we today encounter an issue with OpenSSL $version and we make a commit that bumps OpenSSL to $version+1 that is no longer affected by $heartbleed then we have a single git commit id that we can use to tell people: If you run anything >= $commit then you systems are not affected anymore. yeah, quite simple concept I think | 18:26:46 |
| andi- | Whilst with Debian, Ubuntu, RHEL, .. you'd have to stick to timestamps (uploaded to the repos) and package versions (that contain a fix) | 18:26:53 |
| andi- | And to make it worse tell everyone which of the many repos have been updated | 18:27:19 |
| andi- | Granted in practice that is slightly different but you get the picture. | 18:27:28 |
| andi- | You have a lot more moveable parts that have to be checked. | 18:27:38 |
| kunrooted | yeah, on non-Nix packages you're forced to that and you have no ability to use specific commits of software | 18:27:41 |
| kunrooted | I liked that | 18:28:08 |
| andi- | a) do I have the security repo?
b) did I update the repo before installing upgrades/updates
c) Was my mirror up2date? | 18:28:11 |
| kunrooted | * I liked that in Nix and especially in flakes where I have more control over that | 18:28:22 |
 philipp | andi-: My question on non nixos systems is usally "what version is that package", then list it via the package manager and check whether the version of that specific package is sufficient. | 18:29:18 |
| kunrooted | btw, how well does single-user install of Nix work? | 18:29:44 |
| kunrooted | because when all users have an access to /nix/store, it doesn't sound good, or maybe I'm not too experienced to block it in other way than just performing a single-user installation of Nix on non-NixOS | 18:30:21 |
