| 18 Aug 2025 |
 raitobezarius | The only problem are well, these situations :) | 15:38:32 |
| raitobezarius | * The only problems are well, these situations :) | 15:38:35 |
| raitobezarius | In reply to @raitobezarius:matrix.org
It has bugs and it would take much more energy to take care of these bugs or cleanup after a massive disaster in production (which are not a virtual problem, they happened.) | 15:40:38 |
| raitobezarius | emily i verified what i wanted on cl/3852 | 15:43:19 |
| raitobezarius | emily also consider abandoning the alternative path at this point | 15:43:47 |
| raitobezarius | it confuse me always when i encounter while looking at the relation chain | 15:43:56 |
| raitobezarius | (we can always un-abandon it if needed) | 15:44:02 |
 emily | 3869 you mean? can do when I get back to the stack. possibly later today. still have some thoughts I need to post about 3870 (but I've been running it and it's been fine) | 15:56:01 |
| emily | need to get the reproducibility stuff sent out to Nixpkgs but hopefully I will get to that part of the backlog today | 15:56:30 |
| raitobezarius | dw | 17:47:03 |
| raitobezarius | emily does https://git.lix.systems/lix-project/lix/issues/966#issue-14037 ring a bell to you? | 22:34:58 |
| raitobezarius | sounds like something related to the range we just merged | 22:35:06 |
| raitobezarius | it's a no sandboxing case so… | 22:35:12 |
| raitobezarius | actually, the range is larger | 22:35:48 |
| emily | what's the tests right after the ones reported | 22:41:55 |
| emily | the flake ones are really slow but I guess not hours slow | 22:42:04 |
| raitobezarius | obviously this would be too easy if the ordering was consistent | 22:43:51 |
| raitobezarius | i don't know | 22:43:57 |
| raitobezarius | asking more info | 22:44:26 |
| 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
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? 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 |
