Package Details: protonmail-bridge-nokeychain 3.9.1-1

Git Clone URL: (read-only, click to copy)
Package Base: protonmail-bridge-nokeychain
Description: An IMAP/SMTP bridge to a ProtonMail account (patched, stores secrets in a file)
Upstream URL:
Licenses: GPL3
Conflicts: protonmail-bridge
Provides: protonmail-bridge
Submitter: andrei.dubovik
Maintainer: andrei.dubovik
Last Packager: andrei.dubovik
Votes: 2
Popularity: 0.000316
First Submitted: 2021-05-27 16:36 (UTC)
Last Updated: 2024-02-18 13:50 (UTC)

Dependencies (1)

Required by (2)

Sources (3)

Latest Comments

DrosteEffect commented on 2024-01-27 15:07 (UTC)

@andrei.dubovik Great, thanks!

andrei.dubovik commented on 2024-01-22 15:27 (UTC)

@DrosteEffect Yes, I'll try to allocate some time to update the package this week. Sorry for a long delay.

In general, maybe my two cents on security and why I bothered in the first place to make this package, and why I think it is perfectly reasonable to store "secrets" in a cleartext file. Adding additional security layers on top of what an OS already provides adds extra complexity and possibly extra vulnerabilities while not actually giving any extra security under the scenario that the OS itself is compromised. SSH stores its secrets in plain text, for instance. Then again, if your keychain requires a yubikey to open or a similar authorization solution, then I would agree that using the keychain provides better security. I just don't think it's correct to say the official package is strictly more secure under all typical usage scenarios.

MarsSeed commented on 2024-01-22 14:53 (UTC) (edited on 2024-01-22 14:56 (UTC) by MarsSeed)

@DrosteEffect, it seems at this point it is best if you migrated to the up-to-date protonmail-bridge-core.

It serves the same use case, but in a secure way (unlike this package that stores "secrets" in a cleartext file.)

Edit: changed the link to protonmail-bridge-core, because that is the successor of protonmail-bridge-nogui (and the latter is pending deletion as of now).

DrosteEffect commented on 2024-01-22 11:59 (UTC)

Will this package be updated soon? It's been out of date since July 2023.

andrei.dubovik commented on 2023-01-27 14:26 (UTC)

Bumped the version to 3.0.9. So, I couldn't get the migration of the secrets file to work reliably from v2 to v3, and in the end decided to do nothing about migration. What it means, is that a new secrets file will be created in ~/.config/protonmail/bridge-v3/secrets on first run, and a manual re-login is required (from protonmail-bridge --cli). After that the service can be run as usual. The old secrets file, in ~/.config/protonmail/bridge/secrets, can be deleted.

Just a heads up, many changes in v3 of the protonmail bridge. Not insignificant one is that v3 has altogether new message ids, it seems, see for some history. For instance, if you're using mbsync, expect that it'll break with the version change and a manual intervention will be required.

andrei.dubovik commented on 2022-01-16 14:32 (UTC) (edited on 2022-01-16 14:37 (UTC) by andrei.dubovik)

It should be run as a user (i.e. not from root), the service name is protonmail-bridge. So,

systemctl --user enable protonmail-bridge

should in principle work. Do you have protonmail-bridge.service listed if you do

pacman -Ql protonmail-bridge


Before you enable and start the service, you need to login once by running the service in an interactive mode:

protonmail-bridge --cli

and then login. See also help while in the interactive mode.

wildwestrom commented on 2022-01-16 03:55 (UTC) (edited on 2022-01-16 04:18 (UTC) by wildwestrom)

I'm having one problems with this.

Systemd cannot find the unit file associated with this package. I tried both systemctl --user enable and systemctl enable as root.

Thank you for your time and attention to this matter.

andrei.dubovik commented on 2021-05-27 16:44 (UTC)

This is a patched version of protonmail bridge, where the secrets are kept in ~/.config/protonmail/bridge/secrets file (mode 0600) instead of using pass or gnome-keyring. In this way, protonmail bridge can be started as a service without additional user input. Arguably, this is a weaker security arrangement than the default one, so please use at own discretion.