NTPsec 1.2.2a released

[Richard Laager]

On 2023-08-07 15:13, Fred Wright via devel wrote:
> 
> On Fri, 4 Aug 2023, James Browning via devel wrote:
>>> On 08/04/2023 6:35 PM PDT Fred Wright via devel <devel at ntpsec.org> 
>>> wrote:
>>>
>> :::snip:::
>>>
>>> I notice that the two commits for that don't seem to be in any branch.
>>> Having commits only "owned" by a tag and not a branch seems fragile.
>>
>> I do not think it is particularly fragile; I mean the garbage
>> collector is that aggressive, is it?
> 
> It's not just about the garbage collector.  Git's general philosophy is 
> that non-transient commits are exepected to exist on at least one 
> branch

I'm not sure that I agree with that. In git, unlike other VCSs, commits 
are not part of a branch. A branch just points to a commit, which is 
then definitionally the head of that branch. A branch in git is 
basically like a tag that moves around.

>> That said, I did advocate for merging it back in to master (as a 
>> no-op). But I don't feel particularly strongly about that.
> 
> Attempting to merge it into master now would just result in a conflict 
> that would have to be resolved by turning it into an empty commit (and 
> giving git explicit permission to do that).

The commit will not be empty.

git checkout master
git merge NTPsec_1_2_2a

# Undo the change to VERSION
# Resolve the merge conflict in ntpd/nts_cookie.c in favor of HEAD.
# Resolve the merge conflict in NEWS by keeping both bits.

There will be a merge conflict, of which the code change can be thrown 
away, but the commit will not be empty. There will remain changes to the 
NEWS file.

The resulting commit has these changes relative to master before you 
started:

diff --git a/NEWS.adoc b/NEWS.adoc
index 276f41c83..86170323e 100644
--- a/NEWS.adoc
+++ b/NEWS.adoc
@@ -34,6 +34,11 @@ on user-visible changes.

  * ntpdig shows packet delay in JSON output.

+## 2023-08-02: 1.2.2a
+
+Fix a crash in ntpd if NTS is disabled and an NTS-enabled client 
request (mode
+3) is received. (CVE-2023-4012)
+
  ## 2022-12-28: 1.2.2

  * Restore/cleanup NTPv1 support
diff --git a/VERSION b/VERSION
index 23aa83906..0495c4a88 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-1.2.2
+1.2.3

> The real problem at that level is that the patch wasn't originally 
> created via "git cherry-pick"

git cherry-pick wouldn't have changed anything about the branch/tag 
situation. Using cherry-pick is fundamentally the same as using diff and 
patch. It doesn't preserve any metadata.

> which is because the original master 
> commit combined multiple changes into one commit.  This is one example 
> of why that should be avoided.
It's only in hindsight that one can say the original commit combined 
multiple changes. At the time the original commit was made, Hal wasn't 
aware of this problem.

I might quibble a bit more about commit 
d9a786fe0fafa7ed7357783798b1f206884d28b7, though. That ideally should 
have been the commit that we shipped as 1.2.2a and then the other half 
adding the counters for it.

-- 
Richard