docker
docker copied to clipboard
nextcloud
Secure SMTP credentials
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.
SMTP_NAME is usually a well known mail address and not handled as a secret. Can you give a use case where this matters?
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.
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.
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.
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.