On 2/6/19 11:34 AM, Eric S. Raymond wrote:
> Richard Laager via devel :
>> On 2/5/19 7:49 PM, Richard Laager wrote:
>>> I have a specific proposal that I'll hopefully write up tonight, which
>>> may address the needs in this space.
>> I did some brainstorming on this with a colleague. I initially
Mark said:
> This sounds somewhat similar to the brilliant hack that is
> https://github.com/ioerror/tlsdate
Brilliant? Maybe if you do it for yourself. Not if you publish it in a way
that encourages others to do it.
This sounds somewhat similar to the brilliant hack that is
https://github.com/ioerror/tlsdate
On Wed, Feb 6, 2019 at 9:34 AM Eric S. Raymond via devel
wrote:
> Richard Laager via devel :
> > On 2/5/19 7:49 PM, Richard Laager wrote:
> > > I have a specific proposal that I'll hopefully write up
Richard Laager via devel :
> On 2/5/19 7:49 PM, Richard Laager wrote:
> > I have a specific proposal that I'll hopefully write up tonight, which
> > may address the needs in this space.
> I did some brainstorming on this with a colleague. I initially started
> with an approach that would consider
On 2/5/19 7:49 PM, Richard Laager wrote:
> I have a specific proposal that I'll hopefully write up tonight, which
> may address the needs in this space.
I did some brainstorming on this with a colleague. I initially started
with an approach that would consider the system clock (if after
On 2/4/19 3:40 PM, Hal Murray via devel wrote:
> At shutdown probably isn't good enough. You don't get clean shutdowns on a
> site wide power loss. Maybe shutdown and a weekly/monthly cron job.
Sure, that's a fair point. I'm not sure what the default behavior is on
Raspberry Pi systems.
> Are
On 2/4/19 12:07 PM, Hal Murray via devel wrote:
> Another complication with getting started after a building/site wide power
> loss is that getting time needs DNS and the local caching DNS server may be
> waiting for valid time.
The resolver really shouldn't be waiting for network time, as
Achim Gratz via devel :
> I visited DEC in Palo Alto one time and got to see the very first Alpha
> mainboard (with an alcohol heatpipe made from a glass tube atop the
> CPU).
Damn shame about the Alpha. That was a good design that DEC utterly botched the
positioning and marketing of.
Back
Richard said:
> That said, on a Pi, if you write the time to a file on shutdown, then you
> will be accurate enough for certificate checks to pass on reboots and outages
> shorter than a couple months.
Eric said:
> Thanks, it's important to know the order of magnitude of the slack there.
At
Hal Murray via devel writes:
> Here is an example that I've encountered. Suppose you have 6 servers with
> minsane set to 3 all using each other. When recovering from a power failure
> everybody ends up waiting for everybody else to get started.
Bootstrapping such configurations is indeed not
Another complication with getting started after a building/site wide power
loss is that getting time needs DNS and the local caching DNS server may be
waiting for valid time.
We may need a local cache - /etc/hosts? and a cron job to keep it up to date.
--
These are my opinions. I hate
On 2/4/19 11:37 AM, Eric S. Raymond wrote:
> Richard Laager via devel :
>> That said, on a Pi, if you write the time to a file on shutdown, then
>> you will be accurate enough for certificate checks to pass on reboots
>> and outages shorter than a couple months.
>
> Thanks, it's important to know
Richard Laager via devel :
> That said, on a Pi, if you write the time to a file on shutdown, then
> you will be accurate enough for certificate checks to pass on reboots
> and outages shorter than a couple months.
Thanks, it's important to know the order of magnitude of the slack there.
--
On 2/3/19 5:48 PM, Hal Murray wrote:
> [getting started]
>> How do certificates make this more complicated?
>
> Checking certificates depends on time.
>
> It may be a non problem if your system has a RTC/TOY clock. But they break.
> Raspberry Pis don't have them, ...
Right. We are going to
On 2/3/19 4:49 PM, Hal Murray via devel wrote:
> We'll need documentation to help people setup things to use NTS. I think the
> client side will be simple, a sentence or two.
>
> The server side is more complicated. I think we'll want HOWTO level docs.
> Probably one using Lets Encrypt and
We'll need documentation to help people setup things to use NTS. I think the
client side will be simple, a sentence or two.
The server side is more complicated. I think we'll want HOWTO level docs.
Probably one using Lets Encrypt and maybe others for when you already have a
certificate
16 matches
Mail list logo
