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.

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