51–60 of 65 posts
Earlier quoted context omitted.
Heavily down voted, which is fair because I didn't really explain what I meant, which was: Would using LLM's to parse the generated diffs, as a first pass, be useful/efficient for spotting and interpreting discrepancies?
when your goal is to improve security, the unreliability that comes with LLMs is not the answer.
Earlier quoted context omitted.
Heavily down voted, which is fair because I didn't really explain what I meant, which was: Would using LLM's to parse the generated diffs, as a first pass, be useful/efficient for spotting and interpreting discrepancies?
when your goal is to improve security, the unreliability that comes with LLMs is not the answer.
https://arxiv.org/abs/2405.17238 https://arxiv.org/abs/2404.02056 https://arxiv.org/abs/2404.19715 https://www.sciencedirect.com/science/article/pii/S266638992...
Earlier quoted context omitted.
Heavily down voted, which is fair because I didn't really explain what I meant, which was: Would using LLM's to parse the generated diffs, as a first pass, be useful/efficient for spotting and interpreting discrepancies?
It could work for classifying honest/innocent differences. However, LLMs are incredibly naive, so they could be easily fooled by a malicious actor (probably as easy as adding a comment that this is definitely NOT a backdoor).
Earlier quoted context omitted.
when your goal is to improve security, the unreliability that comes with LLMs is not the answer.
I don't think this is a relevant take. Your goal is to implement a system to automatically scan countless packages and run a heuristic to determine if a package is suspicious or not. You're complaining about false positives/false negatives while ignoring that packages that not checking packages at all is not an improvement.
This is why I like what Go does, where you're downloading from Git directly (optionally proxied through Google, yes)
Related: Proxying can be disabled by setting the environment variable GOPROXY=direct [0]. I put it in my bashrc. [0] https://www.practical-go-lessons.com/chap-18-go-module-proxi...
Earlier quoted context omitted.
TBH, "somewhat immutable" is not "immutable". The Go approach aids to limit the effects of an attempted attach where you're misled into building your project with different code than originally intended, but does nothing to guarantee continuity over time of dependencies being available. For that you have to rely on vendoring. The crates.io approach instead defends you both from a dependency changing silently and from…
As kibween noted above, crates.io can be changed if there's a "good reason" so it's not truly immutable either. Go does not delete modules from the module proxy except for copyright/legal reasons (I suspect crates.io would delete for these reasons too), and additionally the checksums of all modules are published in a tamper-proof transparency log ( https://sum.golang.org/ ) so if they did alter or delete a module, it…
1. The proxy delivers the changed code while issuing a warning to the end user, which if the warning is overlooked would mean that the checksum achieved nothing.
2. The proxy ignores the changed code while delivering the old code and a warning to the user, which would introduce the same concern raised here that the code that gets delivered and the code listed on Github have no requirement to be the same.
3. The proxy refuses to deliver any code and issues a warning to the user, which would mean that anyone can effectively remove their code from the proxy by simply changing the tag to something else.
I would be interested to know which one Go actually goes with, because none of these are ideal.
Earlier quoted context omitted.
> Deterministic compilation is the best way to let people validate what they are downloading from repositories is what is in the codebases. "the best way"? Please make the argument for why. To do it properly, you must steel-man the alternatives (not shoot down straw-men)
Because deterministic compilation lets you (or someone else) do this automatically. If you introduce a backdoor into the compilation step, you run a much greater risk of detection. As long as there are multiple machines compiling packages and verifying whether the checksums match, any single backdoored machine will immediately be caught. This is much more important for package managers that do their own builds and sh…
It is important to remember that crates.io doesn't store binaries.
Earlier quoted context omitted.
I'm not sure what is meant by "downloading from Git", I assume you mean downloading from Github. And Github is far less secure than what crates.io does, because crates.io is immutable (once published, uploaders can't change anything without opening a support ticket which will get rejected if they don't have a good reason), whereas Github history is trivially rewriteable. This means that if you rely on "v1.2.3" of a l…
It’s interesting you even have to point this out. Maven solved this and other problems literally decades ago but the repository packaging wheel keeps getting reinvented. For example, here’s the page on Maven Central’s immutability policy: https://central.sonatype.org/publish/requirements/immutabili...
Deterministic compilation is the best way to let people validate what they are downloading from repositories is what is in the codebases.
> Deterministic compilation is the best way to let people validate what they are downloading from repositories is what is in the codebases. "the best way"? Please make the argument for why. To do it properly, you must steel-man the alternatives (not shoot down straw-men)
How crazy would it be to have a package repository that also builds the artifacts it distributes? You’d need a high barrier to entry to save on costs and time sifting through garbage. Perhaps it’s this high barrier that would prevent such a repository from taking off though. Perhaps this is just a really dumb step on a path leading back to simple checksum validations… though with those, you’re only validating that wh…
Because what you want exists and has a thriving community, and a package set that outclasses, well, statistically every other package manager in existence.
I swear, it's a daily occurrence for me to see software engineering challenges posited here as damn near impossible that Nix has been solving for over a decade.
What if you could run a single command and have exact insight to the source you're using for every single package on your system with the context of the dependency graph it exists in.
I cannot wait for this wave to crash and for people to realize how much engineering effort is reduced by using Nix. And that all of these things they know they want for years, already exists. But hey, the syntax takes time to get used to and how do you compare that against the countless blog posts and hours and institutional knowledge you need to actually use docker properly. And then later on some Go-based SBOM tool made by a VC-backed startup that fundamentally still does an inferior job to Nix. Sigh.
Well anyway I guess nix will keep being used by hedge funds, algorithmic traders, "advanced defensive capabilities" companies, literal (launched, in space) satellites, wallet manufacturers, etc, while everyone else listens to the syntax decriers.