 | Lix Development | 408 Members |
| (Technical) development of Lix, the package manager, a Nix implementation. Please be mindful of ongoing technical conversations in this channel. | 135 Servers |
| Lix Development | 408 Members |
| (Technical) development of Lix, the package manager, a Nix implementation. Please be mindful of ongoing technical conversations in this channel. | 135 Servers |
| Sender | Message | Time |
|---|---|---|
| 19 Aug 2025 | ||
 Kira | hi! i noticed that libsodium, one of the crypto libraries needed for lix, is lead by someone who thinks that vibe coding is an effective way of building software: https://www.reddit.com/r/vibecoding/comments/1kmptbo/my_first_significant_100_vibecoded_project. i don't know that much about libsodium, but just that fact that lix relies on a crypto library managed by one person already makes me nervous. it looks like it was added to support ed25519 signing keys in 2015 for binary caches (https://git.lix.systems/lix-project/lix/commit/e0def5bc4b41ad09ce3f188bf522814ef3389e1f), but it looks like openssl supports them now too. would it be worth it to replace it with openssl and drop the dependency? | 01:42:40 |
| Kira | (i was mainly looking into jedisct1 because i was looking more into who works on dnscrypt-proxy2, but also noticed he maintains libsodium) | 01:46:47 |
| Kira | * (i was mainly looking into jedisct1 because i was looking more into who works on dnscrypt-proxy2, but also noticed he built & maintains libsodium) | 01:48:49 |
 emily | it would take an awful lot of vibe coding to get libsodium down to OpenSSL code quality tbh | 03:05:46 |
| Kira | lol well i was mainly just thinking openssl would be the most obvious alternative choice since it's already used for hashing - and it seems redundant to rely on two different crypto libraries | 03:19:52 |
| Kira | * lol well i was mainly just thinking openssl would be the most obvious alternative since it's already used for hashing - and it seems redundant to rely on two different crypto libraries | 03:21:56 |
| Kira | i don't know enough about either libsodium or openssl, but thought it would be worth it to point out | 03:32:04 |
 Grimmauld (any/all) | maybe, but openssl does get more eyes on it. The concern is valid. | 06:37:05 |
 raitobezarius | In reply to @kira:jakira.space I personally know jedisct1, it's certainly disappointing to see that but I suspect that there's much more than Lix in the boat with libsodium, if libsodium started to have a massive decrease in quality due to AI stuff being introduced or whatever, we would definitely take an action and move away FTR, I don't think jedisct1 is writing much cryptography code in libsodium given that it's a fork of djb's NaCl and the NaCl team is djb, Tanja Lange and Peter Schwabe so… I think this is going to be fine. In the ideal world, we would just move to RustCrypto once we can go to Rust and this will make this problem nonexistent. On the more general problem, I think that there will be plenty of people who believe that vibe coding is an effective way of building software and who will be maintainers of some of our dependencies, I would rather err on waiting until a dependency degrade rather proactively replacing it otherwise we will soon run into resource issues. | 13:27:51 |
| Kira | ok, yeah that makes sense | 13:29:26 |
| raitobezarius | but still thanks for the heads up, appreciated! | 14:02:49 |
 Unhooked Spirits joined the room. | 15:09:45 | |
 aloisw | I actually thought about replacing libsodium usage with OpenSSL some time ago as we already use the latter, and I don't see how depending on two crypto libraries is better than depending on one. However I'm not confident I can do it without introducing security issues. | 16:22:18 |
| aloisw | Libsodium also had quality incidents in the past, like https://github.com/jedisct1/libsodium/commit/ad4584d45590654b9d863ced90d2b2561d5cfbda . | 16:23:31 |
 just1602 | I understand that the switch to rust crypto isn't for tomorrow, but I don't know if it would be well invest energy to try to remove libsodium to only use openssl. Back in the days when libressl fork off openssl, they were having a tumblr where they detailed the first months of development and they were explaining all the cruft they were removing and all the C error they were fixing, and it really make me lost any faith I could have into openssl :/ | 16:50:18 |
| just1602 | But I'm absolutely no cryptographer, so it's more my take on tech dept pay back investment more then on cryptography. | 16:50:57 |
| just1602 | * But I'm absolutely no cryptographer, so it's more my take on tech dept pay back investment rather then on cryptography. | 16:51:13 |
| aloisw | We're already depending on OpenSSL both directly and via curl. | 16:51:21 |
| 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 | In reply to @aloisw:julia0815.dehm 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 | 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 |