< file.txt grep thing also works.

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.

What, do you mean to tell me that random chances are not influenced by God? We call it RNGesus for a reason. /s

Or the over 3.6 million people in the territories of the US.

Macron

People still name their sons Richard...

I guess it's you and 255 others?

So parel is actually feminine and and meisje is gender-neutral.

You moved everything down 3 dirs from root to your working dir.

Bouvet island

See the proof of concept for the pipe detection mentioned elsewhere in the thread https://github.com/Stijn-K/curlbash_detect . For that to work, curl has to send to stdout without having all data yet. Most reasonable scripts won't be large enough, and will probably be buffered in full, though, I guess.

Thanks for the laugh on the package installer, haha.

So I was wondering what the flags do too, to check if this is any safer. My curl manual does not say that -f will not output half downloaded files, only that it will fail on HTTP response codes of 400 it greater... Did you test that it does not emit the part that it got on network error? At least with the $() that timing attack won't work, because you only start executing when curl completes...