| 30 May 2021 |
 Arian | Interesting. I think it's something funky with oracle's setup. They aren't returning the entire certificate chain in the handshake | 13:58:06 |
 philipp | That's a really common issue, sadly. | 13:58:55 |
 hexa | das_j: and the nss version in stlabe doesn't change, should we rely on nss_latest for cacerts possibly? | 14:03:04 |
| hexa | * das_j: and the nss version in stable doesn't change, should we rely on nss_latest for cacerts possibly? | 14:03:12 |
 andi- | nss_latest. -> cacert -> world rebuild-ish | 14:07:08 |
| hexa | yup | 14:07:17 |
| andi- | The idea of nss_latest was to exactly avoid world rebuilds | 14:07:18 |
| hexa | fair | 14:07:24 |
| andi- | while still being able to upgrade firefox | 14:07:28 |
| andi- | One option is always to only update cacert indepdendent of NSS | 14:10:28 |
| andi- | Still a world rebuild but not as high impact as changing NSS | 14:10:41 |
| hexa | on master cacert was already decoupled from nss | 14:30:19 |
| hexa | by you :D | 14:30:26 |
| andi- | Yeah :-) | 14:41:07 |
|  rizary_andika (@rizary_:matrix.org) (@rizary:matrix.org) joined the room. | 17:42:25 |
 kunrooted | I haven't asked in here yet
I'm currently writing a paper on security of Nix and NixOS
maybe someone will suggest other ideas to cover in that paper? | 17:50:26 |
| philipp | Challenges of having to update entire channels v.s. being able to update a single package. | 18:16:03 |
| andi- | Benefits of updating entire channels vs. a single package | 18:17:27 |
| 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 |
