| 19 Aug 2025 |
 emily | OpenSSL is not nearly as bad as it was a decade ago | 16:53:27 |
| emily | though still not great | 16:53:30 |
 just1602 | This is still awesome news to read IMO | 16:55:16 |
 jade_ | the one good thing about crypto code is if it were producing wrong results you would damn well know about it, so the limit of what can be screwed up in practice is pretty low and limited to mostly side channels and protocol screwups. but we are using primitives sooooooo it's really not so important regardless | 18:21:45 |
| jade_ | it is on release branches, the only problem is with if you are using 1. lix's own packaging and 2. on a tag | 18:27:35 |
| jade_ | if we wanted to kill a dependency by using openssl in place of libsodium that sounds good to me, i am not at all fussed either way. | 18:28:26 |
| jade_ | p low on my concerns priority list in the end | 18:28:38 |
 raitobezarius (DECT: 7248) | In reply to @aloisw:julia0815.de
Libsodium also had quality incidents in the past, like https://github.com/jedisct1/libsodium/commit/ad4584d45590654b9d863ced90d2b2561d5cfbda . hm oof indeed | 18:33:53 |
| jade_ | however, as stated, crypto code breaks very loudly and we are not encrypting anything confidential | 18:34:12 |
| raitobezarius (DECT: 7248) | oh lol vcunat intervening in that commit in the comment area | 18:34:25 |
| jade_ | so it is very hard for them to fuck up in a way that materially affects us | 18:34:30 |
| jade_ | ... besides that | 18:34:54 |
| raitobezarius (DECT: 7248) | yeah, i can review a patch moving to openssl if needed | 18:36:34 |
| raitobezarius (DECT: 7248) | i doubt that openssl can fuck up ed25519 but also it's a bit frightening because i think most people using ed25519 use it via libsodium | 18:38:07 |
| raitobezarius (DECT: 7248) | https://git.lix.systems/lix-project/lix/issues/969 cc Kira as aloisw pointed very good reasons to perform that switch | 18:42:10 |
| jade_ | raitobezarius: is your epyc still available for room-heating (mass scale remote builds)? i um, have a use case for a large scale change by messing with the pytest packaging. | 18:42:58 |
| raitobezarius (DECT: 7248) | yes it is | 18:43:05 |
| jade_ | awesome | 18:43:09 |
 Rutile (Commentator2.0) feel free to ping | is it relevant for me to know what you are (planning to) doing? | 18:45:26 |
 helle (just a stray cat girl) | sweats profusely at this idea oh no jade, I am worried | 18:45:54 |
| jade_ | setting dontWrapPythonPrograms = true on it | 18:47:15 |
| jade_ | globally | 18:47:19 |
| Rutile (Commentator2.0) feel free to ping | raitobezarius: can you punch ci/pipeline for 3992? it just says "verfied -1" without any explenation and doesn't update on push | 18:47:25 |
| emily | I'm pretty sure nixpkgs-review on a pytest change will rebuild most of the package set | 18:47:27 |
| jade_ | i also think this will happen :P | 18:47:36 |
| emily | I would recommend testing direct dependencies only (which will still be a billion things) | 18:47:37 |
| raitobezarius (DECT: 7248) | In reply to @commentator2.0:elia.garden
raitobezarius: can you punch ci/pipeline for 3992? it just says "verfied -1" without any explenation and doesn't update on push it's the ASAN flakiness | 18:48:05 |
| jade_ | hm, is there a way to bazel uquery 'rdeps(//:pytest)' in nix? | 18:48:06 |
| raitobezarius (DECT: 7248) | i kicked it again | 18:48:08 |
| emily | trofi has a script lying around somewhere. you can also just rg | 18:48:29 |
