| 31 Oct 2024 |
 emily | VC:L seems wrong, since the impact is itself to confidentiality (if you, say, rely on the Nix sandbox on a host that has sensitive information but then deploy binaries to separate hosts without that information that nonetheless now have access to data they shouldn't?) | 16:06:35 |
 puck | * the big issue is this vuln kinda depends on other vulns to be properly exploitable, and the sandbox isn't really default | 16:06:41 |
| puck | In reply to @emilazy:matrix.org
VC:L seems wrong, since the impact is itself to confidentiality (if you, say, rely on the Nix sandbox on a host that has sensitive information but then deploy binaries to separate hosts without that information that nonetheless now have access to data they shouldn't?) you can't overwrite existing store paths, only create new ones (that Nix won't fully consider valid) | 16:07:03 |
| emily | I guess AT:P is actually accurate to capture that you have to have enabled the sandbox to be vulnerable to it (otherwise you're… unconditionally vulnerable?) | 16:07:14 |
| emily | I was thinking more the read end of things. | 16:07:26 |
| puck | In reply to @emilazy:matrix.org
I was thinking more the read end of things. oh yeah, that's a bigger issue, but also it'd have to be world readable. | 16:07:59 |
| puck | In reply to @emilazy:matrix.org
I guess AT:P is actually accurate to capture that you have to have enabled the sandbox to be vulnerable to it (otherwise you're… unconditionally vulnerable?) yeah, so i think AT:N might be reasonable here | 16:08:30 |
| emily | world readable like a secret in /nix/store that's totally fine because all local users are trusted and we have the sandbox enabled? :) | 16:08:30 |
 connor (burnt/out) (UTC-8) | In reply to @joerg:thalheim.io
connor (he/him) (UTC-7): ok. I could imagine that it takes more cpu time to lookup those nested datastructure (i.e. pointer chasing). I suppose you didn't look at memory usage in comparison? I did; it allocates more memory from what I remember. I’ll try to update the numbers section with the output. | 16:08:45 |
 .. | what about Interpreter Profiling and Bottleneck Identification to optimize operations? do you know any open-source project where mathematical optimization is necessary to engage? | 16:10:44 |
 K900 | Well you could try, but Nix is currently very difficult to profile for a variety of reasons | 16:11:46 |
| K900 | And it's not something you can automate away | 16:11:50 |
| K900 | You need to actually be familiar with the code base and what to optimize | 16:11:59 |
| K900 | And it'll mostly be, like, low level C++ things | 16:12:14 |
| K900 | And not math | 16:12:23 |
| .. | I can do some statistical and complexity analysis over the project | 16:13:06 |
| K900 | That's really not the kind of thing that's going to help | 16:13:21 |
| K900 | The interpreter isn't slow because it's complex | 16:13:38 |
| K900 | It's slow because it was not written to be fast | 16:13:44 |
| K900 | If that makes any sense | 16:13:47 |
| .. | 😕 | 16:14:14 |
 @aloisw:kde.org | In reply to @k900:0upti.me
The interpreter isn't slow because it's complex I think they might mean "complexity" as in "algorithmic complexity". | 16:14:41 |
| K900 | Yes, I get that | 16:15:23 |
| .. | I'm looking for contributing some open-source projects to make my CV | 16:15:25 |
| K900 | And it's not going to help the interpeter | 16:15:27 |
| K900 | Because the interpreter is just ... not very designed to be fast | 16:15:40 |
| .. | K900: anyways, thanks for sharing your experience with us. | 16:17:43 |
| connor (burnt/out) (UTC-8) | If you want to do open source work and have a background in numerical analysis, check out https://herbie.uwplse.org/ | 16:19:04 |
| .. | not bad, thanks a lot | 16:20:38 |
| .. | connor (he/him) (UTC-7): I have just sent an email to them. many thanks. | 16:27:16 |
