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.

@heapifyman For what I see they have their own brave-bin package with their own brave-bin.sh So changes here shouldn't affect those users.

@alosarjos as far as I know brave-flags.conf comes pre-installed with Manjaro Sway. It also brings chromium-flags.conf and chrome-flags.conf with identical content:

--enable-features=UseOzonePlatform --ozone-platform=wayland

See: https://github.com/Manjaro-Sway/desktop-settings/tree/sway/community/sway/etc/skel/.config

I had installed this package without any modifications.

But it seems that Manjaro provides its own build of Brave in its own community package repository: https://gitlab.manjaro.org/packages/community/brave - not sure how it is related to this package.

I used this package because it seemed to receive updates faster than the one provided by Manjaro.

I agree with wknapik. You are trying to fix a non-existent issue and really don't need to do that. It's enough for anybody to pay enough attention what they are adding to brave-flags. It's impossible to specify every single mistake idiots are capable of. There are legion of them and they are very inventive.

For now, I will be reverting the changes. I get the point that these can help in some situations. But right now, since nobody complained about not being able to use special chars like * on their flags, is not fixing anything and only giving some problems to other users.

I'm think I can (But have to check) if a message can be printed when updating the package warning users of the changes and what needs to be done.

Also I'm curious about @heapifyman and the Manjaro Sway. Is the brave-bin package there this one + preconfigured config file for Wayland? Is it written on some wiki? If I understood correctly there the config file is provided by the distro flavor devs, so I might be braking things for users without them knowing, looks like the patches are good, but maybe I need a way to communicate breaking changes specially regarding people where the config file is preconfigured.

I don't like the fact that we are breaking previously running configs for others.

In chromium/chrome, this feature is a part of the browser. Here, it's implemented in 7 lines of code, so there will be limitations.

My regex skills are not at the point where I can understand that last sed, to be honest.

There you go:
- s/\s*#.*//g - remove comments and whitespace before them
- s/^\s*//g - remove whitespace at the beginning of each line
- s/\s*$//g - remove whitespace at the end of each line
- /\S/p (with -n) - print only lines that contain at least one non-whitespace character (equivalent to grep '\S')

are there chrome flags that accept * or white spaces to begin with or are we fixing imaginary issues?

There are many special characters in bash https://mywiki.wooledge.org/BashGuide/SpecialCharacters

Allowing the shell to expand them in this case is a bad idea IMO.

Up to you @alosarjos. Either revert my patch and accept the shell expansion, or apply my second patch and accept the limitations in format (each option on a new line and no quotes). There's also a third option of implementing this properly, which would take more code than those 7 lines.

Hi everyone, sorry for the late response.

I usually test all this on my PC to check everything keeps working, but turns out that, since I have a bunch of flags I already have them all in separate lines, so I didn't see any breaking changes.

I don't like the fact that we are breaking previously running configs for others. My regex skills are not at the point where I can understand that last sed, to be honest.

I don't see harm on the new changes though, but are there chrome flags that accept * or white spaces to begin with or are we fixing imaginary issues?

AFAIK, spaces must be escaped regarding the docs:

https://www.chromium.org/developers/how-tos/run-chromium-with-flags/

So I'm not sure at all if these patches are actually necessary, @wknapik, can you tell me what was failing to you before?

@alosarjos please apply also this patch to improve handling of comments and whitespace:

diff --git a/brave-bin.sh b/brave-bin.sh
index 0e657ed..30940d1 100644
--- a/brave-bin.sh
+++ b/brave-bin.sh
@@ -4,7 +4,7 @@ XDG_CONFIG_HOME="${XDG_CONFIG_HOME:-$HOME/.config}"
 # Allow users to override command-line options
 USER_FLAGS_FILE="$XDG_CONFIG_HOME/brave-flags.conf"
 if [[ -f "$USER_FLAGS_FILE" ]]; then
-   mapfile -t USER_FLAGS < <(sed 's/#.*//g' "$USER_FLAGS_FILE")
+   mapfile -t USER_FLAGS < <(sed -e 's/\s*#.*//g' -e 's/^\s*//g' -e 's/\s*$//g' "$USER_FLAGS_FILE"|sed -n '/\S/p')
 fi

 export CHROME_VERSION_EXTRA="stable"

This takes care of trimming whitespace around options and dropping lines that contain no options, which is relevant when you quote everything you pass on the command line.

PS. The approach you took to removing comments (which I haven't changed) would be problematic if a browser option was used with an argument containing the # character, like --some-option=foo#bar, but that seems like an unlikely edge case, so I think it's fine to favor simplicity of implementation here.

@heapifyman each option should be on a separate line (and should not be quoted, as the script takes care of that), instead of having multiple options on one line.

So this is bad

--enable-features=UseOzonePlatform --ozone-platform=wayland
--foo="bar baz"

This is good

--enable-features=UseOzonePlatform
--ozone-platform=wayland
--foo=bar baz

Some browser options may accept arguments containing spaces, so breaking up arguments on spaces is tricky. Doable, but the code would have to be aware of the context the space occurs in, so would be considerably more complex.

The latest version 1:1.39.111-2 with the patch by @wknampik does not seem to work with the default brave-flags.conf that is installed by Manjaro Sway.

brave-flags.conf has the following content, a single line:

--enable-features=UseOzonePlatform --ozone-platform=wayland

That should make brave run on wayland natively.

With the latest version of brave-bin.sh these settings seem to be ignored. Starting brave and then running xlsclient -a returns brave, meaning it runs on Xwayland, not native wayland, as far as I understand. Running xeyes confirms that - eyes are following mouse cursor when brave is focused.

If I revert the changes to the script then xlsclient -a does not return brave, anymore.

Question: is that an issue with the script or do I (and the Manjaro Sway developers) need to adjust anything in brave-flags.conf?

@wknampik is right, @alosarjos. Shebangs exist exactly for this reason to specify the needed shell interpreter. Besides, Bash is a dependency of base. Everybody has Bash.

@alosarjos bash is a dependency of multiple packages in base-devel, so it's guaranteed to be available. The shebang at the top of brave-bin.sh selects bash as the interpreter, so we're all set. I use zsh myself and this works fine for me.

@wknapik I see... The problem there is that bash is not mandatory as default shell, people may be using ZSH, so i tried there the mapfile, and doesn't recognize it, so I can't put that on the AUR script...

@alosarjos mapfile is a bash builtin that reads lines into an indexed array (see: man bash).

Quotes around a regular variable prevent expansion, but also make the whole value a single commandline argument. Quotes around an array prevent expansion, but each element is quoted separately, which is what we want here.

Please run shellcheck against brave-bin.sh before and after applying the patch to see that this fixes a generic problem.

@PQCraft This is the pre-built binaries by Brave. If you think there is an issue with build options I suggest you ask them on their Github repository.

Hi, I have been experiencing a lot of issues where tabs randomly crash with SIGILL. I wonder if this has to do with the build options. Is this being built for generic x86_64?

@wknapik Thanks for the patch. But I'm not sure it's correct? What is this mapfile you are adding to it?

The script that gets installed as /usr/bin/brave (https://aur.archlinux.org/cgit/aur.git/tree/brave-bin.sh?h=brave-bin) doesn't quote the extra arguments from brave-flags.conf, which means they get expanded by the shell. So, for instance, if you put "*" in your brave-flags.conf, it will cause all files from the working directory to be opened when brave is started.

Here's a patch to address this:

diff --git a/brave-bin.sh b/brave-bin.sh
index 293a314..0e657ed 100644
--- a/brave-bin.sh
+++ b/brave-bin.sh
@@ -3,10 +3,10 @@ XDG_CONFIG_HOME="${XDG_CONFIG_HOME:-$HOME/.config}"

 # Allow users to override command-line options
 USER_FLAGS_FILE="$XDG_CONFIG_HOME/brave-flags.conf"
-if [[ -f $USER_FLAGS_FILE ]]; then
-   USER_FLAGS="$(cat $USER_FLAGS_FILE | sed 's/#.*//')"
+if [[ -f "$USER_FLAGS_FILE" ]]; then
+   mapfile -t USER_FLAGS < <(sed 's/#.*//g' "$USER_FLAGS_FILE")
 fi

 export CHROME_VERSION_EXTRA="stable"

-exec /usr/lib/brave-bin/brave "$@" $USER_FLAGS
+exec /usr/lib/brave-bin/brave "$@" "${USER_FLAGS[@]}"

Brave keeps freezing the whole system, it's random and I don't think its due to high cpu usage or RAM either. Sometimes I'm able to use terminal to end it or go to TTY, otherwise I need to do a full reboot because it's fully frozen.

Seems like it's happening due to having hardware-acceleration enabled. Disabling it fixed for me.

@itsKia2 No problem. I appreciate people notifying me about the package being outdated. But lately I've been getting multiple false reports.

You can try the Curl method, or check if they updated the CHANGELOG file. Or check the status on the release checklist: https://github.com/brave/brave-browser/issues/22786

@alosarjos sincerely sorry for flagging the package. i was not aware that was the method used to check the latest version. will not be making the same mistake again.

Please, don't mark as outdated if the new version is not showing up in https://brave-browser-downloads.s3.brave.com/latest/release.version

Someone flagged the package saying Latest version es 1.38.113, but that version is discarded and the next release will probably be Release v1.38.115

@ijann That looks like you are searing on the same window where you should rename. I see a search text box with the fdg... and then the name file being field-...

You sure are using fine? Anyway, if this kind of bugs are for the Brave Github, not a packaging issue.

Is there any way to stop people from flagging this package for arbitrary reasons?

The flathub package is an unofficial package, not supported upstream.

Just a quick notice: Brave is now available as a Flatpak!

While not related directly to this I think this are fantastic news and specially should help on checking if an issue is only happening on this package or on brave upstream by giving a quick test on the flatpak version

https://flathub.org/apps/details/com.brave.Browser

I think the person who flagged out-of-date didn't realize the stable version changed from 1.36 to 1.37 and checked only the minor .109 version

Also, the 1.37.110 is a prerelease, not a stable release.

So... for some reason someone flagged the package as outdated without even checking that we are already on the latest stable version I I can't unflag it...

@alerque can you unflag it?

Hi! I have a lot of problems with drop-down menus on every website. Sometimes they work, and sometimes they don't. I have tried enabling and disabling all the addons I use. The result is the same. When I click on a menu, I can see all the options but nothing happens when I click on one of them. After a while, the menus work again. I've seen several comments of people with the same problems but no solutions. All of them talked about the AUR version. My system is Manjaro KDE. Any ideas? Thanks in advance!

@urbenlegend It is installed with the package as /usr/bin/brave. It's a wrapper that allows setting custom flags on $HOME/.config/brave-flags.conf over the real brave binary located at /usr/lib/brave-bin/brave

Apologies if this question has already been asked, but what's the purpose for the brave-bin.sh file included in this package? It doesn't seem to get installed onto the system. Is this file there just for reference or should it be removed?

@zerophase @Archanfel80HUN If the issues you are having are not related to packaging I would prefer if you can move the discussion to the Brave Github since it will probably be a Brave issue (Not a packaging issue) and the reporting it to the Brave developers will be more usefull.

@zerophase i have 32Gig ram, its not a ram issue, its a brave issue. Workaround, run brave in a terminal or from a terminal window. It will not crash. Really strange.

update: brave nightly, current version 1.38.1 does not have any crash issue.

@archanfel80HUN Have you found a stable version? I've gone back to 1.33 and the behavior persists. There definitely might be an issue with Brave. But, me having ram instability complicates it with how heavy Chromium is on ram.

@zerophase Same issue here, crashing after start, restart for a second or third time its fine.

@zerophase Hmm, all I do for now at least is keep updating the version to help @alerque. If it's crashing it sounds more like a Brave issue rather than a packaging itself. I would try reporting it on their GitHub.

@alosarjos believe my crashes are from having a stick of ram or two go bad. Going to be a bit before I can test, as my current water cooling setup prevents me from removing all of the ram for testing. I do have crash dumps that might help, if this is not from ram.

@alosarjos I'm using Cinnamon. Don't believe I have any custom flags, and on X11. I do have a coredump in journalctl. This eventually goes away after restarting the browser a bunch.

https://pastebin.com/tZAXEu2n

@zerophase @txhx38 I haven't noticed any issue on my install. Can you provide more info on you config? (Desktop Environment, Custom Flags, X11/Wayland, Ozone...)

@zerophase Yes. For me it's not crashing but freezing sometimes since a week.

Anyone else having issues with the browser crashing frequently?

Started approximately a week ago for me.

@gr523 that sounds like a bug in you AUR helper, not a packaging issue. makepkg does not clean the sources.

The package file along with the zip file is deleted on sudo time out, so the same zip needs to be downloaded again and makepkg again Cleanup should be made only after successful install

@alosarjos thanks for the response! I'm using X11 for my setup for stability reasons and have already installed the previous version. I wanted to share this issue on here since it was breaking some expected browser functionality. Unfortunately, this appears to also affect the Beta and Nightly builds of the browser as well.

Y'all are doing great with this, thanks for supporting this browser's availability on Arch! I'll look forward to the patch update!

@jordangarrison I saw recently that Arch chromium package got rebuilt with some patch to fix it.

In my case is working without any issue. The patches mention X11, so maybe it's working for me because I'm using Ozone/Wayland. Anyways, seems to be an upstream chromium issue.

Thanks for posting the issue on GitHub, sadly it looks like it hasn't been backported to current Chromium version and I don't think Brave will apply it. So you can either:

1. Enable Ozone Wayland
2. Install the previous version (If you don't know how I can help you with that)
3. Install maybe the nightly or brave (Not -bin) version with the patches applied I would say.

Anyways, the users of this package are awesome and they usually notify me really quick of new updates in case I miss them, so if Chromium fixes it, and Brave releases a new update based on fixed Chromium I will update the package ASAP.

There is a functionality-breaking issue with the current version of the package which prevents the user from being able to drag and drop into the browser window or rearrange tabs with the mouse. You can follow this issue here (GitHub brave/brave-browser issue #20386).

The previous version of the package does not contain this issue.

@jemadux: Yes, if you activate them.

does brave-bin provide brave ads ?

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

@alosarjos Thank you. Also, if I am not mistaken, the Brave's pgp fingerprint can be listed from their official public key with gpg by:

gpg --show-keys BRAVE_PGP_PUBLIC_KEY

If that is the case, then according to the wiki the fingerprint can be supplied to validpgpkeys in PKGBUILD...

@Nu4425 I will try to give it a look on how all that works when I get some more free time, for now I just updated the packag :P

Hi @alosarjos, the package builds fine but as an improvement can you verify the authenticity/integrity of the release using brave's official signing key during the build process? This would be great, as Brave provides official signing keys in their website at "https://brave.com/signing-keys/#release-channel".

So I just fixed it, read the archwiki for chromium and updating the flags to brave --use-gl=desktop --enable-features=VaapiVideoDecoder --disable-features=UseOzonePlatform %U seems to have worked (using X11 not Wayland).

Actually ignore my last message, removing --use-gl=egl --enable-features=VaapiVideoDecoder %U did end up working (of course the issue is that I now don't have video video acceleration).

Can't help you there more. I'm on Wayland, so no Video Acceleration for me, I'm using EGL flag too though, but it's working fine on my end. AMDGPU here.

If Chromium has the issue closed, maybe it's something on the mesa side for your hardware?

Still get the same issue, I am pretty sure I am hitting https://bugs.chromium.org/p/chromium/issues/detail?id=951142

Could you try removing them?

I am using the following flags (for video acceleration) brave --use-gl=egl --enable-features=VaapiVideoDecoder %U

@mdedetrich Google Maps is working fine here. Are you using any custom flags?

Has anyone experienced the issue where anything being painted inside a canvas (i.e. Google maps) is upside down?

@vonbloom Can you try removing your user brave config and cache files and retrying?

I get a segmentation fault (core dumped) after upgrading to 1:1.30.89-1

@von Please see previous comments. v1.30.84 is still marked on GitHub as pre-release and is not in the official release manifest yet. You can check with:

$ curl https://brave-browser-downloads.s3.brave.com/latest/release.version

@aafsmarak Please don't flag this as OOD for beta / nightly / other pre-release builds. This in only tracking officially built binaries in the stable channel.

1.30.84 is still a pre-release. Check

https://brave-browser-downloads.s3.brave.com/latest/release.version

before flagging as out of date.

I will leave it marked because it will surely come out in a few hours and someone would probably re-mark it as absolete...

Has anyone else had right clicking / ctrl + v into Brave's search bar stop working recently?

UPDATE: Fixed itself after I caused Brave to crash, and restore itself.

Figured out how I broke the copying and pasting. I copied a link from a download box. Closed the box, and tried pasting it. Believe this is an upstream issue.

Just in case someone wants to fill a bug here. I'm testing 1.30.81 (Which is based on Chromium 94, which finally has the CSD fixed for Linux) but sadly this Brave version is still using an outdated UI component. But it's fixed on Nightly.

@jb.1234abcd I would suggest opening an issue on the Brave Github

brave-bin-1:1.29.80-1-x86_64.pkg.tar.zst

5.14.3-arch1-1

On Brave open these errors are logged (journalctl):

Sep 14 15:29:04 r61i chrome[40650]: [40650:40650:0914/152904.151908:WARNING:chrome_content_verifier_delegate.cc(212)] Corruption detected in extension eoceebklhjepohnakemchinmkdpbolgh installed at: /home/jb/.config/BraveSoftware/Brave-Browser/Greaselion/Temp/scoped_dirtVb0bH, from webstore: 0, corruption reason: 1, should be repaired: 1, extension location: kComponent

Sep 14 15:29:04 r61i chrome[40650]: [40650:40650:0914/152904.163976:WARNING:chrome_content_verifier_delegate.cc(212)] Corruption detected in extension bpkoijdaibakhfgahdfknbdcankhidoa installed at: /home/jb/.config/BraveSoftware/Brave-Browser/Greaselion/Temp/scoped_dirglbwx9, from webstore: 0, corruption reason: 1, should be repaired: 1, extension location: kComponent

Sep 14 15:29:04 r61i chrome[40650]: [40650:40650:0914/152904.164252:WARNING:chrome_content_verifier_delegate.cc(212)] Corruption detected in extension ldopphkgfhfchjcgfilekhkifaodmegm installed at: /home/jb/.config/BraveSoftware/Brave-Browser/Greaselion/Temp/scoped_dirWcPPFX, from webstore: 0, corruption reason: 1, should be repaired: 1, extension location: kComponent

Sep 14 15:29:04 r61i chrome[40650]: [40650:40650:0914/152904.182283:WARNING:chrome_content_verifier_delegate.cc(212)] Corruption detected in extension gajhkmnhhoadjcfchafgbekhgigglnkp installed at: /home/jb/.config/BraveSoftware/Brave-Browser/Greaselion/Temp/scoped_dirB3yGbZ, from webstore: 0, corruption reason: 1, should be repaired: 1, extension location: kComponent

Sep 14 15:29:04 r61i chrome[40650]: [40650:40650:0914/152904.182560:WARNING:chrome_content_verifier_delegate.cc(212)] Corruption detected in extension mjkjompjknhcipamakpfliebpggggpga installed at: /home/jb/.config/BraveSoftware/Brave-Browser/Greaselion/Temp/scoped_dirUjC7FV, from webstore: 0, corruption reason: 1, should be repaired: 1, extension location: kComponent

Sep 14 15:29:04 r61i chrome[40650]: [40650:40650:0914/152904.182739:WARNING:chrome_content_verifier_delegate.cc(212)] Corruption detected in extension feipjgjfhmnfhhmbkclfopokbcgnpnnd installed at: /home/jb/.config/BraveSoftware/Brave-Browser/Greaselion/Temp/scoped_dirKf5TAc, from webstore: 0, corruption reason: 1, should be repaired: 1, extension location: kComponent

Is anyone else having issues where Google sheets is rendering transparent font colors? It seems specific to this latest version, but I'm having trouble narrowing down exactly where this is happening in styling.

@alerque, I agree on you on this being more the second case than the first, but I guess following the chromium package should be the way (And thus, add them)?

Also, I see that the Chromium package has org.freedesktop.secrets as dependency which includes gnome-keyring, but being a freedesktop standard I'm not sure why it's not including the KDE variant (Looks to me to be that the optdepends that should be added)

@blennow Thanks for the further explanation. I get what you're talking about now.

Unfortunately I don't think this falls under a very good use for optdepends. It is kind of on the fuzzy boarder, but there is a difference between things that directly add additional functionality and things that just play nice together if they happen to both exist. I think this falls into the latter case.

@alosarjos I can confirm that when using XDG_CURRENT_DESKTOP=KDE brave will use kdialog and XDG_CURRENT_DESKTOP=GNOME will use GTK based dialogs.

This is further confirmed by brave support with the command line flag --password-store that supports kwallet. It will also automatically choose the best fitting package for the current environment.

I still really think these should be dependecies of the plasma-browser-integration package too but the maintainer did not.

I just checked the generated .deb brave provided on GitHub, and it does not have any optional dependencies on gnome-keyring or anything related. Are we sure these Gnome and KDE packages have any effect on Brave?

PD: Probably they are as dependencies of dependencies. But there is a brave-keyring package to installed. Anyway, if you say that installing those packages have some effects, I don't see why not update them.

@alerque If you don't see any issue too I could update them once I get home

@aleque Hi, I realize now what I wrote was very cryptic, sorry about that. I'm suggesting that kdialog and kwallet be added as optional dependencies like chromium has.

I previously opened a bug at plasma-browser-integration but it got closed as not a bug and the maintainer referred to the chromium package. I think this change would help discoverability to get integrated dialogs with KDE (I don't think there are integrations for other DE).

@Iwirada Yes that is what I have done and it works. Thanks for the suggestion.

Also, great job on getting the package updated so fast!

@blennow not everyone is using Plasma. E.g. I am a dwm user. Maybe you can install those packages by hand?

@blennow Add what exactly? This package is just a repackage of a binary build released upstream, modified only enough to fit in a PKGBUILD according to Arch packaging.

Hi, is it possible to add kdialog and kwallet to integrate with Plasma better? Maybe add plasma-browser-integration also.

Anyone else having these issues:

gnome-shell[7018]: [7018:7018:0819/095339.086798:ERROR:shared_context_state.cc(73)] Skia shader compilation error

Think it's caused by the VA-API enabled flag. :/

@zerophase You can't get fresh adblock lists for one. Please take that conversation to the relevant package though, it isn't an issue with this -bin package.

@alerque What extensions can't run in unofficial builds? Couldn't we just fork the extensions, and enable them?

@srebre It's not an easy as just getting votes. This package is just the upstream binary, for the repos we'd really want to build it ourselves. The brave PKGBUILD does that, but there are other complications (see comments there): Brave Inc. is not letting some extensions run in unofficial builds, plus building it is quite a procedure. That brings us into needing to negotiate license/distribution issues.

I am a TU and have my eye already on moving this to [community] if we can navigate all those dealt with, but don't expect it any time soon. In the mean time using this is your best bet for a working browser (but be aware you're trusting a binary blob built by a for-profit Browser vendor).

Since this package has 400+ votes, can we integrate it into the official repositories and who should we reach out to? It's the third most popular package by votes in AUR at the time of writing.

@alosarjos Yes, if it's deprecated we should be pointing the current dependency, optional if it is so. I don't let my browsers or DE session handle secrets, so I'm a little out of that loop. Feel free..

@alerque, now that the update thing is gone, the package has libgnome-keyring as optional depdency, which is deprecated for libsecret I think. Should that dedepency be changed?

The release of 1.27.111 is inminent. I have the PKGBUILD ready in case alerque can't upload it.

I can confirm that:

1. The systemd-resolved issues are fixed
2. Printer preview is working fine (But I didn't test it on the previous version)

@the-k Yes at this point I'm sticking to my original position. You can take it up on the aur-general list or something if you want to make a scene, but to consider yourself warned. @mixedCase already outlined some of the issues with your position. Yes, practically EVERY browser update these days include security fixes of various grades and people should be running the absolute latest where possible.

The checksum in this packaging is basically only protecting you from not noticing a corrupted download file. Since it's not being published and signed upstream when this gets bumped it's basically just a blind download by me or somebody else and we slap the checksum we got on it. This is true of most AUR packages. It's basically just the maintainer saying "this is the one that worked for me". If you think that is a safeguard against browser security issues then, respectfully, you're guilty of security theater. At best it tells you your browser downloads are only being MITMed by the same party mine are and not some nefarious clown at your ISP.

To you are anyone else that wants a new version sooner than we push a bump here, download this repo, edit the pkgver to the one you want, and makepkg -sif --skipinteg it.

Isn't systemd-resolved not the default DNS setup? I thought the arch install has something else for getting DNS working. By the very definition of it not being default Arch wouldn't an Arch user* have enough skills to fix the problem themselves?

*Distros based on Arch are not supported by the AUR as a best practice. They have their own forums for these issues.

@duhdugg: Tried it again on my computer at home. Same as on my office computer. Opening the print preview in 1.27.109 segfaults for me

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.

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"

@chandradeepdey It is impossible to say which systems/users are using systemd-resolved. I think there are many, and you can't assume that they want to adjust their system (resolve) settings just for Brave.

Fair points, @alosarjos. The package is appropriately flagged as out-of-date currently. I think most types of AUR users are covered.

@duhdugg oh lol. the workaround was known for 10 days and I found out today. @alosarjos ¯\_(ツ)_/¯

I'm not sure it's a good idea to update the package and then show a message telling users to review/alter their system settings to keep Brave working.

We are taking for granted that all Brave-bin users should know how to:

1. Review their system settings to know if they are or not affected
2. In case they are, modify those settings that have been working perfectly and still do for everything else
3. Not only modify, but understand what those modifications mean

Asking people to change their working system settings because of a single package that will be fixed in a matter of days, doesn't sound good to me.

Instead asking the people with the technical skills to know if they can upgrade the package to simply use the provided PKGBUILD in the comments, is by far a safer solution.

Let's remember that there are a lot of user-friendly arch based distros out there where people is using AUR, without knowing even what DNS resolver they are using, and the probably don't even care as long as it works.

I confirmed the solution provided by @chandradeepdey on a fresh VM install with the archinstall script's default networking option selected (this is as close to a "default" configuration as possible, although most users are probably still used to configuring their network manually during install). Removing resolve [!UNAVAIL=return] from /etc/nsswitch.conf fixes the issue even with systemd-resolved running (no restart required). Someone in the chromium thread also pointed out that this is specific to a combination of systemd-resolved and libnss_resolve.

@chandradeepdey also brings up a good point regarding security. Given everything we know about this issue right now, I don't think the update should continue to be blocked. There should be a post_install function in this package which notifies users of the problem with resolved+libnss in the current version.

I think something as adversary facing as Chromium should not be blocked like this. Chromium 92 has multiple security issues fixed.

1. As acknowledged here already, systemd-resolved is only used by a fraction of the userbase.
2. The issue can be easily worked around by removing systemd-resolved from /etc/nsswitch.conf and setting it to something like hosts: mymachines files myhostname dns*.

*DNS resolution still happens via resolved, dns uses /etc/resolv.conf which (if symlinked correctly) contains the address of the systemd-resolved stub resolver. I had this idea because Ubuntu does not use the nss module by default and there is no issue there.

This is the issue I'm following at least:

https://bugs.chromium.org/p/chromium/issues/detail?id=1221442

Fix is merged into Chromium, but now we have to wait until next Chromium release (Which sould be next week), and then for a new Brave release based on this Chromium release. Which I hope we can get soon after.

For example the official Arch Chromium package has a couple of patches applied that can't be applied here.

Until that the update is frozen. You can update manually if you don't want to wait by using @duhdugg PKGBUILD: https://gist.github.com/duhdugg/3cb48d09b5f3c31adbc06c55efb466c8

Could you guys please link to these issues? :)

@alerque: Indeed, I do not use systemd-resolved but Unbound.

Looks like the fix could arrive at Chrome next week. If that happens let's hope Brave makes a new release rebased on it.

I've just tested 1.27.109 and the situation has not improved. With systemd-resolved in the mix it freezes up hard on startup with an error about not being able to reach the update check site. If I disable systemd-resolved and just use the glibc resolver it works fine.

I'm on the fence as to whether to bump this or not until that is fixed. It's clearly an upstream bug and only affects a subset of users, but I think given how common it is its probably not a good idea to force this through yet. Users that want it can bump the version easily enough themselves since no packaging changes are require other than a version bump and skipping the checksum.

@Th30 What DNS resolver is your system using?

No problems either in my case using v1.27.109

@alosarjos No issues with font rendering.

@duhdugg You don't have any problems with text rendering neither? there is an issue with glibc:

https://bugs.chromium.org/p/chromium/issues/detail?id=1164975

Witch the patches applied to the Arch Chromium build (I think these have not been merged yet and then backported to M92)

PD: Latest version is also available on flathub-beta and work nicely with resolved

There seems to be a new release based on a new Chromium version but I can't test it right now. I would wait for the regular chromium update to see if it's still requiring the workarounds

The pinned comment is inaccurate. The affected chromium code is broken only on systems using systemd-resolved for name resolution. You can use NetworkManager, dhclient, or dhcpcd with systemd-resolved disabled and not be affected by this bug.

Here's a PKGBUILD for the recently-released v1.27.109 if anyone not using systemd-resolved wants to stay updated until this is sorted out: https://gist.github.com/duhdugg/3cb48d09b5f3c31adbc06c55efb466c8

1.27.108 is known to be broken on Linux for all users using systemd-resolved. Since this is the default on Arch that would make this broken by default, so we won't be pushing it up here until there is another release that addresses the issue. Those wishing to run a newer release using a different resolver can easily do so by bumping the version to 1.27.109 themselves (see other comments).

@jorgicio @francoism90 @CReimer @HOuadhour Please see comments below, comments in the PKGBUILD, and commit history. 1.27.108 is known to be broken on Linux, we won't be pushing it up here until there is a fix.

1.27.108 is available, however it seems this has been reverted?

@Th30 Thanks for the link to that issue, but that's not actually the blocker we're seeing that has to do with DNS resolution.

https://github.com/brave/brave-browser/issues/17122 ?

Sorry for the flag, I have now seen in the changes that you reverted it because it broke.

@mixedCase Best of luck. NixOS is awesome by the way. If Arch were to loose me entirely to something at this point that is the most tempting alternative.

@alosarjos Thanks for that info, that's super helpful. Please do keep us posted here.

I'll probably push out a pkgrel bump to fix some packaging issues (e.g. the license file is not ending up in the right place and there are some other coding style cleanups I'd like to see) but I'll hold off pushing 1.27 until I get word or see it working better.

The chromium package in which Brave 1.27 is based has some issues on Linux with rendering and navigation if using systemd-resolved

https://github.com/archlinux/svntogit-packages/commits/packages/chromium/trunk

I'm not sure if pushin 1.27 is a good idea until these are fixed upstream. If I'm not mistaken the Arch Chromium package has added the upstream patches to fix them , but those are not available yet on a Chromium release and thus, are not available on the Brave release and would require a patched Chromium and rebuilidng brave.

@alerque TL;DR: I'm disowning this package and there's an update pending.

I pushed an update to version 1.27.108 after successfully checking brave://version and brave://gpu, and after I pushed I found out I was actually unable to load pages. I reverted the commit without pushing epoch since it was only 5 minutes, ran pacman -Syu just in case, rebooted and my system is now unbootable, failing to load kernel modules for whatever reason in both my lts and zen kernels. No will to debug this right now so I'm just going to nuke my Arch partition and move full time to NixOS.

I've unpinned the pinned comment since it's going to be out of date. Here's the one-liner for checking latest version in case it's useful:

curl https://brave-browser-downloads.s3.brave.com/latest/release.version

Thank you for offering to help!

Thanks so much , keep it up

@alerque Added as co-maintainer, thanks!. Keeping it up to date is not a problem for me, but I'd rather not have a package with many users just left to luck of the draw if I'm no longer able to update it without testing it.

@mixedCase Yes I've had a look at the brave PKGBUILD already. It will need a bit of an overhaul before it's ready for [community]. Since I'm a pretty new TU I'm putting off that project until I know the ropes a bit better.

In the mean time feel free to add me as a co-maintainer if you want less pressure to update this one. I see folks are pretty demanding about it being fresh (to the point of obnoxious). But at least with a couple people ready to poke it you won't feel like you have to fire up another distro just for that. Also if you do disown it that will leave me as the maintainer by inheritance and I'll either run with it or help find a good home.

@alerque, thanks for the feedback! @mixedCase, agreed, brave is the one to be merged into community.

@alerque AUR package brave does just that with some manual patching, might be worth looking into. On an unrelated topic I'm doing some distrohopping and I may end up disowning this package. In case it comes to that if you'd rather have me notify you or some other TU in advance instead of doing it out of the blue, lmk.

@mgdobachesky @spsf64 I have an eye on it. Bringing it to [community] involves building Chromium though which is not trivial. You can't just cram an upstream binary from a -bin package in [community].

@mgdobachesky I agree 100%! Can't understand why Brave is not there yet... I'd rather have Brave instead of Vivaldi or Opera (found in std repos).

We should find a TU to bring this to the community repo :)

@The_GodfatherX Cannot reproduce. Sounds like a problem with the AUR helper you're using, try using makepkg.

@maverick1 The package name "brave-deb" is available for the taking in the AUR if you want to try that approach.

I really feel like these small issues will be fixed if we go with deb or rpm build.

brave-bin-1.26.67.zip is failing the "Validating source files with sha512sums...", all the other files

brave-bin.sh ... Passed
browser.desktop ... Passed
logo.png ... Passed

ive used "pamac build brave-bin"

@maxpayne3 Removed x-scheme-handler/ftp from both MimeType declarations.

Please, reupdate the desktop entry from deb/rmp package, the support for ftp has been removed on Linux. See changelog and #15812.

Updated.

Please update the desktop entry since the one contained in rpm/deb release has more mimetypes and translations for new window and private window actions.

@maxpayne3 Well if you want the details of my reasoning:

Linux is the kernel, yes, that doesn't matter; it's the potential for package-specific hacks that only concern itself with the userspace of Debian-derivatives that I'm concerned about. I don't want to maintain patches for those as a matter of principle, no matter how small, and even if there's none needed now, those packages are meant for Debian derivatives, meaning that upstream is free to break compat with us at any time for they don't officially support running the Debian package in a non-Debian system, and they very explicitly ship a tarball for non-Debian systems. Does this mean they'll add such hacks that break .deb's contents for Arch? Unlikely, but I'd rather stick to reasonable expectations for upstream: *.deb meant for Debian-based distros, Tarball is generic.

But even more important to me is the first thing I mentioned: I don't want to make a big packaging change for so small a gain, it's not worth my time. If your network constraints means that those 33MB are a big difference for you, I'd suggest forking the Google Chrome AUR and adapting it for Brave's deb release, and you can even publish it as a brave-deb AUR package for other people who share the same needs.

Hope that makes sense, sorry I didn't explain myself earlier. Cheers.

Sorry, but I don't think it's worth reworking the PKGBUILD and adding unnecessary risk using a release not meant for us for 33MB.

Not meant for us? Fedora and Ubuntu are Linux distributions, just like Arch. Those packages include even the desktop entry and logos, so you don't have to provide yours outside. Maybe it's worth give them a try. Google Chrome on AUR is made from the official deb package.

The scaling problem appears to have been fixed with the newest release. Thanks for the help again mixedCase (o:

@mixedCase Simply adding that flag does show video hardware acceleration on paper. But looking at any videos I found it's using ""Dav1dVideoDecoder" and looking at the CPU usage, I think it's not using GPU for video decoding.

I believe it used to have a build parameter that allows GPU video decoding. Can we get it back?

[update] Just checked the official deb packages. It seems they have switched to compile with vaapi off. I guess unless we compile it ourselves, there's nothing we can do.

[update] OK, filed an issue: https://github.com/brave/brave-browser/issues/16392

[update] My bad. I probably just played a video that's encoded using AV1. But most of other videos are indeed decoded using GPU. Confirmed by using the media tab of the inspector. Sorry for the confusion.

@mixedCase Thanks, that seems to work :)

Graphics Feature Status
Canvas: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Out-of-process Rasterization: Hardware accelerated
OpenGL: Enabled
Rasterization: Hardware accelerated on all pages
Skia Renderer: Enabled
Video Decode: Hardware accelerated
Vulkan: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated

@maverick1 Sorry, but I don't think it's worth reworking the PKGBUILD and adding unnecessary risk using a release not meant for us for 33MB.

@francoism90 That feature moved to a command line parameter when the rebase to Chromium 91 occurred:

--enable-features=VaapiVideoDecoder

You can add it to your .config/brave-flags.conf for convenience.

Seems hardware video decoding support has been removed, is it possible to enable the video_decode flag again?

Can you switch to the .deb package instead of the .zip one? Its saves 33 MB of download.

@mixedCase Yup; running it with --force-device-scale-factor=2 fixes the problem for now.

@mixedCase Thanks; I'll have a look at it. And thank you for maintaining the package.

@Parintachin I don't support Manjaro. Regardless, sounds like a Google-upstream problem, but I suggest looking at this to see if it helps you override whatever the browser's doing: https://wiki.archlinux.org/title/HiDPI#Chromium_/_Google_Chrome

Manjaro KDE. This package, like the Chrome package that dropped a few days ago, does not play well with high-dpi screens when scaling is chosen. It looks like the scaling factor is applied twice - everything is huge.

thanks :D

@chandradeepdey Patch applied to latest revision. Cheers

@mixedCase This is perfect. Thanks.

@chandradeepdey I don't have a desktop to test icons. Does this patch work for you without breaking the regular shortcut? https://gist.github.com/mixedCase/80471462a4135c7b307486f4a5d84869

When you install a web app, the following is added to $XDG_DATA_HOME/desktop-directories/chrome-apps.directory-

[Desktop Entry]
Version=1.0
Type=Directory
Name=Brave Browser Apps
Icon=brave-desktop

Brave expects the icon to be named brave-desktop. This package puts it as brave, can this be changed?

@zerophase the --reflink option was used to speed up the packaging phase by doing a lightweight copy of the package contents to $pkgdir. It had no effect whatsoever on brave-bin performance. See cp(1) manual.

I have had no issues with brave lately, but I do not use it that much.

For anyone having issues with the browser loading the 1.25 brave-beta-bin browser fixes the problem. If we all of that issue it might be worth updating to the beta here anyways.

Having issues with Brave refusing to load pages. Seems to have gotten worse with the latest update.

@mixedCase Could removing that reflink=auto flag break GNU releases? Can't we just add a flag or detection method for using a version of those lines with and without it? Isn't it pretty easy to detect if someone does not have cp? I think it's like 4 lines of a script.

Some of those optimizations definitely impact performance depending on how the code is written in certain use cases.

@Th30 I don't use Brave rewards, but I've seen people complaining about the same thing in the Brave subreddit. Seems like a cross-platform issue.

I haven't had any 'brave rewards' ads in about two months. Is it the same for you?

@konicks Arch is a GNU system, GNU cp being part of the base package and therefore expected. And reflink=auto is a behavior that should be the default in coreutils to make use of CoW where possible.

But... honestly this is such a pointless optimization and you went through the trouble of asking so giving you the benefit of the doubt that you actually have a usecase for it, I went ahead and removed it.

Cheers.

@mixedCase sorry to bother but would you please remove the GNU only flag in the first cp command of the package function (--reflink=auto)? It's better to only use POSIX compliant flags in scripts and packages (man 1p command for posix man page of that command) and because of that flag the package doesn't build on systems with different userland coreutils (BSD, Plan9, BusyBox, ToyBox, UNIX v5, etc). Also, the flag is pretty weirdly placed and doesn't seem to serve a concrete role in significantly improving build speed or build quality, it's just kinda...there, and it means the package requires modifications on non GNU systems

I made a modified PKGBUILD file: https://pastebin.com/4zEfYsJW

Cheers, Nick

What are the "rules" for votes? As in, who actually looks at them? Should we be voting for the source "brave" package instead? Thanks for your work on this!

@ThePierrezou I don't know of any place where Brave uploads signatures (if they even make one) for the files we build upon. Patches welcome if there's actually such a place.

Is it possible to get the PKGBUILD to verify the signature of the package please ? https://brave.com/signing-keys/

Thanks for the bin package! Compiling brave takes over 6hr on this machine so really appreciate your contribution! Last time updated brave it timed out on a chromium request (continued to build) as I was asleep.

@laba I have not, this script pretty much just repackages upstream binaries as you can check yourself. Also AFAIK all Chromium derived browsers use system DNS on Linux and, well, I'm getting 1.1.1.1 with DNS over TLS for I have that set up in systemd-resolved.

I can't find anyone mentioning this in the issue tracker either so it sounds like it's just your system's DNS configured to do that as well.

@mixedCase Hi, I noticed a strange think in that brave version. It uses cloudflare 1.1.1.1 dns server with dns over tls enabled even if brave doesn't support neither dns server changing nor enabling dns over tls or https on GNU/Linux. So, have you added it to brave or they have enabled it and haven't said anything ? It's really strange.

@anjanik012 @Takuya For an AUR package to go into [community] it requires adoption by a trusted user, which I'm not, don't want to be, and I haven't received word from one interested in adopting the package.

Additionally, this is the binary distribution from upstream, I'm almost certain TUs would rather adopt the package that is built from source, which is https://aur.archlinux.org/packages/brave

The person who maintains that package keeps a binary repo for it. If you're comfortable with using third party repos and your goal is just to not have to deal with the AUR for updating your browser, might want to look into it.

@anjanik012 I'm hoping that will change in the near future, Vivaldi already did it, a few months ago, hoping more users will vote this package so we could have it on the official repos :). So the answer to your question, I suppose that will be when this package receives much more votes from the AUR community :D.

Why is this package not in the official repos?

@kiankasad I had forgotten to remove it after Brave fixed the SUID sandboxing fallback not working on their side and I was reminded of it by e-mail, mentioned in commit description.

Comment unpinned, thanks for the reminder.

I noticed that with the update to 1.19.92-1, the check for user namespaces is removed from brave-bin.sh. Why exactly is this?

Also, with this change in effect, @simonorono's comment can be un-pinned, since the kernel.unprivileged_userns_clone sysctl no longer affects anything.

@nowy Thanks for the reminder! That had slipped up my mind. Removed.

I think pepper-flash is no longer needed for brave since it's chromium version upgraded to 88.

It's ok, I cleared my AUR cache and re did it and it worked fine

@gameslayer Which one? I just redownloaded everything and it checksums.

ERROR: One or more files did not pass the validity check!

@maxpayne3 Sorry if that came across as a discussion on the merits/demerits of Nautilus, give me a chance to state the problem in simpler, unbiased terms:

This is a Nautilus bug in their handling of FTP.

There is no browser or app producing an issue, Nautilus just has a bug where it doesn't open FTP files properly if there's an FTP client in the system. The only situation where it's not a bug is if, by design, Nautilus expects the user to never have an app with FTP support installed.

@mixedCase I'm not interested in opening a discussion on how Nautilus is bad.

My only knowledge is that the browsers which produce this issue are Brave and Google Chrome, both not officially supported on upstream and hosted on AUR. No other browser in upstream I use, I have installed some, Firefox, Otter, Gnome Web, throw this issue since they don't have ftp mimetype in their desktop entry.

Maybe guys on upstream are wrong? Who knows? If you don't want to modify it, it's not a big deal, I already have a custom entry in local folder, but I suggested it to avoid users who use ftp share to blame Brave or going to Nautilus bug report to hear that it's a packaging problem.

@maxpayne3 I want to give Mr. Holy the benefit of the doubt but what he said on that issue there makes no sense, even after reading the linked issue. It's a terrible workaround as Brave (or Firefox, in that case, at that time) does support FTP and correctly advertises it according to the XDG MIME Spec.

I'm open to being completely wrong, but from the info I have it's pretty obvious that Nautilus' networked share implementation is just bad UX and it's pretending to the user that it's working in "just another folder" while not hiding properly the fact that the file is remote by passing the URI instead of a file to their file opener. They should either make something like a FUSE filesystem that mounts on the fly if they want to make good UX for their facade, or have GIO have a special way deal with their incorrect behavior.

In the meantime the most user-friendly solution I would recommend is using a dedicated FTP client like FileZilla. If you really want to use Nautilus for accessing FTP, you can manually do what Nautilus should be doing for you and mount your remote FTP server in a folder of your convenience using a FUSE filesystem for FTP like curlftps.

@mixedCase please, modify the desktop entry removing x-scheme-handler/ftp in MimeType lines.

This will fix this issue. Thanks.

@mixedCase, thanks for the quick response. I know that the sandbox binary is not used unless userns is not available. My issue is dropping a 3rd party prebuilt binary that is SUID root into my machine in the 1st place. I would prefer having as few SUID root executables as possible. Though I don't favor with the decision, I now understand your reasoning behind making this change. Sorry if I came out too harsh previously.

@Netboy3 Under a normal Arch install the SUID sandbox is not used. User namespaces are used. Check brave://sandbox/ before getting your panties in a twist again. If it's not the case then it is indeed a bug and you can report it accordingly like an adult.

The reason I fixed it is because some security-minded people think that running Arch with third-party packages is super-fine security wise but user namespaces is a bit too much for their threat model and trust the SUID sandbox more than unprivileged user namespaces. Well they're big boys, Brave officially supports their usecase (https://github.com/brave/brave-browser/issues/6247) and I'm not going to make a stand just because I personally think it's pointless; that's why I set the right perms needed for it instead of letting it be copied over for no reason with the generic perms it had before.

As a downstream packager I try to keep Brave's intentions for the release intact, in that same vein I will not be restoring it if Brave changes their mind and/or Google finishes removing it upstream. Firebird wants to use SUID sandbox, Brave supports it, it takes me no effort to do so so I will support it too, and if you don't like it then go file an issue to Brave or do maintain your own package.

@mixedCase, I don't understand the logic of your last change (commented on 2020-11-24 17:42). You admit that the SUID method is deprecated, and users should use unprivileged namespaces, yet you modify the install to set a third party binary installed with SUID root. I'm sorry but this is illogical and irresponsible, especially considering the number of votes and the popularity of this package. And there's a big difference between the need to use QubesOS and setting an unverified binary SUID root. Hopefully, enough folks will read this comment and either move away from this package, or package it by themselves (like I will from now on).

@rageltman It's trying to get Brave to run with the upstream-deprecated SUID sandbox instead of the officially supported user namespaces sandbox.

Just added it since it seems inoffensive for userns users but I won't be doing anything weirder than that for supporting the SUID sandbox.

Some unsolicited advice: I would recommend QubesOS and not trusting guys like me to do your packaging if you have that level of concern.

The sandbox binary doesn't have the correct permissions set. Need to chmod 4755 $pkgdir/usr/lib/brave-bin/chrome-sandbox in the package() call or the bug prevents launching the browser at all (at least under firejail):

[6:6:1124/122723.010065:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /usr/lib/brave-bin/chrome-sandbox is owned by root and has mode 4755.

@kiankasad Applied. Thanks

@mixedCase I figured out why. makepkg doesn't put the extracted files in a subdirectory. Anyways, here's a patch to remove the useless cat:

diff --git a/PKGBUILD b/PKGBUILD
index 429d407..3f76b95 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -35,7 +35,7 @@ noextract=("$pkgname-$pkgver.zip")

 prepare() {
   mkdir -p brave
-  cat $pkgname-$pkgver.zip | bsdtar -xf- -C brave
+  bsdtar -xf $pkgname-$pkgver.zip -C brave
   chmod +x brave/brave
 }

@kiankasad original maintainer set it up that way and it works. Changing it means changing directory structure and me having to lookup manpages, but it isn't an issue so I don't care about it.

Patches welcome if it bothers you enough.

The prepare function is slightly confusing:

prepare() {
  mkdir -p brave
  cat $pkgname-$pkgver.zip | bsdtar -xf- -C brave
  chmod +x brave/brave
}

Why cat the archive into bsdtar instead of using bsdtar -xf $pkgname-$pkgver.zip -C brave? Why extract the archive this way at all? Can't makepkg do that automatically after downloading?

@eronis55 libnotify integration is working fine here. Just added it to optdepends to make it clear that you need to have libnotify.

Other than that, I don't use Brave rewards so I need feedback by users who do to see what kind of errors they're seeing in their terminal when running Brave from it.

Brave Rewards function has a problem with your package. It may be that you need to add some new dependencies or something like that.

https://community.brave.com/t/brave-does-not-show-any-notifications-on-arch-linux/177664/7

@kiankasad Pushed a fix for this and removing an obsolete workaround. Thanks for the report and collaboration! Please let me know if you have any issues.

@mixedCase I think that'll work. As far as I can tell, this pseudocode covers all use cases:

if CONFIG_USER_NS=y:
   if kernel.unprivileged_userns_clone=0:
      --no-sandbox
else:
   --no-sandbox

@kiankasad Well what I'm seeing is that user namespaces do seem to be enabled by default on Arch. But the kernel parameter is still a thing and it seems to be a way to disable them, which linux-hardened uses and I imagine some users do as well.

Can you confirm you're using a kernel without Arch patches? I can change the script to simply run --no-sandbox if the kernel param exists and is set to 0, I gather that should do it without breaking users of the kernel param.

@mixedCase I linked an image to brave://sandbox results in my previous comment. https://web.archive.org/web/20210118200105/https://files.kasad.com/brave-sandbox.png

@kiankasad I think you misread the wiki article, it mentions that the feature is enabled only for root in linux-hardened, while in every other kernel enabling the feature does it for all users. Relevant section:

Firstly, a kernel is required that has support for User Namespaces (a kernel with CONFIG_USER_NS). All Arch Linux kernels have support for CONFIG_USER_NS. However, due to more general security concerns, the linux-hardened kernel does ship with User Namespaces enabled only for the root user. There are two options to create unprivileged containers there:

Start the unprivileged containers only as root. Enable the sysctl setting kernel.unprivileged_userns_clone to allow normal users to run unprivileged containers. This can be done for the current session with sysctl kernel.unprivileged_userns_clone=1 and can be made permanent with sysctl.d(5).

If this is not upstream behavior, then this is patched downstream in the same manner by Arch as well. Just to make sure, I downloaded latest ISO and booted a virtual machine and sure enough, its kernel recognizes it, and I also added some nonsense to corroborate my knowledge that sysctl fails on a nonexistent parameter: https://i.imgur.com/PayQTEK.png

Can you share what brave://sandbox returns for you? Perhaps they've reenabled the deprecated setuid sandbox for some reason; in which case I'd still rather just point users to use the one that actually has been maintained upstream by Google for the past few years.

@mixedCase It's provided by a Debian kernel patch: https://serverfault.com/a/939457/562138 https://security.stackexchange.com/a/209534/221678
Grepping in the Linux source code returns nothing. I'm not sure why the file exists on your machine, but with the stock Arch kernel, it isn't there:

$ sudo ls /proc/sys/kernel/unprivileged_userns_clone
ls: cannot access '/proc/sys/kernel/unprivileged_userns_clone': No such file or directory

User namespaces will work with the default Arch kernel, even if the kernel.unprivileged_userns_clone option does not exist (as long as CONFIG_USER_NS=y). I've removed the check from the launcher script and sandboxing works fine: https://web.archive.org/web/20210118200105/https://files.kasad.com/brave-sandbox.png (The yama support is unrelated)

This fix has already made it into brave-nightly-bin

EDIT: that ArchWiki page specifically states that that sysctl option is for the linux-hardened kernel, and it does not say to do anything to enable unprivileged user namespaces on the default kernel.

@kiankasad Not sure what gave you that idea, are you using linux-hardened perchance?

https://i.imgur.com/LUOYuUV.png

https://i.imgur.com/uxASIZU.png

https://wiki.archlinux.org/index.php/Linux_Containers#Enable_support_to_run_unprivileged_containers_(optional)

The file /proc/sys/kernel/unprivileged_userns_clone is provided by a kernel patch that exists in Debian. On Arch Linux, the file should never exist. This means that even when user namespaces are enabled, Brave will run with the sandbox disabled (which is not good).

This can be fixed by removing the check for /proc/sys/kernel/unprivileged_userns_clone in brave-nightly-bin.sh

I know there's a pinned comment describing how to fix this, however that fix does not work, since that kernel option is nonexistent on Arch.

Thank you @urbenlegend, the script has been updated to the latest version and to no longer use the .deb workaround.

According to the latest release notes, Brave zip should have the OpenGL files included now, so the deb is no longer needed.

@numToStr It's a temporary workaround for an upstream packaging issue which has been supposedly fixed in Brave master already but will take a little while to trickle down into stable.

Why is there .zip and .deb packages?

@francoism90 No I'm not getting that, with or without Vulkan. I don't have that file either but the browser doesn't seem to complain about it.

@mixedCase Thanks, hope it can be solved soon.

Is this normal:

$ brave
[775988:775988:0918/132645.572591:ERROR:sharing_service.cc(260)] Device registration failed with fatal error
[775988:775988:0918/132645.654279:ERROR:CONSOLE(1)] "[Shields]: Can't request shields panel data. Error: No tab url specified", source: chrome-extension://.../out/brave_extension_background.bundle.js (1)
Failed to parse JSON adblock resources: EOF while parsing a value at line 1 column 0
[776256:776256:0918/132646.927797:ERROR:gl_implementation.cc(286)] Failed to load /usr/lib/brave-bin/swiftshader/libGLESv2.so: /usr/lib/brave-bin/swiftshader/libGLESv2.so: cannot open shared object file: No such file or directory
[776256:776256:0918/132646.928844:ERROR:viz_main_impl.cc(150)] Exiting GPU process due to errors during initialization

@francoism90 Yup I found one already there after my last comment and indeed it seems to be at least AMD specific: https://bugs.chromium.org/p/chromium/issues/detail?id=1122224

According to that thread there are a few more usable workarounds if the Vulkan renderer gives any trouble.

@mixedCase I'm using amdgpu (no navi). Do you have a bug report? :)

@francoism90 It's an upstream bug, it happens to me with Google Chrome as well. Are you perhaps also using amdgpu with a Navi card?

After the latest upgrade, I'm having graphical corruption issues. Could the latest WebGL patches have something to do with this? After switching to Vulkan as backend, the issues seem to be gone, but it's weird as they one appeared on Brave.

My reported GPU settings:

Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Out-of-process Rasterization: Hardware accelerated
OpenGL: Enabled
Hardware Protected Video Decode: Hardware accelerated
Rasterization: Hardware accelerated on all pages
Skia Renderer: Enabled
Video Decode: Hardware accelerated
Vulkan: Enabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated

If I disable Vulkan, the GPU issues start popping up. If this is an upstream bug, please let me know, just checking if I'm the only one. :)

@maverick1 The .deb uses a completely different structure and a PR is already open upstream to fix the WebGL issue for the .zip; so I'd rather not rework the PKGBUILD specially when the .zip is the official non-Debian distribution of Brave.

This nuisance too, shall pass.

This PKGBUILD downloads both .zip and .deb files. But I have seen people in Solus just packaging it with .deb. I know that you included the .deb package to fix WEBGL stuff. So is there a chance to completely switch to .deb only.

@TripleSpeeder Thanks for the heads up, I just pushed the workaround to do so.

Meaning that IN THE MEANTIME until Brave unfucks their shit in that particular area, everyone will have to download the browser twice on install. Please report in case this workaround works for you, or breaks things even more.

Upstream version 1.13.82 broke webGL (and probably all hardware acceleration). The upstream zip release is missing some libraries.

This bug is tracked at https://github.com/brave/brave-browser/issues/11504.

@mixedCase, maybe you can release an interim version that includes the missing libs? See https://github.com/brave/brave-browser/issues/11504#issuecomment-686907258 for instructions :-)

@cikisir Alright, then you can go complain on upstream about the issues you're having or ask for browser recommendations in the forums, IRC, subreddit. This is not the place for it.

@cikisir This is not the brave package, this is the brave-bin package. This is a binary package, if you see anything compiling then you're probably installing the other package.

Try installing this package and see if your issues persist.

Thanks for the reports everyone, package has been updated to tolerate yet another of Brave team's fuck-ups where they remove the LICENSE files for whatever reason.

Yes, it is messed up at the moment. But, all you have to do is remove the last line in the PKGBUILD because it's looking for license files that don't exist. (This does need to be fixed in the package of course, but if you just want it to install...)

@mixedCase I did try cloning using the link above and run makepkg -si. I still got the same error as @ragouel What other ways are there to update an AUR package? I used YAY.

@mixedcase: Done a yay -G brave-bin.

Entered brave-bin directory. Entered makepkg -s. Broken. Full log:

$ makepkg -s
==> Making package: brave-bin 1:1.11.97-1 (Thu Jul 16 20:15:25 2020)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found brave-bin-1.11.97.zip
  -> Found brave-bin.sh
  -> Found brave-browser.desktop
  -> Found logo.png
==> Validating source files with sha512sums...
    brave-bin-1.11.97.zip ... Passed
    brave-bin.sh ... Passed
    brave-browser.desktop ... Passed
    logo.png ... Passed
==> Extracting sources...
==> Starting prepare()...
==> Removing existing $pkgdir/ directory...
==> Entering fakeroot environment...
==> Starting package()...
mv: cannot stat '/home/fred/brave-bin/pkg/brave-bin/usr/lib/brave-bin/LICENSE': No such file or directory
mv: cannot stat '/home/fred/brave-bin/pkg/brave-bin/usr/lib/brave-bin/LICENSES.chromium.html': No such file or directory
==> ERROR: A failure occurred in package().
    Aborting...

Your PKBGUILD is broken.

@ragouel Try not using an AUR helper and post again if you have issues.

mv: cannot stat '/home/crow/.cache/yay/brave-bin/pkg/brave-bin/usr/lib/brave-bin/LICENSE': No such file or directory
mv: cannot stat '/home/crow/.cache/yay/brave-bin/pkg/brave-bin/usr/lib/brave-bin/LICENSES.chromium.html': No such file or directory

@Serial I just tried redownloading again and the checksum checks out fine. Looking at your screen it appears that you're dealing with a bad internet connection and the file ends up being corrupted.

I'd suggest trying two things:

a) Don't use an AUR helper. Clone this package's git repo and run makepkg -si on it.

b) If the problem persists, attempt to download the upstream .zip file from a web browser.

@mixedCase

Preparing... Cloning brave-bin files to compile ... Checking 1brave-bin dependencies ... Synchronizing package database ... Updating community.db ... Solving dependencies ... Checking package conflict ... Dtkgui (5.2.2-1) download started Checking keyring ... Checking package integrity ... Loading package files ... Checking file conflict ... Updating dtkgui (5.2.0.1-1 -> 5.2.2-1) ... Running post-transactional hooks ... Arming ConditionNeedsUpdate ... Reloading system bus configuration ...

Building brave-bin ... ==> Creating the package: brave-bin 1: 1.10.97-1 (Wed 24 Jun 2020 20:28:06) ==> Checking runtime dependencies ... ==> Checking build time dependencies ... ==> Getting fonts ... -> Found brave-bin-1.10.97.zip -> Found brave-bin.sh -> Found brave-browser.desktop -> Found logo.png ==> Validating source files with sha512sums ... brave-bin-1.10.97.zip ... FAILED brave-bin.sh ... passed brave-browser.desktop ... passed logo.png ... Passed ==> ERROR: One or more files have not passed the validity check! Failed to compile brave-bin

View image: ( https://imgur.com/a/gXFmp6O )

@Serial Cannot reproduce, was just able to redownload.

==> ERROR: Failed to download https://github.com/brave/brave-browser/releases/download/v1.10.97/brave-v1.10.97-linux-x64.zip Aborting ... Failed to compile brave-bin

@genelocated Sorry I'm answering late, e-mail got lost in a mountain of crap.

A new version has been pushed. Please let me know if this is now behaving correctly and on what desktop you've observed the behavior whether correct or not.

Thanks for the report and patch!

@mixedCase Please add Actions property under the [Desktop Entry] section:

 Type=Application
 Categories=Network;WebBrowser;
 MimeType=text/html;text/xml;application/xhtml_xml;image/webp;x-scheme- 
 handler/http;x-scheme-handler/https;x-scheme-handler/ftp;
+Actions=new-window;new-private-window;

 [Desktop Action new-window]
 Name=New Window

solved ... seems that the brave update domain was blocked in my hosts file facepalm I'm embarrassed

@kronikpillow Yes, this was a new random extension by Google that I had never used before. I did not reinstall the entire OS to test it, however I just tried testing again by deleting the Brave configuration folder and using a fresh profile with a new add-on. Works just fine.

Try to open Brave in a terminal to get console output and also keep the developer tools open (in network tab, and press escape to open console at the bottom as well) while using the Chrome web store to see if any failures are apparent.

@mixedCase are you sure? have you tried installing a extension or are you using previously installed ones? I'v been having this problem for quite some time now, first I thought it was a error from upstream, reported it there, and they claim its not a upstream issue ... Im on a freshly reinstalled system, with a fresh install of Brave, when i go to the chrome webstore and click add to brave, the download interupts, and when I try to download an extension with a extension downloader service, it downloads, and when i drag and drop it to brave it restarts the propmt for download, and just redownloads it again, meaning it doesn't give me a option to install it

@kronikpillow Working fine here. Months ago I had a similar issue and I think it solved itself after a reboot.

after fresh system reinstallation, I can't install chrome extensions anymore, download interrupts ... reported to mainstream they claim that it works for them, is anyone experiencing similar issues? https://github.com/brave/brave-browser/issues/9138 https://www.youtube.com/watch?v=M2RGbAlOyt

Thank you for maintaining this! I am always surprised by how quickly you update this package, and it is really nice to have an Arch package for Brave.

@mixedCase I don't think upstream will solve this as it depends on mesa and other stuff as well.

@francoism90 This PKGBUILD packages the official Brave release. Let upstream know about this in either an existing GitHub issue or a new one.

@monson This PGKBUILD makes a system package owned by Pacman, matching Arch's official Chromium distribution and compliant to FHS 3.0, it's funny you ask because I actually got an e-mail about this around a couple of weeks ago.

Anyway my interpretation of the FHS and what Arch does is that /opt is more for the sysadmin dumping programs that don't follow the system hierarchy and the files aren't owned by the package manager. Although sometimes packagers can't (or can't be arsed to) reorganize everything so they make packages that dump everything to /opt.

Since it is a stand-alone binary application provided by commercial company, would it be better if put into /opt/brave instead of /usr/lib/brave-bin?

@mixedCase Could you please add the following patch from chromium-vaapi but based on Brave?

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=chromium-vaapi#n35 https://aur.archlinux.org/cgit/aur.git/tree/chromium-drirc-disable-10bpc-color-configs.conf?h=chromium-vaapi

It is possible to enable VA-API in Brave, but the color corruptions keep happening.

Thanks for this. The community package is always out of date. Works great!

For those who were having issues: Brave has released version 1.3.115 with sync disabled, which apparently was the cause of the crashes.

@mixedCase on 1.3.113 I got similar errors to those reported by Philotomy.

Here's terminal output:

[9789:9789:0209/100534.337651:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.

9794:9806:0209/100538.984279:ERROR:broker_posix.cc(40)] Recvmsg error: Connection reset by peer (104)

/usr/bin/brave: line 27: 9766 trace/breakpoint trap (core dumped) usr/lib/brave-bin/brave "$@" $SANDBOX_FLAG $PEPPER_FLASH_FLAG $USER_FLAGS

The very first error line can be safely ignored - it's also thrown on 1.3.114. The next two are specific to 1.3.113 and probably are the cause of problems.

I don't think there is much to play with. Especially since it worked perfectly before - since like 1.0.X. It also works great with 1.3.114. Due to this I'm going with 1.3.114 for the moment.

Out of curiosity, I just took a look at brave community - the issues is reported by various Linux and Mac users. Brave recommends to give 1.3.114 a try (they called it a test version). So indeed 1.3.114 is some kind of pre-release. According to this topic 1.3.114 helps for some, but not all. Link: https://community.brave.com/t/repeated-crashes-on-1-3-113-on-mac-and-ubuntu/106020/18

I have noticed one thing though. On my other device with Windows 10, the installed version of brave is still 1.2.43. Brave auto-updater doesn't find new version. I think it's more of fun fact and it will update to 1.3.X at some point.

I'm also seeing the behavior Krzychu reported with 1.3.113 (crash upon launch). Messages are:

error: package 'pepper-flash' was not found mesa: for the --simplifycfg-sink-common option: may only occur zero or one times! mesa: for the --global-isel-abort option: may only occur zero or one times! [2841:2841:0208/112034.477829:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process. [2847:2851:0208/112035.636714:ERROR:broker_posix.cc(40)] Recvmsg error: Connection reset by peer (104) /usr/bin/brave: line 27: 2816 Trace/breakpoint trap (core dumped) /usr/lib/brave-bin/brave "$@" $SANDBOX_FLAG $PEPPER_FLASH_FLAG $USER_FLAGS

1.3.113 is currently working fine here on a couple of machines.

1.3.114 is still marked as pre-release (now almost 24 hours after first tagging it) and this package strictly follows upstream so I can't switch to that.

@Krzychu if you could go into detail about the kind of error you see on the terminal when launching Brave 1.3.113 maybe we know if there's something else at play.

In my case update to 1.3.113 broke brave - it would crash before letting me open any page. There is already newer version - 1.3.114. I have manually updated brave and it seems like the issue is fixed.

Hope this helps some folks that will also encounter similar problem. Or if you haven't updated yet you might want to wait till maintainer updates package to 1.3.114.

You are quite right. I was building the brave build by mistake ... wow never again I will build that - sorry for the confusion and thanks for maintaining the bin version

@erikdubois, I believe you are talking about package "brave", not brave-bin??

I am currently building brave-bin and it takes as super long time. What I am worried about is the message It is downloading at 90% finished and I have 18GB downloaded - can this be correct?

@Yazarai Yeah not sure what that was all about but I was able to reproduce that it will not run after disabling user namespaces.

Honestly? The setuid sandbox will be deprecated upstream and the Brave team seems to want to support it even less so I suggest to just enable them, it's not like no-sandbox will be secure. But I will leave the workaround at least not to annoy current users.

@mixedCase Hey again! Apparently I missed something in my report, as now Brave won't even open. I then tried to open from the terminal and this was the output:

[16186:16186:0108/185601.983661:FATAL:zygote_host_impl_linux.cc(116)] No usable sandbox! You probably need to enable user namespaces in your kernel. See <https://brave-browser.readthedocs.io/en/latest/installing-brave.html#linux> for more information.

/usr/bin/brave: line 22: 16186 Trace/breakpoint trap (core dumped) /usr/lib/brave-bin/brave "$@" $PEPPER_FLASH_FLAG $USER_FLAGS

Really weird considering what upstream said and showed. Could the problem be anything aside from the zip?

@Yazarai Thanks for the great report! 1.2.42 was just released so I just removed the --no-sandbox workaround. Please let me know if any issues arise in systems without user namespaces.

Dear maintainer,

With the 1.2.41 release, Brave has begun to allow the use of Chromium's sandbox when user namespaces are disabled: https://github.com/brave/brave-browser/issues/6247. This was done partially out of security concerns about user namespaces as a sandbox - see https://github.com/brave/brave-browser/issues/3420 for details.

However, brave-bin.sh still contains a command that makes the browser run with the --no-sandbox flag when namespaces are disabled, which is no longer necessary and makes it impossible to run the other sandbox. Please fix this.

@mixedCase - thanks; that did the trick! I just pulled and did 'pacman -Scc'. (PS AUR helpers are an abomination ;)

==> Validating source files with sha512sums...
    brave-bin-1.0.1.zip ... Passed
    MPL2 ... FAILED
    brave-bin.sh ... Passed
    brave-browser.desktop ... Passed
    logo.png ... Passed

Cache was certainly not cleared if that's the case. Just delete the MPL2 file from the root directory of the AUR repo and run makepkg -si again. If you're using an AUR helper check its documentation on how to properly clear cache.

@cubic - cache cleared and still get error about validity check (MPL2 ... FAILED)

@TeaKov clear cache

The MPL2 license checksum still fails over here

License checksum is now fixed, thanks for reporting.

==> Validating source files with sha512sums... brave-bin-1.0.0.zip ... Passed MPL2 ... FAILED <==== Uh-oh! brave-bin.sh ... Passed brave-browser.desktop ... Passed logo.png ... Passed ==> ERROR: One or more files did not pass the validity check!

Brave is finally 1.0!

I think its time to switch Brave Browser to Community repo!

@nuc you have installed brave instead of brave-bin. its a big difference. Thats why Arch Linux doesn't recommend AUR helper. I actually clone the package with git and install it.

If you use yay you must be careful with package's name

Upon updating Brave wants to download around 17GB of files, I dont even have that much space on my disk so I am unable to update:

Syncing Gclient (with reset)
/home/nuc/.cache/yay/brave/src/brave-browser: gclient sync --force --nohooks --with_branch_heads --with_tags --upstream
WARNING: Your metrics.cfg file was invalid or nonexistent. A new one will be created.
1>________ running 'git -c core.deltaBaseCacheLimit=2g clone --no-checkout --progress https://chromium.googlesource.com/chromium/src.git /home/nuc/.cache/yay/brave/src/brave-browser/_gclient_src_OBT96Y' in '/home/nuc/.cache/yay/brave/src/brave-browser'
1>Cloning into '/home/nuc/.cache/yay/brave/src/brave-browser/_gclient_src_OBT96Y'...
1>remote: Sending approximately 17.37 GiB ...        
1>remote: Counting objects: 230269, done        
1>remote: Finding sources: 100% (319/319)           
^CReceiving objects:  68% (9106301/13229268), 9.70 GiB | 12.13 MiB/s

Anyone knows whats going on?

brave browser can't be set as default browser by clicking on set default button.

I made a work around solution for it (I use KDE plasma):

1- create an empty html file (file.html)

2- Right click -> Open with -> Other Application... -> chose brave & tick remember application -> Ok

I just noticed I missed your last message arcomus. This package does not build Brave. This just extracts and uses the official binary. Please make sure you're trying to install brave-bin and not some other package and if it's the case please post the makepkg output.

Thanks for the report. Soon check.

Thanks for the report JantarMantar! Fixed.

There is a bug in brave-bin.sh shell script. One can't open a local file that has spaces in its name. To fix this, the last line must have double quotes around $@. That is, it should be:

/usr/lib/brave-bin/brave "$@" $SANDBOX_FLAG $PEPPER_FLASH_FLAG $USER_FLAGS || true

Hello Brave builder,

I have a question. Yesterday i tried to install brave on a arcolinux i3 xfce system. I stopped the install after 3 < hours. It also put 30 gig of data on my disk.

At the end not installed and it took a long time to delete brave components.

Strange situation for me.

I just installed the package and it works perfect. Very grateful for your work

@mixedcase, ops, sorry... did not see that orange "pre-release" tag

Deleting the comment...

@spsf64 That one is marked as prerelease.

Noting here in case anybody wonders: Package was just rolled back because a GitHub release was incorrectly marked as stable for some period of time by the Brave team, forcing an epoch increase.

@cg505 You are right, I didn't think that one through and in retrospect it should've been obvious, mb. Fixed.

Thank you @mixedCase! As for L21/22, I'm still not entirely sure how it's supposed to work. Doesn't ${pkgname%} just expand to brave-bin, like plain old ${pkgname}? I assumed the intent of these lines was to strip the -bin so that this package conflicts with/provides brave.

Thanks for the report @cg505! Can't test actully setting the default browser here but the detection is working with that change.

As for L21 and L22 fixed it because it was technically working but the code was misleading. Great catch.

@mixedCase Could you rename brave.desktop to brave-browser.desktop? This will resolve the issue where you can't use the button in Brave to set it as the default browser. See https://github.com/brave/brave-core/blob/e569501ac1d8c4a203776249cee4eaa7ad77dd5f/patches/chrome-browser-shell_integration_linux.cc.patch for the relevant code.

Also, I may be mistaken but I think on lines 21 and 22 of the PKGBUILD you want ${pkgname%-bin} instead of ${pkgname-bin}.

@maximbaz Sure, it has a few things hardcoded and storage relies on Google cloud but the querying mechanism should be straightforward enough: https://gitlab.com/mixedCase/aur-out-of-date-reminder

@mixedCase: could you please share your script that checks for availability of a new stable release? I wanted to setup an urlwatch rule, but the query is not very obvious...

Thank you @maximbaz, very appreciated!

I'm experimenting with Brave and I have pushed PKGBUILD to AUR/brave to compile the browser on our own, it also includes VA-API patch to enable hardware video acceleration just like chromium-vaapi does.

I have the compiled version in my repo as well, if you are interested to play around.

@mixedCase: this package should conflict with brave.

After I posted I thought maybe even inline comments can be supported as well, tested with | sed 's/#.*//', seems to work well :)

Oof nice catch, I forgot to retest that after some var renames. And great suggestion, included as well. Thanks maximbaz!

Perhaps also support comments in the conf file by replacing $(cat FILE) with $(cat FILE | sed 's/#.*//'), it can be useful.

Beautiful work @mixedCase, thanks a lot! You have a typo in BRAVE_USER_FLAGS_FILE, you use USER_FLAGS_FILE variable instead when trying to actually read the file. Otherwise works great!

Hey guys, just pushed an update to solve some of Brave's annoyances, thanks to all the users who reported them and sorry for taking so long.

navarroaxel: Didn't have that so I just added it. It will look in $XDG_CONFIG_DATA/brave-flags.conf (or ~/.config/brave-flags.conf) for your custom flags.

Smit_17: From what I can tell it helped the old Brave codebase (Muon) locate Pepper Flash. Now that's gone and replaced with a new hack for enabling it manually when the pepper-flash package is installed.

maximbaz: Thanks for the tip, added it as well.

And finally, please let me know if this broke anything since there are a few ugly changes.

FYI if you are struggling with making xdg-open use Brave as default browser, the workaround is to update /usr/bin/brave to always return 0 exit code - I updated it like the following:

#!/usr/bin/env bash

if [[ ! (-r /proc/sys/kernel/unprivileged_userns_clone && $(< /proc/sys/kernel/unprivileged_userns_clone) == 1 && -n $(zcat /proc/config.gz | grep CONFIG_USER_NS=y) ) ]]; then
    >&2 echo "User namespaces are not detected as enabled on your system, brave will run with the sandbox disabled"
    FLAG="--no-sandbox"
fi

/usr/lib/brave-bin/brave "$@" "$FLAG" || true

@aramirez, the ArchWiki says that the base-devel package group is required to install packages from AUR: https://wiki.archlinux.org/index.php/Arch_User_Repository#Getting_started. So is not required add those packages on makedepends.

Hi. I believe this package requires 'fakeroot' and 'm4' in order to build. They should be added to the makedepends.

Whats the point of line

ln -s /usr/lib/PepperFlash "$pkgdir/usr/lib/pepperflashplugin-nonfree" ??

Its creating false symlink as /usr/lib/pepperflashplugin-nonfree doesn't exists. It also prevents one from installing brave-bin and brave-dev-bin at the same time

@navarroaxel If that flag doesn't work (I've never used it so can't say) (I don't see why you couldn't try, just in your .desktop or from terminal even), you do realise there is an option built directly into Brave's Browser Settings which lets you set it to Dark mode? It's way easier than messing around with flags :)

How I can add this flags automatically when I open brave? --enable-features=WebUIDarkMode --force-dark-mode

In the google-chrome AUR package I can edit the ~/.config/chrome-flags.conf to force the dark mode

@digitalone Thanks for the heads up, just uploaded the PKGBUILD without the .deb code.

As for Widevine support, Brave manages its own version and thus doesn't need the chromium-widevine package to work.

Generic Linux zip package has now resources folder included, so we can skip deb package downloading.

Besides, I made a new PKGBUILD with optional chromium-widevine support. Note that you don't have to install chromium to get chromium-widevine.

Installed and tested with a streaming service I use in my country: playback works smoothly (obviously you have to disable brave shield for that specific page). Should also work for Netflix, Amazon Prime and other streaming services.

I think it's because those files were copied manually before and pacman detects a conflict.

The last build failed for me because it didn't remove the old locale files at: /usr/lib/brave-bin/resources/brave_rewards/_locales/ and /usr/lib/brave-bin/resources/brave_extension/_locales/

run sudo rm -rf for each of them.

Thanks. Anyway, deb package uses Ubuntu directory schema that seems a little bit different from Arch's one. Brave primary folder is in /opt/brave.com/brave rather than /usr/lib/brave-bin. I don't know if this can cause any issue on Arch.

Hey guys, sorry I didn't respond earlier just saw the comments today and re-enabled notifications. So:

afontenot: Removed gconf from depends and moved libgnome-keyring to optional dependencies.

digitalone: Thanks for the reminder on pkgrel, I made the change on a machine without my usual pre-commit hook and didn't notice. Regarding the extension bug, I was looking into avoiding a second download of the browser just because of an upstream packaging issue; but since a lot of people use Brave solely for the crypto stuff I'll just merge those changes until I have more time to look into using the deb alone. Thank you for the patchset, just merged.

When you modify the PKGBUILD, you should also increase pkgrel number otherwise users that already installed the package won't get any change.

And, please, merge my modification reported here to include resources directory from deb release so Brave Shield issue can be fixed until developers will make a fully working linux zip package.

This PKGBUILD modified by me fixes Brave Shield issue. Please update.

Following up: I've been running an edited version of this PKGBUILD with libgnome-keyring and gconf removed from depends for a while with no problems under KDE. As I said in a previous comment, they're not required by the Debian brave package. Can you move them to optdepends please?

@vith If you're referring to the Brave Shield and Brave Rewards, use the fix Cpt_Pi brought up in a prior comment that states,

"The no text in Shield and missing translation in Rewards are due to how Brave have been packaging the .tar.gz.

To fix the "No text in Shield and no translation in Rewards" - you have to download the .deb and extract the Resources directory into /usr/lib/brave-bin"

There seems to be some problem with some (localized?) strings in Brave's customizations. Their added icons in the right side of the address bar have missing and/or placeholder text in their popups.

@mixedCase: Several issues / questions.

1. Can you add yourself as the maintainer to the PKGBUILD? Currently now-im is listed as the maintainer.

2. I haven't flagged it, since you say you have a script, but is this not a more recent release from 8 days ago? https://github.com/brave/brave-browser/releases/tag/v0.61.52 (I'll flag to get your attention if you don't respond within a day or two.)

3. Can you please check to see whether moving libgnome-keyring and gconf to optdepends (or removing them entirely) is possible. The official debian package of the most recent release does not have these listed as dependencies. In particular removing the latter would eliminate the dependency on Python 2, which I do not have installed.

Thanks!

=== PLEASE READ PLEASE READ BEFORE REPORTING OUT OF DATE ===

Before making your report, please note that the newer GitHub release you're looking at belongs to the "Release Channel" and --isn't marked as prerelease--.

I have a cron running that's checking every 30 minutes if there's a new release and sends me an email if so. If you see the release was tagged in the last couple of hours please give it some time before flagging.

Also please take into account a stable version may be "released" on GitHub but not marked as ready (read, NOT PRELEASE) for a long time.

Another handy tool to check latest OFFICIALLY MARKED AS STABLE version of Brave is to run:

curl https://brave-browser-downloads.s3.brave.com/latest/release.version

@miomio, this is fixed with PR-3446 which should be in a release soon.

@miomio No, one should have too. Unfortunately, that's the reality of not having an official Arch build and having to rely on a user repository to use a preferred piece of software.

If the Brave team could include the resource directory in the official zip file, then it's my understanding that you wouldn't have to go through this extra step. The best thing to do would be to let Brave developers know of this problem so it can be included in future releases.

@neontiger26 - should anybody really be having to do this.

@miomio I downloaded it from Brave's GitHub account.

https://github.com/brave/brave-browser/releases

@Cpt_Pi / @neontiger26 - where is the deb package?

Just wanted to confirm that the latest update by mixedCase installed properly.

I also wanted to confirm that the fix Cpt_Pi mentioned to get text in the Brave shield works.

Hi now-im, if you're having trouble fixing the build I'm willing to take maintainership of this package since I depend on it. Thanks.

The PKGBUILD file doesn't work in its current incarnation:

==> Removing existing $srcdir/ directory...
==> Extracting sources...
==> Starting prepare()...
chmod: cannot access 'brave/brave': No such file or directory
==> ERROR: A failure occurred in prepare().
    Aborting...
Error making: brave-bin

I'm getting this error when trying to install the latest update

chmod: cannot access 'brave/brave': No such file or directory ==> ERROR: A failure occurred in prepare(). Aborting...

@miomio - these are issues with Brave.
The no text in Shield and missing translation in Rewards are due to how Brave have been packaging the .tar.gz.
The widevine support is due to Brave currently not supporting Widevine on Linux.

To fix the "No text in Shield and no translation in Rewards" - you have to download the .deb and extract the Resources directory into /usr/lib/brave-bin

The issues I commented about on the 4th are still present: text in the shield missing, and no widevine.

https://community.brave.com/t/brave-shield-ui-bug/33570/63 https://github.com/brave/brave-browser/issues/413

UI bug as described here: https://community.brave.com/t/brave-shield-ui-bug/33570/63 & https://github.com/brave/brave-browser/issues/3104 .

Widevine support issue: https://github.com/brave/brave-browser/issues/413

Anyone else having issues with Brave refusing to load web pages, while all other browsers and web services work fine?

@Martian According to a Brave employee, this will be fixed soon.

https://community.brave.com/t/brave-shield-ui-bug/33570/64

Please have a look at this in regards to the UI bug: https://community.brave.com/t/brave-shield-ui-bug/33570/62

The bug itself : https://github.com/brave/brave-browser/issues/1150

Note that sh might not be bash. I use dash, and so brave.sh will not work. You could just change the shebang to #!/usr/bin/env bash.

gnome-keyring is required for the password saving feature to work.

I also noticed password generation is not working. Is there a package that's needed to bring that feature over from Chrome to Chromium based browsers?

It shows that it is not set to the default browser, even when it actually is. https://www.just4dummies.com/gmail-sign-up

To fix default browser under chrome and to avoid showing the icon two times in the gnome dock, you can create a file ~/.local/share/applications/brave-browser.desktop with the following content:

(the most important line here is the StartupWMClass=brave-browser pointing to the correct window manager class name)

[Desktop Entry]
Version=1.0
Name=Brave Browser
# Only KDE 4 seems to use GenericName, so we reuse the KDE strings.
# From Ubuntu's language-pack-kde-XX-base packages, version 9.04-20090413.
GenericName=Web Browser
GenericName[de]=Web-Browser
# Not translated in KDE, from Epiphany 2.26.1-0ubuntu1.
# Gnome and KDE 3 uses Comment.
Comment=Access the Internet
Comment[de]=Internetzugriff
Exec=/usr/bin/brave %U
StartupNotify=true
StartupWMClass=brave-browser
Terminal=false
Icon=brave
Type=Application
Categories=Network;WebBrowser;
Actions=new-window;new-private-window;
Name[de_DE]=Brave Browser

[Desktop Action new-window]
Name=New Window
Name[de]=Neues Fenster
Exec=/usr/bin/brave

[Desktop Action new-private-window]
Name=New Incognito Window
Name[de]=Neues Inkognito-Fenster
Exec=/usr/bin/brave --incognito
MimeType=x-scheme-handler/unknown;x-scheme-handler/about;text/html;text/xml;application/xhtml_xml;image/webp;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/ftp;

And as suggested by @whezzel update ~/.config/mimeapps.list to use brave-browser.desktop for all browser related entries.

@dencrypt Regarding brave shield settings: https://github.com/brave/brave-browser/issues/1150

As @asynec I also have the problem with browser always telling me to set default browser. Tried the Suggestions from @whezzel but no avail unfortunately.

<s>Also the Brave Shield settings (in the address bar) has a UI that lacks any icons or text. It's just the sliders and the name of the page. Hard to set anything when I don't know what it is :) However great work anyway. These are just small complaints tbh and it works otherwise fine!</s>
This is an upstream bug.

I use Cinnamon DE and had similar issues. I was able to fix it by editing ~/.config/mimeapps.list and changing all occurrences of chromium.desktop (my previous browser) to brave-bin.desktop, and deleting all the BraveBrowser data stored in ~/.cache and ~/.config.

I'm not sure why, but brave bugged me, for several days, about setting it to default, but a friend of mine said he only clicked 'Set as Default' once and it stopped asking him.

Any idea why this package always complains that it is not set to the default browser, even when it actually is? Using Gnome, fwiw.

@simonorono Awesome. Thanks for such a quick fix

I just solved that issue on version 0.56.15 @whezzel

I understand the reason for the brave-bin.sh script, is to notify the user that the browser is not running in a sandbox which can be insecure. I have applied the fix listed in the 'pinned' comment so that my browser runs in a sandbox.

My question is, would it be possible to modify brave-bin.sh to pass additional flags to /usr/lib/brave-bin/brave?

For example:

brave --incognito     # opens a new brave window with a url of --incognito

/usr/lib/brave-bin/brave --incognito     # opens a new window in incognito mode.

Unfortunately, I'm not that great with scripting yet, otherwise I would try to make this modification on my own.

@Vrakfall the main Brave executable gets installed at /usr/lib/brave-bin/brave and will not run unless:

1) it finds a way of sandboxing the processes or 2) it's run with the --no-sandbox flag (very insecure)

The brave-bin.sh checks if you have user namespaces enabled; if not then it will run Brave with the --no-sandbox flag.

This is a known issue: https://github.com/brave/browser-laptop/issues/9955

If you try to run the main Brave executable with no flags you get this:

[23868:23868:1117/153840.810367:FATAL:zygote_host_impl_linux.cc(116)] No usable sandbox! Update your kernel or see <https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md> for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.
Trace/breakpoint trap (core dumped)

I can't find which command this flag is from. What is it linked to? I find it weird you advice using a kernel feature that weakens it.

Looks like there is an error in the desktop file... in Gnome, the desktop file opens a duplicate icon in the dock when added to favorites.

To disable the message telling "that you're using an unsupported command-line flag --no-sandbox" you must enable user namespaces with sysctl:

sudo sysctl kernel.unprivileged_userns_clone=1

To make it persist after reboot:

echo kernel.unprivileged_userns_clone = 1 | sudo tee /etc/sysctl.d/00-local-userns.conf

Sorry I've been traveling and out of date on upstream changes. I'll take a look at this over the coming week.

If anybody can confirm @mariow's comments below and that Gist building I might expedite putting that in here.

This PKGBUILD works to update brave-bin to the currently latest 0.56.12 for me: https://gist.github.com/mariow/b295c2f0c6dc9f274cdf324873a1d712 For full disclosure: that version either isn't as stable as one would like or there are open issues with dependencies, some UI elements look a bit unfinished.

@veox The old Muon-based Brave browser in the browser-laptop repo that this package sources is no longer considered the mainline Brave browser product and I don't think it qualifies for the 'stable' label. They've created a new Chromium-based browser, available at the brave-browser repo. See https://brave.com/new-brave-browser-release-available-for-general-download/ for more info.

Indeed:

The Muon-based Brave browser is no longer available for download on our site, but users who currently browse with it (latest version is 0.25.2) will continue to receive necessary updates until they are fully upgraded to this new release in the near future.

Merely bumping pkgver to 0.25.2 (as well as updating the hash-sums) should be enough for those still wishing to use the "stable" channel.

No need to switch to the beta repo.

Thanks for the tip, ronaldscott!

https://aur.archlinux.org/packages/brave-beta-bin/ is already updated to point at the brave-browser repo. I got the latest version by using that PKGBUILD and bumping the pkgver to 0.55.20.

That PKGBUILD could easily be adapted to work for this package.

As mentioned by others, this needs to be updated to the brave-browser repo. However, looking at it, the install is completely different, so it's a good amount of work...

Can we please get an update to the new source, per tuckerboniface ? This package has been out of date for a long time.

Please use the new location https://github.com/brave/brave-browser

@Kabir Please ask that on a Brave related forum, or check the issue tracker. This is only the comment section for the AUR package, and we just wrap up what the upstream project produces in a way that can be easily installed on Archlinux. Your question is about the upstream project, not this package.

Has the feature to edit browser / website fonts and themes been implemented yet? Thanks!

@caleb Awesome, great work. Wish I'd added you weeks ago, sorry again!

(1/2) Arming ConditionNeedsUpdate... (2/2) Updating the desktop file MIME type cache... fatal: repository 'https://raw.githubusercontent.com/brave/browser-laptop/master/LICENSE.txt/' not found

Thanks @mischka. I'll work on these two first and then maybe approach the -git package owner about normalizing these three again.

I did a whole bunch of cleanup to the packaging, mostly to closer match current AUR packaging guidelines, but also to simply the scripting, make it easier to track changes to the files being injected by this package separate from the PKGBUILD, and generally clean things up. You might have a look at the git log to see what I did. Notably only the change to the wrapper script (moving the warning message from build()) bumped the pkgver, everything else in the installed should end up being identical, it just gets there in a safer way.

@caleb Great thanks! Except I forgot that I already orphaned the -git one a while ago for similar reasons so I can no longer add you to that one, ha. Thanks again!

@mischka Sure you can add me on those too.

Oh great apologies, I really wish I saw your offer to be co-maintainer earlier. I'd been on vacation and sort of unplugged for a while, apologies, and I don't use Brave myself any longer so I don't really prioritize updates. Sorry about that.

Thanks for offering, I've added you as a co-maintainer! Would you be willing to do the same for the other two brave packages?

Can we maybe get some co-maintainers on this package? The upstream project moves very fast and releases frequently and it seems there is frequently a week or two lag in this package. With very little changing between most releases, maybe with a few more people with push access we can keep it more up to date.

Edit: 2018-08-13 — I'm willing to help update as a co-maintainer if you add me.

Please do me a favour and do not ever use Brave.

It is a browser specifically designed to allow fingerprinting for advertisers and I am not even kidding. Go compare how much entropy stock Brave provides compared to stock Firefox.

Nothing destructive about it. It's a wiki, after all. Duh. Stop whining about the inevitable and update the build more often.

This build has a backdoor, I believe.

Git gave me some weird errors when I committed this last time, it seems to have gone through alright but if anyone experiences issues please post a comment.

Permissions for this packages are now 700. Which means you cannot run the browser if you're not root. Am I missing something here?

This is not the place to advertise destructive alt-right websites.

Thanks for the tip, Xeno_Idaltu. I'll make sure to install the latest version of this browser now. Great search engine, an unbiased, censorship-free, untrolled equivalent of Wikipedia!

It came with "infogalactic" as a preinstalled search engine.

If this Alt-Right idiocy keeps going on people in the year 2100 will actually believe dinosaurs lived along Jesus and that White Supremacists were riding Sauropods to work.

AlternativeFacts