Skip to content
This repository has been archived by the owner on Oct 11, 2023. It is now read-only.

Is this repo still being maintained? #64

Open
ElmoTheWizard opened this issue Mar 3, 2022 · 100 comments
Open

Is this repo still being maintained? #64

ElmoTheWizard opened this issue Mar 3, 2022 · 100 comments

Comments

@ElmoTheWizard
Copy link

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

@calexandru2018
Copy link
Contributor

calexandru2018 commented Mar 3, 2022

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.

@alexandrevicenzi
Copy link

@calexandru2018 let distributions get an early preview if possible, so we can adapt our packages 😄

@bionicworx
Copy link

@calexandru2018 Any updates on this upcoming multi-platform release? Any way we can test it yet?

@Redsandro
Copy link

we are currently working a new and improved multi-platform client

This sounds good. Can we track this new version somewhere? Is it open source?

@Bruflot
Copy link

Bruflot commented Jul 16, 2022

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

Four months later and these updates are nowhere to be seen. Are we ever getting Wireguard support? It's over a year since Wireguard support was added for other platforms, whereas Linux users are left waiting with no ETAs or updates in sight.

@benstockil
Copy link

Will the new client still depend on systemd?

@FillingTheVoidOnYT
Copy link

FillingTheVoidOnYT commented Aug 5, 2022

hopefully this new client brings an flatpak or appimage, many people hate installing stuff from terminal

@alastortenebris
Copy link

hopefully this new client brings an flatpak or appimage, many people hate installing stuff from terminal

Flatpaks are terrible for applications with system level integration. I don't think any sort of permission setup will allow it to work.

@GloriousWizard
Copy link

make the new repo public. I've been waiting for months and I honestly don't care if it's broken. I just need to see something

@Nottt
Copy link

Nottt commented Aug 17, 2022

It's a shame the linux client is basically useless...there is no offficial/easy way to run at boot and I tried lots of stuff.

And with this thread i know this client won't have any future...so probably better for me to cancel my protonvpn and switch to another provider that is more linux friendly !

@benstockil
Copy link

@Nottt I'm using the Wireguard configurations until the new client is released publicly. It works well enough for now, but the lack of news from the dev team concerns me about how long I'm going to be stuck with this workaround.

@LunaDoll
Copy link

Hi, when the new version is available, can you please post info it here?

I watched this topic :-)

@FillingTheVoidOnYT
Copy link

It's a shame the linux client is basically useless...there is no offficial/easy way to run at boot and I tried lots of stuff.

And with this thread i know this client won't have any future...so probably better for me to cancel my protonvpn and switch to another provider that is more linux friendly !

mullvad has a great linux client

@Slayer5934
Copy link

iVPN has a good linux client as well, and has working UPnP from my experience (for some reason Mullvad did not port forward correctly, even after setting a port online.)

Can't believe it's taking so long for a non-jank linux client, and they are not giving status updates either; Proton looking a little corporate from where I sit, and not in a good way.

@Zylquinal
Copy link

Seven month's later, still no wireguard support.

@ghost
Copy link

ghost commented Nov 3, 2022

Hey, @calexandru2018

A half year has passed Eight months have passed since #64 (comment), still no wireguard support, no visible significant development.

It is a real pain to wait without knowing roughly when they are planned to be done.
I know you are probably very busy, but can you give us regular updates on the internal progress and development plans?

@calexandru2018
Copy link
Contributor

Hey @jbas23

I'll copy/paste what I've wrote on another ticket:

Apologize for not being much active here, but we're currently working really hard on the new client, so that we don't have the same dependency issues that we currently have.

The idea for the new client is to be as modular as possible, meaning that if someone would like to run native backends instead of 3rd party (ie native openvpn/wg vs NM openvpn/wg ) that would happen transparently. The only difference would be which packages are required (we'll be creating meta-packages that help with installation). Apart from that we're working also on making the applications in general to be much more reliable, and all of this takes time. Initially the rebuild app won't have many features, but we intend in releasing it gradually.

At this current point we have some of the sub-packages written, and we're working mostly in refining (quality and reliability) some of them and at the same time re-writing the apps.

@GloriousWizard
Copy link

Why not make the project public? Even if it's far from stable, it will make people stop asking about the progress of the new client.

@Anonymous941
Copy link

Anonymous941 commented Dec 14, 2022

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.

@calexandru2018

Can you make the client public? Then the open-source community can actually help it go faster. Unless, of course, you made no progress at all.

@ghost
Copy link

ghost commented Dec 17, 2022

Hey @jbas23

I'll copy/paste what I've wrote on another ticket:

Apologize for not being much active here, but we're currently working really hard on the new client, so that we don't have the same dependency issues that we currently have.
The idea for the new client is to be as modular as possible, meaning that if someone would like to run native backends instead of 3rd party (ie native openvpn/wg vs NM openvpn/wg ) that would happen transparently. The only difference would be which packages are required (we'll be creating meta-packages that help with installation). Apart from that we're working also on making the applications in general to be much more reliable, and all of this takes time. Initially the rebuild app won't have many features, but we intend in releasing it gradually.

At this current point we have some of the sub-packages written, and we're working mostly in refining (quality and reliability) some of them and at the same time re-writing the apps.

It's great to hear that some progress is being made. I'm sure everybody would appreciate little updates like this one from time to time. We are anxiously waiting for a new Proton VPN client. The current one is practically unusable, not to mention missing several features.

I appreciate what you guys are doing and understand that it is a lot of work to build a new client. But it's not easy waiting (with no updates or ETAs) when I am paying for an Unlimited account.

@calexandru2018
Copy link
Contributor

Thank you all for the feedback.

About releasing it public while still in development, it's tricky, mainly due to the fact the we don't want the client to be usable by anyone while it's in pre-alpha, given that certain things are still not in place to assure that connections are reliable and secure.

On another note, we'll soon start working on a roadmap definition for the Linux client, and then we'll be able to share it with everybody.

@Anonymous941
Copy link

Thank you all for the feedback.

About releasing it public while still in development, it's tricky, mainly due to the fact the we don't want the client to be usable by anyone while it's in pre-alpha, given that certain things are still not in place to assure that connections are reliable and secure.

On another note, we'll soon start working on a roadmap definition for the Linux client, and then we'll be able to share it with everybody.

@calexandru2018 Thanks for the update. I have an idea: make the client connect to a separate testing server that doesn't allow access to the Internet and the only site you can visit is something like "test.invalid" which resolves to a Proton-controlled server. That way, no matter how insecure the connection is, it won't put anyone at risk or at a false sense of security and the open-source community can help the development go faster.

@ghost
Copy link

ghost commented Dec 17, 2022

Thank you all for the feedback.

About releasing it public while still in development, it's tricky, mainly due to the fact the we don't want the client to be usable by anyone while it's in pre-alpha, given that certain things are still not in place to assure that connections are reliable and secure.

On another note, we'll soon start working on a roadmap definition for the Linux client, and then we'll be able to share it with everybody.

I understand not wanting to open up a pre-alpha or even alpha build to the public. As a privacy/security focused VPN, I think that it would be irresponsible if people could use a half-finished product.

Thanks! We would greatly appreciate a roadmaps and something to look forward to

@Anonymous941
Copy link

Thank you all for the feedback.
About releasing it public while still in development, it's tricky, mainly due to the fact the we don't want the client to be usable by anyone while it's in pre-alpha, given that certain things are still not in place to assure that connections are reliable and secure.
On another note, we'll soon start working on a roadmap definition for the Linux client, and then we'll be able to share it with everybody.

I understand not wanting to open up a pre-alpha or even alpha build to the public. As a privacy/security focused VPN, I think that it would be irresponsible if people could use a half-finished product.

Thanks! We would greatly appreciate a roadmaps and something to look forward to

@orange-tin I understand that, but why not publish it with a test server as said above? That way there's no risk and a great reward for both Proton and its users.

@kazin-kharizma
Copy link

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

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

@kazin-kharizma
Copy link

@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
Copy link

@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
Copy link

Snaggly commented Jul 15, 2023

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

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.
Screenshot_nm-openvpn — Dolphin_1

@Zylquinal
Copy link

Zylquinal commented Jul 16, 2023

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
Copy link

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
Copy link

@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
Copy link

@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
Copy link

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
Copy link

kazin-kharizma commented Jul 21, 2023

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?

#64 (comment) - per a post from @calexandru2018 way back when, the source code will be closed source for the time being.

#64 (comment) - 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
Copy link

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
Copy link

kazin-kharizma commented Jul 22, 2023

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
Copy link

@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
Copy link

kazin-kharizma commented Jul 30, 2023

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
Copy link

jacopom commented Aug 3, 2023

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
Copy link

Anonymous941 commented Aug 3, 2023

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
Copy link

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
Copy link

kazin-kharizma commented Aug 3, 2023

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
Copy link

Anonymous941 commented Aug 3, 2023

@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
Copy link

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
Copy link

@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
Copy link

@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
Copy link

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
Copy link

@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
Copy link

Anonymous941 commented Sep 8, 2023

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
Copy link

@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
Copy link

Anonymous941 commented Sep 8, 2023

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

@Zylquinal
Copy link

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
image

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
Copy link

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests