| 19 Nov 2025 |
 WeetHet | At least I think SSL_CERT_FILE should just not be tampered with | 10:35:52 |
| WeetHet | Because it's something not-nix related in all cases | 10:36:09 |
 toonn | Is the sandbox enabled by default? | 10:38:40 |
| WeetHet | For FODs no | 10:40:40 |
| WeetHet | For non-FODs also no | 10:40:48 |
| WeetHet | I think | 10:41:00 |
| WeetHet | But why does it matter what happens when sandbox is disabled. If it's disabled all guarantees are off anyways | 10:41:42 |
| toonn | Since it's the common case it shouldn't be broken more than is unavoidable, no? | 10:42:34 |
| WeetHet | Setting SSL_CERT_FILE to a non-existent file doesn't fix anything, there are 2 options:
- The build would randomly break with an error which is difficult to trace to
SSL_CERT_FILE being /no-cert-file.crt
- The program would see that the file doesn't exist and ignore the variable entirely and still continue to access whatever it would if it was unset
| 10:45:01 |
| WeetHet | Neither behaviour is very nice honestly | 10:45:14 |
| WeetHet | Setting it to /no-cert-file.crt does nothing in 99% of the cases and breaks the remaining 1% which is using native macOS keychain in FODs | 10:46:32 |
| WeetHet | If you really want to set it to something set it to NIX_SSL_CERT_FILE but this is also incorrect since now the program that expects that it would use native keychain now starts using the .crt file | 10:47:33 |
|  Trond joined the room. | 10:48:09 |
| WeetHet | This is still better than having a non-existent file since it wouldn't break immediately and for nixpkgs you can't rely on some certificates being installed locally | 10:48:28 |
| WeetHet | So maybe this is the correct way for nixpkgs | 10:48:45 |
| WeetHet | But the current behaviour is objectively incorrect | 10:49:00 |
| toonn | I don't see how using the native keychain is right during builds. There's no way to manage that from Nix so it'd mean builds could never be pure. | 10:53:10 |
|  7karni joined the room. | 10:55:52 |
| WeetHet | I'm still talking about FODs | 10:55:56 |
| WeetHet | They can use whatever certs they want as long as the output hash matches | 10:56:22 |
| WeetHet | The other option still is
# Prevent SSL libraries from using certificates in /etc/ssl, unless set explicitly.
# Leave it in impure shells for convenience.
if [[ -z "${NIX_SSL_CERT_FILE:-}" && "${IN_NIX_SHELL:-}" != "impure" ]]; then
export NIX_SSL_CERT_FILE=/no-cert-file.crt
fi
# Another variant left for compatibility.
if [[ -z "${SSL_CERT_FILE:-}" && "${IN_NIX_SHELL:-}" != "impure" ]]; then
export SSL_CERT_FILE=$NIX_SSL_CERT_FILE
fi
| 11:00:46 |
| WeetHet | Which is still better than the current one | 11:00:55 |
| toonn | For FODs I agree, if the hash matches there's no purity problem. But that shell excerpt has nothing to do with FODs, no? | 11:31:28 |
 Randy Eckenrode | How would that break using Keychain? Do some libraries not try to use it if you set SSL_CERT_FILE? | 11:34:06 |
| Randy Eckenrode | (Even if it doesn’t exist.) | 11:35:09 |
| WeetHet | As far as I can tell this just uses the bundle of the variable is set | 11:35:19 |
| WeetHet | Given that unseting it fixes there run | 11:35:50 |
| WeetHet | * | 11:35:59 |
| WeetHet | * | 11:41:35 |
| WeetHet | * | 11:41:52 |
