bug: aerc reports that generated file from accounts module has incorrect permissions

[Slime90]

Are you following the right branch?

• [X] My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

• [X] I have searched the existing issues

Issue description

When trying the email accounts integration with aerc for the first time, I get this error (username redacted):

❯ aerc
The file /home/$USER/.config/aerc/accounts.conf has too open permissions.
This is a security issue (it contains passwords).
To fix it, run `chmod 600 /home/$USER/.config/aerc/accounts.conf`
Failed to load config: account.conf permissions too lax

Maintainer CC

@lukasngl @patwid

System information

❯ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.0.10-zen2, NixOS, 22.11 (Raccoon), 22.11.20230424.f536431`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.11.1`

[lukasngl]

Hi,

It is possible to keep your plain text credentials in the config file, thus aerc complains when the permissions of the file are "too open".

The configuration files generated by home-manager are stored in the nix-store and then get symlinked. Thus, they are (and must be) readable by any user of your system, i.e. use "too open" permissions.

When you use home-manager, you (hopefully) do not store your plain credentials in the configuration, but use passwordCommand instead. Thus, no credentials are stored in the generated config files and "too open" permissions are actually fine.

In this case you can set the following option, that allows "too open" permissions on your config file.

programs.aerc.extraConfig.general.unsafe-accounts-conf = true;

As far as I know, you should have gotten a warning when switching your configuration, advising you to do just that.

[Slime90]

Hello,

The explanation makes sense, although I must admit I did not carefully inspect my log when I rebuilt. Now I am wondering why this aero option is not automatically added in the module as a default, if this is required for any store linked config file then I would think this should always be set by the module if it is required for the accounts to work.

[lukasngl]

Hi,

I agree that the current state is a little cumbersome, but I argue that this should be fixed by aerc itself, i.e. checking if any account-configuration actually contains passwords before complaining about too lax permissions.

Now I am wondering why this [aerc] option is not automatically added in the module as a default, [...].

The main reason is, that the option is written to aerc.conf and not accounts.conf. When you use home-manager to configure the account but not the program itself, you only opted-in for managing accounts.conf with home-manager, not aerc.conf. Thus, if unsafe-accounts would be enabled if any account is configured, we would also write aerc.conf, even if the user does not want to manage the configuration with home-manager. (In this scenario, home-manager would quit with the error, that the file is in the way.)

Another minor reason is keeping assumptions minimal to ensure forward-compatibility, i.e. if the aerc devs would decide to rename the option the module would become incompatible.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.