> for example:
> ```
> SERVER_PROTOCOL=HTTP/1.1 REQUEST_METHOD=GET PATH_INFO=/user/repo/info/refs git.sr.ht-http-clone
> 2025/03/16 08:11:48 Loaded config from config.ini
> Status: 500 Internal Server Error
> Content-Type: text/plain; charset=utf-8
> ```

Oh, I just now noticed it's acctually going to stderr,
so that is fine for sure.

"Drew DeVault" <drew@ddevault.org> writes:
>
> Is it? Cannot reproduce

To be more specific, it is printed to stdout,
it doesn't actually get sent to the user,
at least with Caddy.
I presume that is because it's sent
before the headers.

I observed this in 1. caddy log, 2. when executing the script manually.
As I was saying, I am not sure if this is actually a problem,
just something I noticed and was a bit surprised about,

Hello Drew,

quoting from your e-mail to the admin mailing list:

"Drew DeVault" <drew@ddevault.org> writes:

>
> The /authorize endpoint has been removed and git HTTP traffic should be
> run through git.sr.ht-http-clone, which will perform authorization
> checks and exec(2) git http-backend if all is well.

Any reason this doesn't respect SRHT_CONFIG env var like the git ssh
scripts do? On a system without FHS this would be easier. Though I guess

So I was reconfiguring my server to not use this patch:
https://lists.sr.ht/~sircmpwn/sr.ht-dev/%3C20211208082636.65665-1-me@ignaskiela.eu%3E#%3C20220514212908.2356683-2-julm+srht@sourcephile.fr%3E
anymore. This patch adds a redis+socket scheme support through
importing Celery and constructing the client with it.

And I noticed a problem. While Both Celery worker and core.sr.ht
codebase support sockets, they both want different scheme.
Specifically, Celery worker doesn't understand unix://, but understands
redis+socket:// scheme. But core.sr.ht has it the other way round.

This poses a problem, webhook url from config is used from both the python
codebase and webhook instances. Since one doesn't like unix and the
other doesn't like redis+socket, it's impossible to use sockets currently.
[message trimmed]

> Not sure I can follow. There is already a comment above yours stating 
> that this is required. Your reasoning also doesn't really make sense, 
> because the user is used for, well, the username in plain auth. Did you 
> mean "if smtp-auth is _not_ plain"? If so, the commit message has it 
> mixed up as well...

Sent patch version 2:
https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/58050,
is that the right way to send a second version?
I can't seem to find instructions on that.

The smtp-user option currently has to be set even
if smtp-auth is none, because it's used for
the Sender field in e-mails.
---
 config.example.ini | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/config.example.ini b/config.example.ini
index 062616b..0aab280 100644
--- a/config.example.ini
+++ b/config.example.ini
@@ -50,8 +50,9 @@ smtp-encryption=starttls
 # Default: plain
 # Options: plain, none
[message trimmed]

Currently there are three messages
that say just "Invalid mail configuration".
That can be confusing, mainly for the mail.smtp-user
option, where it might not be clear this option is
required to send emails (and that in turn is required
to open tickets when someone is subscribed).
---
 api/graph/events.go | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/api/graph/events.go b/api/graph/events.go
index 2e45616..e71d3c4 100644
--- a/api/graph/events.go
+++ b/api/graph/events.go
[message trimmed]

I see. I just misunderstood. Thanks for the clarification. I will try to get to that soon. I agree with everything in the ideal case you described, I see it the same way.

What you are saying makes sense to me. But it is not the case from would be set to user in this case where I got the error. The From is set to todo.sr.ht::notify-from. That is why I am so confused by the need of Sender header in this case. Yes there seem to be other instances that are like you say and there Sender header makes sense to me.

What I am talking about specifically is what is in api/graph/events.go in function SendEmails that doesn't send e-mails 'on behalf' of someone, but from the notify-from.

In my opinion the Sender should be set to the notify-from option rather than the smtp user by default, and be overridable by a separate option. Because as I reasoned, if the mail server accepts Senders used in lists.sr.ht (being the emails of the lists, not the smtp user), why would it not receive Sender of todo's notify-from?

Hello,

Sorry for that. The comment is currently wrong,
it should read 'even if smtp-auth is none', not plain.
I will fix it today later. 
I got distracted by the comment above. 

Yes, it is confusing, but currently is is not the only
use of smtp-user. It is hardcoded to be used as
Sender header in todo.sr.ht. 

See also this thread (which I should've linked before): <https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C87setb7y5w.fsf@ditigal.xyz%3E>.
Since I don't know how long it will be to reach conclusion,
I wanted to submit a patch that explains