Package Details: mullvad-vpn-beta 2021.4.beta1-3

Git Clone URL: https://aur.archlinux.org/mullvad-vpn-beta.git (read-only, click to copy)
Package Base: mullvad-vpn-beta
Description: The Mullvad VPN client app for desktop (beta channel)
Upstream URL: https://www.mullvad.net
Licenses: GPL3
Conflicts: mullvad-vpn
Provides: mullvad-vpn
Submitter: None
Maintainer: yochananmarqos
Last Packager: yochananmarqos
Votes: 8
Popularity: 2.57
First Submitted: 2019-08-09 21:46
Last Updated: 2021-06-13 16:50

Pinned Comments

yochananmarqos commented on 2019-12-07 17:44

--> ALWAYS DO A CLEAN BUILD <--

This package will verify the signature of the git tag. Developer keys are available here and instructions are here. See the PKGBUILD to determine which developer key you need.

Latest Comments

1 2 3 4 Next › Last »

kubrick commented on 2021-06-17 13:27

@sdht0: I'm not a polkit expert, therefore what I would do, following your philosophy of having more discretionary groups, I would create a mullvad group, add your user to it, and allow the socket to be controlled by users in this group by editing the service file. Maybe there is a polkit way, but it looks very involved.

sdht0 commented on 2021-06-14 10:05

@kubrick: I see what you mean. My setup uses the first option, which I only have to unlock once at login.

So how can I configure mullvad-gui to use the same, so that it can connect to the daemon properly?

kubrick commented on 2021-06-14 07:03

@sdht0, which of these options are you using to control NM from your user session?

yochananmarqos commented on 2021-06-13 19:21

@Rangvar: lto is not enabled by default.

Ranguvar commented on 2021-06-13 19:20

Build fails with LTO enabled Adding options=('!lto') works fine

sdht0 commented on 2021-06-13 17:49

then they are not going to be able to control anything network related by default on arch

I am able to control my network just fine on Plasma+NetworkManager without my user being in the wheel group.

kubrick commented on 2021-06-13 17:46

Yes, of course it is always going to cause some issues to restrict control of the mullvad daemon to the wheel group, and it is a matter of opinion.

But if a user is created without being part of the wheel group, then they are not going to be able to control anything network related by default on arch, so why would they be allowed to control the VPN?

So on the one hand not setting this new option make the default set-up not safe, on the other hand restricting it to the wheel group is going to annoy a few people who have set up their systems in a way that their users can't control the network without elevating their privileges.

Of course I don't know how widespread this is but this seems wrong to me anyway to expect users not to be able to control the network and be able to control VPNs at the same time...

sdht0 commented on 2021-06-13 17:29

Ah cool, thanks.

yochananmarqos commented on 2021-06-13 16:47

@sdht0: Hmm, you make a good point. I'll revert the change here in few minutes.

Those who want to restrict access to the management socket can set MULLVAD_MANAGEMENT_SOCKET_GROUP=wheel as an environment variable instead.

sdht0 commented on 2021-06-13 16:12

Right, which brings me back to the question: is the only way of fixing this is to add my user to the wheel group? That feels like kinda beating the purpose and gives any process running as my user even greater privileges than now.

I'll have to check if I can run only the GUI in the wheel group.