Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Test Git repository for INN (Russ Allbery)
2. Re: Discussion about Cancel-Lock support (Russ Allbery)
3. Re: Please generate the ChangeLog file also for snapshots
(Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Sun, 05 Sep 2021 10:06:03 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Test Git repository for INN
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> Done on both 2.6 and main branches.
> Is there a need to also clean up previous branches? Maybe only the $Id$
> strings in POD documentation for 2.4 and 2.5 branches for which HTML
> documentation is still generated on your web site? (I've not tried to
> merge the commit from 2.6 against these older branches, maybe it applies
> without too many conflicts.)
I'm not too worried about the older branches and think we can leave them
alone. I've been maintaining the documentation on my web site because it
was fairly easy, but I'm not sure whether anyone really uses it, so having
a stray somewhat-odd $Id$ string in the generated documentation doesn't
seem like a huge problem.
(The documentation is still based on Subversion because I haven't gotten
my tooling switched over but that should be fixed shortly, since I have a
week of vacation to catch up on personal projects.)
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 2
Date: Sun, 05 Sep 2021 10:15:57 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Discussion about Cancel-Lock support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> OK, I'll see how to get rid of the verifycancels stuff.
> Couldn't refusecybercancels also be removed? Its default value is already
> false and our inn.conf documentation mentions it is a "somewhat messy,
> inefficient, and inexact way of refusing spam cancels"...
Yes, I think we should remove refusecybercancels. It was always a hack
and I don't think anyone is issuing mass spam cancels using that
convention any more (or probably has in more than a decade).
Other readers of inn-workers, yell if this is something you think is still
useful.
> I've begun to look at the integration of Cancel-Lock support.
> I believe the possibility to have several secret phrases could be useful,
> notably to deal with a period of transition when changing the password
> (during which 2 Cancel-Key hashes will be sent).
Yes, supporting key rotation is always a good idea.
> Suggestion:
> - add a "secretsfile" inn.conf parameter for the path to the secrets file
> (<pathetc>/secrets.conf by default?)
> - use the new INN configuration parser for it
> cancels {
> canlockuser: password
> canlockadmin: otherpassword
> extracanlockuser:
> extracanlockadmin:
> }
> I don't see use cases for more than 2 passwords so a list might be
> over-kill for extracanlockuser & admin).
> cancels {
> canlockuser: password
> canlockadmin: otherpassword
> extracanlockuser: oldpassword
> extracanlockadmin: oldotherpassword
> }
I'm not sure that I understand the difference between canlockuser and
extracanlockuser. They both result in sending a hash, and they are both
valid for verifying hashes, correct? If that's the case, it may be
simpler to remove the extra* parameters and just make the values lists.
I like the idea of a separate secrets file.
One of my past regrets was when I was looking at configuration file
formats, I probably shouldn't have hand-rolled a parser and instead
figured out how to use YAML. In my defense, at the time it was far from
obvious that YAML would win the configuration language wars (and I guess
it hasn't entirely won them even now), and there were a lot of other
possibilities. But now I kind of wish all the INN configuration files
were just in YAML. The popularity of Kubernetes among other things has
made YAML fairly universal, with great editor, linting, and schema
support. Ah well. Maybe a project for some future day when someone is
feeling wildly ambitious. :)
(And yes, I know YAML is hideously, absurdly complicated and there are a
lot of language features you probably don't want to use. But it's still
the most readable and writable configuration language for humans IMO, even
with its strange quirks and aggressive interpretation of words as
booleans.)
> Perhaps the cancels group is not useful, and we could just have in
> secrets.conf:
> canlockuser: password
> canlockadmin: otherpassword
> extracanlockuser: oldpassword
> extracanlockadmin: oldotherpassword
I feel like we have other secrets that could potentially benefit from this
over time, though (passwd.nntp, for instance, or the secret parameter in
inn-radius.conf), so I like the grouping. It feels more future-proof. It
would be lovely if eventually we could put all the secrets used by INN in
one file, since that makes life much easier for configuration management
and permissions.
> Re-reading our doc/config-syntax file, I also see that we could use an
> included file as a group:
> group tag <filename>
> Hmmm, if we use in inn.conf something like:
> secrets cancels <pathetc>/secrets.cancels
> secrets passwd <pathetc>/secrets.passwd (for the purpose of current
> passwd.nntp)
> secrets feeds <pathetc>/secrets.feeds (where we could put the passwords of
> incoming.conf and innfeed.conf)
> wouldn't it respond to the need of secrets file?
This would also work but I think I like the first syntax a bit better.
> I still have not played with the possibilities of the parser; it seems
> that construction is possible. It is then unclear if the referenced
> file can list parameters/values (like inn.conf) or if it has to contain
> groups {}. Then we could have 1 secret file with cancels/feeds/etc.
> groups (or without groups).
My recollection is that if you use the group tag <filename> syntax, the
contents of the filename are treated as if they are contained in a group
{} block. But it's been a very long time....
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 3
Date: Sun, 05 Sep 2021 10:21:02 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Please generate the ChangeLog file also for snapshots
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> Following a discussion from last year, it is now the right time to
> handle that request while updating snapshot generation.
My feeling on this is that the Debian package shouldn't include the raw
changelog. It's potentially huge and it feels like a waste of space. We
maintain a fairly complete NEWS file that should already mention anything
that people using INN need to know about what changed, and that's the
useful file to install in the Debian package.
Most Debian packages don't contain detailed changelog files in their
documentation because most upstreams don't generate them and when they do
they're often huge and not very useful. We've been doing this for a long
time, but the world has moved on from this approach to documenting changes
in favor of encouraging people to clone the Git repository and run git
commands themselves if they care about the details of specific
line-by-line changes. 99% of the important information is in NEWS,
already summarized for people to easily understand.
I'd lke to drop ChangeLog generation from releases as well. I know there
were some objections here the last time I said that, but they seemed
strange to me (IIRC, someone said they only read ChangeLog files because
they don't trust NEWS files to be meaningful and, well, okay, but I don't
think that's a good reason for us to do extra work to ship a ChangeLog
file given that our NEWS file is meaningful).
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 133, Issue 1
*******************************************
