| 30 May 2021 |
 Arian | It seems NixOS is missing DigiCert's new Root CA. E.g. i can not curl https://signup.cloud.oracle.com | 11:47:00 |
| Arian | How is the nixos trust store kept up to date? | 11:59:36 |
 das_j | In reply to @arianvp:matrix.org
How is the nixos trust store kept up to date? nss's trust store (mozilla) ist used | 13:56:56 |
| das_j | see pkgs/data/misc/cacert | 13:57:38 |
| 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 |
