[Git][NTPsec/ntpsec][master] Address issue #268: Waf uses current date and time breaking repro builds

[Eric S. Raymond]

Eric S. Raymond pushed to branch master at NTPsec / ntpsec


Commits:
4e23794c by Eric S. Raymond at 2017-04-16T14:41:38-04:00
Address issue #268: Waf uses current date and time breaking repro builds

- - - - -


1 changed file:

- devel/packaging.txt


Changes:

=====================================
devel/packaging.txt
=====================================
--- a/devel/packaging.txt
+++ b/devel/packaging.txt
@@ -9,11 +9,10 @@ and boilerplate for default ntpd configuration.
 == Platforms without Python ==
 
 Many tools (actually, almost everything except the core daemon itself)
-have either been moved from C to Python or are in the process of
-translation.  This is an important step for improving maintainability
-and reducing attack surface.  However, we know that some platforms
-cannot support Python or choose not to include it in their core
-configuration.
+have been moved from C to Python. This is an important step for
+improving maintainability and reducing attack surface.  However, we
+know that some platforms cannot support Python or choose not to
+include it in their core configuration.
 
 For these platorms, we recommend using cx_Freeze to render the NTPsec
 Python programs, and all their imported modules, into standalone files.
@@ -49,5 +48,56 @@ not have Python installed and execute the programs there.
 There appears to be no speed advantage, or disadvantage, to running the
 binaries created by cx_freeze.
 
+== Non-reproducible builds ==
+
+Many Linux distributions now want binary-package builds to be fully
+reproducible - that is, the same sources always produce identical
+output.
+
+NTPsec *cannot* do this.  There are specific reasons it cannot.
+
+== Cross-era interoperability in modular calendar arithmetic ==
+
+The protocol necessarily uses time/date stamps of finite length in
+order to fit into fixed-size fields; they happen to have a 136-year
+cycle, but the problems this produces aren't dependent on the specific
+cycle length.  Thus, each instance of ntpd speaks time based on a
+specific epoch (cycle start date).  The epoch of era 0 was at the
+beginning of 1900; the epoch of era 1 will be in 2036.
+
+Two instances talking to each other have no way to know that they're
+based in the same era. To mitigate this problem, each instance
+has a pivot date and resolves incoming timestamps to the era that
+minimizes distance between now and the timestamp.  This procedure
+is part of the core protocol specification.
+
+An instance's pivot time is constructed from __TIME__/__DATE__ and
+thus binaries are intrinsically non-reproducible.  Any
+alternative to this most recent possible pivot would decrease
+the span of time in the future over which it can achieve timebase
+synchronization with instances from later eras, degrading function.
+
+== Disambiguation of NMEA dates ==
+
+Due to bad design of NMEA0183, the reporting protocol used by many
+GPS sensors, the NMEA driver in NTPsec sometimes has to make an
+assumption about what century it is.  Choice of a base-century
+hits the saame issues; using anything other than __TIME__/__DATE__
+would decrease the future span over which the driver's assumption
+is correct.  The alternative - trusting the system clock to report
+the right century - could produce very bad behavior near century
+boundaries.
+
+== Unpredictable leap seconds ==
+
+On first startup (that is, before it can fetch a leapsecond file)
+NTPsec also needs to make an assumption about UTC's offset from TAI.
+To do this it captures that offset at build time, again implying
+nonreproducibility of builds in the prsens of leap-offset bumps.
+
+Again, any attempt to change this would necessarily increase risks 
+by shortening the span over which an ntpd instance will speak correct
+UTC in the future.
+
 // end
 



View it on GitLab: https://gitlab.com/NTPsec/ntpsec/commit/4e23794c37f6053fb2210831c27066059114ee58

---
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/commit/4e23794c37f6053fb2210831c27066059114ee58
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/vc/attachments/20170416/f0f464ba/attachment.html>