Package Details: brave-bin 1:1.78.97-1

Git Clone URL: https://aur.archlinux.org/brave-bin.git (read-only, click to copy)
Package Base: brave-bin
Description: Web browser that blocks ads and trackers by default (binary release)
Upstream URL: https://brave.com
Keywords: brave browser
Licenses: BSD, MPL2, custom:chromium
Conflicts: brave
Provides: brave, brave-browser
Submitter: toropisco
Maintainer: brave
Last Packager: brave
Votes: 875
Popularity: 17.75
First Submitted: 2016-04-06 13:16 (UTC)
Last Updated: 2025-05-07 17:04 (UTC)

Dependencies (8)

Required by (9)

Sources (4)

Pinned Comments

brave commented on 2025-04-25 13:00 (UTC)

Latest Comments

« First ‹ Previous 1 .. 32 33 34 35 36 37 38 39 40 41 42 .. 61 Next › Last »

mixedCase commented on 2020-11-18 17:42 (UTC)

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

kiankasad commented on 2020-11-18 17:35 (UTC)

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?

mixedCase commented on 2020-11-18 14:43 (UTC)

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

eronis55 commented on 2020-11-18 13:17 (UTC)

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

mixedCase commented on 2020-10-13 00:03 (UTC)

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

kiankasad commented on 2020-10-12 23:51 (UTC)

@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

mixedCase commented on 2020-10-12 23:46 (UTC)

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

kiankasad commented on 2020-10-12 22:24 (UTC) (edited on 2021-01-18 20:03 (UTC) by kiankasad)

@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

mixedCase commented on 2020-10-12 22:21 (UTC)

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

kiankasad commented on 2020-10-12 21:30 (UTC) (edited on 2021-01-18 20:04 (UTC) by kiankasad)

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

« First ‹ Previous 1 .. 32 33 34 35 36 37 38 39 40 41 42 .. 61 Next › Last »