>Every package install is checked against the threat feed and it raises an exception if we find something malicious being installed.

So your solution is to reinvent signature based antiviruses, like Norton Antivirus and McAffee?

The problem with these 2000s approaches were that attackers could:

1- Fuzz their payloads so that they are never the same and they don't trigger detection.

2- Offload payload mechanisms so that your monitoring system needs to play cat and mouse. For example, what if the malicious code does wget https://IP/file, will you detect wget commands? Will you scan for whatever looks like a URL? Ok, what if they do "another_package_manager_like_flatpack malicious_package", will your scanner implement all package managers? What if they construct the url? "protocol + "://" + domain + file" surely your global hook thing will notice that is a url and how it is downloaded and inspect those contents as well?

3- The attacker can control the timing and infect every user at the same time, especially if they control the update mechanism of users whose security policy is to keep things patched. Even if the malicious update is not simultaneous, the malicious update can start distribution, and the attack only triggered months later (simultaneously) when enough users have downloaded it (beating latency policies).

The only solution is to do actual work and either write the thing you are trying to offload to the 'open source community, or to actually write it yourself. But of course more work is going to be put into the possibility of a magical easy solution, than on an deteriministic hard solution.

▲

captn3m0 5 hours ago | parent | next [-]

(Author here). I don’t really care _how and what you decide to do with it_, the post is about package managers giving users the ability to decide.

Dependency Cooldowns can be implemented with global hooks, git-commit-signing checks can be implemented, LLM-scans can be implemented, someone can run the code in a jail and use the eBPF logs to publish a threat feed.

Modern language packaging is also _source available_, and we have a huge leg up over traditional virus scans - we have the source code almost always. You can do amazing static analysis.

Yes, it’s hard work. But package managers are doing it already. Yay and Paru both now support hooks. I’m offering to help for AUR to publish more metadata: https://lists.archlinux.org/archives/list/aur-dev@lists.arch...

▲

oefrha 7 hours ago | parent | prev | next [-]

That’s just a wall of text for “malware detection is hard, write everything yourself, don’t use third party”. Thanks for the insight, I guess.

▲

TZubiri 6 hours ago | parent [-]

>Malware detection is hard Hell yeah

>Write everything yourself, don't use third party

No, you are exaggerating my point of view so that it's easier to dismiss and so you don't have to evaluate the proposition.

A mix of a Strawman and a false dilemma.

"Write more and use less third party, than you are currently using." would be more accurate.

Consider this, the package manager I use has not been infected in over a decade, the package manager you are suggesting improvements for is currently distributing malware as we speak.

Doesn't that invite you more to learn about our ways? It takes effort, especially if you consider what I'm writing to be a wall of text. But unless you consider 'shipping faster' to be a worthy tradeoff for cybersecurity, then it's worth it to learn, no?

▲

weinzierl 6 hours ago | parent [-]

"Consider this, the package manager I use has not been infected in over a decade [..]"

Which package manager do you mean?

	▲	lelanthran 4 hours ago \| parent [-]
		>> "Consider this, the package manager I use has not been infected in over a decade [..]" > Which package manager do you mean? Apt, rpm. Anyway, don't you think that this line: > Which package manager do you mean? Gives off "'No way to prevent this problem', says users of only package manager that has this problem" vibes?

▲

self_awareness 6 hours ago | parent | prev [-]

These are not 2000 approaches, these are approaches used today (signature based detection).

The difference is that in 2000s the signatures were written by hand and described static file info, today they're often autogenerated and describe the system behavior, either by looking at one executable, or a whole network of computers. But it is still signature based detection. Since they describe the program behavior, not the program structure, then if the program itself stayed the same (the sequence of system api calls stayed the same), no runtime packing/obfuscation makes a difference to a signature. Unless obfuscation changes the behavior.

Also security is not binary, it's layered. Sometimes we can address an attack vector by using multiple levels. And sometimes it's simply worth checking for low hanging fruits if only to make the attack more expensive. The "cat and mouse" game is always about the cost of attack and cost of defense, if we raise one then we win in this area, unless the other party finds a way of lowering the cost of their side. Or unless they pay an unexpected amount of cost, for example in state sponsored malware.

By the way, some security solutions also have actual parsers for example for PowerShell, so they can actually detect string concatenation that constructs the URL.

▲

TZubiri 4 hours ago | parent [-]

>Also security is not binary, it's layered. Sometimes we can address an attack vector by using multiple levels. And sometimes it's simply worth checking for low hanging fruits if only to make the attack more expensive.

Defense in depth and multiple redundant layers is a legitimate technique.

But it should usually be 2 virtually unbreachable layers, like 99.999% effective, because there may be a memory leak somewhere and it will be exploited once per year or so. Because 1 layer is just shy of 100%, 2 layers is already overkill, we would do 1.1 layers if possible (but of course it's not)

Maybe if it's a multibillion dollar product you'd add a third or more impenetrable layers.

And once you have those two redundant security layers, then you add deterrents and monitors, if you want.

But relying on security measures that will maybe catch 20% of attacks or 40% of attacks as a main mechanism will lead to what some have described as swiss-cheese models. https://en.wikipedia.org/wiki/Swiss_cheese_model

So yes, sometimes you can add a cheap measure that might make things more difficult to an attacker, on top of your main line of defense, then do it. But keyword cheap, if it takes 2 minutes like using a custom port, yeah for sure do that, but if you have to write an article and invent a new theory of hooks, then it's not it.

Antivirus techniques are not used by serious development professionals that I know of, I've seen it used in IT contexts were there's non technical users that might download stuff, but even then it's not really a central technique, just something that security firms sell to non-technical execs. And it's in the context of sys admins trying to control the security environment of hundreds of employees whose actions they cannot control. In the context of developers who have to ensure the security of systems they have code for, you do not need these faith based techniques, you are importing the code, you have access to it, and you have the time resources to inspect it. These antivirus technologies are used either by personal end users that don't have the ability to verify the software or audit its source, or for IT departments that cannot even inspect the contents and packets of the software their employees are using for security reasons.

	▲	self_awareness 25 minutes ago \| parent [-]
		Does official Apple security framework ("Apple EndpointSecurity") targeted at AV vendors serious enough for you? They themselves built an OS subsystem specifically for AVs to use, and Microsoft has done the exact same with AMSI. There are actually very few techniques that are 99.999% effective. Cryptography when considered per se maybe is, but the wide topic of heuristic analysis is much lesser than that. Even if we consider some imagined, mythical 99.999% effectiveness, it's always measured in the specific boundaries we set during our analysis. Permission rights in the OS are 100% secure if we assume the authentication for sysop is secure. If we store the password for root in a public git repo, then OS permissions are 0% effective even if the system code hasn't changed at all. Your percent value is very fragile and relative to the boundaries we set. The unbreakable wall you think of can turn into a sheet of paper in the blink of an eye. The cheap port-changing trick can even be 100% effective against generic massive port scanning attacks. But it's 0% effective against a targeted attack. It depends entirely on the surface area we want to defend against. If we define our protection to work against generic automated bots, then changing the port is an entirely effective solution. If we want to ensure our systems are globally "unbreakable" (whatever that means), then it's a weak security solution. In other words, effectiveness is not absolute; it's relative to the threat model. It's not possible to inspect all the code we use. There's too much of it changing every second. The idea that developers have the time or ability to manually inspect every line of open-source code they import is an economic fantasy. In an era where frontier AI models like Mythos are finding and chaining 0-days in minutes, human review is simply outpaced. But even if we somehow did it, something would already change by the time you finish reading this paragraph. Everything needs to be reanalyzed because we don't know what shifted. And sometimes, the vulnerability manifests in the parts of the code that DIDN'T change. By the way, I think you might not be aware that current, "next-gen" security solutions offered by Crowdstrike or SentinelOne are actually old antivirus techniques marketed as something new. EDRs are 'just' log aggregators and routers for signatures to be matched on. Also, please don't think about programmers as someone immune to attacks, as this is not true at all. The fact that programmers invented a method of installation for programmer tools based on piping curl output directly to bash is direct proof that some programmers have absolutely no idea how security works. Especially web developers. If anything, programmers can be more dangerous than normal users because they assume they are better, and then they make the exact same mistakes as everyone else. They are just plain computer users who need to be defended from their own carelessness.