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@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
_______________________________________________
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
