~sircmpwn/sr.ht#214: 
Provide authenticated SMTP access for sr.ht users

this one resonates with me:

The problem is, the email is a pretty sensitive service, you may not want any apps to access it. If you attempt to follow the guide, for example, Git will store your email password unencrypted on the disk!

Yes, there are ways around it, for example, you can enable keyring integration. But to be more specific, I personally never allow any apps to access my primary email. Ever. And I have no plans to maintain a separate email for the sake of SH way of doing things. And I believe there are other people that take this way more seriously, than I do.

My proposal is to accept SMTP encrypted and authenticated connections from sr.ht users. The SMTP service will only accept mail that goes to a sr.ht service; It won't even allow CC or BCC outside sr.ht.

With that in place, a security sensitive user can:

  • Create a sr.ht account.
  • Configure git to use sr.ht for git send-email using either the account password or a SMTP specific password created by sr.ht.

and then git send-email would just work!

Even better, there could be a page in the account settings with the copy-pastable lines for configuring git with the correct SMTP server, user and password.

-- elias

Status
RESOLVED WONT_FIX
Submitter
~eliasnaur
Assigned to
No-one
Submitted
1 year, 1 month ago
Updated
a month ago
Labels
No labels applied.

~dennwc 1 year, 1 month ago

Quote author here. Plus one for this feature!

~rumpelsepp 1 year, 27 days ago

Interesting idea. But doesn't git use the originating email address (in this case foo@git.sr.ht) use as the author?

~eliasnaur 1 year, 27 days ago

On Tue Sep 3, 2019 at 11:37 AM ~rumpelsepp wrote:

Interesting idea. But doesn't git use the originating email address (in this case foo@git.sr.ht) use as the author?

No, because the user.name and user.email settings used by git commit are separate from the sendmail.* settings used by a suqsequent git send-email.

~sircmpwn REPORTED WONT_FIX a month ago

I don't like this for a number of reasons.

  1. "The SMTP service will only accept mail that goes to a sr.ht service; It won't even allow CC or BCC outside sr.ht." kind of defeats the purpose of decentralization that sr.ht pushes for.
  2. If we ditch that, then we are operating a general purpose mail server, which is ripe for abuse and is a bigger question than this feature demands.
  3. Git is open source and a highly reputable project and can be trusted with your email credentials.
  4. The patchset preparation UI and other more specialized forms of letting sr.ht send emails for you are proving to be a better approach to this problem.
Register here or Log in to comment, or comment via email.