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 indentation (Julien ?LIE)
2. Re: Discussion about Cancel-Lock support (Julien ?LIE)
3. Re: Discussion about Cancel-Lock support (Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Sun, 19 Sep 2021 22:11:06 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: INN indentation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
> It's unfortunately a big flag day that breaks backporting of diffs, so
> we'd probably want to do the same thing in both the main and 2.6 branches
> at the same time
I would suggest not to consider that drawback as we can easily state
that the next 2.6.5 release will be the final one in the 2.6 branch.
Then we can only re-indent 2.7 (future STABLE) and leave 2.6 as-is.
Between the time of the CURRENT 2.7 branch re-indenting and the 2.6.5
release, let's just backport only bug fixes to the 2.6 branch. I bet
there won't be many of them or if there are, they will be
straight-forward to backport.
--
Julien ?LIE
??Cela n'a rien de remarquable. Il suffit d'appuyer sur la bonne touche
au bon moment et l'instrument joue tout seul.?? (J.-S. Bach)
------------------------------
Message: 2
Date: Sun, 19 Sep 2021 22:20:56 +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,
>> 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.
>
> Oh, I see. In that case, maybe change extracanlockuser to
> canlockverifyuser? That makes it clearer the extra user is for
> verification only.
It would then look like:
cancels {
canlockuser: [ password ]
canlockverifyuser: [ anotherpassword ]
canlockadmin: [ adminpassword ]
canlockverifyadmin: [ anotheradminpassword ]
}
I am unsure it is clear by only looking at the names of the parameters
that "canlockverifyuser" is for adding another password to verify.
Looks like naively that the canlockuser password should also be set in
canlockverifyuser so as to also be verified (and not solely used for the
initial generation).
People generally do not know how Cancel-Lock works.
Having 4 parameters may appear to be a bad idea (though I initially had
it in mind). Your suggestion of only 2 makes it clearer I think.
During key rotation, both hashes are sent and verified. Simply.
cancels {
canlockuser: [ password anotherpassword ]
canlockadmin: [ adminpassword anotheradminpassword ]
}
seems simpler over all.
--
Julien ?LIE
??Cela n'a rien de remarquable. Il suffit d'appuyer sur la bonne touche
au bon moment et l'instrument joue tout seul.?? (J.-S. Bach)
------------------------------
Message: 3
Date: Sun, 19 Sep 2021 13:28:21 -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:
> Having 4 parameters may appear to be a bad idea (though I initially had it
> in mind). Your suggestion of only 2 makes it clearer I think. During key
> rotation, both hashes are sent and verified. Simply.
> cancels {
> canlockuser: [ password anotherpassword ]
> canlockadmin: [ adminpassword anotheradminpassword ]
> }
> seems simpler over all.
Yeah, I agree. Unless there's a strong reason to not send the hash for
the key being retired (and I'm not seeing one), I think the above is
simpler.
--
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 12
********************************************
