Make new log files group-readable by default. To retain the prior
behavior, soju can be started with a umask set to 0077.
---
 msgstore_fs.go | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/msgstore_fs.go b/msgstore_fs.go
index d17859d..5f7025b 100644
--- a/msgstore_fs.go
+++ b/msgstore_fs.go
@@ -129,12 +129,12 @@ func (ms *fsMessageStore) Append(network *network, entity string, msg *irc.Messa
 		}
 
 		dir := filepath.Dir(path)
[message trimmed]

On Sat, 12 Jun 2021 12:21 +0000, Simon Ser wrote:
>Yeah. Log files can be a little sensitive, since they contain private
>communication.
>
>Can you tell a little bit more about your use-case? Why do you need to
>access the log files as a different user?

Sure. I run soju on a single-user server using a dedicated user and 
group (soju:soju). I've added my user to the 'soju' group and chmod'ed 
the soju log directory to g+rX to make browsing and reading log files a 
little easier (i.e. without using sudo).

However, new log files are written with 0600 so even though they are 
owned by the 'soju' group I still can't read them without sudo.

Fixes a bug where the first commit in the log after clicking the Next 
button would match the last commit on the previous page.

---
 gitsrht/blueprints/repo.py | 12 ++++++++----
 gitsrht/templates/log.html |  4 ++--
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/gitsrht/blueprints/repo.py b/gitsrht/blueprints/repo.py
index 49e4f58..5cf1d0b 100644
--- a/gitsrht/blueprints/repo.py
+++ b/gitsrht/blueprints/repo.py
@@ -418,17 +418,21 @@ def log(owner, repo, ref, path):
         if not commit:
[message trimmed]

On Thu, 10 Jun 2021 22:49 +0300, Sol Fisher Romanoff wrote:
>If you find any more tickets, please add them so Drew can check.

https://todo.sr.ht/~sircmpwn/git.sr.ht/334 is done.

Now that I think about it I wonder if the best way to handle this is to just delegate to the *actual* umask set by the user/OS instead of re-implementing the functionality in soju. In order to do that, the patch would be much simpler: we’d simply change the mode argument of the MkdirAll call to 0777 and the mode argument of the OpenFile call to 0666.

Of course, for anyone who has a standard umask of 0022 set, this would suddenly make log files world readable, which is undesirable. But I do think having *some* way to handle the permissions on the log files is a useful feature (it’d be useful to me, at least).

I’m curious to hear your thoughts.

Greg

Add a umask parameter (0077 by default) that specifies the umask to use
when creating new log files. This allows users to specify more
relaxed permissions which allows finer grained access control of log
files on their servers.
---
 cmd/soju/main.go |  1 +
 config/config.go | 13 +++++++++++++
 doc/soju.1.scd   |  5 +++--
 msgstore_fs.go   | 10 +++++++---
 server.go        |  2 ++
 user.go          |  2 +-
 6 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/cmd/soju/main.go b/cmd/soju/main.go
[message trimmed]

---
 downstream.go | 16 ++++++++++++++--
 upstream.go   | 23 ++++++++++++++++++++---
 2 files changed, 34 insertions(+), 5 deletions(-)

diff --git a/downstream.go b/downstream.go
index 8e94095..5ee99ec 100644
--- a/downstream.go
+++ b/downstream.go
@@ -1182,6 +1182,14 @@ func (dc *downstreamConn) welcome() error {
 		}
 	})
 
+	if uc := dc.upstream(); uc != nil {
[message trimmed]

The first MOTD upon connection is ignored, but subsequent MOTD messages
(requested by the "MOTD" message from the client, typically using a
/motd command) are forwarded.
---
 downstream.go |  2 +-
 upstream.go   | 29 ++++++++++++++++++++++++++++-
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/downstream.go b/downstream.go
index e263054..8e94095 100644
--- a/downstream.go
+++ b/downstream.go
@@ -1105,7 +1105,7 @@ func (dc *downstreamConn) welcome() error {
 	dc.SendMessage(&irc.Message{
[message trimmed]

On Wed, 09 Jun 2021 18:59 +0000, Simon Ser wrote:
>Maybe a third, less intrusive solution would be to add a `gotMOTD bool`
>field to upstreamConn, set it to true in the RPL_ENDOFMOTD/ERR_NOMOTD
>handlers and only forward the messages if it's already set to true.

I like this. It also has the benefit of ensuring that subsequent /motd 
commands from the client actually receive the up-to-date MOTD from the 
upstream server. If we buffer the MOTD locally and then soju doesn't 
reconnect to the upstream server for a long time then the MOTD would not 
be updated.

On Wed, 09 Jun 2021 18:37 +0000, Simon Ser wrote:
>On Wednesday, June 9th, 2021 at 20:29, Simon Ser <contact@emersion.fr> wrote:
>One thing missing though is that we should use uc.srv.prefix() for the
>message prefixes, not the upstream server's prefix. Some clients might
>expect server messages to have the same prefix as RPL_WELCOME.

Ok I'll make that change.

>Also I think this sends out the MOTD when a downstream is connected and
>the upstream reconnects. Maybe not that of a big deal.

Yes this is indeed the case. A possible alternative: instead of 
forwarding the MOTD messages directly to downstream, each upstream 
connection could buffer the MOTD messages and then only send those down