Re:Detecting the use of “curl | bash” server side
by KyeRussell on Tuesday December 27, 2022 @06:29AM
(#34147757)
At the risk of pointing out what I see as the obvious, but you’re focusing on different attacks. It’s a lot more nuance than “it should be the other way around”. A very valid argument can be made that it’s more likely that you’re installing a dodgy package rather than being subject to some sort of MITM attack.
Re:Detecting the use of “curl | bash” server side
by gorgoiler on Tuesday December 27, 2022 @10:20PM
(#34157161)
My worry isn’t about the method of proving authorship. Once a third-party apt repo is added it has to be trusted in perpetuity. Every time I run apt upgrade the third party site has an opportunity to slip something new and nefarious in. At least with curl|bash it’s a one time risk.
Repository packages usually are signed with GPG. You can even use HTTP - it does not matter. And GPG could be used to sign packages on another machine, may be even on offline machine with HSM.
Things like pip or curl rely only on HTTPS. There are many agents between developer who built a deliverable artifact and your machine. There's WWW-server. There's some CDN with HTTPS termination. There's NSA which can issue fake certificate and MITM attack you (mostly imaginably threat for sure, but still).
And hacked WWW servers already happened. Transmission website was hacked and their binary was infected.
Now I don't claim it to be a big issue. Malevolent developer is much more dangerous and much more likely to happen. But if we want to compare those two methods - I think that repositories with proper signatures are safer.