devel@ntpsec.org said:
> Why wouldn't we require a certain openssl version as there are a number of
> security vulnerabilities in (older) openssl?
Do you have a pointer to a list of the insecure versions with a summary of
the bug so we can see if we use that feature?
--
These are my opinions.
> So my opinion is that eliminating the openssl version check has only one
> drawback: we lose our single possibility to influence what openssl we build
> against. This /could/ have certain security implications and thus tainting
> ntpsec's name.
I don't think the version check is intended to ca
devel@ntpsec.org said:
> What kind of special labeling does ntpsnmpd require? Is putting
> "experimental" in the documentation sufficient? Does it need to give a
> warning on launch?
I'd put "experimental" in NEWS.
If you put something in the documentation it should probably say a bit about
ho
How am I supposed to figure out that the format is
--build-epoch=$date
rather than
--build-epoch $date
None of the examples show the equal sign.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpse
> After a bit more, incoclusive, chat with the user, it seems that he somehow
> started root with a PATH that did not include /usr/sbin where scons lives.
Why would scons go in /usr/sbin?
Is that a typo or a strange setup?
--
These are my opinions. I hate spam.
___
>> How am I supposed to figure out that the format is
>> --build-epoch=$date
>> rather than
>> --build-epoch $date
> Both forms work.
Thanks.
> Do we suggest that only 1 form works somewhere?
./waf configure --help shows the = version
I don't know of any place that says anything about which
> Where do you want to document it? Is "./waf configure --help" sufficient?
I don't have a good suggestion. It's the sort of detail that belongs in an
overview section, but nobody ever reads those.
Do we have an overview section?
> (packaging/packaging.txt has several typos related to --build
INSTALL says:
You can browse a summary of differences from legacy NTP here:
https://docs.ntpsec.org/latest/ntpsec.html
How does that compare to NEWS? Does the web version get updated with each
release? ...
--
These are my opinions. I hate spam.
__
I'm putting together a new system.
ntpq dies with:
ntpq: can't find Python NTP library -- check PYTHONPATH.
No module named util
Note is says "util", not "ntp.util". I've got ntpsec.pth and it works well
enough to fix the initial can't find error.
The build directory contains util.py and util
Thanks for testing this area.
Do you have a HOWTO type checklist that I can use to try to reproduce this
problem?
Were there any errors/warnings, possibly a long time back early in startup?
The hardpps option uses code that is not normally included in the kernel.
What kernel/distro are you us
I didn't see an announcement. In case you didn't notice...
commit 0b2beb1ffbebed5bd6d9ef615aac905df7e2f220 (tag: NTPsec_1_1_0)
Author: Mark Atwood
Date: Thu Mar 15 04:11:41 2018 +
version 1.1.0
Signed-off-by: Mark Atwood
--
These are my opinions. I hate spam.
___
Gary said:
> Currently I am playing with a Javad GPS that lets you set your PPS to GPS,
> SBAS, GLONASS, GALILEO, BeiDou, QZSS, IRNSS, UTC(USNO), UTC(SU), UTC(SBAS),
> UTC(GALILEO), UTC(BeiDou), UTC(QZZSS) or UTC(IRNSS)
What is the theoretical spread on all those different flavors of time? How
>> About time the NTP told the user what time is being served?
>Yes.
> It should got into an extension block.
It seems like a wild goose chase to me. We should focus on distributing UTC.
> It should got into an extension block.
> Two, one for time base, one for PPS source. ...
The PPS idea is
>From packaging/packaging.txt
> The shebang lines in our Python scripts point to
> "python". Part of our standard tests check that
> you can change that to "python3" without breaking
> anything.
What sort of testing is that? How do I run it on my setup?
--
These are my opinions. I hate spam
> Here is the log:
> 12-21T17:28:40 ntpd[6085]: PROTO: 0.0.0.0 0017 07 panic_stop +579076096 s;
> set clock manually within 1000 s.
> 12-21T17:28:40 ntpd[6085]: CLOCK: Panic: offset too big: 579076096.001
You only get one big jump with -g. Was there another jump earlier?
I looked at the code,
e...@thyrsus.com said:
> Alas, the client tools are difficult ebnough to test-jig that I have to
> hand-test under Python 3 before releases. I have a routine for this and I
> assume Ian does as well.
How much testing do you do by hand? Is that written down anyplace? Should
it be on the relea
> I'm thinking there were two jumps in the first little bit. Maybe 60
> seconds?
There should be something in the log file.
> Do you have a GPS clock that is prefer? Did you set the time to 2134,
> restart gpsd so it is in the wrong epoch? Then start ntpd? very repeatable
> for me. Even on
Eric said:
> I've never tried do describe that kind of testing because it's not easy to
> tell people without prior experience running the clients what a success/
> failure indication looks like. Of course alarm bells would go off on a
> crash, but the most definite thing I could say otherwise is
Gary said:
>> Was there a successful jump in the log file?
> You tell me, below is all I have for one test cycle. I have many similar
> test cycles logs.
This looks like a successful big jump to me.
12-31T16:00:24 ntpd[1931]: PROTO: 0.0.0.0 c41c 0c clock_step
+902266367.623732 s
09-10T21:01:27
> It just marks ALL chimers and refclocks as invalid. Then hangs.
Is it really hanging? This usually indicates success:
03-22T17:39:49 ntpd[10392]: PROTO: 204.17.205.30 901a 8a sys_peer
--
These are my opinions. I hate spam.
___
devel mailing li
Gary said:
> Also no way to put panicgate in the ntp.conf. At least the man page does
> not say how.
It's a flag, not a variable. -g sets it.
There are several tinker variables in this area. Details in
docs/includes/misc-options.txt
+tinker+ [+allan+ _allan_ | +dispersion+ _dispersion_ | +
Gary said:
>> It's a flag, not a variable. -g sets it.
> Yeah, and most daemons let you put flags in the config file.
I'd be happy with a policy that said anything you can do on the command line
you can also do in the config file, but it doesn't seem like a big deal.
[tinker doc for panic and
Gary said:
> I guess I did not wait long enough. ntpd, and ntpmon, hang for about three
> minutes, then wake up fine. Hang is at: 2134-03-01T17:57:35
> How do we explain that?
I'm not sure the case you are describing.
ntpd waits a while to be sure before stepping the clock. In general, that
>> I'm not sure the case you are describing.
> Hangs, as in unresponsive, frozen. ntpmon fails to update its output.
Is that a problem in ntpd or ntpmon? Try ntpq -p from another window and/or
tail rawstats to see if it is getting any answers.
> Seems to me any daemon that crashes itself on p
> I want my clock not stuck in 2134. -g alone does not fix that.
Back to the beginning. Where does 2134 come from?
> 'tos minsane 3' fixes it, unless I'm offline, which is pretty common for
> RasPi.
If you are getting bogus time from a local source and you want to work
offline, you are pr
Gary said:
> The raspberry pi has no RTC. When it starts cold, the time may well be in
> 1969. Somehow, not sure how, that becomes 2134. Then gpsd uses that as the
> GPS epoch, and things go downhill from there...
So gpsd does something stupid and you expect ntpd to figure out how to
recover
The 674 should be 474.
commit c8c888f8f2ef295c0ea5f854127069b3812e4c09
Author: Hal Murray
Date: Fri Mar 23 01:11:17 2018 -0700
Add logging of year(s) on large clock steps. Issue #674
--
These are my opinions. I hate spam.
___
devel maili
e...@thyrsus.com said:
> If it weren't in the public repo this would be easy - I'm enclosing a script
> that does this.
> Since it is, I'd have to edit it here, then unprotect the public master
> branch, then force-push, then reprotect it. This will take the public repo
> temporarily out of servi
rlaa...@wiktel.com said:
>> Are there any alternatives?
> See `git notes` to attach notes to objects (e.g.
> commits) after the fact without changing the object itself.
> Using the example from the man page, try something like this:
> git notes add -m 'The 674 should be 474.' c8c888f8
Thanks.
rlaa...@wiktel.com said:
> This should make notes push by default:
> git config --add remote.origin.push \
> '+refs/notes/commits:refs/notes/commits'
> Since this is the first set of notes, push them: git push
That said:
Counting objects: 3, done.
Delta compression using up to 4 threads.
Com
Gary said:
> Intesting, but now I gotta install a javascript interpreter. Yet another
> language and API to deal with. This will take a while...
Your web browser is probably already set up to handle javascript. I don't
know if you can use that to solve your problem, but it might be worth a
Anybody recognize this one"
[murray@hgm raw]$ git push
Everything up-to-date
[murray@hgm raw]$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
--
These are my opinions. I hate spam.
_
> You are not on master branch?
But git status said:
> On branch master
> What does this say:
> # git branch -la
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/origin/proto-refactor
remotes/origin/refgenfix
--
These are my opinions. I hate spam.
__
I made a fresh clone, fixed my .git/config, made the edit, commit-ed it, and
tried to push. It didn't work.
My "fixup" to .git/config ends up with:
[remote "origin"]
url = g...@gitlab.com:NTPsec/ntpsec.git
fetch = +refs/heads/*:refs/remotes/origin/*
push = +refs/notes/com
We've had a couple of bug reports involving musl. One recent. I think they
were on Alpine Linux, so I setup a box to see what would happen.
I've got things setup so it builds, but it doesn't run. Is anybody actually
running ntpsec on Alpine Linux?
Anybody recognize this?
Note that there is
It's working now. The problem was seccomp with various help from operator
errors to confuse debugging.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
This is from gcc:
gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20)
Which is shipping with Fedora 28 which is in beta. (I'm testing on a Pi 3.)
../../ntpd/ntp_loopfilter.c:366:13: warning: passing argument 1 to
restrict-qualified parameter aliases with argument 4 [-Wrestrict]
../../ntpd/ntp_loopfi
> The ANSI C function you look for is strncat, I'd think.
Actually, strncat checks for bogus source. We have constants for the source.
We want to check for overflowing the destination. Fortunately, we have
strlcat, even if the environment doesn't provide it.
Thanks for pointing me in the rig
Fedora 28 is out. It's using gcc 8 which has tightened some type checking.
Things like this will become much more common.
../../tests/ntpd/leapsec.c:434:19: warning: cast between incompatible
function types from âint (*)(FILE * restrict, const char * restrict,
...)â {aka âint (*)(stru
I just pushed a simple fix. GitLab tells me:
Subject: ntpsec | Pipeline #21417003 has failed for master | 7f1a350a
Anybody recognize this?
It works for me on Fedora 27. The tests that fail are clang-basic and
clang-refclocks and the same pair again and python-coverage.
The previous pipeline
> ... now we need to explicitly install the netbase package...?
Should that be added to buildprep?
Should we be using buildprep to setup the build environment?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://
> I've fixed the pipelines. ...
My pipeline retries are failing. Have they remembered the old setup recipe?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
> This was discussed on IRC and I wanted to make sure everyone was aware.
Was there anything interesting in the IRC discussion?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinf
devel@ntpsec.org said:
> There are no panaceas, but enabling this feature in Gitlab means that we can
> use it when we're ready for it.
I'm missing the big picture. I don't use merge requests. I just do a git
push.
What are the advantagesof a merge request if the submitter has write access?
If ntpd exits cleanly, it should clean up most of the allocated memory. I
assume the idea is to help raise the signal/noise ratio when looking for
leaks.
There is an emalloc.c in libntp/
There are a few calls to malloc rather than emalloc in ntpd/ We should fix
them, and poke around to make
Do we know if it works?
Should we have minimal documentation for how to set it up?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Eric said:
> SINGLESOCK: While messy and somewhat difficult, this is mostly a SMOP
> (Simple Matter of Programming). There is one potential technical risk,
> relatively minor I think.
> The reason for iterating over interfaces is that ntpd has the capability to
> block incoming packets by interf
e...@thyrsus.com said:
>> Could that feature be moved to a packet filter? I think most
>> OSes support some form of kernel level packet filtering. I'm not
>> familiar with any details.
> It could be. That would move control of it out of the ntp.conf file,
> though, which I think would count as
>> Is there a better term than alarm? The normal case will be to
>> wait for a packet to arrive with a N second timeout. That's just
>> a timeout on a poll.
> I use 'alarm' because I think of it as what alarm(2) does. I'm not wedded
> to that term.
alarm(2) uses a signal. I think of that as
e...@thyrsus.com said:
>> You should probably add cleaning up SHM to your list. I think
>> we want to make the read side read-only. The current approach
>> is polled. Maybe we should move to a socket. ???
> If we move to a socket it's not SHM any more.
I'm being sloppy and using "SHM" as a
> I don't think it can be made bakward-compatible with the existing one,
> though. Which means we might as well write a new triver onforming to the
> POSIX shared-memory interface.
I'd be happy to make a new driver and use POSIX. We could call it SHM2, or
SHMP, or ...
The real question is sho
Nice. Thanks.
mark.atw...@ntpsec.org said:
> There are a couple of different but very similar angles of approach to
> explain why a network security experts will not trust a userspace daemon to
> control it's own defensive packet filtering.
My reading of Eric's concerns is that he doesn't wa
Achim Gratz said:
> However, there is still value in the knowledge of which interface the packet
> came in so that ntpd can place different levels of trust depending on
> whether it's from a private (virtual) network segement, an internal or
> public network. Also, this information would potent
> We could kill the interface command, and let the usual syntax error happen.
> Or we could raise a special syntax error, calling out the need to use the
> packet filter instead. Then the question becomes, is it a warn-and-continue,
> or a error-and-halt?
Error and halt. (or set a flag to ha
There are command line options as well as ntp.conf:
-I Str interface Listen on an interface name or address
- may appear multiple times
-L no novirtualips Do not listen to virtual interfaces
--
These are my opinions. I hate spam.
_
k...@roeckx.be said:
> Do we only have 1/2 socket by default, or do we still have a listen socket
> per interface / ip address?
The current code has a socket per interface and a wildcard socket.
It also has another pile of (ugly) code to watch the interfaces and create a
new socket when an in
devel@ntpsec.org said:
> Provided you somehow route the packets from different networks to different
> (virtual) interfaces, you could measure and eventually compensate the
> asymmetry associated with that particular network provided you have some
> trusted time server on each side of the asymmet
> -I would definitely dropped. I don't comprehend "virtual interfaces". so I
> don't know if that should survive.
I've never used them, so be somewhat suspicious.
I'm pretty sure they are just what they sound like. If your eth0 is 1.2.3.4,
you can add another logical interface sharing the sam
devel@ntpsec.org said:
> Assuming we drop interface-name filtering, everything but the wildcard
> socket is going to go away. I think this will make tracking routing
> unecessary. I hope so, anyway. That code is a mess and I want to nuke it.
We don't track routing in the sense of BGP. We do t
> I gather it's been a while since you did anything with raw IP. What you want
> is sendto(2)/sendmsg(2). It's dead easy with those.
Yes. I think most of my work was with connected sockets.
I poked around a bit and haven't figured out how to use it, but it feels like
it should work. Other peo
We can filter by IP Address using the restrict command. We may have to add a
new flag that says don't poke any holes in me.
Case ALPHA:
> Nothing visible changes. Packet filtering by interface name is still
> supported by using IP_PKTINFO to get the interface of incoming packets.
recvmsg()
Focusing on the single in SINGLESOCK...
That doesn't work in FreeBSD. (see my previous message about no IP_PKTINFO)
Is that fatal?
Even if we have a single socket, do we still need to track interface changes?
If so, should we be discussing how to clean up that code?
---
The interface
e...@thyrsus.com said:
> >Is there a clean way to get notified when an interface comes or goes?
> Yes, that's what routing sockets gives you - notification when there's a
> routing change. (I don't understand the details well, but this seems to be
> the big picture.)
Are routing sockets availa
As much as I'd like to clean up this area, I think we should put it on the
back burner for now.
Maybe we should put a note in devel/ with a summary of what we have learned.
Actually, I'd like to see a class of notes there. We should use this as a
good example. I'm interested in things that a
> What makes it a better idea to wait?
I don't see any clean solution.
There are actually two separate areas. One is a single socket. The other is
interface tracking.
FreeBSD doesn't support single socket.
The interface cleanup gets tangled up with cleaning up the UI. I don't see
any clean
Let's step back from SINGLESOCK for a bit and focus on security.
Is the NTS draft-RFC in good enough shape that we can write code now?
I've studied it, but didn't understand things. My criteria for "understand"
is that I could explain it to somebody else. "Write code" might be another
test.
Ian Bruene said:
> 1. Stop using work queue. Handlers are called directly by the receivers.
> 2. Remove work queue checking by mainloop()
The receive loop is several layers down. The handler dispatching is up in
the main loop.
You may want to move the receive loop up to the main loop rather
> IIRC draft 10 didn't specify any certificate signing or out of channel
> distribution.
I thought I saw something like that, but that was a while ago and I was
expecting it and I wasn't reading that section carefully.
Plan A is to piggyback on the web certificate structure. Basically, the
Thanks.
devel@ntpsec.org said:
> This is just off the top of my head, but I wonder if this is ultimately
> going to need an SSH-style "leap of faith" trust model. For example, the
> first time NTP starts up, it would ignore the NotBefore and NotAfter
> attributes, but validate everything else in t
Richard Laager said:
> FWIW, for me, at least, the typical cases for daemons are:
> A) bind to localhost only (preferably at least ::1, else 127.0.0.1)
> B) bind to everything (with additional control happening in the kernel)
ntpd has 2 cases.
A) Client only - leaf node on the tree. (forest?
fallenpega...@gmail.com said:
> I still want to strip it all and delegate it to iptables, case OMEGA.
I'm happy with that. It may not be my first choice, but it's a decision we
can all understand and get back to work.
Thanks.
Eric said:
> Case OMEGA:
> -I, -L, and the interface config direc
[Home case - no admin]
> For them, just defaulting to listen on the wildcard address is OK. I think.
> Am I missing something?
I think the listen part is simple. We still need to track interfaces.
--
These are my opinions. I hate spam.
___
dev
> I don't undetstand why the tracking is needed.
If an interface goes away, you want to forget all the state you have for
servers that was collected using that interface.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.
Gary said:
> You may say that can be duplicate in your firewall settings. But maybe you
> want to run two ntpd ...
I assume firewalls are smart enough to allow different rules for different
servers.
"firewall" is potentially ambiguous in this discussion. It could refer to a
package running
e...@thyrsus.com said:
> I'm going to take this as direction to start by ripping out the interface
> directive in ntp.conf; that's orthogonal to the rest of this mess because
> it's restrictive and default behavior without it won't change.
We should consider the timing on this. Do we want to d
e...@thyrsus.com said:
> Isn't such state retention something that should be keyed by server IP
> address? I don't really see how the interface can be relevant.
Yes, there is state for each server ntpd is using stored by the server's IP
address.
Currently, part of that state is the interface
>> Maybe we should make a plan with a list of changes that
>> all have to get done before we can do another release.
> I want to do a triage pass over the bug list. That's about it.
Sorry I wasn't clear. I was thinking of releasing SINGLESOCK. Can we
release it in pieces or should we colle
> Hal, can you check the assertion about FreeBSD? Do we have a NetBSD system
> to test on?
>> I can't think of why we actually need it. I would have to scan
>> the code to look.
> If you have the bandwidth, please do check that premise.
I really want to get away from the SINGLESOCK stuff and
> I want to do a triage pass over the bug list. That's about it.
There is a RFC close to release that requires some changes in the crypto
area. Gary forwarded the announcement few days ago. I'll dig out the
details if anybody can't find it.
They aren't complicated. It should only take a day
4:30 Pacific time. It will be on YouTube in a day or two.
https://web.stanford.edu/class/ee380/
https://ee380.stanford.edu/Abstracts/180606.html
Python is a dynamically typed language, and some of its appeal derives from
this. Nevertheless, especially for large code bases, it would be nice
Gary said:
> But in the case of ntp.conf, the 'interface' is taking IPv4 addresses, IPv6
> addresses, and hostnames. So the ntp.conf 'interface' has nothing at all
> like an interface. It is an address.
Are you sure about that?
I think that "name" in that context refers to an interface name
e...@thyrsus.com said:
> I thought interface was restrictive rather than additive - I've never seen a
> configyration that uses it. I'll look into this; it might be that parts of
> it shouldn't be removed.
I think it is both. The first parameter can be "listen | ignore | drop".
The default c
I occasionally add msyslog lines when debugging. The DPRINTF stuff isn't
interesting - too much junk I don't want. When I'm cleaning up, should I
disable them with "if (0)", or delete them? Is there a better way? ...
Some/many of the prototypes in our header files are not very useful. I th
ctl_putsys in ntpd/ntp_control.c is full of things like:
case CS_MRU_MAXDEPTH:
ctl_putuint(sys_var[varid].text, mon_data.mru_maxdepth);
break;
CS_MRU_MAXDEPTH comes from a big line of things like:
#define CS_MRU_MAXDEPTH 30
It is also used in a big
[if (0) on debugging msyslog]
> What I do is delete them unless I think they might have continuing value, in
> which case I put them under DPRINTF.
I agree on the "continuing value" part.
For what I'm after, msyslog is more convenient that DPRINTF. I'm willing to
do an edit/build/restart cycl
Should I write
if (NULL != foo) ...
or is
if (foo) ...
OK?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Video at:
https://www.youtube.com/watch?v=GiZKuyLKvAA
I thought it was good. I really like type checking. I remember the first
time I figured out what was going on when the compiler gave me an error
message for using foo where I wanted foo*. Thank you!
I'm not enough of a language geek to
Can I pass parameters to a test?
I want to do something like
RUN_TEST_CASE(macencrypt, Encrypt, foo);
RUN_TEST_CASE(macencrypt, Encrypt, bar);
I suppose I could put the parameters in global variables.
--
These are my opinions. I hate spam.
I want to test reading a keys file.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Eric said:
> Nothing but the last LTS of Fedora still fails to support Python 3.
Fedora doesn't have LTS. They have the current release which comes out
roughly every 6 months, and support the previous release. There is usually a
month or so of overlap after a release when they support the o
Since we now require libcrypto, it looks like we can drop libntp/strl_obsd.c
with a bit of work on include/ntp_stdlib.h
OPENSSL_strlcpy(), OPENSSL_strlcat() and OPENSSL_strnlen() are
equivalents of the common C library functions and are provided for
portability.
--
These ar
Context is
https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/
I just pushed the code to add CMAC authentication.
There may be some very old systems with versions of OpenSSL/libcrypt that
don't support CMACs. I haven't conditionalized any of the code. Be alert to
errors about a missing ope
> I'm seeing some warnings on NTPsec git head with Gentoo stable on RasPi.
They are from my recent authentication work.
Does it happen on X86?
I thought we had gentoo on the gitlab collection. I didn't get any
complaints. Is there a magic flag we need to turn on? That seems like a
simple
devel@ntpsec.org said:
> Oh. Gary's builds must be using "./waf configure --enable-warnings". That
> enables "-Wswitch-default" and other extra checks where available. I'll
> check the implications of enabling that for all jobs and make also enabling
> "-Werror" so that GitLab builds will fail
devel@ntpsec.org said:
>> It only generates warnings on a few systems. I don't see why not
>> on the others. ??
> I looked at the code. Noting mysterious or suspcious there; has to be some
> kind of compiler version-skew issue.
Or a glitch in my brain.
I'm seeing it now in modern systems.
Eric said:
> It's not actually in the least difficult to design a skeleton that gets this
> right. I did it once. The point is that that warning is nothing we're doing
> wrong, it's GCC correctly noticing that the skeleton code kinda sucks, and we
> probably *would* have to build a custom skele
Gary said:
> In a perfect world someone rewrites ntp_parser.tab.c in a modern language.
What are the options in that area?
wc ntpd/ntp_parser.y
1460 3242 27686 ntpd/ntp_parser.y
--
These are my opinions. I hate spam.
___
devel mailing list
d
Eric said:
> The problem with the new-parser-generator theory is that as much fun as I'd
> have doing it, the net effect on stability and maintainability would probably
> be negative. There's that how-do-you-know-you-specced- the-same-grammar
> problem again.
Actually, I think the stability wo
e...@thyrsus.com said:
> What I think one needs for a test harness is the ability to dump the parse
> tree structure in a textual form. Changing parser generators won't give us
> that. What really matters is whether our target language has introspection
> capability and dynamic dump code.
Is t
> I had a look through libntp/ and tests/libntp/ today.
Nice. Thanks.
> I will go through these and check / patch everything to be where it should
> be, then start filling out the existing test files, etc.
There are 3 modules associated with authentication:
macencrypt.c, authkeys.c, and au
1201 - 1300 of 1887 matches
Mail list logo
