> Let us not call it the "cookie key", lets use the terminology of the RFC.
Please suggest a file name.
>> I'm assuming that the system defaults will cover 99+% of the normal
>> cases. I don't have to do anything special for my browser to work.
> Because your browser includes its own cert
Yo Hal!
On Thu, 07 Mar 2019 22:39:12 -0800
Hal Murray via devel wrote:
> > I cant find that in the Proposed RFC. Got a citation?
>
> Bottom of page 21. Last paragraph of section 5.
Ah, there it is:
"To allow for NTP session restart when the NTS-KE server is
unavailable and to
> I cant find that in the Proposed RFC. Got a citation?
Bottom of page 21. Last paragraph of section 5.
> And what is the point of storing cookies and K/I pair together? The client
> has no K/I pair. A server is to regenerate the cookies from K/I pairs.
> Mixing the roles is bad.
I didn't
Yo Hal!
On Thu, 07 Mar 2019 21:18:28 -0800
Hal Murray via devel wrote:
> Gary said:
> > Why do you need a cookie file? I would think those should never be
> > stored. Ever.
>
> The cookies are sent from client to server in the clear.
Of course.
> It's the "cookie key" file, not a cookie
Gary said:
> Why do you need a cookie file? I would think those should never be stored.
> Ever.
The cookies are sent from client to server in the clear.
It's the "cookie key" file, not a cookie file. Do you have suggestions for a
better name?
It holds the K/I used to decode cookies -- but
Yo Hal!
On Thu, 07 Mar 2019 19:11:59 -0800
Hal Murray via devel wrote:
> > If the cookie key file is unexpectedly removed, what other useful
> > option is there? If the file was permanently deleted, there's
> > really nothing to be done but re-create it anyway.
>
> The question is does the
Yo Hal!
On Thu, 07 Mar 2019 19:36:00 -0800
Hal Murray via devel wrote:
> The client side is easy: just add "nts" to the server line. There
> are no parameters needed so the initialization for the client side
> just works.
How does it know which of the myriad locations that the CA and
The client side is easy: just add "nts" to the server line. There are no
parameters needed so the initialization for the client side just works.
That assumes the certificates for the servers you want to use are covered by
the default root certificates on your system.
--
For the server
> If the cookie key file is unexpectedly removed, what other useful option is
> there? If the file was permanently deleted, there's really nothing to be done
> but re-create it anyway.
The question is does the admin know something happened.
> Also, by the way, the cookie key file is storing
Hal Murray :
>
> Eric said:
> > This raises an interesting point. ntpd can now tell when its on first
> > startup (absence of this file). I'm not a fan of this kind of statefulness
> > -
> > worked hard at avoiding it in GPSD - but since NTS's requirements stick us
> > with it there's a
On 3/7/19 8:50 PM, Hal Murray via devel wrote:
> Creating it when it doesn't exist means it will do the wrong thing if the
> file
> gets unexpectedly removed.
If the cookie key file is unexpectedly removed, what other useful option
is there? If the file was permanently deleted, there's really
Eric said:
> This raises an interesting point. ntpd can now tell when its on first
> startup (absence of this file). I'm not a fan of this kind of statefulness -
> worked hard at avoiding it in GPSD - but since NTS's requirements stick us
> with it there's a question: what else should trigger
e...@thyrsus.com said:
>> Can we and/or should we make the default file names OS dependent?
> I recommend trying to avoid that. Follow the Filesystem Hierarchy Standard
> and let other OSes be their local packagers' problem.
That seems reasonable, but only if you provide an easy way for the
Yo Daniel!
On Thu, 7 Mar 2019 17:18:28 -0500
Daniel Franke wrote:
> 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:
> >
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
Yo Daniel!
On Thu, 7 Mar 2019 16:19:34 -0500
Daniel Franke wrote:
> 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
Yo Hal!
On Thu, 07 Mar 2019 13:51:33 -0800
Hal Murray via devel wrote:
> Gary said:
> > Remeber, user installed codes should NEVER use /usr or /var.
> > I do realize this is a rule frequently violated, but givin how
> > often users install both the distro ntpd/gpsd and the source
> > ntpd/gpsd
Yo Hal!
On Thu, 07 Mar 2019 13:29:58 -0800
Hal Murray via devel wrote:
> > Documentation isn't a problem. The docs can and should get the same
> > waf subst behavior anyway. So the docs should always mention the
> > paths that match how I built my ntpd.
>
> That gets interesting. Many
Yo Hal!
On Thu, 07 Mar 2019 13:17:25 -0800
Hal Murray via devel wrote:
> Gary said:
> >> Or, we could fix SHM so the client side is read-only.
> > As Eric has said: Changing the SHM protocol is not an option.
>
> I believe there is a reasonable way to do it.
>
> GPSD writes to both old
Gary said:
> Remeber, user installed codes should NEVER use /usr or /var.
> I do realize this is a rule frequently violated, but givin how often users
> install both the distro ntpd/gpsd and the source ntpd/gpsd it is good to keep
> their files in different places.
Interesting. But this is
> Documentation isn't a problem. The docs can and should get the same waf subst
> behavior anyway. So the docs should always mention the paths that match how I
> built my ntpd.
That gets interesting. Many copies of documentation end up on the web. Can
we arrange things so the default says
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
Gary said:
>> Or, we could fix SHM so the client side is read-only.
> As Eric has said: Changing the SHM protocol is not an option.
I believe there is a reasonable way to do it.
GPSD writes to both old and new forms.
ntpd supports two drivers (or a mode bit)
If you want to add SHM via
Yo Richard!
On Thu, 7 Mar 2019 15:00:44 -0600
Richard Laager via devel wrote:
> On 3/7/19 2:44 PM, Hal Murray via devel wrote:
> > Gary said:
> >> My idiosyncratic read of the FHS would, by default, put the master
> >> keys in /usr/local/var/lib:
> >
> > Is that a typo? There is no
On 3/7/19 2:44 PM, Hal Murray via devel wrote:
> Gary said:
>> My idiosyncratic read of the FHS would, by default, put the master keys in
>> /usr/local/var/lib:
>
> Is that a typo? There is no /usr/local/var/ or /usr/var/ on Fedora or Debian.
It might be reasonable to default to
Yo Hal!
On Thu, 07 Mar 2019 12:44:40 -0800
Hal Murray via devel wrote:
> Gary said:
> > My idiosyncratic read of the FHS would, by default, put the master
> > keys in /usr/local/var/lib:
>
> Is that a typo?
No.
> There is no /usr/local/var/ or /usr/var/ on Fedora
> or Debian.
Now would
Gary said:
> My idiosyncratic read of the FHS would, by default, put the master keys in
> /usr/local/var/lib:
Is that a typo? There is no /usr/local/var/ or /usr/var/ on Fedora or Debian.
> We can pick a default, but no default would be fine for most linux.
> It needs to be configurable for
Yo Hal!
On Thu, 07 Mar 2019 12:25:52 -0800
Hal Murray via devel wrote:
> Gary said:
> >> What would ntpd need root for?
> > SHM(0) and SHM(1).
>
> That would mean that you would have to restart ntpd to add SHM
> drivers.
>
> Or, we could fix SHM so the client side is read-only.
As Eric
Gary said:
>> What would ntpd need root for?
> SHM(0) and SHM(1).
That would mean that you would have to restart ntpd to add SHM drivers.
Or, we could fix SHM so the client side is read-only.
The comments in ntpd.c
#ifdef ENABLE_EARLY_DROPROOT
/* drop root privileges */
/* This
Yo Achim!
On Thu, 07 Mar 2019 21:13:47 +0100
Achim Gratz via devel wrote:
> Hal Murray via devel writes:
> > They are needed to use old cookies after restarting ntpd.
>
> I'd not go there. If you do a cold restart, you lose the
> cryptographic state, end of story.
Now imagine you are
Richard Laager via devel :
> Is microjson something I can dynamically link against, or is it embed only?
There are two parts to a microjson deplyment: the generic microjson runtime,
and a set of application-specific structure initializers you have to declare to
tell the runtime how to parse. The
Hal Murray via devel writes:
> They are needed to use old cookies after restarting ntpd.
I'd not go there. If you do a cold restart, you lose the cryptographic
state, end of story. Now, doing a warm restart that doesn't lose all
state is something that's useful independent of the topics around
Yo Richard!
On Thu, 7 Mar 2019 13:50:20 -0600
Richard Laager via devel wrote:
> On 3/7/19 1:22 PM, Gary E. Miller via devel wrote:
> > Yo Richard!
> >
> > On Thu, 7 Mar 2019 11:06:58 -0600
> > Richard Laager via devel wrote:
> >
> >> On 3/7/19 12:56 AM, Eric S. Raymond via devel wrote:
>
Yo Richard!
On Thu, 7 Mar 2019 13:59:36 -0600
Richard Laager via devel wrote:
> On 3/7/19 1:07 PM, Eric S. Raymond wrote:
> > Dissenting mildly. For reasons I've explained before I'm trying to
> > move us away from config options. I will be resistant to adding
> > more in the future. Doesn't
Richard Laager via devel :
> On 3/7/19 12:56 AM, Eric S. Raymond via devel wrote:
> > JSON is C is normally *very* awkward, vastly worse than Go, because
> > full JSON parse needs to do fancy dancing with dynamic memory to
> > handle heterogenous arrays. The good news is that I ran into this
> >
On 3/7/19 1:07 PM, Eric S. Raymond wrote:
> Dissenting mildly. For reasons I've explained before I'm trying to move us
> away from config options. I will be resistant to adding more in the future.
> Doesn't mean that we can never do it, but I'd want to see a demonstration of
> need in each
>> Where should we put the file used to store the key used to make cookies?
It
>> gets read at startup and updated daily.
> Nowhere. Those keys are ephemeral and shouldn't be stored at all, except
> maybe for debugging.
They are needed to use old cookies after restarting ntpd.
A side
On 3/7/19 1:22 PM, Gary E. Miller via devel wrote:
> Yo Richard!
>
> On Thu, 7 Mar 2019 11:06:58 -0600
> Richard Laager via devel wrote:
>
>> On 3/7/19 12:56 AM, Eric S. Raymond via devel wrote:
>>> JSON is C is normally *very* awkward, vastly worse than Go, because
>>> full JSON parse needs to
> One problem that just occured to me is that any actual restart will have to
> be done with dropped privileges already. The PID shouldn't change during
> restart anyway, so maybe that's taken care of already.
Currently, one of the privs it drops is being able to change privs so there is
no
Yo Richard!
On Thu, 7 Mar 2019 11:06:58 -0600
Richard Laager via devel wrote:
> On 3/7/19 12:56 AM, Eric S. Raymond via devel wrote:
> > JSON is C is normally *very* awkward, vastly worse than Go, because
> > full JSON parse needs to do fancy dancing with dynamic memory to
> > handle
Achim Gratz via devel :
> Hal Murray via devel writes:
> > Where should we put the file used to store the key used to make cookies?
> > It
> > gets read at startup and updated daily.
>
> Nowhere. Those keys are ephemeral and shouldn't be stored at all,
> except maybe for debugging.
I think
Richard Laager via devel :
> Either /var/lib/ntp, or as suggested in a previous message, /var/NTP
> seems fine for the default. The important part is discussed below.
I concur. I think I'd prefer the former slightly, but that's a pure
matter of taste (I dislike caps in filenames) so Hal gets to
Yo Achim!
On Thu, 07 Mar 2019 19:41:05 +0100
Achim Gratz via devel wrote:
> Hal Murray via devel writes:
> > Where should we put the file used to store the key used to make
> > cookies? It gets read at startup and updated daily.
>
> Nowhere. Those keys are ephemeral and shouldn't be stored
Hal Murray via devel writes:
> Where should we put the file used to store the key used to make cookies? It
> gets read at startup and updated daily.
Nowhere. Those keys are ephemeral and shouldn't be stored at all,
except maybe for debugging.
> Fedora and Debian put things like that in
Hal Murray via devel writes:
> Achim said:
>> In a nutshell, SIGHUP is already taken, but USR1 and USR2 are still
>> available. Thte idea is that one of these does the equivalent of
>> re-configuring via ntpq or a restart without loss of internal state (as far
>> as possible).
>
> USR1 and USR2
On 3/7/19 12:56 AM, Eric S. Raymond via devel wrote:
> JSON is C is normally *very* awkward, vastly worse than Go, because
> full JSON parse needs to do fancy dancing with dynamic memory to
> handle heterogenous arrays. The good news is that I ran into this
> problem back in 2009 on GPSD, solved
On 3/7/19 6:43 AM, Eric S. Raymond via devel wrote:
> Hal Murray via devel :
>>
>> Where should we put the file used to store the key used to make cookies? It
>> gets read at startup and updated daily.
>>
>> Fedora and Debian put things like that in /var/lib/ntp/
>> NetBSD and FreeBSD put them
Hal Murray via devel :
>
> Where should we put the file used to store the key used to make cookies? It
> gets read at startup and updated daily.
>
> Fedora and Debian put things like that in /var/lib/ntp/
> NetBSD and FreeBSD put them in /var/db/ntp/
Given that we don't have any intrinsic
On 3/6/19, Hal Murray via devel wrote:
>
> Where should we put the file used to store the key used to make cookies? It
>
> gets read at startup and updated daily.
>
> Fedora and Debian put things like that in /var/lib/ntp/
> NetBSD and FreeBSD put them in /var/db/ntp/
>
> There used to be a
49 matches
Mail list logo
