| 31 Oct 2024 |
 emily | I think AT:P implies that the actual attacker has to be present at the machine, so I agree that that part is inaccurate too. | 16:02:21 |
 puck | In reply to @emilazy:matrix.org
I think AT:P implies that the actual attacker has to be present at the machine, so I agree that that part is inaccurate too. that'd be AV:P i think | 16:02:41 |
| puck | AT:P just means the system has to be misconfigured | 16:02:49 |
| emily | sigh why do tehy have to use inscrutable acronyms | 16:03:05 |
| emily | * sigh why do they have to use inscrutable acronyms | 16:03:12 |
 .. | are there areas where they need mathematical optimization? | 16:03:26 |
| emily | in any case it's definitely not 1.0 and I hope the CVSS score wasn't just massaged to make it so… | 16:03:29 |
| emily | In reply to @khaleghi:matrix.org
are there areas where they need mathematical optimization? we explicitly don't do any kind of SAT or anything | 16:03:59 |
| emily | unlike almost every other package manager :) | 16:04:05 |
 K900 | In reply to@khaleghi:matrix.org
are there areas where they need mathematical optimization? Not really, no | 16:04:19 |
| K900 | At this point the slowest part of Nix is, by a long shot, the interpreter itself | 16:04:32 |
| K900 | And that needs less fancy maths and more rolling up sleeves and profiling for a week | 16:04:50 |
| puck | In reply to @emilazy:matrix.org
in any case it's definitely not 1.0 and I hope the CVSS score wasn't just massaged to make it so… if i change it to CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N it ends up a 2.4 | 16:04:58 |
| puck | the big issue is this vuln kinda depends on other vulns, and the sandbox isn't really default | 16:06:23 |
| 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 |
