Arch Linux User Repository

@ant0n et all, lets keep the comments here about packaging issues, general Brave usage issues should go in another forum to not clutter up this comment space. I'm deleting comments that have no relation to packaging. Grey areas like crashes that could be blamed on Arch can stay until proven otherwise, but things like how to configure Brave to handle popups or site X or whatever just don't belong here. Thanks for understanding.

@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.

skip the checksum on build

Are you serious?! Looks like you generally don't take security seriously enough (even though the bar is pretty low).

My not posting that bump here is not depriving you of being able to use the browser.

Duh, I'm talking about this package, not the browser itself. I can still go grab brave package, which includes the relevant patch.

Pushing something known to be broken on at least a large chuck of systems would.

If this wasn't a security upgrade, I'd agree with you 100%. My suggested solution is far from ideal, but it's temporary and it'd make things work while preserving security, which is of the utmost importance. It's also not the only possible solution. You could have made pacman print a short message explaining the situation and describing the workarounds. That way, no downgrade would be forced, and even though the browser would be broken by default on the affected systems, the users would be made aware of the workarounds, which are trivial. Please, keep in mind that we're talking about a security upgrade here.

@the-k I'm sorry, but no, holding back systemd for some -bin package is not a solution I'll be posting here. You are welcome to bump the version number yourself (all it needs in the version number changed and skip the checksum on build). My not posting that bump here is not depriving you of being able to use the browser. Pushing something known to be broken on at least a large chuck of systems would.

@alerque The latest version contains important Chromium security fixes. The correct solution would have been to require systemd-libs<249. The current state prevents me from using this package and deprives the existing users of security.

The Chromium team has released the new version with the corrections. I'm not sure if Brave will make a new 1.27 rebased release or if they will wait until 1.28 which is due for next week.

@francoism90 assuming you are talking about Arch Linux only and not other distributions whose users use AUR for some reason.

It is impossible to say which systems/users are using systemd-resolved.

Still a fraction of users, Arch offers a variety of ways to set up name resolution.

can't assume that they want to adjust their system

Why not? I don't see anything wrong with "if there is a regression, either hold the package yourself or apply the available workarounds"