Package Details: brave-bin 1:1.25.73-2

Git Clone URL: (read-only, click to copy)
Package Base: brave-bin
Description: Web browser that blocks ads and trackers by default (binary release).
Upstream URL:
Keywords: brave browser
Licenses: BSD, MPL2, custom:chromium
Conflicts: brave
Provides: brave, brave-browser
Submitter: vorbote
Maintainer: mixedCase
Last Packager: mixedCase
Votes: 412
Popularity: 28.76
First Submitted: 2016-04-06 13:16
Last Updated: 2021-06-17 14:45

Dependencies (8)

Required by (2)

Sources (4)

Pinned Comments

mixedCase commented on 2019-03-11 13:52


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:


Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 ... Next › Last »

mixedCase commented on 2021-01-20 05:14

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

gameslayer commented on 2021-01-20 03:33

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

mixedCase commented on 2021-01-03 15:43

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

maxpayne3 commented on 2021-01-03 09:39

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

mixedCase commented on 2021-01-01 21:29

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

maxpayne3 commented on 2021-01-01 10:58

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

This will fix this issue. Thanks.

Netboy3 commented on 2020-12-03 14:50

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

mixedCase commented on 2020-12-02 23:32

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

Netboy3 commented on 2020-12-02 22:52

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

mixedCase commented on 2020-11-24 22:42

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