The code it committed has comments with “old code did this”, “old code did that”, like AI likes to insert. That is not useful info. It’s what version control is for… You can explain why you do a thing, like the AI does at the start, the actual code edited. The assertion it edited is just clutered with irrelevant info now. Is including history like this the usual style for the kernel, seeing that Linus himself signed off on it?

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

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…

What’s that? A connection problem? Ah, it’s already running the part that it did get… Oops right on the boundary of rm -rf /thing/that/got/cut/off. I’m angry now. I expected the script maintainer to keep in mind that their script could be cut off at litterally any point… (Now what is that set -e the maintainer keeps yapping about?)

Can you really expect maintainers to keep network error in mind when writing a Bash script?? I’ll just download your script first like I would your binary. Opening yourself up to more issues like this is just plain dumb.

It is absolutely possible to know as the server serving a bash script if it is being piped into bash or not purely by the timing of the downloaded chunks. A server could halfway through start serving a different file if it detected that it is being run directly. This is not a theoretical situation, by the way, this has been done. At least when downloading the script first you know what you’ll be running. Same for a source tarball. That’s my main gripe with this piping stuff. It assumes you don’t even care about the security.

At the end, in redirection, <<: that’s not how here-documents work. The example gives the impression it will read the given file up until “STOP”, but in reality the shell expects you to keep writing your here-doc until you write “STOP” and then feeds it to the program as if it were all on stdin. I don’t think wc even does anything with the stdin if you give it a filename… Note that variable expansion will happen in here-docs, so it’s a bit different than a simple cat. Also look into here-strings. And process substitution, I find that quite handy.