On 4/1/19 12:00 AM, Hal Murray via devel wrote:
There is some cleanup I've wanted to do in that area anyway. I'll try to get
to it tonight.
Noted, will wait before stirring it up.
Only that it seemed reasonable at the time. I was more interested in getting
things working than how to test
> After staring at the code for long enough I see a number of natural cleavage
> points for solving this issue. MR in a few days.
There is some cleanup I've wanted to do in that area anyway. I'll try to get
to it tonight.
> Is there any particular reason why SSL structs need to be passed
After staring at the code for long enough I see a number of natural
cleavage points for solving this issue. MR in a few days.
On 3/31/19 2:33 PM, Ian Bruene wrote:
Is there any particular reason why SSL structs need to be passed all
over the place to functions that do not depend on SSL
Let me try this again, as one standalone post, updated with the latest
information, including that we already have a documented "ca" option
which just needs implementation.
1) I agree that "noval" is useful for _debugging_. For now, and probably
indefinitely, it should stay.
2) Since "noval"
Yo Richard!
On Sun, 31 Mar 2019 21:06:25 -0500
Richard Laager via devel wrote:
> On 3/31/19 8:58 PM, Gary E. Miller via devel wrote:
> > Yo Richard!
> >
> > On Sun, 31 Mar 2019 18:47:35 -0500
> > Richard Laager via devel wrote:
> >
> >> This option would allow Gary's scenario to validate,
Yo Richard!
On Sun, 31 Mar 2019 18:33:54 -0500
Richard Laager via devel wrote:
> On 3/28/19 6:06 PM, Gary E. Miller via devel wrote:
> > On Thu, 28 Mar 2019 17:54:04 -0500
> > Richard Laager via devel wrote:
>
> > Updating the pins every 90 days
> > was a PITA.
> Yes, pinning the end
On 3/31/19 8:58 PM, Gary E. Miller via devel wrote:
> Yo Richard!
>
> On Sun, 31 Mar 2019 18:47:35 -0500
> Richard Laager via devel wrote:
>
>> This option would allow Gary's scenario to validate, without needing
>> to trust that root system-wide. He would presumably then eliminate
>> "noval"
Yo Richard!
On Sun, 31 Mar 2019 18:47:35 -0500
Richard Laager via devel wrote:
> This option would allow Gary's scenario to validate, without needing
> to trust that root system-wide. He would presumably then eliminate
> "noval" from that configuration line.
Failing to match a root CA in the
On Sun, Mar 31, 2019, 4:47 PM Richard Laager via devel
wrote:
> On 3/31/19 5:07 AM, Achim Gratz via devel wrote:
> > So yes, injecting the trust anchor(s) to use for a specific set of
> > NTS-KE would be the easier option.
>
> How about this:
>
> 1) Add a root=file (or dir?) option. This
On 3/31/19 5:07 AM, Achim Gratz via devel wrote:
> So yes, injecting the trust anchor(s) to use for a specific set of
> NTS-KE would be the easier option.
How about this:
1) Add a root=file (or dir?) option. This overrides the allowed roots
for that association. Only the root(s) in that file are
On 3/28/19 6:06 PM, Gary E. Miller via devel wrote:
> On Thu, 28 Mar 2019 17:54:04 -0500
> Richard Laager via devel wrote:
> Updating the pins every 90 days
> was a PITA.
Yes, pinning the end certificate or end public key is going to be
annoying if those rotate frequently. That's why you
> HPET should be OK, but if you can figure out why the TSC doesn't work that
> would be better. Check what clocksources are available, there might actually
> multiple TSC to chose from.
If I was going to chase this, I'd look at the kernel sources to see what
changed. I haven't seen similar
Is there any particular reason why SSL structs need to be passed all
over the place to functions that do not depend on SSL itself?
The notable example here is nts_ke_do_recieve, which only uses the SSL
to pass to SSL_read. I don't see any obvious reason that couldn't be
done in the calling
Udo van den Heuvel via devel writes:
>> Again no direct experience, but TSC should be stable these days unless
>> something is very much wrong with the drivers. ALso, I've seen reports
>> that Ryzen TSC is unstable when certain overclocking options are
>> activated.
>
> I am not overclocking this
Udo van den Heuvel via devel writes:
> udev.
So, with ldattach?
> rc.local
Use an udev rule again, much easier and more reliable, too.
>> I haven't seen one of these in person, but I believe the serial port
>> for Ryzen systems is part of the SuperIO, not the chipset itself.
>
> We have an
On 31-03-19 15:13, Achim Gratz via devel wrote:
> Udo van den Heuvel via devel writes:
>> But it was runnning on clocksource tsc.
>
> Again no direct experience, but TSC should be stable these days unless
> something is very much wrong with the drivers. ALso, I've seen reports
> that Ryzen TSC
Udo van den Heuvel via devel writes:
> But it was runnning on clocksource tsc.
Again no direct experience, but TSC should be stable these days unless
something is very much wrong with the drivers. ALso, I've seen reports
that Ryzen TSC is unstable when certain overclocking options are
activated.
On 31-03-19 14:43, Achim Gratz via devel wrote:
>> Same as it ever was:
>
> How are we supposed to know that if you don't say it?
Because I was happy and documented stuff on linuxpps.org.
Because no backups were made there the documentation went missing.
>> Garmin GPS18X getting power from USB,
Udo van den Heuvel via devel writes:
>> How is the GPS connected and how do you get the PPS in?
>
> Same as it ever was:
How are we supposed to know that if you don't say it?
> Garmin GPS18X getting power from USB, PPS is coming in on DCD I believe.
So is this a USB serial or is it an LVC model
On 31-03-19 13:37, Udo van den Heuvel via devel wrote:
>> As long as the time is that much off, yes it'll do that.
>
> Time is not that much off.
> It also happens when I sync the clock manually and then start ntpd.
>
>> Does anything in the boot log complain about unstable clock sources and
>>
On 31-03-19 13:16, Achim Gratz via devel wrote:
>> 186 is not sensible.
>> When I set it to 0.000 it still goes way up.
>
> As long as the time is that much off, yes it'll do that.
Time is not that much off.
It also happens when I sync the clock manually and then start ntpd.
> Does anything in
Udo van den Heuvel via devel writes:
> On 31-03-19 12:34, Achim Gratz via devel wrote:
>>> This behaviour is not normal.
>>
>> Uh, that is reporting from an ntpd that has just started and hasn't
>
> One that starts counting again after being up for a little while.
>
>> collected many statistics.
On 31-03-19 12:34, Achim Gratz via devel wrote:
>> This behaviour is not normal.
>
> Uh, that is reporting from an ntpd that has just started and hasn't
One that starts counting again after being up for a little while.
> collected many statistics. So the only way it can get a PLL frequency
>
Udo van den Heuvel via devel writes:
> When simply rebooting?
Again, the normally the clock is either set from RTC and then ntpdate or
ntpd with that allowed to step it.
> # ntpq -c kerninfo -pn
> associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer,
> pll offset:
Matthew Selsky via devel writes:
> Do you have an example of software the implements pinning as BOTH a
> central trust store + a specific pin?
Pinning doesn't provide a trust store, it restricts it.
> postfix allows the user to specific a trust-anchor file per destination. So a
> typical
Richard Laager via devel writes:
> I think public key (as opposed to certificate) pinning is the common
> approach these days. The application simply requires that one of the
> public keys in the chain match the pinned public key. The user can
> decide if they want to pin the server public key,
On Sat, Mar 30, 2019 at 08:05:41PM -0700, Hal Murray wrote:
> > A sockaddr is not meant to store the address, ...
>
> But the API wants a sockaddr.
>int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
> There is no hint in the man page that an IPv6 address won't fit.
>
>
On 31-03-19 11:21, Achim Gratz via devel wrote:
> Udo van den Heuvel via devel writes:
>>> How close are you to "true" time when you start the ntpd?
>>
>> Within 100's of ms if not better.
>
> If you are really that far off when you start ntpd,
When simply rebooting?
# ntpq -c kerninfo -pn
Udo van den Heuvel via devel writes:
>> How close are you to "true" time when you start the ntpd?
>
> Within 100's of ms if not better.
If you are really that far off when you start ntpd, it can very easily
peg at the 500ppm mark. That 500ppm limit means the clock will drift no
more than
Hal Murray via devel writes:
> Context is a helpful user who found a bug in the version of our code from his
> distro and wants to test a fix but isn't familiar with git or gitlab etc.
This is what I do on each new rasPi or TinkerBoard:
--8<---cut
30 matches
Mail list logo
