<div dir="ltr">I concur with this plan.<div><br></div><div>Everyone, as you explore in the code, if you whitebox find potential issues, please put them in the gitlab issue tracker, and also post them to <a href="mailto:devel@ntpsec.org">devel@ntpsec.org</a>. If the fix would be a pointfix and very low risk, we will fix immediately. Otherwise, it will wait until bisect and testframe work.</div><div><br></div><div>Also, with any luck, we will be getting comments and merge request contributions on GitLab and GitHub. I'm not going to preassign reviewers, so please just pick them up as they come in, and ping them over to who makes the most sense to look at them. Again, if they are low risk pointfixes, we will land them immediately, otherwise they wait until after bisect and testframe.</div><div><br></div><div>I have a followup to write about our outstanding embargos. Expect it soon. I will also keep working on formalized release and version polices to write into the hacking guide, and more work on infosec security policy docs, which are currently in gdocs, and will migrate into our docs and website repos.</div><div><br></div><div>..m</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 17, 2015 at 10:02 AM Eric S. Raymond <<a href="mailto:esr@snark.thyrsus.com">esr@snark.thyrsus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here is how I see the road towards 1.0.<br>
<br>
In laying out this plan, I'm going to make the optimistic assumption<br>
that nobody comes back at us with a report that we've screwed up<br>
something complicated and have to scramble to recover.<br>
<br>
On that assumption, I think we're looking at six to eight weeks to 1.0,<br>
with two or maybe three 0.9.x betas in between. For funding-politics<br>
reasons, six would be better than eight - CII wants to see velocity,<br>
and we ought to be able to deliver it.<br>
<br>
The core C codebase (that is, excluding tests) appears to be in good<br>
shape. Putting it on a serious reduction diet seems to have done it no<br>
real harm, and quite a lot of good in the maintainability department.<br>
I have no real worries about it other than that one unreproduced<br>
report of an ntpdig coredump from Hal.<br>
<br>
Other than currently embargoed vuln fixes, he only core C change that<br>
I think really needs to land before 1.0 is Chris's rewrite of the<br>
worker code for handling getaddrinfo() requests. That will fix an<br>
annoying bug that we inherited from Classic and make us look good.<br>
<br>
The unit tests are a different matter. It's *bad* that we shipped<br>
with only 20% of them working. That needs to be fixed ASAP and<br>
should in my opinion be top priority for 0.9.1.<br>
<br>
Myself, I think I badly need to get working on TESTFRAME and<br>
concentrate on it. It's absolutely central to our strategy and<br>
positioning that the code be able to demonstrate replicability and<br>
end-to-end correctness.<br>
<br>
That means I need to be able to offload everything but five-alarm<br>
vuln responses onto other people. It's time for that anyway; it's<br>
not really long-term healthy for just one person to be doing 85%<br>
of the coding, it means others are not developing enough implicit<br>
knowledge to sustain the project if that one person gets hit by<br>
a truck.<br>
<br>
So start spelunking, people! And thank your fortunate stars that<br>
I sandblasted most of the accreted historical crud off the code<br>
before you had to look at much of it. Later in this note I'll<br>
list some get-to-know-the-C-code tasks.<br>
<br>
Here's how I think the pre-1.0 tesks naturally break down. Mark<br>
may correct my priority assessments...<br>
<br>
Daniel Franke:<br>
1. Vuln response, embargo tracking. Your #1 job is to make sure<br>
that we look *golden* to InfoSec people, merging solid vuln fixes<br>
to the main repo the day they come out of embargo.<br>
2. Explore. You are at or near the top of my list of people most<br>
qualified to get intimate with the time-sync algorithms. A<br>
prerequisite is that you become comfortable with the codebase<br>
as it is.<br>
<br>
Chris Johns:<br>
1. Asynch worker code for getaddrinfo bug. Should land in a beta.<br>
2. Windows port work. Port not required for 1.0 - take your time,<br>
get it right, no kludges.<br>
3. Explore. You are one of the people I am counting on to get<br>
fluent with the codebase and do things that surprise me.<br>
<br>
Hal Murray:<br>
1. Live testing. You are going to be our most important reality<br>
check until TESTFRAME lands and probably after it as well.<br>
2. Bring the ports to older BSDs up to snuff. Not absolutely<br>
necessary for 1.0 but would be nice.<br>
3. Watch what Classic is doing. Alert us of the need to cross-port<br>
new bug and security fixes.<br>
4. Feature vs. test status matrix.<br>
<br>
Me:<br>
1. TESTFRAME. I should be able to finish at least capture mode before 1.0.<br>
2. Replay branch construction (gated on one of Amar's tasks).<br>
<br>
Joel Sherrill:<br>
You don't have a record yet, so I have no idea what you ought to<br>
be doing. Maybe you can come up with something.<br>
<br>
Amar Takhar:<br>
1. Make all the unit tests work.<br>
2. Backport the waf port so it works at the fork point (needed for<br>
replay branch construction).<br>
<br>
If I've missed anything, or any of you has any objection to these<br>
assignments, speak up so we can allocate more efficiently. I encourage<br>
everyone to reply with time and difficulty assessments.<br>
<br>
Explanation of replay branch construction: Right now, due to<br>
occasional build breakage and general autoconf horribleness,<br>
running bisections all the way back to the fork point is hard.<br>
<br>
I want to fix that - making sure we can easily isolate bugs on<br>
our backtrail is the best anti-Murphy medicine against actually<br>
*having* bugs on our backtrail.<br>
<br>
Thus, I want Amar to start a new branch from the fork point that<br>
builds the codebase as it then existed with waf. I will then replay<br>
the post-fork commit history onto the branch; I expect this to be<br>
about 4 or 5 days of hard slogging.<br>
<br>
At the end of it we'll have a new master branch with no build breaks<br>
that can be bisected fast all the way back to its zero point. Among<br>
other good things, this will give us the ability to say of inherited<br>
bugs "We didn't do it!" and *prove* that.<br>
<br>
Now, for intrepid codebase explorers out there, some C tasks that I am not<br>
planning to do because TESTFRAME:<br>
<br>
* seccomp sandboxing fails to build under Ubuntu due to some confusion<br>
in the Linux headers. Investigate.<br>
<br>
* systime.c needs patching to put ntpdsim's hook back in place. Deferred<br>
until the ntpdsim build is fixed.<br>
<br>
* There is a mess around the symbols NO_MAIN_ALLOWED, BUILD_AS_LIB, and<br>
LIBNTP_C that needs to be refactored. ntpd should *always* be built as<br>
a library linked to a main module, these guard symbols should go away.<br>
<br>
* Use the snprintb in util/ntptime for flag words like flash<br>
codes and use it systematically to make reports more readable.<br>
--<br>
<a href="<a href="http://www.catb.org/~esr/" rel="noreferrer" target="_blank">http://www.catb.org/~esr/</a>">Eric S. Raymond</a><br>
<br>
The two pillars of `political correctness' are,<br>
a) willful ignorance, and<br>
b) a steadfast refusal to face the truth<br>
-- George MacDonald Fraser<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@ntpsec.org" target="_blank">devel@ntpsec.org</a><br>
<a href="http://lists.ntpsec.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ntpsec.org/mailman/listinfo/devel</a><br>
</blockquote></div>