ssmtp: Add AuthUser and AuthPass options.

[the-kenny]

Add AuthUser and AuthPass options for ssmtp.

These can be used to enable all users to send mail via a simple SMTP server like smtp.gmail.com.

[bluescreen303]

This would leave your plain-text password (full access to your google account in case of your gmail example) in the nix-store, readable for every user on the system.
Please have a look at other modules (mysql, gogoclient) to see how they handle passwords.

[bjornfor]

Both mysql and gogoclient take the path to a file containing the password. Seems like a good solution to me. But this is what mysql.nix says about it: "FIXME: remove this option; it's a really bad idea." Why is that?

[bluescreen303]

I don't know why that comment is there for mysql, but in general setting-passwords stuff can be problematic.

As the password is not allowed to end up in store, this means that it has to be "activated" during system activation or during the startup of a service. As this probably happens more than once (for example on every reboot), it has to be idempotent (should not fail the second time). Also, it might be that the password changed, so it has to be decided if password-changes should work too.

For gogoclient this is not an issue, as a new config file is generated on every start.
For mysql however (where there is state involved), there is no easy way to check if the password has changed, and when it changes, it would require access to the old password, or a hack requiring the db to launch in a mode without access control to reset the password, followed by a normal startup. You will probably agree this gets messy really quick.
That's why mysql chose to only set the rootPassword on first startup, which is described with the option, fully understandable, but not very nix-like, as you end up with a different system depending on whether or not mysql was installed before.

For ssmtp though, it's probably easy (like with gogoclient) so I think it's safe to use.

[domenkozar]

Are there any other alternatives to file storage approach? Feels like something nix as a language should solve.

[vcunat]

@iElectric: there was at least one discussion of this kind already, mainly from @MarcWeber http://lists.science.uu.nl/pipermail/nix-dev/2012-July/009567.html

[MarcWeber]

https://github.com/MarcWeber/nix/tree/experimental/write-file-hashed

But please be aware that it introduces kind of "not garbage collected state directory you do not copy with nix-copy-closure"
But at least it is nice way to ensure this kind of security. You can also checkout the nix branch at github.com/MarcWeber/nixpkgs which provides the patches - so you can just reinstall nix

Its not perfect, but solutions based on it should be easy to review.

[domenkozar]

As far as I understand, that's impure and basing services with that is not an option. I'd recommend merging this one (in contrast to other services currently doing the same) and discuss this at NixOS/nix#8

[domenkozar]

I'm merging this one. We have password usage all over MixOs, but this shouldn't stop adding a new one. Once we fix this in Nix, we can go over existing services and make sure they use more secure way of storing passwords.