Secure SMTP credentials

[aentwist]

Usernames are part of credentials and are therefore also secrets. Add an env var SMTP_NAME_FILE so that SMTP_NAME can be used with Docker secrets.

[J0WI]

SMTP_NAME is usually a well known mail address and not handled as a secret. Can you give a use case where this matters?

[aentwist]

Yes, are you sure you aren't thinking of SMTP_HOST?

I found a good article which appears to be based on RFCs. There exists both a username and password. More authoritatively,

PLAIN SASL Mechanism

The mechanism consists of a single message, a string of [UTF-8]
encoded [Unicode] characters, from the client to the server. The
client presents the authorization identity (identity to act as),
followed by a NUL (U+0000) character, followed by the authentication
identity (identity whose password will be used), followed by a NUL
(U+0000) character, followed by the clear-text password. As with
other SASL mechanisms, the client does not provide an authorization
identity when it wishes the server to derive an identity from the
credentials and use that as the authorization identity.

https://datatracker.ietf.org/doc/html/rfc4616

As an example, when you generate a key for AWS / SES it looks something like [keyboard mashing]

key: AOREHNK3UN34OU3OORS
secret: o23un4ouenowfenjh3on3/33ehnjo3uk

Imagine trying to hack something where the username is admin vs. something where it is instead roiehduyowaouwdhowuyhd but you don't know that. This is some kind of credential, and even if it is less sensitive than the secret, in my opinion it should be able to be a secret if users want it to be. The goal of this issue is to allow users to make that choice conveniently.

[J0WI]

Nextcloud itself does not treat mail_smtpname as a sensitive information. It's not common to do so. Many systems will show the identity in logs, UIs etc. whereas passwords are always treated as confidential values. If you need stronger secrets, just add more random bits to them and deploy countermeasures like rate limiting.

[aentwist]

Nextcloud itself does not treat mail_smtpname as a sensitive

Well that is just unfortunate.. thanks for looking into it.

I am ok with that point as long as it has parity with other usernames. i.e. database username is not treated as sensitive.

[aentwist]

workaround: get the updated smtp config file from the MR and mount it over the existing smtp config file at /usr/src/nextcloud/config/smtp.config.php to support SMTP_NAME_FILE. if you don't mount over it then it will be overridden by the existing smtp.config.php, so you have to provide a replacement for the entire file.