Re: NTS AEEF extension confusion

[Daniel Franke via devel]

The translation of the AEEF ciphertext into corresponding plaintext is
given by the negotiated AEAD algorithm; for AES-SIV, by RFC 5297. The
structure of the plaintext is defined in the draft, as a concatenation of
RFC 7822 extension fields.

On Sun, Jun 23, 2019, 16:42 Ian Bruene via devel  wrote:

>
> While working on the NTS test code I have reached a point where I know
> that I am misunderstanding *something*, but do now know what.
>
> According to the RFC the AEEF "ciphertext" field looks like it is a
> generally usable data blob for extension data. Variable size, no specific
> data, etc.
>
> According to the code the AEEF "CMAC" field which is in the same spot
> looks like a fixed length data blob with a very specific meaning.
>
> These do not match up, and I do not know what I am missing.
>
> --
> *"In the end; what separates a Man, from a Slave? Money? Power? No. A Man
> Chooses, a Slave Obeys."* -- Andrew Ryan
>
> *"Utopia cannot precede the Utopian. It will exist the moment we are fit
> to occupy it."* -- Sophia Lamb
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Driver strategy - we need to decide among incompatible goals

[Daniel Franke via devel]

Option 2. If the manufacturer won't support the product any more, we
shouldn't either.

On Thu, Aug 8, 2019 at 8:36 AM Eric S. Raymond via devel
 wrote:
>
> Issue #608, "Future need for oncore GPS driver", foregrounds a product
> strategy question we need to make a decision about.
>
> In the early days of this project, we had a conflict between two objectives:
>
> 1. In order not to upset the NTP Classic userbase, support whatever
> old hardware we can determine they still care about.
>
> 2. Remove support for device classes that pose an unacceptable
> security risk, e.g. by requiring proprietary binary blobs to be
> linked to the kernel.
>
> We resolved that one by removing a couple of risky drivers. We never
> got any pushback at all about this.
>
> I wrote about this bit of history because it's a precedent for
> narrowing our hardware support in order to improve our security
> and reduce our expected downstream defect rate.
>
> You're all aware that there is a nasty swamp of error states around
> three problems: (1) Two-digit year reporting from some devices
> (including NMEA GPSes that don't ship GPZDA), (2) wraparound
> in date reporting - devices with a time counter of limit size
> (including GPses) can wrap around at any time and start reporting
> dates in the far past, and (3) NTP era rollovers (one coming in
> 2036).
>
> NTPsec aims to be highly secure and reliable.  If we're serious about
> that, we need to reduce our vulnerability to defects from these
> wraparound/rollover problems.
>
> There's a related issue about running autonomously, e.g with only
> local GPSes or clock radios and no upstream NTP servers.  Used to be
> you couldn't do this.  In 2017 I figured out why and fixed it. But
> the ability to run automomous depends on your clocks shipping full
> 4-digit years.
>
> After doing this, I marked every driver type that could only ship
> 2-digit years deprecated. That set is Arbiter, certain modes of the
> Generic driver, certain modes of the JJY driver, certain modes of the
> Modem driver, the Neoclock driver, the Oncore driver, and the
> Spectracom Type 2 driver.  NMEA GPSes sometimes report a 4-digit year
> (if they ship GPZDA) and sometimes don't.
>
> My thinking was that we would eventually drop all of the 2-digit-only
> modes and drivers, and say "if your refclock doesn't ship 4-digit
> years, it's disqualified".  Besides the autonomy issue, devices with
> this quirk are often very old hardware with wraparound problems.
>
> Now we have a request to remove the deprecation marker from the Oncore
> driver. The Oncore product line is EOL, but we are told there are
> receivers still in production that can use this driver.
>
> We have a couple of possible responses to this problem.  Which one we
> choose depends on what our priority is.
>
> 1. If our highest priority is not annoying anyone whose hardware
> support expectations were formed by NTP Classic, then yes, we should
> un-deprecate Oncore.
>
> 2. If we think our actual customers consider replacing hardware a
> trivial cost and would prefer correctness and autonomy guarantees,
> we shoot *all* the 2-digit-year drivers and modes through the head.
>
> 3. Compromise. Support drivers and modes that only ship two-digit
> years but require the user to somehow configure their
> century/wraparound state.
>
> This is really a product-strategy decision about which group of
> cutomers we want to put first.  The Ciscos and AWSes and Azures of
> the world do not care about keeping 20-year-old clocks running with
> potentially dodgy patches for wraparound problems.  Hobbyists care
> about that a lot. Some potential project contributors are hobbyists,
> which gives us some reason to care aout them.
>
> If it were up to me alone, I'd go with (2) - correctness and autonomy
> over supporting old hardware.  The compromise (3) looks attractive
> at first sight, but I am wary of "add a config option" patches;
> they add complexity and get you grief from misconfigurations.
>
> Also present in my thinking is that if we go with (2) we get to drop
> more lines of code and further reduce attack surface.  This is
> always a good thing.
>
> Discuss...
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> "Gun control" is a job-safety program for criminals.
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Future directions

[Daniel Franke via devel]

On Mon, Sep 16, 2019, 22:50 Hal Murray via devel  wrote:

>
> The disadvantage of SHM is that there is no way to wake up a reader when
> new
> data is available.  Readers have to poll.
>

This is exactly what futexes are for.

>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Another server at Netnod, bug fix

[Daniel Franke via devel]

This is a security bug and needs a point release and a CVE.

On Tue, Oct 29, 2019, 05:06 Hal Murray via devel  wrote:

>
> Announcement below.
>
> It triggered a bug.  When copying the hostname out of the NTS-KE server
> response, I forgot to add a NUL.  I assume we tested that code.  I guess
> we
> were lucky.
>
> I just pushed a fix.
>
> 
>
> Subject: [Ntp] NTS enabled NTP service up and running at Netnod
> From: Patrik Fältström  
> Date: Tue, 29 Oct 2019 06:28:41 +0100
> To: n...@ietf.org
>
> Hi,
>
> This is slightly off topic for the IETF WG, but as people that are implem=
> enting NTS enabled NTP is hanging around here, I want to send a notice th=
> at we at Netnod have launched an NTS enabled NTP service.
>
>  nts-enabled-time-services-in-the-world
> 
> >
>
> We are very happy to have reached this far.
>
> Instrumental people for this are the ones you all know: Christer, Ragge, =
> Marcus and MC. To be added are all friends that have participated in the =
> hackatons on the client side. Specifically Daniel Lublin and Martin Samue=
> lsson.
>
> And you in this group that have worked together to get the NTS specificat=
> ion this far down the road. Now we "just" have a few steps to go.
>
>Regards, Patrik
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: [PATCH] ALPN validation fix

[Daniel Franke via devel]

On Sun, Dec 8, 2019 at 7:58 AM Hal Murray via devel  wrote:

> The current code now requires ALPN if using TLSv1.3.  ***

Why only TLS 1.3? The spec makes it mandatory for all versions.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: [PATCH] ALPN validation fix

[Daniel Franke via devel]

On Sun, Dec 8, 2019 at 9:15 AM Hal Murray  wrote:
> Because ALPN is not supported by TLSv1.2

Nonsense. ALPN predates TLS 1.3 by several years and RFC 7301 doesn't
even restrict it to TLS 1.2 and up; it even can support 1.0.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: cloudflare refers NTS users to wrong page

[Daniel Franke via devel]

I've forwarded your message to Watson Ladd.

On Mon, Dec 9, 2019, 17:38 Paul Theodoropoulos via devel 
wrote:

> I just noticed that Cloudflare's documentation for NTS -
>
> https://developers.cloudflare.com/time-services/nts/usage/
>
> links to the NTPsec quickstart page -
>
> https://docs.ntpsec.org/latest/quick.html
>
> which only discusses NTP, rather than NTS.
>
> The correct destination would be
>
> https://docs.ntpsec.org/latest/NTS-QuickStart.html
>
> If anyone has a contact over at cloudflare, you might ask them to correct
> this...
>
> --
> Paul Theodoropouloswww.anastrophe.com
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>

On Mon, Dec 9, 2019, 17:38 Paul Theodoropoulos via devel 
wrote:

> I just noticed that Cloudflare's documentation for NTS -
>
> https://developers.cloudflare.com/time-services/nts/usage/
>
> links to the NTPsec quickstart page -
>
> https://docs.ntpsec.org/latest/quick.html
>
> which only discusses NTP, rather than NTS.
>
> The correct destination would be
>
> https://docs.ntpsec.org/latest/NTS-QuickStart.html
>
> If anyone has a contact over at cloudflare, you might ask them to correct
> this...
>
> --
> Paul Theodoropouloswww.anastrophe.com
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: [Ntp] Last Call:

[Daniel Franke via devel]

Hal,

Yes, we'll be getting a new port number, but the more important item
for IANA is the NTP extension registry. I know NTPsec and several
other NTS implementations are all squatting on a set of EF type
numbers and we probably don't want these to change. You and other
maintainers should coordinate in asking IANA to make these assignments
official.

On Fri, Feb 14, 2020 at 2:26 PM Hal Murray via devel  wrote:
>
>
> > The IESG plans to make a decision in the next few weeks, and solicits final
> > comments on this action.
>
> I assume we are going to want to do a release as soon as the  RFC is official.
>
> Looks like it will get a new port number so we'll need to do a release to
> support that.  What else do we need to do?
>
> The python stuff is broken.  See #642
> I'd like to see #547 get fixed.
>
> ---
>
> Subject: [Ntp] Last Call:  (Network
>  Time Security for the Network Time Protocol) to Proposed Standard
> From: The IESG 
> Date: Fri, 14 Feb 2020 06:46:16 -0800
> To: "IETF-Announce" 
> Cc: ntp-cha...@ietf.org, n...@ietf.org,
> draft-ietf-ntp-using-nts-for-...@ietf.org,
> "Karen O'Donoghue" , sur...@kaloom.com
>
> The IESG has received a request from the Network Time Protocol WG (ntp) to
> consider the following document: - 'Network Time Security for the Network
> Time Protocol'
>as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-c...@ietf.org mailing lists by 2020-02-28. Exceptionally, comments may
> be sent to i...@ietf.org instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>This memo specifies Network Time Security (NTS), a mechanism for
>using Transport Layer Security (TLS) and Authenticated Encryption
>with Associated Data (AEAD) to provide cryptographic security for the
>client-server mode of the Network Time Protocol (NTP).
>
>NTS is structured as a suite of two loosely coupled sub-protocols.
>The first (NTS-KE) handles initial authentication and key
>establishment over TLS.  The second handles encryption and
>authentication during NTP time synchronization via extension fields
>in the NTP packets, and holds all required state only on the client
>via opaque cookies.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
> rfc5297: Synthetic Initialization Vector (SIV) Authenticated Encryption
> Using the Advanced Encryption Standard (AES) (Informational - IETF stream)
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: warnings from libaes on Fedora 32

[Daniel Franke via devel]

There's nothing to fix. It's the just optimizer telling you it'd rather not
inline a function that was declared inline. Which is fine, it doesn't
affect correctness.

On Wed, Apr 29, 2020 at 8:32 PM Hal Murray  wrote:

>
> What's the right fix for this?
> gcc (GCC) 10.0.1 20200328 (Red Hat 10.0.1-0.11)
>
> ../../libaes_siv/aes_siv.c: In function ‘AES_SIV_EncryptFinal’:
> ../../libaes_siv/aes_siv.c:385:19: warning: inlining failed in call to
> ‘do_s2v_p’: --param max-inline-insns-single limit reached [-Winline]
>   385 | static inline int do_s2v_p(AES_SIV_CTX *ctx, block *out,
>   |   ^~~~
> ../../libaes_siv/aes_siv.c:470:21: note: called from here
>   470 | if(UNLIKELY(do_s2v_p(ctx, &q, plaintext, len) != 1)) {
>   | ^
> ../../libaes_siv/aes_siv.c:52:41: note: in definition of macro
> ‘UNLIKELY’
>52 | #define UNLIKELY(cond) __builtin_expect(cond, 0)
>   | ^~~~
> ../../libaes_siv/aes_siv.c: In function ‘AES_SIV_DecryptFinal’:
> ../../libaes_siv/aes_siv.c:385:19: warning: inlining failed in call to
> ‘do_s2v_p’: --param max-inline-insns-single limit reached [-Winline]
>   385 | static inline int do_s2v_p(AES_SIV_CTX *ctx, block *out,
>   |   ^~~~
> ../../libaes_siv/aes_siv.c:513:21: note: called from here
>   513 | if(UNLIKELY(do_s2v_p(ctx, &t, out, len) != 1)) {
>   513 | if(UNLIKELY(do_s2v_p(ctx, &t, out, len) != 1)) {
>   | ^~~
> ../../libaes_siv/aes_siv.c:52:41: note: in definition of macro
> ‘UNLIKELY’
>52 | #define UNLIKELY(cond) __builtin_expect(cond, 0)
>   | ^~~~
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Has anybody seen a system without STA_NANO?

[Daniel Franke via devel]

It's present on Linux, FreeBSD, NetBSD, and Darwin. It's absent on
Solaris and IllumOS.

On Tue, Aug 25, 2020 at 8:03 PM Hal Murray via devel  wrote:
>
>
> When was clock_gettime and struct timespec introduced?
>
> We can cleanup some cruft if we assume it exists.
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Has anybody seen a system without STA_NANO?

[Daniel Franke via devel]

clock_gettime is. Adjtimex isn't in any standard except for an obscure RFC
that nobody follows.

On Tue, Aug 25, 2020, 20:47 Eric S. Raymond via devel 
wrote:

> Hal Murray via devel :
> >
> > When was clock_gettime and struct timespec introduced?
> >
> > We can cleanup some cruft if we assume it exists.
>
> Assune it.  These are in the Single Unix Standard.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Release gymnastics

[Daniel Franke via devel]

The normative content of the RFC is not going to change. There's no
reason to hold back any release while waiting for publication.

On Fri, Sep 18, 2020 at 11:43 AM Hal Murray via devel  wrote:
>
>
> Maybe we should get 1.2 out now/soon so it will be ready when the RFC comes
> out rather than shortly after.
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Blog announcing NTS

[Daniel Franke via devel]

I've already said yes, but the yes was contingent on IANA fixing an
error in a descriptive field so the change in the datatracker is
waiting on that happening.

On Tue, Sep 22, 2020 at 7:35 PM Hal Murray via devel  wrote:
>
> Subject: Re: Coordinating some blog posts celebrating the publication of NTS
> From: Watson Ladd 
> Date: Tue, 22 Sep 2020 13:02:06 -0400
> To: Hal Murray 
> Cc: Susannah Gray , "Karen O'Donoghue" ,
> Patrik Fältström ,
> Miroslav Lichvar ,
> Dieter Sibold ,
> "Langer, Martin" ,
> Marcus Dansarie ,
> Daniel Franke ,
> "kristof.teic...@ptb.de" ,
> Ragnar Sundblad , Phil Roberts ,
> Johanna Eriksson 
>
> So right now it looks like Daniel Franke is the last author who needs
> to say yes. Please share the URLs you want us to point to before then!
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: #ifdef cruft in Go/Rust

[Daniel Franke via devel]

Rust uses cfg attributes for most such things.

https://doc.rust-lang.org/rust-by-example/attribute/cfg.html

On Sun, Jun 20, 2021, 21:12 Hal Murray via devel  wrote:

>
> How do Rust and/or Go handle the cruft that C coders use #ifdefs for?
>
> Does that just get pushed down to a C library?
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Interleaved Mode (Was: Re: Using Go for NTPsec)

[Daniel Franke via devel]

On Tue, Jul 6, 2021 at 1:40 PM Richard Laager via devel
 wrote:
>
> On 7/5/21 8:38 AM, Eric S. Raymond via devel wrote:
> >> There is a close-to-RFC to handle this area.  "Interleave" is the 
> >> buzzword.  I
> >> haven't studied it.  The idea is to grab a transmit time stamp, then tweak 
> >> the
> >> protocol a bit so you can send that on the next packet.
>
> > Daniel discovered it was broken and removed it from the protcol machine.
>
> Broken implementation or broken design? If the latter, is the current
> IETF proposal (wherever that is) still broken?

It was a completely broken implementation of a seriously flawed
design. See 
https://mailarchive.ietf.org/arch/msg/ntp/u5D_-IIeFVnj2j_PMvbW-48nd8Y/
for my critique of the proposed standard.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Time to plan for 1.0

[Daniel Franke via devel]

If we're aiming for a September 28 release then I propose we should
have a dev freeze by September 1. Bug fixes only during that month;
anything that's mere polishing goes on a branch.

I don't want to release 1.0 without having
https://tools.ietf.org/html/draft-ietf-ntp-data-minimization-01
implemented. As of the last IETF meeting I'm confident that there
aren't going to be any significant normative changes before it's
finalized. I'll make the time for this before my proposed September 1
freeze.

On 8/7/17, Eric S. Raymond via devel  wrote:
> Summary:
>
> * We need to start working towards a 1.0 release no later than 28
> September.
>
> * I need our senior devs to identify any release-blocker issues
>   and tell me what they think our pre-release priorities should be.
>
> Details:
>
> On Saturday, I had a phone conversation with Mark Atwood during which
> he apologized to me and the team for being pretty absent recently.  I
> assured him that we all get it about a adjusting to a senior position
> at Amazon being enough to eat anyone's bandwidth.
>
> Then yesterday (Sunday), at an ICEI planning meeting, Susan Sons
> revealed a hard deadline for an NTPsec 1.0 release.  For fundraising
> purposes she needs it to be out by the O'Reilly infosec conference on
> 28 October.
>
> If I had believed that Mark was going to be back on stream in the near
> future I would have left it to him to respond.  As it is, and
> considering my evaluation of the state of the project, I assured Susan
> that Oct 28 was doable and committed us to it.
>
> Since Mark and I were previously discussing an end-of-summer release
> date, I doubt he will object. If and when Mark becomes available I
> will cheerfully defer to his judgment about state of readiness and
> release timing, if we have not already shipped.  In the mean time,
> I'll step up.
>
> This might have been a tougher call, but since early summer we've
> basically been polishing (Ian's AgentX work will be a nice-to-have but
> I do not regard it as essential for a 1.0 release).  I experimentally
> faded out of view for a couple of weeks to find out if the project
> would stall or hit serious difficulty without my hand on things.  It
> didn't.  I found that reassuring.
>
> Accordingly, I told Susan that if she needed us to ship a week from
> *now*, it would be a bit hair-raising but doable. I've seen nothing on
> the issue list that I think is a blocker.  But I need our devs to tell
> me if I'm missing anything, and what set of priorities we should put
> on pending work.
>
> I'd like to aim for no later that 28 September.  That way we'll be
> able to report not just first ship but a month of field experience.
>
> If anyone thinks my assumptions are incorrect, speak up quickly,
> please.  Otherwise let's ID what we need to get done and do it.  I
> actually think we ought to be fully able to ship in three weeks
> (that is, around 28 August); let's try for that.
>
> Gary, Hal, Matt, Daniel: Would all of you check in on this, please?
> --
>   http://www.catb.org/~esr/";>Eric S. Raymond
>
> Non-cooperation with evil is as much a duty as cooperation with good.
>   -- Mohandas Gandhi
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Blue-sky thread - ideas for well after 1.0

[Daniel Franke via devel]

There aren't many deficiencies in NTPv4 which can't be fixed by adding
extension fields. A change big enough to make a version bump
worthwhile would incorporate at least most of the following:

1. Drop everything other than client/server mode. Replace mode 6 with
something that runs over HTTPS on the NTS-KE port.

2. Let client and server packets be formatted differently. Achieve
data minimization by just taking the unnecessary fields out of client
packets altogether.

3. Forbid use of the legacy MAC field, thus fixing the hairiness
around extension parsing.

4. Make NTS mandatory. In the NTPv5 packet format, the version, mode,
NTS unique identifier, and (in client packets) NTS cookie come first
in plaintext, then the whole rest of the packet is encrypted.

5. Ditch the useless poll, stratum, refid, and reference timestamp
fields. Given that all of the above are implemented, origin timestamp
also becomes redundant (NTS takes the place of its anti-spoofing
role).

6. Represent timestamps as days, seconds, and fractions so that the
time can be represented unambiguously during leap seconds. Make the
day field 64 bits wide so that its range comfortable exceeds the
lifespan of the solar system.

7. Don't implement leap smearing in the wire protocol (servers should
always report accurate, unsmeared time), but standardize a formula for
translating NTP time into smeared UNIX time seen by other
applications.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Blue-sky thread - ideas for well after 1.0

[Daniel Franke via devel]

On 8/26/17, Hal Murray  wrote:

> Is there a good high-level writeup of NTS?

https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-09#section-1.2

> Why encrypt stuff?  (as compared to verify)

NTS authenticates everything and encrypts as much as possible without
breaking backward compatibility and middleboxes. Encryption is mostly
for privacy -- prevent leaking anything that could permit tracking of
mobile systems. Data minimization already solves 99% of this, but
since adding encryption is basically free, it should be the default
anytime there's not a particular reason you *want* middleboxes to be
able to snoop traffic.

> Are there any useful techniques for monitoring or debugging encrypted
> traffic?

Log encryption keys, or the plaintext itself, at endpoints. If you
don't have endpoint cooperation, then inability to extract debug info
is a feature, not a bug.

> 64 bits of days seems like way overkill.  32 bits of days is over 23 bits of
>
> years.  Are you really worried about more than a million years?

It certainly won't be *my* problem. But either way, packets, not bits,
are the bottleneck. NTP messages fit in one packet either way. The
extra 32 bits are free.

> Should the wire protocol use a non-leap time scale?  (and include the offset
>
> to UTC)

Either way, I favor including UTC-TAI offset as a field. But even
given that, providing timestamps as UTC rather than TAI gives more
information, since it enables conversion to calendar date & time
without needing a full leap table.

> That's the tip of an iceberg for getting POSIX to get their leap out of the
> sand.

Yeah, POSIX time sucks, but that's a separate problem. My proposal
allows NTP to do things the right way, while at same time translating
into POSIX with as much fidelity as it's capable of representing.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: ntpsec vulnerabilities / latest ntp round

[Daniel Franke via devel]

CVE-2018-7182 only.

On Tue, Mar 6, 2018 at 3:10 PM, Richard Laager via devel
 wrote:
> I tried this to security-discuss, but I'm not sure if it went through:
>
> The Debian security team has asked me which of the February 2018
> ntp-4.2.8p11 vulnerabilities apply to NTPsec:
>
> http://support.ntp.org/bin/view/Main/SecurityNotice#Recent_Vulnerabilities
>
> --
> Richard
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: The libaes_siv dependency

[Daniel Franke via devel]

You probably don't want to auto-pull the latest HEAD every time it gets an
update; only releases get the full battery of QA. Note I'll probably be
stamping a release this weekend since the last release from two years ago
has a build issue with more recent OpenSSL versions.

On Thu, Feb 14, 2019, 17:05 Eric S. Raymond via devel  Hal Murray :
> > Did you fix the CI checks?
> >
> > Is anybody working on fixing libeas_siv to build on NetBSD?  Until that
> is
> > fixed, we won't build on NetBSD.
>
> Yikes!  I forgot about the CI - I almost never have to modify it.
>
> Matt Selsky maintains that YAML file.  I've pinged him on IRC. We';ll
> figure out how to modify it so it clones Daniel's repo and makes the
> library in tha environment.
>
> Then we can work on the NetBSD port problem.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> My work is funded by the Internet Civil Engineering Institute:
> https://icei.org
> Please visit their site and donate: the civilization you save might be
> your own.
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: The libaes_siv dependency

[Daniel Franke via devel]

Release tags match v.., so just check the tag list for
the most recent v1.y.z. Don't automatically go to 2.anything since releases
are semantically versioned and that would indicate backward-incompatibility.

On Thu, Feb 14, 2019, 17:24 Eric S. Raymond  Daniel Franke :
> > You probably don't want to auto-pull the latest HEAD every time it gets
> an
> > update; only releases get the full battery of QA. Note I'll probably be
> > stamping a release this weekend since the last release from two years ago
> > has a build issue with more recent OpenSSL versions.
>
> How do you recommend we get the latest stable version from within a CI
> script?
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> My work is funded by the Internet Civil Engineering Institute:
> https://icei.org
> Please visit their site and donate: the civilization you save might be
> your own.
>
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Setting up libaes_siv

[Daniel Franke via devel]

On Thu, Feb 14, 2019 at 9:15 PM Hal Murray via devel  wrote:
> How do I tell it that I don't want the doc?
>   (I don't have a2x on that system.)

You shouldn't have to tell it anything. All the manpage
target-generation directives are wrapped in if(A2X). If a2x isn't
found, those targets won't be generated.

> How do I get it to use my compiler?
>
> my compiler is at /usr/lib/ccache/gcc
>  (not lib64)
> cmake says
>   The CMAKE_C_COMPILER:
> /usr/lib64/ccache/cc
>   is not a full path to an existing compiler tool.
>   Tell CMake where to find the compiler by setting either the environment
>   variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
>   the compiler, or to the compiler name if it is in the PATH.
>
> so, I try:
> CC=/usr/lib/ccache/gcc cmake .
> and get the same thing.

I think what you did will probably work if you delete your CMakeCache
and try again, but otherwise try

cmake -DCMAKE_C_COMPILER=/usr/lib/ccache/gcc .
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Setting up libaes_siv

[Daniel Franke via devel]

This looks like namespace pollution of some kind -- perhaps one of
NetBSD's standard C headers defining a bswap64 macro that conflicts
with my definition. Can you send me what aes_siv.c looks like on your
system after preprocessing?

I'm not going to support CMake 2, but CentOS has CMake 3 available as
the 'cmake3' package.

On Thu, Feb 14, 2019 at 11:10 PM Hal Murray  wrote:
>
>
> dfoxfra...@gmail.com said:
> > I think what you did will probably work if you delete your CMakeCache and 
> > try
> > again
>
> Thanks.  That is the hint I needed.  I was scp-ing stuff from my main system
> to others giving them a bogus cache.
>
> -
>
> It doesn't build on NetBSD.  Do you recognize the error:
>
>  [ 11%] Building C object CMakeFiles/runtests.dir/aes_siv_test.c.o
> In file included from /usr/include/stddef.h:37:0,
>  from /home/murray/ntpsec/libaes_siv/aes_siv.h:8,
>  from /home/murray/ntpsec/libaes_siv/aes_siv.c:5,
>  from /home/murray/ntpsec/libaes_siv/aes_siv_test.c:3:
> /home/murray/ntpsec/libaes_siv/aes_siv.c:114:24: error: expected declaration
> specifiers or '...' before '__builtin_constant_p'
>  static inline uint64_t bswap64(uint64_t x) { return __builtin_bswap64(x); }
>
> -
>
> Any chance of building it with an old cmake?
>
> CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
>   CMake 3.0 or higher is required.  You are running version 2.8.12.2
>
> That's from CentOS.
>
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Setting up libaes_siv

[Daniel Franke via devel]

It's exactly like I suspected: a system header is #defining bswap64 as
a macro, causing a syntax error in my local definition. This is a
upstream bug twice over. First, nothing should be giving you
 if you don't ask for it. Second, the manpage clearly
states that bswap64 is a function, so it's unacceptable to implement
it as a macro.

The first bug might be either NetBSD or OpenSSL's fault, I need to
figure out which. The second one is clearly NetBSD's fault. I'll deal
with the OpenSSL fix if a fix is needed. I'll need you to do the
NetBSD reporting since I don't have a NetBSD system and won't be able
to answer any follow-up questions if I file the ticket myself. For the
meantime, I'll probably have to work around the issue by renaming that
function in libaes_siv.

On Thu, Feb 14, 2019 at 11:33 PM Daniel Franke  wrote:
>
> This looks like namespace pollution of some kind -- perhaps one of
> NetBSD's standard C headers defining a bswap64 macro that conflicts
> with my definition. Can you send me what aes_siv.c looks like on your
> system after preprocessing?
>
> I'm not going to support CMake 2, but CentOS has CMake 3 available as
> the 'cmake3' package.
>
> On Thu, Feb 14, 2019 at 11:10 PM Hal Murray  wrote:
> >
> >
> > dfoxfra...@gmail.com said:
> > > I think what you did will probably work if you delete your CMakeCache and 
> > > try
> > > again
> >
> > Thanks.  That is the hint I needed.  I was scp-ing stuff from my main system
> > to others giving them a bogus cache.
> >
> > -
> >
> > It doesn't build on NetBSD.  Do you recognize the error:
> >
> >  [ 11%] Building C object CMakeFiles/runtests.dir/aes_siv_test.c.o
> > In file included from /usr/include/stddef.h:37:0,
> >  from /home/murray/ntpsec/libaes_siv/aes_siv.h:8,
> >  from /home/murray/ntpsec/libaes_siv/aes_siv.c:5,
> >  from /home/murray/ntpsec/libaes_siv/aes_siv_test.c:3:
> > /home/murray/ntpsec/libaes_siv/aes_siv.c:114:24: error: expected declaration
> > specifiers or '...' before '__builtin_constant_p'
> >  static inline uint64_t bswap64(uint64_t x) { return __builtin_bswap64(x); }
> >
> > -
> >
> > Any chance of building it with an old cmake?
> >
> > CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
> >   CMake 3.0 or higher is required.  You are running version 2.8.12.2
> >
> > That's from CentOS.
> >
> >
> >
> >
> > --
> > These are my opinions.  I hate spam.
> >
> >
> >
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Setting up libaes_siv

[Daniel Franke via devel]

Hal, try putting

#define _ANSI_SOURCE 1
#define _ISOC99_SOURCE 1

at the very top of aes_siv.c and let me know if that fixes the build error.

Looks like the way  is getting in is via
 via  via  via
. But  guards it with

#if defined(_NETBSD_SOURCE)
#include  /* for quad_t, etc. */
#endif

while  has

#if !defined(_ANSI_SOURCE) && !defined(_POSIX_C_SOURCE) && \
!defined(_XOPEN_SOURCE) && !defined(_NETBSD_SOURCE)
#define _NETBSD_SOURCE 1
#endif

so I think defining _ANSI_SOURCE will suppress definition of
_NETBSD_SOURCE which will prevent the namespace pollution. If this
works for you I'll commit the change.

On Fri, Feb 15, 2019 at 7:49 AM Daniel Franke  wrote:
>
> It's exactly like I suspected: a system header is #defining bswap64 as
> a macro, causing a syntax error in my local definition. This is a
> upstream bug twice over. First, nothing should be giving you
>  if you don't ask for it. Second, the manpage clearly
> states that bswap64 is a function, so it's unacceptable to implement
> it as a macro.
>
> The first bug might be either NetBSD or OpenSSL's fault, I need to
> figure out which. The second one is clearly NetBSD's fault. I'll deal
> with the OpenSSL fix if a fix is needed. I'll need you to do the
> NetBSD reporting since I don't have a NetBSD system and won't be able
> to answer any follow-up questions if I file the ticket myself. For the
> meantime, I'll probably have to work around the issue by renaming that
> function in libaes_siv.
>
> On Thu, Feb 14, 2019 at 11:33 PM Daniel Franke  wrote:
> >
> > This looks like namespace pollution of some kind -- perhaps one of
> > NetBSD's standard C headers defining a bswap64 macro that conflicts
> > with my definition. Can you send me what aes_siv.c looks like on your
> > system after preprocessing?
> >
> > I'm not going to support CMake 2, but CentOS has CMake 3 available as
> > the 'cmake3' package.
> >
> > On Thu, Feb 14, 2019 at 11:10 PM Hal Murray  wrote:
> > >
> > >
> > > dfoxfra...@gmail.com said:
> > > > I think what you did will probably work if you delete your CMakeCache 
> > > > and try
> > > > again
> > >
> > > Thanks.  That is the hint I needed.  I was scp-ing stuff from my main 
> > > system
> > > to others giving them a bogus cache.
> > >
> > > -
> > >
> > > It doesn't build on NetBSD.  Do you recognize the error:
> > >
> > >  [ 11%] Building C object CMakeFiles/runtests.dir/aes_siv_test.c.o
> > > In file included from /usr/include/stddef.h:37:0,
> > >  from /home/murray/ntpsec/libaes_siv/aes_siv.h:8,
> > >  from /home/murray/ntpsec/libaes_siv/aes_siv.c:5,
> > >  from /home/murray/ntpsec/libaes_siv/aes_siv_test.c:3:
> > > /home/murray/ntpsec/libaes_siv/aes_siv.c:114:24: error: expected 
> > > declaration
> > > specifiers or '...' before '__builtin_constant_p'
> > >  static inline uint64_t bswap64(uint64_t x) { return 
> > > __builtin_bswap64(x); }
> > >
> > > -
> > >
> > > Any chance of building it with an old cmake?
> > >
> > > CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
> > >   CMake 3.0 or higher is required.  You are running version 2.8.12.2
> > >
> > > That's from CentOS.
> > >
> > >
> > >
> > >
> > > --
> > > These are my opinions.  I hate spam.
> > >
> > >
> > >
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Setting up libaes_siv

[Daniel Franke via devel]

Excellent. I just pushed the fix to HEAD.

On Fri, Feb 15, 2019 at 5:54 PM Hal Murray  wrote:
>
>
> dfoxfra...@gmail.com said:
> > Hal, try putting
> > #define _ANSI_SOURCE 1
> > #define _ISOC99_SOURCE 1
>
> ...
> [100%] Linking C executable demo
> [100%] Built target demo
> -bash-4.4$ make test
> Running tests...
> Test project /home/murray/ntpsec/libaes_siv
> Start 1: test
> 1/1 Test #1: test .   Passed0.01 sec
>
> 100% tests passed, 0 tests failed out of 1
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: linking to libaes_siv

[Daniel Franke via devel]

This is on Linux? Make sure /usr/local/lib is in your /etc/ld.so.conf
and then run ldconfig.

On Sat, Feb 16, 2019 at 9:46 AM Hal Murray  wrote:
>
>
> I'm getting closer to actually using it.
>
> Of course, it didn't work or you wouldn't be reading this message.
>
> The symptom is that it links but doesn't run.  At runtime, it can't find
> libaes_siv
>
> It was installed in /usr/local/lib/
>
> It works after I add links from /usr/lib64/ over to /usr/local/lib/
>
> [murray@fed play]$ ldd fed/main/ntpd/ntpd
> linux-vdso.so.1 (0x7ffcb13db000)
> libssl.so.1.1 => /lib64/libssl.so.1.1 (0x7fa097d41000)
> libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x7fa097a67000)
> libaes_siv.so.1 => not found
> libm.so.6 => /lib64/libm.so.6 (0x7fa0978e3000)
> librt.so.1 => /lib64/librt.so.1 (0x7fa0978d9000)
> libcap.so.2 => /lib64/libcap.so.2 (0x7fa0978d2000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x7fa0978ae000)
> libc.so.6 => /lib64/libc.so.6 (0x7fa0976e8000)
> libz.so.1 => /lib64/libz.so.1 (0x7fa0976ce000)
> libdl.so.2 => /lib64/libdl.so.2 (0x7fa0976c8000)
> /lib64/ld-linux-x86-64.so.2 (0x7fa097e42000)
>
> [murray@fed play]$ fed/main/ntpd/ntpd --version
> fed/main/ntpd/ntpd: error while loading shared libraries: libaes_siv.so.1:
> cannot open shared object file: No such file or directory
> [murray@fed play]$
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: linking to libaes_siv

[Daniel Franke via devel]

His problem had nothing to do with waf or ntpd. ld.so.conf is magic
used by the ELF loader to locate the libraries it needs -- at runtime,
not at link time.

On Sat, Feb 16, 2019 at 10:09 AM Eric S. Raymond  wrote:
>
> Hal Murray via devel :
> > The symptom is that it links but doesn't run.  At runtime, it can't find
> > libaes_siv
> >
> > It was installed in /usr/local/lib/
> >
> > It works after I add links from /usr/lib64/ over to /usr/local/lib/
>
> I suppose a more graceful solution would be to beat waf into looking at
> /usr/local/lib.  This might do it:
>
> ./waf configure [your-usual-options] --libdir=/usr/local/lib
>
> That's assuming --libdir is additive. It's also passible you might have
> to mwess with PKG_CONFIG_PATH, as in this report:
>
> https://github.com/MTG/essentia/issues/248
>
> Let us know what work - it should be documented.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> My work is funded by the Internet Civil Engineering Institute: 
> https://icei.org
> Please visit their site and donate: the civilization you save might be your 
> own.
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: linking to libaes_siv

[Daniel Franke via devel]

The BSDs work the same way Linux does except on FreeBSD the
configuration file is called /etc/ld-elf.so.conf and you run 'ldconfig
-elf' after you've changed it.

Your distribution owns /usr and packages not installed through your
distribution's packaging system shouldn't touch it and should default
to /usr/local. And under no circumstances should a makefile be
touching /etc/ld.so.conf. This is just standard UNIX stuff, absolutely
nothing special about ntpd or libaes_siv.

On Sun, Feb 17, 2019 at 10:37 AM Eric S. Raymond  wrote:
>
> Hal Murray :
> > > Let us know what work - it should be documented.
> >
> > This is what I used on Linux:
> >
> > echo "/usr/local/lib/" > /etc/ld.so.conf.d/libaes_siv.conf
> > ldconfig
> >
> >
> > This is what I used on NetBSD and FreeBSD.  There is probably a 
> > better/cleaner
> > way, but I wasn't in the mood to go hunting for it.
> >
> > cd /usr/lib/
> > ln -s /usr/local/lib/libaes_siv.a
> > ln -s /usr/local/lib/libaes_siv.so
> > ln -s /usr/local/lib/libaes_siv.so.1
> > ln -s /usr/local/lib/libaes_siv.so.1.0.0
> >
> >
> > NetBSD needed one more:
> > cd /usr/include/
> > ln -s /usr/local/include/aes_siv.h
> >
> >
> > All as root
>
> Hmmm.  Daniel, is there any way to beat cmake into setting PREFIX=/usr/lib?
> That would make all these problems go away.
>
> /me looks
>
> According to
>
> https://stackoverflow.com/questions/6003374/what-is-cmake-equivalent-of-configure-prefix-dir-make-all-install
>
> this might do it:
>
> cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr . && make all install
>
> Hal, please test at least to the point of make -n install.  If this works
> it would be a good recipe to put in INSTALL.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> My work is funded by the Internet Civil Engineering Institute: 
> https://icei.org
> Please visit their site and donate: the civilization you save might be your 
> own.
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

libaes_siv release candidate

[Daniel Franke via devel]

The current HEAD of libaes_siv is a release candidate. Whether or not
it becomes the release depends on what I decide to do about the CentOS
6 issue, which in turn depends on the OpenSSL team getting back to me.
I'm also waiting on Hal to run it through his build farm again to let
me know if last-minute changes caused any breakage. If the answers
turn out to be "nothing" and "no", then this will become 1.0.1. For
the meantime, I've tagged HEAD with '1.latest' which is what the CI
system can use to get something of suitable stability for testing. If
I make any further changes before 1.0.1, I'll re-point the tag.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: libaes_siv release candidate

[Daniel Franke via devel]

Try the new HEAD (3562205). I changed ANSI to POSIX.1-2001 which
should hopefully make FreeBSD happy again while still suppressing the
colliding symbols on NetBSD.

What version of OpenSSL are you building against on FreeBSD? I want to
go through sources to figure out exactly why it fails.

On Mon, Feb 18, 2019 at 3:10 PM Hal Murray via devel  wrote:
>
> Google/gmail has been rejecting some of my mail recently.
>
> Daniel said:
> > I'm also waiting on Hal to run it through his build farm again to let me 
> > know
> > if last-minute changes caused any breakage.
>
> The ANSI fix for NetBSD broke FreeBSD.
>
> -- Build files have been written to: /home/murray/ntpsec/libaes_siv
> [ 11%] Building C object CMakeFiles/runtests.dir/aes_siv_test.c.o
> In file included from /home/murray/ntpsec/libaes_siv/aes_siv_test.c:3:
> In file included from /home/murray/ntpsec/libaes_siv/aes_siv.c:23:
> In file included from /usr/include/openssl/cmac.h:19:
> In file included from /usr/include/openssl/evp.h:16:
> In file included from /usr/include/openssl/bio.h:20:
> In file included from /usr/include/openssl/crypto.h:415:
> /usr/include/pthread.h:195:7: error: unknown type name 'clockid_t'
> clockid_t * __restrict);
> ^
> /usr/include/pthread.h:219:39: error: unknown type name 'clockid_t'
>
> int pthread_getcpuclockid(pthread_t, clockid_t *);
>  ^
> 2 errors generated.
>
> *** Error code 1
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: libaes_siv release candidate

[Daniel Franke via devel]

You can assume it's a verification failure because "failure in
underlying machinery" shouldn't be possible. The call doesn't allocate
memory and doesn't make any system calls. There's nothing that can
fail.

On Mon, Feb 18, 2019 at 3:53 PM Hal Murray  wrote:
>
>
> There is a rough edge that I don't fully understand.
>
> The man page for AES_SIV_Decrypt says:
>These functions return 1 on success and 0 on failure.
>
> There are 2 types of errors: the CMAC check failed, or there was a problem in
> some underlying machinery.
>
> Is there any way to distinguish between the two?
>
> It seems like you have inherited a general OpenSSL problem.  You might be able
> to solve it by storing a magic value in out_len.
>
> --
> These are my opinions.  I hate spam.
>
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: libaes_siv release candidate

[Daniel Franke via devel]

Okay, not surprised that's where the breakage was introduced, since
OpenSSL 1.1.0 rearchitected how it handles threading:
https://www.openssl.org/blog/blog/2017/02/21/threads/

Did my commit switching _ANSI_SOURCE to _POSIX_SOURCE resolve the build failure?

On Mon, Feb 18, 2019 at 11:53 PM Hal Murray  wrote:
>
>
> dfoxfra...@gmail.com said:
> > What version of OpenSSL are you building against on FreeBSD? I want to go
> > through sources to figure out exactly why it fails.
>
> Current release:
> 12.0-RELEASE
> /usr/include/openssl/opensslv.h:# define OPENSSL_VERSION_NUMBER  0x1010101fL
> Fails
>
> An older system:
> 11.2-RELEASE-p5
> /usr/include/openssl/opensslv.h:# define OPENSSL_VERSION_NUMBER  0x100020ffL
> Works.
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: NTS off the ground - time for testing

[Daniel Franke via devel]

On Wed, Feb 20, 2019 at 12:48 AM Hal Murray via devel  wrote:
> The K and I used to encrypt cookies is a hack constant so old cookies work
> over server reboots.

I assume this is temporary while you work on this code, right?
Obviously if K is a hardcoded constant you have no security.

> With the NTS flag, the client side tries NTS-KE, and drops into normal mode if
> that doesn't work.  If it does work, it sends NTS packets until it runs out of
> cookies.  Then it drops into normal mode.

Don't do that. Not even temporarily, not even as an option, not even
"opportunistically". If an adversary can force a client out of NTS
mode by dropping a few NTS packets, then NTS has no value.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: What's left to doo on NTS.

[Daniel Franke via devel]

On Fri, Mar 1, 2019 at 7:01 PM Gary E. Miller via devel
 wrote:
> "noval" is not mostly for debugging.  It is essential for off
> network operation.

There's no point in doing NTS if you're not doing certificate
validation. The result isn't any more secure than unauthenticated NTP.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: What's left to doo on NTS.

[Daniel Franke via devel]

Which ones do you intend to relax? And in any case you don't need a whole
CA, you can pin a self-signed cert and still do full validation on it.

On Fri, Mar 1, 2019, 23:41 Gary E. Miller via devel 
wrote:

> Yo Daniel!
>
> On Fri, 1 Mar 2019 21:26:15 -0500
> Daniel Franke  wrote:
>
> > On Fri, Mar 1, 2019 at 7:01 PM Gary E. Miller via devel
> >  wrote:
> > > "noval" is not mostly for debugging.  It is essential for off
> > > network operation.
> >
> > There's no point in doing NTS if you're not doing certificate
> > validation. The result isn't any more secure than unauthenticated NTP.
>
> There is validation, and there is validation.  Without some relaxation
> of the validation rules you can't run in a private net without doing
> your own CA.
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: What's left to doo on NTS

[Daniel Franke via devel]

On Fri, Mar 1, 2019 at 11:39 PM Gary E. Miller via devel
 wrote:
> Not complete security, but at least encryption.  And there are
> levels of validation.  If you are off net, you can't completely
> validate the cert, but you can partially validate it.  Maybe you
> would want to pin it.

Encryption doesn't work without authentication; a MitM can cause you
to negotiate keys with *him* instead of the endpoint you think you're
communicating with.

You can skip the notBefore/notAfter constraints under the
circumstances described in the RFC. Otherwise, either do full
validation or don't bother with NTS at all. Pinning counts as full
validation.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: What's left to doo on NTS

[Daniel Franke via devel]

On Sat, Mar 2, 2019 at 12:36 PM Gary E. Miller via devel
 wrote:
> Yes, but you seriously reduce the attack time window.  Instead of
> a possible MitM every few seconds, you need to grab the one time the
> cookies are shared.

No you don't, because a MitM who appears at any time can drop time
packets until you run out of cookies, forcing a renegotiation, and
then MitM the renegotiation.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: What's left to doo on NTS.

[Daniel Franke via devel]

On Sun, Mar 3, 2019 at 8:45 AM Kurt Roeckx via devel  wrote:
> On Sun, Mar 03, 2019 at 05:23:31AM -0800, Hal Murray wrote:
> >
> > k...@roeckx.be said:
> > > If this is something you're worried about, this can be solved with the
> > > interleave mode, which was removed.
> >
> > How well does it work?
>
> It works great, the errors are much smaller when it's enabled.

Interleaved mode in NTP Classic doesn't do what you think it does.

The concept behind interleaved mode is sound: get packet timestamps
from the NIC at the moment they cross the wire, thus eliminating the
contribution of local buffers to jitter. But ntpd doesn't do anything
of the kind!

Actually getting timestamps from the NIC is fairly involved. The NIC
has its own clock and its own oscillator, which has to carefully be
kept in sync with the system clock. Furthermore, all the APIs for
doing this are OS-specific. Check out the linux-ptp project to see
what it looks like when it's done right; it's a fair bit of code, and
nothing of the kind is present in ntpd.

One thing ntpd does do (both in NTP Classic and in NTPsec) is fetch
kernel timestamps on incoming packets using the SO_TIMESTAMP option.
This is different from hardware timestamps; they're not generated by
the NIC, they're generated by the kernel at the moment the NIC passes
the packet to it. No analogue to SO_TIMESTAMP exists for outgoing
packets.

For outgoing packets in interleaved mode, all NTP Classic does is call
clock_gettime(2) right after calling send(2), rather than right
before. You can see it here:
https://github.com/ntp-project/ntp/blob/stable/ntpd/ntp_proto.c#L3324-L3355
It purports the result of this call to be a hardware timestamp, but
it's nothing of the sort. All send(2) does is copy the packet into the
kernel's IO buffers and then return. The return time has nothing to do
with when the packet *leaves* any buffer. The only circumstance under
which the post-send(2) timestamp will be less jittery than the
pre-send(2) timestamp is if the kernel's IO buffer is full, in which
case the call will block until there's room again for the packet. This
should only ever happen on an overloaded server.

Now, the post-send(2) timestamp is not less jittery than the
pre-send(2) timestamp, but it is different, because for send(2) to do
a context switch in and out of kernel space takes a non-zero amount of
time. So, you claim you're getting smaller errors when interleaved
mode is enabled. I'm not going to credit that claim without
substantiation: how are you measuring these errors? Do you have a GPS
reference clock to check them against? But if you convince me it's
true, then it's likely true because the difference in the point where
the timestamp is captured is offsetting an asymmetry somewhere else in
ntpd or on your network path.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: SO_TIMESTAMP may go away

[Daniel Franke via devel]

If you try to measure the cost of the authentication code using log
messages you're going to get total noise, because the cost of logging
a message is higher than the cost of doing the authentication. Each
invocation of AES-SIV should take, in round numbers, 250 CPU cycles,
and processing a typical request should take four invocations (unseal
cookie, unseal message, seal new cookie, seal message), with only the
final one being in the critical section.

On Mon, Mar 4, 2019 at 8:14 AM Eric S. Raymond via devel
 wrote:
>
> Hal Murray :
> > I think I'll take a break from NTS and go add a log file for this sort of
> > thing.  I want a place for the time spent in auth code.
>
> Good idea.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> My work is funded by the Internet Civil Engineering Institute: 
> https://icei.org
> Please visit their site and donate: the civilization you save might be your 
> own.
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: SO_TIMESTAMP may go away

[Daniel Franke via devel]

On Sun, Mar 3, 2019 at 9:44 PM Eric S. Raymond  wrote:
> (Also, it turns out not to be important at post-Y2K machine speeds to
> get those arrival timestamps from the UDP layer ASAP, rather than
> looking at packet read time in userspace. The cost of the latter,
> naive approach is additional jitter dominated by process-scheduling
> time; this used to be significant relative to users' accuracy
> expectations for NTP, but scheduler timeslices have since decreased
> by orders of magnitude and squashed the issue. We know this from some
> tests setup having run for six months with packet-timestamp fetching
> accidentally disabled...  But they weren't busy systems.)

Scheduler timeslices haven't changed much. The current default on
Linux is 1ms and it's been that way for a long time. What's changed is
that everybody has multicore processors now, so contention almost
never happens.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: SO_TIMESTAMP may go away

[Daniel Franke via devel]

One thing to keep in mind is that if the client is using SO_TIMESTAMP
but the server isn't, or vice versa, you're going to introduce a
persistent inaccuracy on the order of a microsecond, due to the
resulting asymmetry in the point at which the timestamp is captured.

On Mon, Mar 4, 2019 at 8:36 AM Daniel Franke  wrote:
>
> On Sun, Mar 3, 2019 at 9:44 PM Eric S. Raymond  wrote:
> > (Also, it turns out not to be important at post-Y2K machine speeds to
> > get those arrival timestamps from the UDP layer ASAP, rather than
> > looking at packet read time in userspace. The cost of the latter,
> > naive approach is additional jitter dominated by process-scheduling
> > time; this used to be significant relative to users' accuracy
> > expectations for NTP, but scheduler timeslices have since decreased
> > by orders of magnitude and squashed the issue. We know this from some
> > tests setup having run for six months with packet-timestamp fetching
> > accidentally disabled...  But they weren't busy systems.)
>
> Scheduler timeslices haven't changed much. The current default on
> Linux is 1ms and it's been that way for a long time. What's changed is
> that everybody has multicore processors now, so contention almost
> never happens.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: SO_TIMESTAMP may go away

[Daniel Franke via devel]

Yes, if you go back that far then there's been significant change.
Nonetheless, that change isn't relevant. The current granularity of
1ms is still coarse enough that it would be obvious if it were a
factor. Multicore processors are the reason it isn't.

On Mon, Mar 4, 2019 at 9:25 AM Eric S. Raymond  wrote:
>
> Daniel Franke :
> > Scheduler timeslices haven't changed much. The current default on
> > Linux is 1ms and it's been that way for a long time. What's changed is
> > that everybody has multicore processors now, so contention almost
> > never happens.
>
> Your historical baseline isn't long enough.  The NTP code has roots in
> the 1980s, but there was a massive change in Unix schedular
> granularity in the 1990s as typical clock speeds went from 10e7Hz to
> 10e8Hz. On Linux it happened early enough that the changeover was
> poorly documented and is now largely forgotten; it's reasonable
> that you don't know about it.
>
> I actually learned this the hard way when it happened; one of my older
> small projects was a real-time game (Tetris implemented for curses) with a
> delay loop that became unplayably fast after the jump.  If I groveled
> through my git logs I could probably pin down when I had to change it.
>
> The NTP packet-stamp code dates from the before time, when sampling lag
> due to timeslice granularity was an order of magnitude or more worse
> than it is now.  From some of its details I'd guess it was written about
> '87 or '88.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> My work is funded by the Internet Civil Engineering Institute: 
> https://icei.org
> Please visit their site and donate: the civilization you save might be your 
> own.
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: SO_TIMESTAMP may go away

[Daniel Franke via devel]

On Mon, Mar 4, 2019 at 9:25 AM Eric S. Raymond  wrote:
> The NTP packet-stamp code dates from the before time, when sampling lag
> due to timeslice granularity was an order of magnitude or more worse
> than it is now.  From some of its details I'd guess it was written about
> '87 or '88.

I just checked some old versions, and the string "SO_TIMESTAMP" only
appears in 4.2.4 and beyond, dating to 2006.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: What's left to doo on NTS

[Daniel Franke via devel]

The intended design for running NTS with pool servers is that only the
pool operator runs an NTS-KE server. The NTS-KE server then picks an
NTS-enabled NTP server out of the pool and serves you an appropriate
NTPv4 Server Negotiation Record. Individual server operators, on a
one-time basis, establish a shared secret with the pool operator
out-of-band; this secret is used as the master key for creating and
decrypting cookies. As recommended in the draft RFC, this key can be
rotated on a periodic basis using a key-derivation function such as
HKDF as a ratchet. Since new keys are deterministically derived from
old ones (using a one-way function so you can't go backward), no
communication is required as long as the pool operator and server
operator agree on a schedule for generating new keys and forgetting
old ones. They don't have to synchronize this perfectly; as long as
the pool operator isn't still issuing new cookies under a given key-ID
when the server operator has already forgotten that ID, it'll work.

In any case, you should absolutely not pay attention to anything you
get from DNS when validating a certificate. Whatever name the users
puts in the configuration file is what you should expect to see in the
certificate.

On Mon, Mar 4, 2019 at 3:58 PM Hal Murray via devel  wrote:
>
>
> rlaa...@wiktel.com said:
> > CNAMEs don't really help. Certificate validation uses the original name
> > anyway.
>
> I was assuming we could intercept the CNAME and use that for certificate
> validation.  Maybe I should have said SRV or TXT or ???
>
> The normal  getaddrinfo and friends automatically follow CNAMEs.  Thus my
> comment about needing some DNS code.
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: What's left to doo on NTS

[Daniel Franke via devel]

On Mon, Mar 4, 2019 at 4:28 PM Gary E. Miller via devel
 wrote:
> The name in ntp.conf MUST match the name in the cert.  Unless you
> override it ("noval", pin, etc.).
>
> > The normal  getaddrinfo and friends automatically follow CNAMEs.
> > Thus my comment about needing some DNS code.
>
> Which opens a big fat back door.

Whatever CNAMEs the DNS hands you, you should follow; the default
behavior of getaddrinfo is fine. Just match the name in the cert
against what's in ntp.conf and not against anything else.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: How not to design a wire protocol

[Daniel Franke via devel]

I'll post a rebuttal sometime later this week. As for IETF processes,
though, you're years late. The WG already had a consensus call in 2016
on what NTS-KE's framing format should look like, and it was
unanimous. You can still comment during IETF Last Call and try to
convince the IESG to block the document from advancing, but you're not
likely to be taken seriously there; the IETF publishes new binary
protocols all the time.

On Tue, Mar 5, 2019 at 1:17 AM Eric S. Raymond via devel
 wrote:
>
> This is why my design sketch for NTPv5 is a JSON profile, and wgy I
> intend to file an objection to the KE protocol in the NTS draft.
>
> http://esr.ibiblio.org/?p=8254
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> I cannot undertake to lay my finger on that article of the
> Constitution which grant[s] a right to Congress of expending, on
> objects of benevolence, the money of their constituents.
> -- James Madison, 1794
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: How not to design a wire protocol

[Daniel Franke via devel]

On Tue, Mar 5, 2019 at 7:21 AM Eric S. Raymond  wrote:
> You yourself advocated that Mode 6 ought to be replaced by an HTTP
> service on TCP port 123. I think that's a good idea, if we can do
> it. The problem is than NTS-KE *also* wants to have TCP 123.

Like Hal pointed out, ALPN makes this a non-issue. But what gave you
the idea that NTS-KE wants 123/tcp? There's been some back-and-forth
on this in the WG but I've been advocating against using 123 because
NTS-KE is explicitly not specific to NTP and can be extended to
provide similar negotiation mechanisms for other protocols.
Regardless, it's just a number and makes no technical difference.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: How not to design a wire protocol

[Daniel Franke via devel]

On Tue, Mar 5, 2019 at 1:52 PM Eric S. Raymond  wrote:
> If you end up going with a non-123 port number, I requst that the RFC
> allow use on other ports when and if ALPN is available and specify
> the ALPN tag to be used.

The spec already mandates that ALPN always be used and allocates a tag
with IANA.

> I disagree.  New firewall holes are difficult, practically if not
> theoretically.

tcp/123 is already a new firewall hole. If you want to work around
unchangeable firewall rules you probably have to use 443 (and again
rely on ALPN).
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: How not to design a wire protocol

[Daniel Franke via devel]

On Tue, Mar 5, 2019 at 2:28 PM Eric S. Raymond  wrote:
> Thanks.  I didn't see that in the RFC draft.  Did I simply miss it or is
> it in a registry that is entirely separate?

Last sentence of section 3, first sentence of section 4, and section 7.2.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: How not to design a wire protocol

[Daniel Franke via devel]

On Tue, Mar 5, 2019 at 4:10 PM Hal Murray  wrote:
> How does that work in practice?  443 is for HTTPS.  Does Apache have a call
> out mode?  Is there a standard utility that does ALPN dispatching?  What
> fraction of clients send ALPN info?

I've never tried it myself, but I think Nginx can handle this. Use
ngx_stream_ssl_preread_module to check ALPN, then based on what's
there either terminate TLS locally or forward traffic at the TCP layer
to some other port on ::1. AFAIK Apache users are SOL though.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: timer_create

[Daniel Franke via devel]

Still accurate.

OTOH, OS X finally got clock_gettime() in 10.12.

On Tue, Mar 5, 2019 at 4:28 PM Hal Murray via devel  wrote:
>
>
> wscript says MacOS doesn't have it.
>
> timer_create seems pretty basic.  Is that still accurate?  Or perhaps leftover
> from an old version that is no longer supported?
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: What's left to doo on NTS

[Daniel Franke via devel]

On Wed, Mar 6, 2019, 03:33 Hal Murray  wrote:

>
> dfoxfra...@gmail.com said:
> > The intended design for running NTS with pool servers is that only the
> pool
> > operator runs an NTS-KE server. The NTS-KE server then picks an
> NTS-enabled
> > NTP server out of the pool and serves you an appropriate NTPv4 Server
> > Negotiation Record. Individual server operators, on a one-time basis,
> > establish a shared secret with the pool operator out-of-band; this
> secret is
> > used as the master key for creating and decrypting cookies.
>
> It's amazing what you see when you start actually writing code.
>
> For that description to work, both the NTS-KE server and the NTP server
> have
> to use the same cookie recipe and same new key recipe.
>
> Section 6 is "Suggested Format for NTS Cookies"  "Suggested" isn't strong
> enough for interoperability.  The key rotation recipe is in there too.
>

That's correct: ensuring interop between differing implementations of the
NTS-KE server and the NTP server is outside the scope of this document.

>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: What's left to doo on NTS

[Daniel Franke via devel]

A different RFC, eventually. But I'm not in a rush. Let people managing
large scale deployments figure out what works for them and then standardize
around it later.

On Wed, Mar 6, 2019, 13:25 Achim Gratz via devel  wrote:

> Daniel Franke via devel writes:
> > That's correct: ensuring interop between differing implementations of the
> > NTS-KE server and the NTP server is outside the scope of this document.
>
> So what are the plans for that department?  Have everything bloom into
> chaos or put it into a different RFC?
>
>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> Samples for the Waldorf Blofeld:
> http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Tangle - cookie keys file

[Daniel Franke via devel]

On Thu, Mar 7, 2019 at 3:10 PM Gary E. Miller via devel
 wrote:
> My idiosyncratic read of the FHS would, by default, put the master keys
> in /usr/local/var/lib:
>
> "State information. Persistent data modified by programs as they run,
> e.g., databases, packaging system metadata, etc. "

I have no idea what you're reading because there's no such thing as
/usr/local/var in the FHS. It's /var/local.

The FHS-compliant place to put these keys is $VARDIR/lib/ntp, where
$VARDIR is /var/local if you're installing NTPsec by hand and /var if
it's packaged by your distro. $VARDIR/ntp is specifically prohibited:
"Applications must generally not add directories to the top level of
/var. Such directories should only be added if they have some
system-wide implication, and in consultation with the FHS mailing
list". So is $VARDIR/lib: "An application (or a group of inter-related
applications) must use a subdirectory of /var/lib for its data".
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Tangle - cookie keys file

[Daniel Franke via devel]

On Thu, Mar 7, 2019 at 5:14 PM Gary E. Miller via devel
 wrote:
> Wikipedia makes no mention, even sideways, of /var/local.
>
> Nor does the base document, FHS 3.0:
> https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf
>
> See section 5. "The /var Hierarchy".

It's specified in the table at the start of section 5.2.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: How not to design a wire protocol

[Daniel Franke via devel]

On Tue, Mar 5, 2019 at 2:37 AM Daniel Franke  wrote:
>
> I'll post a rebuttal sometime later this week. As for IETF processes,
> though, you're years late. The WG already had a consensus call in 2016
> on what NTS-KE's framing format should look like, and it was
> unanimous. You can still comment during IETF Last Call and try to
> convince the IESG to block the document from advancing, but you're not
> likely to be taken seriously there; the IETF publishes new binary
> protocols all the time.

Rebuttal here: http://esr.ibiblio.org/?p=8254&cpage=1#comment-2202914
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: NTS: config and initialization

[Daniel Franke via devel]

I recommend having no default at all for the trust store location and
forcing to be set in the config file. Too much risk otherwise of
finding something that looks like a store but isn't actually
trustworthy and entering an insecure state without the user realizing
it. Leave it up to packagers to pre-populate the default config with
the location of the distro's trust store.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Installing ntpd.service

[Daniel Franke via devel]

Everything about init scripts should be assumed distro-specific and
'make install' should not be attempting to touch them. Leave that up
to distro packagers.

On Wed, Mar 20, 2019 at 2:57 PM Gary E. Miller via devel
 wrote:
>
> Yo Hal!
>
> On Tue, 19 Mar 2019 22:07:26 -0700
> Hal Murray via devel  wrote:
>
> > If we are going to install it, can we bypass the install if the
> > currently installed file is identical to the to-be-installed
> > version?
>
> More interesting to me, what do you do if it is NOT identical?
>
> Many people dual install NTP Classic and NTPsec.  Overwriting the
> service file of the one with the service file of another causes
> confusion.
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel