Live data from Hacker News

Package Managers need global hooks

captnemo.in

61–63 of 63 posts

Re: Package Managers need global hooks

#61

Earlier quoted context omitted.

This piqued my curiosity and it seems you really didn't do it justice there. Rather than patch out the actual use of the uninitialized memory (always a good thing to do) IIUC instead the core part of the function that mixes new randomness in was patched out. Like the tire was flat so you went ahead and just chopped off the entire axle with an angle grinder because who needs 4 wheels anyway.

Agreed, but you also have to look at it from a packager's point of view. Here is the actual patch: https://salsa.debian.org/debian/openssl/-/commit/8f27a7dc022... Notice how clean and small a patch it is? (ignore that, in making it clean and small, it has "chopped off the entire axle" as you say) And here's what led to making that patch: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 These links contain spe…

A community that thought it knew better than upstream, and didn't check their changes with them.

It is my recollection that they both tried to run it by upstream, and believed that they had successfully done so. That may still be an error, but not the kind of fundamental flaw you imply.

Re: Package Managers need global hooks

#62
post #32

Earlier quoted context omitted.

>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…

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…

>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.

Neat

>There are actually very few techniques that are 99.999% effective...

Yes, I was thinking, for example SSH + VPN. 2 99.999% secure layers.

Also, Unix users + Apparmor. Recently in Linux unix users were vulnerated by copy.fail for example, but it's not a common event. And it already assumes (in my threat model), that users managed to vulnerate my http server to run arbitrary commands, so they would have to break 2 layers to get me (3 if I were to use apparmor)

>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

I add them up and average them, so if something is 100% effective against 1000 attacks, but 0% effective against 10 others, it's 99% effective? Not great. Especially when you get 1000 of these per day. It's also not purely probabilistic, since attackers are smart and can find that 1%.

>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.

Sounds like a choice you are making there. I have a 10KLoc system, you have a 100MKloc system. It is possible to inspect all the code that I use, it's not possible to inspect all the code you use.

>Also, please don't think about programmers as someone immune to attacks, as this is not true at all.

I do agree, here, I like the approach Socket is taking, they are bringing the AV security tactics with signatures and active monitoring, to code repos. But to be fair, if it were my company or I were CTO, I would rather start distributing PIPs or firing people that cause cybersec incidents. I get that there's different styles, but my strategy just values absolute cybersec much more, we are not a good fit if you are using npm and we need to bring in an Antivirus company for developers.

What I'm saying is that GOOD developers are expected to be less vulnerable than normal users, and that BAD developers benefit from the techniques that protect normal users. Again, if someone runs 'wget URL | sh' under my watch, that's a PIP, and it's being generous, there's no strike 2.

Re: Package Managers need global hooks

#63

Earlier quoted context omitted.

This piqued my curiosity and it seems you really didn't do it justice there. Rather than patch out the actual use of the uninitialized memory (always a good thing to do) IIUC instead the core part of the function that mixes new randomness in was patched out. Like the tire was flat so you went ahead and just chopped off the entire axle with an angle grinder because who needs 4 wheels anyway.

Agreed, but you also have to look at it from a packager's point of view. Here is the actual patch: https://salsa.debian.org/debian/openssl/-/commit/8f27a7dc022... Notice how clean and small a patch it is? (ignore that, in making it clean and small, it has "chopped off the entire axle" as you say) And here's what led to making that patch: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 These links contain spe…

> thought it knew better than upstream, and didn't check their changes with them

That is not fair. Debian generally works close with upstream, since most Debian Developers are free software enthusiasts in some way. The patch in question made it to the OpenSSL mailing list and received only encouragement. The only problem, as it turns out, was that less than a handful people knew those parts of OpenSSL well enough, and they didn't have time to hang around the mailing list. The real development of OpenSSL happened behind closed doors.

A lot of people learned from that incident. It is wrong to blame it on the Debian Developer who tried to clean up the code and went to the OpenSSL development mailing list for help. It is far from clear that uninitialized memory helps randomness at all, unless you are intimately familiar with the history behind those lines.

Post reply on HN