Obviously installing anything from AUR must be done cautiously and there have always been sketchy (as in improperly built/packaged) packages in the past but seeing actively malicious injections is concerning. I think there are two main problems with AUR: 1. it is a remnant of a slightly more egalitarian era in the open source history when you could generally trust 3rd party code and 2. orphaned packages can be adopted by anyone with their full history and vetting intact.
I think we are well past (1) but (2) could be mitigated by tighter controls on AUR accounts and potentially additional safeguards from AUR helpers. Maybe show a big scary warning if the package has changed owners recently. I know there will still be people that will "y" their way forward but it's better than nothing.
Or just avoid AUR helpers altogether and inspect/build the packages you need yourself from their PKGBUILDs directly.
> Or just avoid AUR helpers altogether and inspect/build the packages you need yourself from their PKGBUILDs directly.
The AUR helpers actually make it easier to integrate the review step into your workflow IMO; they actively prompt to review and let you know when a change is present since you last accepted the risk.
But "AUR considered harmful" is not a novel take. Everybody using it should understand the risk here, it's really just one step removed from curl/bash'ing something you found on StackOverflow.
For every single update, for all your AUR packages, all the time.
You know that thing where if you make a security review feature obnoxious, after some time people will just accept everything without even looking? Yeah...
> For every single update, for all your AUR packages, all the time.
Yes, that's what I used to do when I ran Arch. It's usually easy. The PKGBUILD is usually small to begin with and the difference for a new version should normally be something like the URL and the version number and not much else, so you can just diff it against the old version.
paru presents all pkgbuild diffs to you before installing, that's what I use to read them.
I usually only use AUR to install trusted pre-compiled binary packages, the scripts are very simple and the only thing that should ever change is the url and the sha256
Yea, paru makes it really easy, i noticed the diffs are a little easier/different versus yay. Not sure though if it's a config setting, haven't figured out the details yet.
Also paru shows you coloured code syntax if you have `bat` installed, i think.
I do it too, but I can see why this can be a problem for users. There should be an "official" scan for potentially malicious changes. I use a third party AUR scanner to help me with this.
You are thinking of the alarm fatigue[1], but it doesn't apply here -- there are no constant alerts warning that you are doing something dangerous to the point you get desensitized and start to ignore them. The correct analogy here are checklists -- things that you need to check if you are to do this "dangerous" activity (AUR usage), akin to pre-flight checklist.
Oh yeah, that's the name of it. But I guess something similar happens with checklists, you do it so many times without anything bad ever appearing that you start to subconsciously assume nothing will ever happen. Why check the rotor of my helicopter when nothing ever happened to it for 5 years? This checklist is a waste of time!
There are not enough words to describe how much I hate Akamai EdgeSuite. So many random validation loops and 403s across different physical computers, different operating systems, different connections and even countries. A couple of services I need use it and it's 30% I'll make it past their stupid "protection".
Despite the HN title (and while the focusing optics are similar), the structure in the article was directly milled with an ion beam (FIB), not electrons.
There is an implicit shame in disgrace but faceless entities have no shame. They'll just put out another press release written in corporate newspeak by an LLM and move on withe the plans anyway. This is standard Google behaviour. They do it with Chrome, they do it with Android, they'll keep doing it with all their captive markets. I fear that in practice even having an "advanced flow" will make little difference as some applications will refuse to work if you have it enabled anyway (in the same vein if debugging is enabled, for example).
Nothing about Android is open except the absolutely minimum amount of linux kernel that's required to boot the thing. Then it's blobs and restrictions all the way to the screen.
Chrome is the dominant browser. Sad as this may be removing it from Blink means de facto removing it from the spec.
That being said, I'm not against removing features but neither this or the original post provide any substantial rationale on why it should be removed. Uses for XSLT do exist and the alternative is "just polyfill it" which is awkward especially for legacy content.
In a lot of cases on a residential line you can't even pay for a public and/or static v4. The option simply doesn't exist. Many ISPs just force you to buy a "business" package for 3x the cost with a bunch of other features you may not need.
Issue (1) has been a long-standing issue and a prolonged back and forth [0,1] between NVIDIA and Xorg/Wayland devs about implicit and explicit synchronisation protocols. It looks like the explicit sync protocol is in the process of getting merged upstream and the 555 series driver [1] will take advantage of this so hopefully things are looking better. Problem with wayland is that all of the driver, xwayland and every compositor must support the new protocol but it looks like mutter, kwin and wlr will eventually support it. That being said there are constantly new paper-cuts appearing with the NVIDIA driver and Wayland support so who knows what will break with the new driver. Definitely not a pleasant experience. I'm not saying that AMD is smooth sailing but at least you don't have to fight the driver at every new release.
I'm afraid (2) will probably never work properly :-(
PrinceXML is expensive but I feel it's worth the money. I've used it to layout several RPGs with Markdown source files and HTML and CSS for templates and styling. RPG layouts can be quite complex with stat blocks and the like and it's handled everything I've thrown at it.
Nothing all that exciting, I'm afraid. The new director of InfoSec must have watched a Cable News Show about supply chain attacks, or something, so suddenly anything with package management - pip, npm, gem, etc - was banned from the official Windows policy. Since his flunkies didn't want to get nailed, they just went ahead and flushed any associated environments/runtimes too. It wasn't super consistent. It was, however, generally a surprise - you'd log in one Monday and whoops! Where'd my Python tooling go?
Now, ok, funny thing. Engineering could just get bare metal laptops, whenever they wanted, then blow the thrice-blessed CentOS image on it, and then do whatever the hell. So what happened - and this probably sounds real predictable - they used the CentOS machines to make all sorts of nutty crap, boxed it up, and then sent it back to their "official" Windows machines, now as a locked-in-amber config that never updates, even if five years later it had like fifty zero days in it and none of the libraries were good anymore.
I understand it took a new director and a LOT of meetings to explain whitelist mirrors for package managers, but I was long gone by then, even if I had a tiny hand in rolling out the demo whitelist mirror on-prem. Man, I had no idea what I was doing . . it still makes me shudder when I think of the things they were asking me to do.
I think that's a relatively simplistic way of viewing this. Although I don't disagree with the core argument, Google will always implement and ship "standards" that fit their business model or their vision of the web. A Chrome API becomes a defacto standard regardless of the state of consensus between engine vendors. Chrome can bulldoze through the standards process because of the massive amount of Chrome installations (and derivatives).
There are standards that have never been fully accepted by Mozilla [0] or WebKit (famously webusb for instance, because of security implications) but they are still in Chrome and now Firefox or Safari are effectively a "worse" browser because they don't support "standard" X that never reached consensus but Chrome implemented anyway. It always starts as an "experimental" feature under a config flag while the supposed discussion is taking place "just to see how it works, promise" before Google decides to remove the experimental flag and ship it. WEI started to play out exactly in the same way but given the massive outrage they decided it was too damaging to keep pursuing it (they still sneakily implemented it in Android WebViews).
So although I don't disagree that, yes Google has certainly improved on some things when it comes to standard processes they have abused their powerful position and continue to do so to push forward whatever they think it benefits them.
If there were peers out there beyond Mozilla, Apple, and Edge, I'd agree more. Safari has long been the web's boat anchor that keeps it from going anywhere. Mozilla has lots of good moments, but they also have been snotty meanspirited aggressive press hounds talking mad shit about sensor support, web USB, web midi, and other really amazing capabilities.
Google has no peers who are pro web. So them not having full consensus on what they do try bothers me not the slightest.
I think we are well past (1) but (2) could be mitigated by tighter controls on AUR accounts and potentially additional safeguards from AUR helpers. Maybe show a big scary warning if the package has changed owners recently. I know there will still be people that will "y" their way forward but it's better than nothing.
Or just avoid AUR helpers altogether and inspect/build the packages you need yourself from their PKGBUILDs directly.
reply