@Cimbali Thanks a lot!

I can confirm these patches work as intended (tested on Arch Linux). I backported them to the Arch's protonmail-bridge package while waiting for them to be merged & released here (or for upstream to provide their own fixes at some point).

Thanks for the patch. Also felt bad for the developers getting all that whining from a few Arch users over such a trivial matter. I. E. - just run it without the QT interface until 6.8 becomes more commonplace. This kind of thing is "par for the course" for Arch (or any distro close to "bleeding edge"), and the Proton developers had an easy work around already in place.

Hi @Cimbali, Thank you for your contribution. We have reviewed and tested your changes and we're pleased to announce that they've been approved. We will perform QA testing on all our supported platforms, and if the results are positive, your contribution will be included in our next release.

Note that this GitHub repository is a mirror of our internal development repository, so this pull request cannot be approved and merged here. We will cherry pick your two commits into our repository, and this pull request will be closed. Obviously, you will get credit for your work as the authorship of the commit is preserved in the process.

Thanks @Cimbali for this patch, and @Antiz96 for implementing so quickly in Arch.

Thanks for the patch. Also felt bad for the developers getting all that whining from a few Arch users over such a trivial matter. I. E. - just run it without the QT interface until 6.8 becomes more commonplace. This kind of thing is "par for the course" for Arch (or any distro close to "bleeding edge"), and the Proton developers had an easy work around already in place.

I would be too if the response they gave make sense but it actually bring me more worries than anything else as a proton business user, anyway not trying to start new drama but I was really unpleased with the official answers on that thread.

Thanks for the patch. Also felt bad for the developers getting all that whining from a few Arch users over such a trivial matter. I. E. - just run it without the QT interface until 6.8 becomes more commonplace. This kind of thing is "par for the course" for Arch (or any distro close to "bleeding edge"), and the Proton developers had an easy work around already in place.

I would be too if the response they gave make sense but it actually bring me more worries than anything else as a proton business user, anyway not trying to start new drama but I was really unpleased with the official answers on that thread.

Indeed. As a Proton Business user, I am going to run Bridge in headless or CLI mode going forward. Relying on EOL dependencies is not a good development practice and the official responses did not acknowledge this at all. It is nice of Arch Linux to backport these fixes to their version of the Bridge packages, but upstream should really be looking after these issues. That is what we, the customers, pay them to do after all. While I donate to Arch Linux from time to time, they are not contractually obliged to support my business (and I do not expect them to). As a business user, I expect Proton to step in at times like this and do the needful.

For now, I am tied into a contract with Proton but I will certainly be looking at migrating to alternatives which more consistently value security in their development practices. I accept that no business is perfect all of the time, but the slow response and dismissive attitude from Proton is extremely disappointing and worrying and speaks to wider issues about their management and culture.

Please, @joekm @singatias @thereillywriter, none of this is constructive.

Yes, using up-to-date dependencies would be nice. Yes, running bleeding edge distros means occasional unsupported dependencies and bugs. But developer time is finite.

This PR is opened in the spirit of constructively sharing solutions, and ranting only gets discussions closed and reduces the space for people to collaborate. If you’re unhappy with proton, with how they prioritise their resources, or with other users’ opinions (?), send them an email or write a post (including X, reddit, blogs -- whatever your favourite platform may be). If you agree or disagree with something said, use a reaction emoji. But github is not a place to vent. And forcing technical staff to spend time moderating discussions hardly seems a better use of resources.

Please, @joekm @singatias @thereillywriter, none of this is constructive.

Yes, using up-to-date dependencies would be nice. Yes, running bleeding edge distros means occasional unsupported dependencies and bugs. But developer time is finite.

This PR is opened in the spirit of constructively sharing solutions, and ranting only gets discussions closed and reduces the space for people to collaborate. If you’re unhappy with proton, with how they prioritise their resources, or with other users’ opinions (?), send them an email or write a post (including X, reddit, blogs -- whatever your favourite platform may be). If you agree or disagree with something said, use a reaction emoji. But github is not a place to vent. And forcing technical staff to spend time moderating discussions hardly seems a better use of resources.

Hi @Cimbali, I’ll quickly explain why this issue bothered me, but I won’t be discussing it further here. The issue has nothing to do with Arch Linux or using bleeding-edge libraries/features. The real issue is with the following response that was given:

Qt is only used for the user interface that is well separated from the part of Bridge that is security sensitive (they are different processes), therefore using an EOL Qt version doesn't make the application insecure.

From a security standpoint, this is quite concerning and gives the impression of lack of knowledge on the subject and “we don’t care about it”.

Attackers often target UI libraries with known vulnerabilities, as they can still open indirect access to data or resources, depending on the application’s design. If an attacker gains control over the UI process, they could exploit or manipulate inter-process communications, depending on the security of the protocol. If the UI has access to sensitive resources, even indirectly, this could be a potential attack vector.

As a developer, I consider it poor practice not to update dependencies to an LTS version, especially for a company claiming to prioritize privacy and security.

I'm not asking for having it fix in the next 24 hours but at least have it added to your backlog as a potential security issue.

I stand behind my response. This program is run-able without the QT interface and, if you're running a bleeding edge distro, that's to be expected. This is not a security issue.