Is this repo still being maintained?

[ElmoTheWizard]

The last commit was 3 months ago, while the windows app was updated 13 days ago.

[Anonymous941]

@calexandru2018 Where's the GitHub repo for the new client?

[kazin-kharizma]

@calexandru2018 Where's the GitHub repo for the new client?

I do not believe it is readily available since it is in pre-alpha stage at this time. There is a note about this above: It means that a limited amount of people outside of Proton will be invited to test the application and provide feedback, and yes at this point it will be "closed-source" (the code won't be hosted anywhere for now), although worth pointing out that since it's Python one can easily inspect the code, thus it will never be completely closed source as windows applications.

[calexandru2018]

@calexandru2018 Where's the GitHub repo for the new client?

See what I wrote here: https://github.com/ProtonVPN/linux-cli/issues/64#issuecomment-1480897614

[kazin-kharizma]

@calexandru2018 Where's the GitHub repo for the new client?

See what I wrote here: #64 (comment)

HAHA! Beat ya to it by a few seconds. :P Sorry for answering and not letting you get to it first.

[Anonymous941]

So should I use this repo for the issues?

[seanms]

Although Fedora 37 isn't officially supported, the packages for Fedora 38 work on 37.

[alastortenebris]

I noticed the package has -gnome as part of its name. Does that mean there might be a QT version in the future for us KDE users?

[calexandru2018]

I noticed the package has -gnome as part of its name. Does that mean there might be a QT version in the future for us KDE users?

That's a bit of a tough question. Our idea is for at the least (a bit further down) support KWallet instead of forcing people to install the gnome keyring on a KDE based distro. Lastly, we have plans to support "native" installations that don't rely on gnome, kwallet nor network manager. But those are a bit long term goals, as we would like to provide as much support as possible within sane boundaries.

So should I use this repo for the issues?

Feel free to use the in-app bug report, we'll be very grateful.

[kazin-kharizma]

Hey @calexandru2018, I noticed in my repo a bunch of different updates just yesterday for Proton and I was curious whether or not the pre-release has been updated or something like that or if it is piping in the dependencies of the entire ProtonVPN set.

Here is the repository: deb [arch="all", signed-by=/usr/share/keyrings/protonvpn-beta-archive-keyring.gpg] https://repo.protonvpn.com/debian unstable main

The updates were: python3-proton-vpn-connection 0.6.4 up from 0.6.3, proton-vpn-gtk-app 4.0.0~a5 up from 4.0.0~a2, python3-proton-core 0.1.11 up from 0.1.10, python3-proton-vpn-api-core 0.10.3 up from 0.10.2

Just wanted to clarify that the repository will indeed send updates of the pre-release as for some reason I thought we would have to do this manually. Is there a tracker for changes you guys are making?

[calexandru2018]

Hey @kazin-essen, those updates are legit, I've recently shared an update about that (which also tackles the question of tracking new updates). Technically you can always read the changelog in each package.

Check out my post on Reddit: https://www.reddit.com/r/ProtonVPN/comments/13xlaey/new_features_on_linux_alpha_application/?utm_source=share&utm_medium=ios_app&utm_name=ioscss&utm_content=2&utm_term=1

[kazin-kharizma]

Seeing your post from 6 hours ago now.

It is hilarious how in tandem you and I seem to be. I checked for updates on this on the subreddit all this morning. It is now early evening here. It is good to see that you are on top of things and that I have to be just a little bit less "me" and let you get the details out. HAHA! I am glad that I didn't post on the subreddit first. ;)

[kazin-kharizma]

@calexandru2018 , I’m facing issues with the ProtonVPN pre-release on Linux following recent Ubuntu updates. Despite reinstalling the app after a system reboot, the GUI loads but displays nothing. I can’t use the feedback function either. The steps on https://protonvpn.com/support/linux-prerelease/ are not adequate enough to guide users toward any resolution following the Python updates you mention in your Reddit post. Have you received similar reports? I’ll gather logs as best I can to assist in troubleshooting.

While I figure the logs out, since I used Timeshift I am not sure how much remain, we need some sort of guidance on how to remove all components and how to use commands like before that turn off kill switches and kill the GUI via command line.

[calexandru2018]

@kazin-essen what is the ubuntu version ? Feel free to fill in this support form https://protonvpn.com/support-form and attach the log file found under ~/.cache/Proton/VPN/logs please

[Snaggly]

I've been first time using a VPN, that being ProtonVPN- so bear with me if I don't understand everything yet. From what I gather, the yet official "stable" client only really generates some profiles and applies them to the Desktop's NetworkManager. I could also do it manually by downloading a OpenVPN or Wireguard profile from my Account. I noticed that using the VPN that was takes a hefty impact on the overall connection speed. Also with the Chrome browser I can no longer access certain websites (mail.yahoo.com, reddit.com, speedtest.com,...) unless I open them from an Incognito Tab which I don't understand at all.

I also looked at more alternatives and found this other VPN client called "Qomui". I don't know how this one set's up the connection but the Desktop's NetworkManager is kept untouched. On KDE I dont see any new entries under the Network settings, nor does it really tell me that I've been secured by a VPN. Only I can see on "whatismyip.com" that my location has indeed changed. Also the above mentioned issues are also gone, I can access all the sites without problems and my speed is also much improved (see below results from speedtest.net).

ProtonVPN-Client/NetworkManager:

Qomui:

Now I was wondering if the new client that is being tested uses the same technique; unfortunately I couldn't get it to run on my current Arch+KDE desktop with the above PKGBUILD- I read an ImportError when I try to run the binary. I also wonder how come that the VPN connection from my Desktop or from the official client is performing so poorly? Or is it actually doing its job properly and Qomui is leaking?

EDIT: I investigated further and found my answers: [1]- Qomui was leaking. The reason I had better speeds and websites still loading was because somehow somewhy my system managed to set up connections outside the VPN tunnel. ...Probably I have to report this, to the devs, if not already done. [2]- The reason why I had connection issues with some websites was partly with with Protocol chosen. Using TCP I was able to open those problematic websites again and couldn't find more issues. This probably has something to do with my setup, but it shows the urgency to have those basic options in the GUI client as well. [3]- The newer beta client still relies on the NetworkManager which I don't think poses as a bad choice. But looking that this has been in development for a year with less options and a somewhat lacking skeleton implies to me as a consumer that the company doesn't seem to have any interest in properly supporting the app. (Which ngl makes Mullvad look more appealing I have to say)

[kazin-kharizma]

Hey @ElmoTheWizard

Yes, all repos are being maintained, although it should be noted that we are currently working a new and improved multi-platform client which will support Wireguard and should not be fully dependent on NetworkManager nor keyring backends (as currently we're tied to Gnome-keyring and KWallet). Thus it should allow even more distros to use our official client without having hard dependencies baked in.

Either way, we'll be releasing a couple new features for the current client in the coming weeks, stay tuned :)

PS: Please don't close this issue, as other might find this useful.

Hello @calexandru2018. Let me put this simply: I am displeased. The GUI issue with the alpha release was resolved, yes, 6 hours later, it was found to be an issue with the selfsame backends we were told were being worked out. Omitting the fact that the GUI not displaying would be resolved by an effective CLI, let’s talk about why I'm referencing your March 2022 post talk.

Once again, I find ProtonVPN's actions disappointing. A multi-platform client, independent of NetworkManager and keyring backends with Wireguard support, was committed to. Are we to assume ProtonVPN intends to drag this out or dishonour that commitment?

Exploring https://repo.protonvpn.com/debian/dists/unstable/main/binary-all/, it's clear we're still chained to the same dependencies, with no sign of WireGuard. I may be a novice in code development, but my early reports and bug bounty submission should testify to my commitment and attempt at understanding. Edit: That changelog shows that these were removed, though it seems a bit odd that they still update: ```

    proton-vpn-gtk-app (0.19.0) unstable; urgency=medium

  * Remove connection and keyring backend dependencies

 -- Alexandru Cheltuitor <alexandru.cheltuitor@proton.ch>  Wed, 08 Mar 2023 16:00:00 +0100

We've been told to test this pre-release while enduring an equally flawed official app and CLI. But let's face it, our patience isn't endless. ProtonVPN needs to uphold its commitments or face the potential repercussions.

The questions need answering: 1. What is the actual state of the Linux pre-release?

2. What is the roadmap, the concrete plans for the Linux pre-release? 3. How do you intend to uphold the statement made back in March 2022?
3. Is compensation in sight for customers in countries whose laws protect against disenfranchising business practices, given that we've tolerated a substandard product for nearly a year?

I've been your champion and your critic, ProtonVPN. But this cyclic pattern of disappointment is growing tedious. My folder of correspondence is becoming less organisation attempt and more a gathering of evidence for a forthcoming complaint. I think I speak for most Linux users when I say that we demand better.

[jacopom]

Hi @kazin-essen, I understand your concerns and frustrations. We are listening to every feedback provided here, and on other sources, this is guiding our roadmap towards the substitution of the current app with the pre-release you are testing. In the following period we'll bring some of our features and settings in a dedicated menù. This will make it possible to quickly change configurations without having to know the details of the config file. Also on the basis of your comment on reddit, we will introduce a changelog visible in app to communicate what is new and the direction of developments.

[kazin-kharizma]

Hi @kazin-essen, I understand your concerns and frustrations. We are listening to every feedback provided here, and on other sources, this is guiding our roadmap towards the substitution of the current app with the pre-release you are testing. In the following period we'll bring some of our features and settings in a dedicated menù. This will make it possible to quickly change configurations without having to know the details of the config file. Also on the basis of your comment on reddit, we will introduce a changelog visible in app to communicate what is new and the direction of developments.

Fantastic! What a great follow up and acknowledgement of my concerns. :) I don’t mind having to edit the config file at all ever really, I just like to know what to prepare for/what I’m working with. Though if I’m being honest, I’ve never been able to get the Port Forward NAT-PMP working and no matter how many times I delete the old config file it seems to generate the same one.

[Anonymous941]

@kazin-essen Recently, Proton added port forwarding to OpenVPN, and I've successfully gotten it to work without much trouble. While I still would prefer a working app, I finally got port forwarding working after struggling for years: you simply have to add +pmp (keep the + even if you have other suffixes) to your username. I'm not sure exactly when Proton added this feature, but it's a godsend for me and hopefully other Linux users that want to torrent over ProtonVPN.

See more details on their guide: https://protonvpn.com/support/port-forwarding-manual-setup/

[kazin-kharizma]

@kazin-essen Recently, Proton added port forwarding to OpenVPN, and I've successfully gotten it to work without much trouble. While I still would prefer a working app, I finally got port forwarding working after struggling for years: you simply have to add +pmp (keep the + even if you have other suffixes) to your username. I'm not sure exactly when Proton added this feature, but it's a godsend for me and hopefully other Linux users that want to torrent over ProtonVPN.

See more details on their guide: https://protonvpn.com/support/port-forwarding-manual-setup/

Would it be ok to reach out one on one for your experience?

[Anonymous941]

@kazin-essen Sure, give me a DM at @anynomous:matrix.org

[calexandru2018]

@Anonymous941 with the latest version alpha11 we've added a settings window to the app, which facilite now things a bit.

[kazin-kharizma]

@kazin-essen Sure, give me a DM at @anynomous:matrix.org

How the heck did you snag @anynomous:matrix.org?

[kazin-kharizma]

@Anonymous941 with the latest version alpha11 we've added a settings window to the app, which facilite now things a bit.

This is an amazing update team! Like really! If I may offer one suggestion. It would be GREAT if the content team could update the Port Forwarding site that the settings app links out to to account for the Pre-Release. While the steps remain largely the same what it does not tell us is whether or not we need to make the requisite edits to the config in the same way we did before and/or if there are changes to the config you set on your Reddit post.

[kazin-kharizma]

@Anonymous941 with the latest version alpha11 we've added a settings window to the app, which facilite now things a bit.

And it’s AWESOME!

[Snaggly]

I tried out the version from 11th July 2023 on Arch Linux. Seems to work just fine! I noticed that everytime I connect, a new "pvpn-killswitch-ipv6" profile is being added. The previous existing one will not be removed.

Also on ~/.cert/nm-openvpn it inflates the folder with new keyfiles everytime I connect. This behavior was also present on the current stable version.

[Zylquinal]

The previous existing one will not be removed.

Yep, me too and fixed it by doing this

Well from what i see the app hard coded the certificate, so what I'm thinking is 'why not put it into a file so all the connection could just refer to that file?'

Then i created a patch where the app will write the cert into a file located in .config/Proton/VPN folder, and a check function to compare the certificate whenever a new connection was made, and rewrite it if there's a difference or write if it doesn't exist.

More edit:

But your first problem doesn't happen to me, so i don't know what's wrong with it.

[kazin-kharizma]

Hi @kazin-essen, I understand your concerns and frustrations. We are listening to every feedback provided here, and on other sources, this is guiding our roadmap towards the substitution of the current app with the pre-release you are testing. In the following period we'll bring some of our features and settings in a dedicated menù. This will make it possible to quickly change configurations without having to know the details of the config file. Also on the basis of your comment on reddit, we will introduce a changelog visible in app to communicate what is new and the direction of developments.

proton-vpn-gtk-app (4.0.0~a13) unstable; urgency=medium

  * Add user-friendly release notes to app

 -- Alexandru Cheltuitor <alexandru.cheltuitor@proton.ch>  Mon, 17 Jul 2023 13:00:00 +0100

Thanks so much guys for really keeping in touch with the Linux community and responding to our needs. It makes such a huge difference and generates such good will. :)

[Anonymous941]

@calexandru2018 Thank you for all the updates, it's restored my faith in ProtonVPN and is going to be so helpful. I'm currently using an OpenVPN tunnel, and the only reason I'm not using this client is because of no kill switch. Is blocking all traffic not in tun0 enough for the client since it works in OpenVPN?

[kazin-kharizma]

@calexandru2018 Thank you for all the updates, it's restored my faith in ProtonVPN and is going to be so helpful. I'm currently using an OpenVPN tunnel, and the only reason I'm not using this client is because of no kill switch. Is blocking all traffic not in tun0 enough for the client since it works in OpenVPN?

The lack of a kill-switch is something that is holding me back as well on some uses of the client, well if I am being honest, IPv6 lacking forever has been a point of contention as well but I digress. @calexandru2018 what does the roadmap look like for kill-switch and dare I ask, IPv6?

[Tru3Mark]

Glad to see the recent developments for the new client. When can we expect wireguard support? Seems like it should be high on the priority list. Also where can we view the source code? The about page says it is licensed with the GPLv3 so according to my knowledge we need to have access to the source code right?

[kazin-kharizma]

Glad to see the recent developments for the new client. When can we expect wireguard support? Seems like it should be high on the priority list. Also where can we view the source code? The about page says it is licensed with the GPLv3 so according to my knowledge we need to have access to the source code right?

https://github.com/ProtonVPN/linux-cli/issues/64#issuecomment-1480897614 - per a post from @calexandru2018 way back when, the source code will be closed source for the time being.

https://github.com/ProtonVPN/linux-cli/issues/64#issuecomment-1356111793 - there is also a note here about having it open during its initial testing phase.

Of note thought is the licensed GPLv3 note on the about page. I am assuming that you mean the About on the new client which of course reads as:

This program comes with absolutely no warranty.
See the GNU General Public License, version 3 or later for details.

I am pleased with the attention to ProtonVPN team has made and I've begun to champion them once more but based on the nearly 1.5 year nightmare it took to get to this point, I intend to make sure they continue with transparency. I'll give @calexandru2018 and the ProtonVPN team about a week to respond on this matter and I will watch the changelog and code for changes that are not announced. I'm still surly over the Terms and Conditions change that happened. It was after I officially filed my case so it was hard to not see the change as a slight against customers who seek compensation for breach of Terms on Proton's end. Thankfully my case is valid and will proceed.

Keep an eye out on the client and know that you can file a compliant for breaching the GPLv3 license on their website at: https://www.gnu.org/licenses/gpl-violation.html but be sure to look for the things below first. As @calexandru2018 said, the python base for the project means that it is available but in consulting a friend and member of the Free Software Foundation, I was told:

Hey dude, so about the developer's statement that "since it's Python one can easily inspect the code, thus it will never be completely closed source as Windows applications" - it's a bit of a gray area when it comes to the GPL. Let me explain:

The GNU GPL requires that the source code is included in the distribution or there's a written offer for the source code with just binary distributions. Now, Python code isn't usually compiled into a binary format like Windows applications, so it's definitely more open and inspectable. However, that doesn't automatically make it compliant with GPL.

For full GPL compliance, the source code needs to be properly delivered to the users. This includes all modules, scripts, and related files needed to run the program, not just an opportunity to inspect it. If ProtonVPN isn't providing the full source code in a way that aligns with these stipulations, they might indeed be at odds with the GPL.

But this is a nuanced issue and could use a thorough legal review. My advice? Get in touch with James. He might suggest you to file an inquiry with us or another organization like the Software Freedom Conservancy.

So to me its kinda the old adage regarding privacy and personally identifiable information in things like GDPR, PIPEDA/CPPA, etc. which says that information when requested, has to be made available in a format that the average consumer can both access and understand, not just Python wizards on Linux. Ha-ha!

Violations of the GNU Licenses
If you think you see a violation of the GNU [GPL](https://www.gnu.org/licenses/gpl.html), [LGPL](https://www.gnu.org/licenses/lgpl.html), [AGPL](https://www.gnu.org/licenses/agpl.html), or [FDL](https://www.gnu.org/licenses/fdl.html), the first thing you should do is double-check the facts:

Does the distribution contain a copy of the License?
Does it clearly state which software is covered by the License? Does it say anything misleading, perhaps giving the impression that something is covered by the License when in fact it is not?
Is source code included in the distribution?
Is a written offer for source code included with a distribution of just binaries?
Is the available source code complete, or is it designed for linking in other nonfree modules?
If there seems to be a real violation, the next thing you need to do is record the details carefully:

the precise name of the product
the name of the person or organization distributing it
email addresses, postal addresses and phone numbers for how to contact the distributor(s)
the exact name of the package whose license is violated
how the license was violated:
Is the copyright notice of the copyright holder included?
Is the source code completely missing?
Is there a written offer for source that's incomplete in some way? This could happen if it provides a contact address or network URL that's somehow incorrect.
Is there a copy of the license included in the distribution?
Is some of the source available, but not all? If so, what parts are missing?
The more of these details that you have, the easier it is for the copyright holder to pursue the matter.

Once you have collected the details, you should send a precise report to the copyright holders of the packages that are being wrongly distributed. The GNU licenses are copyright licenses; free licenses in general are based on copyright. In most countries only the copyright holders are legally empowered to act against violations.

The Free Software Foundation acts on GPL violations reported on FSF-copyrighted code. Thus, if the program includes code that is copyright Free Software Foundation, please send your report to [<license-violation@gnu.org>](mailto:license-violation@gnu.org).

It's important that we be able to write back to you to get more information about the violation and the product. Thus, if you use an anonymous remailer, please provide a return path of some sort. If you'd like to encrypt your correspondence, just send a brief mail saying so, and we'll make appropriate arrangements. Because the FSF endorsed [the Principles of Community-Oriented GPL Enforcement](https://www.fsf.org/licensing/enforcement-principles), you can rest assured that your report will not lead to punishing anyone for an innocent mistake who is willing to correct it.

The FSF offers assistance and advice to any other copyright holder who wishes to enforce GNU licenses. But we cannot act on our own where we do not hold copyright. Thus, be sure to find out who are the copyright holders of the software, and report the violation to them.

Our colleagues at the Software Freedom Conservancy do GPL enforcement for many free programs, through their own copyrights and with coalitions of copyright holders in those programs. The programs include Linux, Git, Samba, QEMU, and others. If you encounter a GPL violation on those programs, we suggest you visit [the Conservancy's copyleft compliance page](https://sfconservancy.org/copyleft-compliance/) for the up-to-date list of programs it handles, and how to report violations.

This page is maintained by the Free Software Foundation's Licensing and Compliance Lab. You can support our efforts by [making a donation](http://donate.fsf.org/) to the FSF. Have a question not answered here? Check out some of our other [licensing resources](http://www.fsf.org/licensing) or contact the Compliance Lab at [licensing@fsf.org](mailto:licensing@fsf.org).

I have reached out to the ProtonVPN team and my case has been escalated for response to what I assume will be the legal and product teams. I will keep everyone updated.

This page is maintained by the Free Software Foundation's Licensing and Compliance Lab. You can support our eff
(12:12:28 PM) *** Aleksandar joined the chat ***
(12:12:37 PM) Aleksandar: Helo, thank you for contacting us!
(12:12:49 PM) Aleksandar: Please give me a moment to go through your report.
(12:13:57 PM) Aaron: Thanks. I am of the opinion that everything is in order but I believe it is key that users and developers like us keep ProtonVPN committed to transparency. With that in mind, I think a proof of compliance is in order.
(12:15:07 PM) Aleksandar: Thank you for your feedback Aaron.
(12:15:30 PM) Aaron: :)
(12:15:47 PM) Aleksandar: Please note that I would be unable to provide you with the appropriate response at this moment, regarding your inquiry.
(12:15:57 PM) Aaron: I figured as much.
(12:16:16 PM) Aleksandar: That being said, I will escalate your inquiry over to our responsible team, so that they could take a further look at it.
(12:16:20 PM) Aaron: This was practically begging for escalation due to its context. Legal team and such.
(12:16:37 PM) Aleksandar: Afterward, they will reach out to you with a proper response via your [******@**.**](mailto:******@**.**) email.
(12:16:46 PM) Aaron: I appreciate the swift and fast escalation my friend.
(12:16:52 PM) Aleksandar: Of course!
(12:17:03 PM) Aleksandar: It was my pleasure to assist you in this regard.
(12:17:18 PM) Aaron: Enjoy your day! That is all and you've been great. :)
(12:17:27 PM) Aleksandar: Thank you! You have a great day as well!
(12:17:30 PM) Aleksandar: Talk to you soon!
(12:17:41 PM) Aleksandar: If anything else is needed in the meantime, we remain available.

[Tru3Mark]

I did find the source code, but I do not see a copy of the license. It would be great for the code to be on a public repository though, so anyone can easier submit issues or possibly contribute. This is in the spirit of free software and I'm sure it can at least slightly speed up the development time, and I don't see how this would negatively effect business in any way. For a company that advertises the open source nature so much, just having the source code in your filesystem isn't good enough. I do give props to how much your small team has accomplished over this time period though. Consistency through different operating systems is still a big problem. I'm hoping the Linux team expands in general, especially including Drive. A native Linux app for Drive would be amazing. Once Wireguard support gets added to the new VPN app, I will probably subscribe to Proton Unlimited.

[kazin-kharizma]

I did find the source code, but I do not see a copy of the license. It would be great for the code to be on a public repository though, so anyone can easier submit issues or possibly contribute. This is in the spirit of free software and I'm sure it can at least slightly speed up the development time, and I don't see how this would negatively effect business in any way. For a company that advertises the open source nature so much, just having the source code in your filesystem isn't good enough. I do give props to how much your small team has accomplished over this time period though. Consistency through different operating systems is still a big problem. I'm hoping the Linux team expands in general, especially including Drive. A native Linux app for Drive would be amazing. Once Wireguard support gets added to the new VPN app, I will probably subscribe to Proton Unlimited.

From the Proton Team directly in Reddit. I am still waiting for the official word back from my escalated ticket.

Proton Team Admin
**Honestly, it's written in python, there is no compiled code, and the python code itself is self-contained and accessible, so it's for practical purposes already open source. It's also an alpha pre-release. That being said, yes, there will be a cleaned up github repo created for this post-release, as is customary for every Proton app.**

Rest assured if it is determined that there should be more transparency after the response from the legal and product team, I will submit the violation report myself to the bodies mentioned in my original post.

[Zylquinal]

@calexandru2018 Thank you for all the updates, it's restored my faith in ProtonVPN and is going to be so helpful. I'm currently using an OpenVPN tunnel, and the only reason I'm not using this client is because of no kill switch. Is blocking all traffic not in tun0 enough for the client since it works in OpenVPN?

The lack of a kill-switch is something that is holding me back as well on some uses of the client, well if I am being honest, IPv6 lacking forever has been a point of contention as well but I digress. @calexandru2018 what does the roadmap look like for kill-switch and dare I ask, IPv6?

This is also holding me back as well, and the fact that it sometimes pollute my NetworkManager connection when the app are getting closed forcefully annoys me. If you're interested on the KS tho maybe you could look at my work here by adding the Kill Switch.

[kazin-kharizma]

I have reached out to the ProtonVPN team and my case has been escalated for response to what I assume will be the legal and product teams. I will keep everyone updated.

No reply from either end of their team so I'll be filing my report tomorrow or Tuesday having reached out to them today. This is unfortunate as I believe transparency to be so important and I've been impressed with the team thus far.

I'd love if someone could take a look at it and ensure the letter I drafted honours the https://www.gnu.org/licenses/gpl-3.0.en.html and properly references the sections that are worrying. Given the way these violation reviews work, I have to reach out to the copyright holders of each component as well, so a second look would be a good idea. Essentially, it boils down to potential violations as such: GPL Section 6, GPL Section 1, GPL Section 3.

[jacopom]

Hi @kazin-kharizma, releasing the source code has always been a cornerstone of Proton’s approach and this Linux version is no different. In the last period we have all been busy putting the finishing touches to the project before the beta, which will take place in September. You can expect then to see the code on GitHub and our first release with kill switch 🙂

[Anonymous941]

No reply from either end of their team so I'll be filing my report tomorrow or Tuesday having reached out to them today. This is unfortunate as I believe transparency to be so important and I've been impressed with the team thus far.

I'd love if someone could take a look at it and ensure the letter I drafted honours the https://www.gnu.org/licenses/gpl-3.0.en.html and properly references the sections that are worrying. Given the way these violation reviews work, I have to reach out to the copyright holders of each component as well, so a second look would be a good idea. Essentially, it boils down to potential violations as such: GPL Section 6, GPL Section 1, GPL Section 3.

I'm confused as to why you're doing this - this is written in Python code so the source code is contained in the package. I don't believe Proton did any minifying or just gave us the .pyc.

But even if this does violate GPL (I don't know it very well so I'm not sure), what are you hoping to gain from this? They finally made a Linux version of their VPN, it's at least source-available (and I highly doubt they're going to track down and DMCA hypothetical forks, so it's basically GPL), and they're planning to repost (for a lack of a better word) it on GitHub soon.

...on a more light note, this issue (not necessarily with this comment, but earlier ones) might make a good github-drama candidate :)

[kazin-kharizma]

Hi @kazin-kharizma, releasing the source code has always been a cornerstone of Proton’s approach and this Linux version is no different. In the last period we have all been busy putting the finishing touches to the project before the beta, which will take place in September. You can expect then to see the code on GitHub and our first release with kill switch 🙂

This is all that I needed to hear. :)

[kazin-kharizma]

No reply from either end of their team so I'll be filing my report tomorrow or Tuesday having reached out to them today. This is unfortunate as I believe transparency to be so important and I've been impressed with the team thus far. I'd love if someone could take a look at it and ensure the letter I drafted honours the https://www.gnu.org/licenses/gpl-3.0.en.html and properly references the sections that are worrying. Given the way these violation reviews work, I have to reach out to the copyright holders of each component as well, so a second look would be a good idea. Essentially, it boils down to potential violations as such: GPL Section 6, GPL Section 1, GPL Section 3.

I'm confused as to why you're doing this - this is written in Python code so the source code is contained in the package. I don't believe Proton did any minifying or just gave us the .pyc.

But even if this does violate GPL (I don't know it very well so I'm not sure), what are you hoping to gain from this? They finally made a Linux version of their VPN, it's at least source-available (and I highly doubt they're going to track down and DMCA hypothetical forks, so it's basically GPL), and they're planning to repost (for a lack of a better word) it on GitHub soon.

...on a more light note, this issue (not necessarily with this comment, but earlier ones) might make a good github-drama candidate :)

I'm sure it would make for great github-drama and by all means post it. If holding the firms, tech giants, organisations, governments to the standard consumers and citizens are promised and deserve is dramatic, then I welcome the association. For too long, apathy and resignation have allowed people to be stomped on and their privacy stripped away, not to mention erosion of rights on the government end of things. So you keep up your memes and your external validation my friend, I have real matters to attend to.

Proton failed in its obligation to keep the Linux community updated for years, in more ways than one and a review of my posts will show that I have gone from criticising that approach to even applauding them. I was the first person to post about the Linux alpha on Reddit and with great excitement! Heck, it was before Proton even got to it. I don't require your approval and so I continue to give praise where it is due and concern when called for. More should do the same and not simply accept their lot.

Now lets drop this matter and move forward.

[Anonymous941]

@kazin-kharizma ...by saying it would make a good github-drama post, I didn't mean that it was unwarranted, just that it was conflict. Sorry if I implied that. And I certainly agree with you on most points - I was as frustrated as you with the awful client.

Now lets drop this matter and move forward.

Agreed, this is the last post about it. Thank you, Proton, for finally making this new client.

[kazin-kharizma]

Now lets drop this matter and move forward.

Agreed, this is the last post about it. Thank you, Proton, for finally making this new client. It’s all good buddy. Truth be told, you were the unfortunate recipient of a weeks worth of work stress and it was wrong of me to be so blunt.

You’ve been a champ in responding the way that you did @Anonymous941, taking it in stride. We have a Linux client that is surpassing all expectations and a confirmation that the repo will be posted upon transitioning to beta in September, plus kill-switch. Way to go Proton team! And thank you @jacopom and @calexandru2018 for keeping this thread aware.

[Zylquinal]

@calexandru2018 In the code i see that the app used b:[label} appended by default to the OpenVPN username, is there any reason behind this? Wouldn't it be better if the user could manually chose it?

Let's say i connect to SG#69

"Servers": [
        {
          "EntryIP": "37.19.201.130",
          "ExitIP": "37.19.201.131",
          "Domain": "node-sg-14.protonvpn.net",
          "ID": "Kk6z1U6Pml59hTTBT2eBhsrmZNfwCj4XndRWXIbn3Z0pKIfLHA8mFsGfKK07RzjLm3VUfEXVb205ll4-NR8a8Q==",
          "Label": "6",
          "X25519PublicKey": "rKXFNhvVY+l4GE0STa1u3Yn/2hptVI6Dms/brS341zg=",
          "Generation": 0,
          "Status": 1,
          "ServicesDown": 0,
          "ServicesDownReason": null
        }
      ],

With b:[label} flag appended, my exit IP will be the same as the exit IP of the server that i'm connecting to which is 37.19.201.131.

And if i it's not appended (turned off), i will get random exit IP assigned for my connection:

$ curl http://ip.me
37.19.201.135

My other question would be, what kind of kill switch implementation would Proton use? In Proton previous linux app i see that you guys were using NetworkManager to block it, which work by creating a dummy connection with low route-metric value so the connection would go there (by priority) instead of leaking to the internet.

But this could leave some kind of fake sense of security as application (e.g. Torrent app) could be manually assigned to use specific interface, and render the kill switch useless. I know this could be prevented if we use iptables or nftable based rule, but we need root permission to achieve it.

Example:

$ ping -I <interface> <some_ip>
.... (Ping goes successfully, ignoring the KS)

Example: (With IP Tables based rule to block connection)

$ ping -I <interface> <some_ip>
.... (Failed, or rejected, KS can't be ignored)

And if Proton would still go with the NM way, i would be happy if user were warned (inside the app) about the possibility of an app explicitly using certain interface to connect to the internet which may ignore the KS.

[kazin-kharizma]

@calexandru2018 In the code i see that the app used b:[label} appended by default to the OpenVPN username, is there any reason behind this? Wouldn't it be better if the user could manually chose it? ... And if Proton would still go with the NM way, i would be happy if user were warned (inside the app) about the possibility of an app explicitly using certain interface to connect to the internet which may ignore the KS.

And it is for this very reason that I do what I do with my pushes for transparency. I may not be a skilled developer, a learning one at best but I think its these kinds of convos, my own and yours that push for accountability. While I am sure that Proton has every intention to deliver the best product possible, that doesn't mean we stop asking questions like this. @Zylquinal you are the one who has been using the pre-release alpha with Arch Linux, yes? Great work on that btw if so. I have directed many a person to your repo who use Arch.

[Zylquinal]

Thank you for the release of 4.0.0a16, and after inspecting some of the change i saw that Proton decide to use same method of network blocking. Yeah i do know that this site exist https://protonvpn.com/support/bittorrent-vpn/ and it explain the people on how to Torrent safely, since as we know that particular Torrenting app could bypass the restriction.

Here is some example that's also happening in new update:

[zylquinal@arch ~]$ ip route 
default via 10.96.0.1 dev tun0 proto static metric 50 
default via 100.85.0.1 dev pvpnksintrf0 proto static metric 98
... 

Then we bypass the killswitch just by explicitly using certain device:

[zylquinal@arch ~]$ ping -I wlan0 1.1.1.1
PING 1.1.1.1 (1.1.1.1) from 192.168.1.189 wlan0: 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=13.7 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=11.9 ms
...

I do know it's kinda hard to block it unless we are using firewall, which need elevated permission to run. That's why i think it's better if the app also explicitly warn the user of any possibility that certain apps could possibly bypass this restriction when they're using the kill switch, since not everyone knows that such possibility exist.

[Anonymous941]

@calexandru2018 Thank you for adding the kill switch! Can you also add a permanent kill switch option, so when I'm disconnected, it won't leak my real IP?

[Anonymous941]

Then we bypass the killswitch just by explicitly using certain device

@Zylquinal not my experience on Ubuntu:

$ ping -I wlp58s0 1.1.1.1
PING 1.1.1.1 (1.1.1.1) from 192.168.101.52 wlp58s0: 56(84) bytes of data.
^C
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9211ms

[Zylquinal]

@Zylquinal not my experience on Ubuntu:

It's working for me on Arch:

DEVICE          TYPE      STATE                   CONNECTION           
ipv6leakintrf0  dummy     connected               pvpn-killswitch-ipv6 
lo              loopback  connected (externally)  lo                   
tun0            tun       connected (externally)  tun0                 
pvpnksintrf0    dummy     connected               pvpn-killswitch      
wlan0           wifi      connected               internet_private              
[zylquinal@arch ~]$ ping -I wlan0 1.1.1.1
PING 1.1.1.1 (1.1.1.1) from 192.168.1.112 wlan0: 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=12.4 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=10.6 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=10.8 ms
^C
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 10.647/11.270/12.376/0.784 ms

[Anonymous941]

Maybe you need to reinstall it, or install ufw? Or it only works on Debian-based systems for some reason?

[Zylquinal]

Maybe you need to reinstall it, or install ufw? Or it only works on Debian-based systems for some reason?

It doesn't use ufw, and if it use one the app need root permission.

Okay, so i just installed clean Ubuntu 22.04.3 for the test, and here's the result

Here you would see specifying interface still works, and you would also see the difference in latency when using the VPN interface and not using it.

[Anonymous941]

@calexandru2018 On all of my computers, I'm having an issue where after each reboot I have to sign in again. Do you mind looking into that?