Submit Linux package updates in official distro repos
Proton VPN is open source and uses well-known and established components of the NetworkManager stack. Due to these two things, there is virtually nothing standing in the way of the Proton VPN team from building and submitting packages officially to Linux distributions like Fedora, Debian, Ubuntu, EPEL, etc. Proton VPN is further enhanced by packaging upstream by increasing the availability of Proton VPN software packages in the global software package mirroring network (deterring censorship) and benefiting from improved transparency and openness by building packages through distribution-supported build systems, which are often reproducible.
The policies of most distros are friendly to this since the Proton VPN Linux pieces use Open Source licenses. A community-supported Fedora Proton packaging SIG already exists.
Implementing this is both a matter of technical expertise but also being able to navigate and collaborate with other communities. Proton engineers would submit package updates directly to Linux build systems and benefit from being stakeholders in the distribution end of software production. This also gets Proton engineers closer to user feedback and bug reports.
(Not to be biased, but I get copied on bug reports for Proton VPN bugs in Fedora and I am not always sure how to best route that feedback from distro users back to upstream developers.)
One idea for the Proton-hosted repos is that they could still be provided, but for beta or experimental users. This way, Proton still maintains a mechanism for shipping updates extremely fast to end users without distro build systems and update policies, but the users who participate with those repos could be closer to the in-development versions, while users subscribed to updates on their favorite distros would receive them normally through stable update repos.
JWF
shared this idea
-
EldrinSMP
commented
Arch is a major distribution with many others based on it. There's no reason it shouldn't be supported officially, either through direct distribution from Proton or providing an official PKGBUILD for it to be built by users. The current AUR client is unreliable at best.
-
Efertone
commented
I would be happy if they can simply provide a PKGBUILD file for each of the application available on Linux. Back when Bridge Beta came out, I liked the idea of getting the PKGBUILD file from a trusted source (their website), build it and done. Sadly newer services get less love, like Mail rpm and deb only.
-
Anonymous
commented
Flatpak sandboxing is critical to a secure future of Linux, as well as the cornerstone of various immutable distros.
I hope Proton reconsiders and starts supporting Flatpaks, proposing portals where needed.
-
Anonymous
commented
There was a relevant Reddit discussion on this, which I'm reposting here:
---
HatBoxUnworn:
Will this eventually be distributed as a flatpak?
Adding your remote has been a terrible experience. After I updated to Fedora 38, your remote broke updates for my system for weeks before I was able to track down the problem.
---
Proton team member:
Hey u/HatBoxUnworn, there are no plans for now. One of the downsides of this is how flatpaks works. The nature of flatpaks is to run in a sand-box mode, thus if we need escalated privileges say for a Kill Switch implementation that manipulates the firewall via nftables, we won't be able to do that because Flatpak don't allow privilege escalation, due to it's nature.
As a side-note, there was an unofficial package uploaded by a user, and that one is working mainly because currently our app uses NM, which does not require escalated privileges since all we do is communicate with NM.
---
enjoyingfoss:
Wouldn't the best approach here be to work within the confines of the sandbox (as the unofficial Flatpak does now), and if extra functionality is needed and not implemented via portals yet, to propose those portals via the official Flatpak channels?
That would:
1. make ProtonVPN much easier to use on immutable distros (e.g. Steam OS)
2. support better security models on Linux
3. fill in gaps in Flatpak portals where there are needs for it
4. allow you to push timely updates across all Linux distros
5. make testing and distribution on all Linux distros much easier in the long run
---
Unfortunately, no official reply to that last message. :(
-
XxTriviumxX
commented
how does one convince a trusted user to maintain protonvpn? LOL
-
Bink
commented
Whilst this would be nice, it isn't really up to Proton.
To go from AUR to Community requires an Arch "Trusted User" to take ownership of the package.
To go from Community to Extra, requires Arch developers (who are separate from Trusted Users) to take ownership of the package.
https://wiki.archlinux.org/title/Community_repository#Historical_background
-
XxTriviumxX
commented
Why is there not an official arch linux package at this point? I think it would be awesome to just enter "sudo pacman -S protonvpn" in order to install it.
It's not like arch linux is an lesser known operating system.
-
rakesh
commented
I think this is a good idea. I have about 10% Appimage and Flatpak apps in my system. Sometimes it can be very useful. The Appimage is the best package format for me. But I also like Flatpak.
-
[Deleted User]
commented
I would recommend making Flatpak the main supported Linux app, even over .debs and .rpms, since it works on all Linux distros, autoupdates, and is easy to maintain and install.
-
gkn
commented
How about a snapcraft.io package for multi-dist support?
-
Darth Nagar
commented
AppImage is absolutlya a must have for Linux distros, and that as to support sandboxing as well (using Firejail).
-
Incola
commented
Especially the AppImage is easy to use, takes less space, and deployable on many distros.
Tutanota is already offering it. It would be great, if you could offer your client as AppImage.
ALSO: with AppImage you are in the full control of the distribution as opposed to Flatpak and its hub. -
Orfeas Agis Karachalios
commented
These days it is very common to package applications across linux distros into flatpaks or appimages. These would be easy to manage for the ProtonVPN team and provide us with a working GUI app instead of the hard to manage cli client.