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. Patches to include in 2.6.5? (Julien ?LIE)
2. Parametring cancel processing (Cancel-Lock vs unauthenticated
cancels) (Julien ?LIE)
3. Re: Parametring cancel processing (Cancel-Lock vs
unauthenticated cancels) (Martin Burmester)
4. Re: Parametring cancel processing (Cancel-Lock vs
unauthenticated cancels) (Julien ?LIE)
5. Re: Parametring cancel processing (Cancel-Lock vs
unauthenticated cancels) (Russ Allbery)
6. Re: Parametring cancel processing (Cancel-Lock vs
unauthenticated cancels) (Grant Taylor)
----------------------------------------------------------------------
Message: 1
Date: Sun, 2 Jan 2022 19:56:22 +0100
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Patches to include in 2.6.5?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi all,
And first of all, happy new year!
I'm planning on generating a release candidate for INN 2.6.5 in one or
two weeks. (Without ChangeLog, as it appears from previous discussions
that such a detailed file is not needed, easily retrievable via a mere
"git log --name-status tags/2.6.4..HEAD" for people wanting it, and
because we already provide a NEWS file already containing all the
valuable information.)
Has anyone (especially distribution maintainers) any patches that could
be integrated in the release?
This 2.6.5 release will certainly be the last in the 2.6 series. After
it, we'll focus on the 2.7.0 release.
--
Julien ?LIE
??La terre ?tant ronde, le kilom?tre devrait ?tre rond et non pas
carr?.?? (Ram?n Gomez de La Serna)
------------------------------
Message: 2
Date: Sun, 2 Jan 2022 21:00:39 +0100
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Parametring cancel processing (Cancel-Lock vs unauthenticated
cancels)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi all,
innd can be started with a flag (-C) to accept and propagate, but *not*
process cancel or supersedes messages. (NoCeM notices are processed
anyway.)
With the upcoming support of Cancel-Lock, should we add a new inn.conf
parameter to enable/disable Cancel-Lock processing?
If INN is compiled without Cancel-Lock support:
- the "-C" flag given to innflags permits disabling the process of any
cancels.
If INN is compiled with Cancel-Lock support:
- Cancel-Lock and Cancel-Key header fields are added by nnrpd if secrets
are set in inn-secrets.conf (otherwise, this feature is disabled);
- the "-C" flag given to innflags permits disabling the process of XXX
(any kinds of cancels, including via Cancel-Lock? only unauthenticated
cancels?)
I would say that "-C" just disables the process of unauthenticated
cancels only. But maybe some people will want to generate locks via
nnrpd but not actually process any cancels (to keep all the articles in
their spool)?
So we would need a "canlockcheck" inn.conf parameter (set to true by
default) to disable innd's processing if wanted.
Any comments about that or a better suggestion of name for the parameter?
--
Julien ?LIE
??La terre ?tant ronde, le kilom?tre devrait ?tre rond et non pas
carr?.?? (Ram?n Gomez de La Serna)
------------------------------
Message: 3
Date: Sun, 2 Jan 2022 21:59:17 +0100
From: Martin Burmester <[email protected]>
To: [email protected]
Subject: Re: Parametring cancel processing (Cancel-Lock vs
unauthenticated cancels)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Julien,
from an admins perspective there are four possible polices regarding
cancels:
1. Execute all cancels, don't check Cancel-Lock. (the default now)
2. Execute no cancels. (with "-C" flag)
3. If the original article is protected by Cancel-Lock, check Cancel-Key
and execute the cancel if it authenticates. If it is not protected by
Cancel-Lock execute in any case.
4. If the original article is protected by Cancel-Lock, check Cancel-Key
and execute the cancel if it authenticates. If it is not protected by
Cancel-Lock, do not execute.
With your idea all four could be achieved without recompiling:
1: canlockcheck=false
2: -C, canlockcheck=false
3: canlockcheck=true
4: -C, canlockcheck=true
Wich would make 3 the new default, which is also a good idea.
But having to configure it in two places and think this through is not
so easy. What about a new parameter, eg. "docancels" with the options
"all", "none", "auth" and "require-auth"?
Cheers,
Martin
Am 02.01.2022 um 21:00 schrieb Julien ?LIE:
> Hi all,
>
> innd can be started with a flag (-C) to accept and propagate, but *not*
> process cancel or supersedes messages.? (NoCeM notices are processed
> anyway.)
>
> With the upcoming support of Cancel-Lock, should we add a new inn.conf
> parameter to enable/disable Cancel-Lock processing?
>
>
> If INN is compiled without Cancel-Lock support:
> - the "-C" flag given to innflags permits disabling the process of any
> cancels.
>
> If INN is compiled with Cancel-Lock support:
> - Cancel-Lock and Cancel-Key header fields are added by nnrpd if secrets
> are set in inn-secrets.conf (otherwise, this feature is disabled);
> - the "-C" flag given to innflags permits disabling the process of XXX
> (any kinds of cancels, including via Cancel-Lock? only unauthenticated
> cancels?)
>
> I would say that "-C" just disables the process of unauthenticated
> cancels only.? But maybe some people will want to generate locks via
> nnrpd but not actually process any cancels (to keep all the articles in
> their spool)?
> So we would need a "canlockcheck" inn.conf parameter (set to true by
> default) to disable innd's processing if wanted.
>
> Any comments about that or a better suggestion of name for the parameter?
>
------------------------------
Message: 4
Date: Sun, 2 Jan 2022 22:28:51 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Parametring cancel processing (Cancel-Lock vs
unauthenticated cancels)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Martin,
> from an admins perspective there are four possible polices regarding
> cancels:
>
> 1. Execute all cancels, don't check Cancel-Lock. (the default now)
> 2. Execute no cancels. (with "-C" flag)
> 3. If the original article is protected by Cancel-Lock, check Cancel-Key
> and execute the cancel if it authenticates. If it is not protected by
> Cancel-Lock execute in any case.
> 4. If the original article is protected by Cancel-Lock, check Cancel-Key
> and execute the cancel if it authenticates. If it is not protected by
> Cancel-Lock, do not execute.
>
> With your idea all four could be achieved without recompiling:
>
> 1: canlockcheck=false
> 2: -C, canlockcheck=false
> 3: canlockcheck=true
> 4: -C, canlockcheck=true
>
> Wich would make 3 the new default, which is also a good idea.
Yes, exactly.
> But having to configure it in two places and think this through is not
> so easy. What about a new parameter, eg. "docancels" with the options
> "all", "none", "auth" and "require-auth"?
I like this idea. I suggest that the default be "require-auth" (4) if
INN was built with Cancel-Lock support, and "all" (1) otherwise.
Or maybe "none" (2) otherwise? We can do that change in the upcoming
major 2.7.0 release.
I also suggest removing the "innd -C" flag, or rather make it a no-op,
as the "docancels" parameter does the same thing, better.
--
Julien ?LIE
??C'est une for?t vierge o? la main de l'homme n'a jamais mis le pied.??
------------------------------
Message: 5
Date: Sun, 02 Jan 2022 13:41:53 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Parametring cancel processing (Cancel-Lock vs
unauthenticated cancels)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> I like this idea. I suggest that the default be "require-auth" (4) if
> INN was built with Cancel-Lock support, and "all" (1) otherwise. Or
> maybe "none" (2) otherwise? We can do that change in the upcoming major
> 2.7.0 release.
I like this idea. I'd default to "none" otherwise (may as well be more
secure by default, and we're allowed to break some compatibility in the
2.7.0 release).
> I also suggest removing the "innd -C" flag, or rather make it a no-op,
> as the "docancels" parameter does the same thing, better.
I think it shouldn't be a no-op; it should either work to override the
config setting or we should remove it so that it will cause an error and
people will have to update their configuration. Otherwise, I think we
risk silent and surprising behavior change.
--
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: 6
Date: Sun, 2 Jan 2022 14:50:10 -0700
From: Grant Taylor <[email protected]>
To: [email protected]
Subject: Re: Parametring cancel processing (Cancel-Lock vs
unauthenticated cancels)
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 1/2/22 2:41 PM, Russ Allbery wrote:
> I think it shouldn't be a no-op; it should either work to override
> the config setting or we should remove it so that it will cause an
> error and people will have to update their configuration. Otherwise,
> I think we risk silent and surprising behavior change.
I too am against the no-op.
I'd much rather see it be a warning for one (or more) versions and
eventually be tantamount to a syntax error to fail hard / fast.
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://lists.isc.org/pipermail/inn-workers/attachments/20220102/402d674b/attachment.bin>
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 137, Issue 1
*******************************************
