Arch Linux User Repository

• Find answers - FAQ, Help Center
• Ask questions - Community
• Report bugs - GitHub
• Request features - GitHub

leaving security to the user by default is a recipe for disaster

@the-k the AUR exists on the premise that the user has the necessary technical acumen to mitigate the risks of installing user-submitted packages. People using AUR helpers (and "friendly" derivatives) to upgrade packages without review is the much larger risk here.

That said, my argument could also be applied as a reason for bumping the version and telling the user to just reconfigure DNS (the user is just as capable of maintaining their system config for the packages they have installed). Either way, you decide whether to pull the latest changes from AUR and build your package from that. You are always free to fork the package or start your own repo. You may disagree with the maintainer's decision here, but he still doesn't owe you anything.

@CReimer no segfaults here on 1.27.109. here is my PKGBUILD

I can't believe how people has reacted to having a single -bin package that has no dependants outdated for a few days.

There is a new 1.27 release being due for today or tomorrow which should fix all this.

I still can't believe the behaviour that some package managers have to handle for their work during their free time.

I hope I could help a bit providing as much info as I could on the bug and it's resolution upstream. Thanks a lot to mixedCase and now alerque for their time and effort.

Hoping we can see this package on the community repo at some point too.

@alerque So, are you sticking to your original position or are you gonna take an action? I see some input from other users, yet nobody's really weighing on the security aspect and the fact that leaving security to the user by default is a recipe for disaster.

I think there's another huge problem with the newer versions of Brave. Anyone else seeing segfaults in print preview?

The update to 1.27.108 is in the package history, so the following works for me (I'm using openresolv instead of systemd-resolved). No need to skip checksums.

$ git checkout 7339c3c && makepkg -sri

Many thanks to @mixedCase and @alerque for all their time and work.

@the-k I wasn't even involved on this discussion, I just disowned this package and the new maintainer has immediately been on the receiving end of a rain of caca for differences on how to handle upstream's fuck-ups by people who think it's okay to break a large userbase as long as they get their update early without having to move out of their precious AUR helper, even after the maintainer has already communicated his intention. There's a perfectly good mechanism for handling the issue differently on your system and it takes all of 2 minutes: Clone the repo, bump the version, makepkg -sif. Want to be helpful? Explain your reasoning nicely (good start there by linking to the actual problems) and move on.

Responding with "Duh" to being politely pointed out a solution to your problem, or language like "Are you serious?! Looks like you generally don't take security seriously enough (even though the bar is pretty low)", is clearly past the threshold of constructive criticism, and living in a glass house you better not be throwing stones. Your take on a "realistic" threat model is someone else's joke.

I'm unsubscribing from this feed since I'm no longer using let alone maintaining this package and I've said enough. Hope you find your peace upgrading to 1.27.108 on your machine. Cheers.

@alerque @mixedCase I appreciate the decision to not force me to change my system config to install a new version of Brave. I hope the Arch community is strong enough to get this browser in the official repos. Thanks for your hard work.

@mixedCase See https://chromereleases.googleblog.com/2021/07/stable-channel-update-for-desktop_20.html and https://security.archlinux.org/AVG-2246. Many of those fixes appeared first in M92, Brave 1.26.77 uses M91 (see https://github.com/brave/brave-browser/blob/9a2797b2ca60188087b78e70a34c5f7805c6db3b/package.json#L234).

I'd like to kindly ask you to tone down on the rhetoric. Being critical isn't intimidation. I've made constructive arguments, I've outlined two possible solutions and I'd welcome a constructive feedback from you, which would help us to fix the issues at hand. Baseless allegations, name-calling and suggestions disregarding the more realistic threat models certainly aren't helpful. Please, let's get back to discussing the real issues.

@alerque First off, sorry I left you this shitshow. I hope I'm not overstepping here.

@the-k Feel free to actually point out the security patches to make an argument. I've grepped through the patchset notes and found nothing under a few common security keywords.

But most important of all: If you care about security to the degree you're trying to intimidate a voluntary maintainer into following your own judgment of what's right, then I must suggest you stop making a public clown out of yourself and your own security practices and stop using a release maintained by a third party of a binary someone else compiled, and compile your own damned browser. I'm not even going to suggest you to read the code, let alone audit it, but at least compile it yourself instead of making nonconstructive comments on someone else's release.