- name: proton-vpn
- description: Proton VPN Client
- snapcraft: GitHub - kenvandine/proton-vpn-snap: A community-maintained package to easily install ProtonVPN on Linux · GitHub
- upstream: GitHub - ProtonVPN/proton-vpn-gtk-app: Official ProtonVPN Linux app · GitHub
- upstream-relation: contributor
- interfaces:
- log-observe:
- request-type: auto-connection
- reasoning: Needed for the integrated bug reporting tool to submit logs.
- login-session-observe:
- request-type: auto-connection
- reasoning: To check for session unlocking.
- network-control:
- request-type: auto-connection
- reasoning: For checking network connectivity and route information.
- network-manager:
- request-type: auto-connection
- reasoning: To use the network manager dbus service to create VPN connections.
- password-manager-service:
- request-type: auto-connection
- reasoning: To integrate with the system keyring
- u2f-devices:
- request-type: auto-connection
- reasoning: To access u2f devices for login
- log-observe:
This request has been added to the queue for review by the @reviewers team.
@reviewers can someone please help with this?
@policy-reviewers can someone please help with this?
This looks reasonable and Ken is a trusted member of the ecosystem. +1
Hey folks!
Sorry for the delay in my response.
I think granting auto-connection to log-observe, network-control, network-manager and u2f-devices is expected and reasonable.
For login-session-observe, could you please provide more context about why checking for session unlocking is needed?
I don’t think we should grant auto-connection password-manager-service. We only grant this auto-connection on really few exceptional cases. Is there any reason why proton-vpn needs access to all secrets stored in the system keyring? Otherwise, it should use the secret-portal instead.
Responses from the ProtonVPN team:
- we need login-session-observe because some vpn protocols (openvpn) get disconnected when the user suspends the laptop. We hook to session login to connect to the vpn again at that point if required.
- we need password-manager-service because we store our api token and other sensitive info in the keyring, in the standard way (via the secret service session bus)
Hey, sorry for the delay
login-session-observesounds reasonable to mepassword-manager-serviceI still think we should not grant auto-connection to it. We (almost) never grant auto-connection to this interface as it exposes all the secrets stored in the keyring. This is the case even for well-known snaps maintained by Canonical (see Chromium for example). The right approach here is using the Secret-portal for secure storage, which might be easier or harder depending on the programming language/framework used. If you could provide some details maybe I can give some guidance here
I think this is reasonable it makes sense so yeah +1 from me (#voteFor)
Hello @kenvandine!
Considering what @jslarraz explained above, this is also a +1 (#voteFor) for auto-connecting login-session-observe, log-observe, network-control, network-manager and u2f-devices, from my side.
Hello all!
Adding my +1(#voteFor) here as well for granting auto-connection of the login-session-observe, log-observe, network-control, network-manager, and u2f-devices to hopefully unblock some functionality. I agree with the above reviewers that these are expected and reasonable.
Voting period has ended. This request is approved with 2 votes for and 0 votes against.
+3 votes for, 0 votes against, granting auto-connect of only the interfaces login-session-observe, log-observe, network-control, network-manager, and u2f-devices to snap proton-vpn. This subset of the request is now live.