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: INN snapshot changes (Julien ?LIE)
2. Re: GitHub Actions CI now enabled for INN pull requests
(Julien ?LIE)
3. Re: Discussion about Cancel-Lock support (Julien ?LIE)
4. INN indentation (Richard Kettlewell)
----------------------------------------------------------------------
Message: 1
Date: Sun, 19 Sep 2021 08:50:26 +0200
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: INN snapshot changes
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
>> There seems to be a synchronisation issue though because latest CURRENT
>> is 20210912, latest STABLE is 20210910 and inn-2.7-20210913.tar.gz is
>> not present at <https://downloads.isc.org/isc/inn/snapshots/>...
>
> Yeah, I'm getting all sorts of weird timeout errors from their rsync
> client talking to my server. I think something may be having trouble on
> the ISC side.
OK, synchronization with ftp.isc.org sometimes works and sometimes does
not. Hopefully they will resolve their problem.
Do you know how many snapshots on changes will be retained for each
branch? (purge after a certain date? for instance 3 months but always
keep at least 1 snapshot? It would for instance mean for the FreeBSD
inn-current port that a notification of inexistent snapshot will not
happen before at least 3 months, which seems reasonable.)
--
Julien ?LIE
??Some joys are better expressed in silence as a smile holds more
meaning than words.??
------------------------------
Message: 2
Date: Sun, 19 Sep 2021 09:18:01 +0200
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: GitHub Actions CI now enabled for INN pull requests
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
> I've enabled some simple GitHub Actions testing for all pull requests and
> pushes for the main branch. This does the same checks that we are doing
> when generating snapshots: builds with various options with warnings
> enabled plus running the (somewhat meager, alas) test suite. That should
> at least give us a basic sanity check for pull requests.
Works pretty fine, thanks!
Having a look at GitHub possibilities, I see we can add code scanning
for common vulnerabilities and coding errors (like CodeQL Analysis).
Has anyone tested it? Is it worthwhile?
--
Julien ?LIE
??Vous savez, les id?es, elles sont dans l'air. Il suffit que quelqu'un
vous en parle de trop pr?s, pour que vous les attrapiez?!?? (Raymond
Devos)
------------------------------
Message: 3
Date: Sun, 19 Sep 2021 11:09:10 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Discussion about Cancel-Lock support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
>> 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).
OK, I'll remove verifycancels and refusecybercancels during the
integration of Cancel-Lock support.
>> 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.
The idea behind was to send a hash only for canlock* and verify hashes
for both canlock* and extra* but I agree it is a bit complex and confusing.
During key rotation, we can still go on send both hashes, and verify
both hashes, then at one time remove the old password. Looks like
simpler indeed, with canlock* lists.
> I like the idea of a separate secrets file.
>
> 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.
Yep.
So in a nutshell the best design would be an inn.conf parameter:
secretsfile: <pathetc>/secrets.conf
With secrets.conf like:
cancels {
canlockuser: [ password ]
canlockadmin: [ password anotherpassword ]
}
# And other groups to come when merging other secrets.
--
Julien ?LIE
??Vous savez, les id?es, elles sont dans l'air. Il suffit que quelqu'un
vous en parle de trop pr?s, pour que vous les attrapiez?!?? (Raymond
Devos)
------------------------------
Message: 4
Date: Sun, 19 Sep 2021 11:26:43 +0100
From: Richard Kettlewell <[email protected]>
To: [email protected]
Subject: INN indentation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
The current stated style is, in hacking.pod:
Use a roughly BSD indentation style but with four-space indents. This
means no space before the parenthesis around function arguments, open
brace on the same line as if/while/for, and close and open brace on
the same line as else.
However the reality is slightly more complicated: many files use tabs
and spaces interchangeably, apparently with an assumption that the tab
character represents 8 spaces, despite the coding style saying indent is
4 spaces.
However some editors that assume that the tab distance and the indent
depth always match, e.g. VS Code. It's a lot harder to figure out the
real layout of the code as a result.
Would it be possible to adopt an indent rule in which either tabs match
the indent depth, or tabs are not used at all, and reformat the source
code accordingly?
(My personal preference would be to completely ban the tab character
from source code, enforced with build time tests, since the meaning of
the tab character depends on local configuration and it is, empirically,
unrealistic to assume that everyone will share the same configuration.
But I don't mind what the solution is as long as it works. In the Go
world the policy is "indent = 1 tab" and that works in practice.)
ttfn/rjk
------------------------------
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 10
********************************************
