ntpdate.c unsafe buffer write - NTP

This is a discussion on ntpdate.c unsafe buffer write - NTP ; In ntpdate.c around line 542 (4.2.4p4)is the sequence if (!authistrusted(sys_authkey)) { char buf[10]; (void) sprintf(buf, "%lu", (unsigned long)sys_authkey); msyslog(LOG_ERR, "authentication key %s unknown", buf); exit(1); } Since unsigned long does not have a definite length on all machines, and with ...

+ Reply to Thread
Page 1 of 5 1 2 3 ... LastLast
Results 1 to 20 of 84

Thread: ntpdate.c unsafe buffer write

  1. ntpdate.c unsafe buffer write

    In ntpdate.c around line 542 (4.2.4p4)is the sequence
    if (!authistrusted(sys_authkey)) {
    char buf[10];

    (void) sprintf(buf, "%lu", (unsigned long)sys_authkey);
    msyslog(LOG_ERR, "authentication key %s unknown", buf);
    exit(1);
    }

    Since unsigned long does not have a definite length on all machines, and with the trailing
    zero certainly is potentially longer than 10 bytes, that buf is ripe for
    buffer overflow.
    It should be something like
    char buf[(sizeof(unsigned long)*12/5+2)];
    And/or the sprintf should be an snprintf.



  2. Re: ntpdate.c unsafe buffer write

    Bill,

    ntpdate is being deprecated.

    And it is *much* better to file reports like this using bugs.ntp.org as
    otherwise they tend to get lost in the wind.

    H
    --
    >>> In article <4FIqj.1315$FO1.16@edtnps82>, Unruh writes:


    Unruh> In ntpdate.c around line 542 (4.2.4p4)is the sequence if
    Unruh> (!authistrusted(sys_authkey)) { char buf[10];

    Unruh> (void) sprintf(buf, "%lu", (unsigned long)sys_authkey);
    Unruh> msyslog(LOG_ERR, "authentication key %s unknown", buf); exit(1);
    Unruh> }

    Unruh> Since unsigned long does not have a definite length on all machines,
    Unruh> and with the trailing zero certainly is potentially longer than 10
    Unruh> bytes, that buf is ripe for buffer overflow. It should be something
    Unruh> like char buf[(sizeof(unsigned long)*12/5+2)]; And/or the sprintf
    Unruh> should be an snprintf.



    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  3. Re: ntpdate.c unsafe buffer write

    Harlan Stenn writes:

    >Bill,


    >ntpdate is being deprecated.


    Maybe, but it should still not have bugs if it is actually still part of
    the distro.

    >And it is *much* better to file reports like this using bugs.ntp.org as
    >otherwise they tend to get lost in the wind.


    OK. Will do.


    >H
    >--
    >>>> In article <4FIqj.1315$FO1.16@edtnps82>, Unruh writes:


    >Unruh> In ntpdate.c around line 542 (4.2.4p4)is the sequence if
    >Unruh> (!authistrusted(sys_authkey)) { char buf[10];


    >Unruh> (void) sprintf(buf, "%lu", (unsigned long)sys_authkey);
    >Unruh> msyslog(LOG_ERR, "authentication key %s unknown", buf); exit(1);
    >Unruh> }


    >Unruh> Since unsigned long does not have a definite length on all machines,
    >Unruh> and with the trailing zero certainly is potentially longer than 10
    >Unruh> bytes, that buf is ripe for buffer overflow. It should be something
    >Unruh> like char buf[(sizeof(unsigned long)*12/5+2)]; And/or the sprintf
    >Unruh> should be an snprintf.




    >--
    >Harlan Stenn
    >http://ntpforum.isc.org - be a member!


  4. Re: ntpdate.c unsafe buffer write

    >>> In article , Unruh writes:

    Unruh> Harlan Stenn writes:
    >> Bill,


    >> ntpdate is being deprecated.


    Unruh> Maybe, but it should still not have bugs if it is actually still part
    Unruh> of the distro.

    I mostly agree with you. And one reason there are a bunch of outstanding
    bugs in ntpdate is that nobody has stepped forward to maintain it,
    especially after the last round of bugs where we decided that the best thing
    to do for ntpdate was kill it off and replace it with sntp.

    Speaking of which, I need to ping the folks who volunteered to work on the
    SNTP code and see what the status is.

    >> And it is *much* better to file reports like this using bugs.ntp.org as
    >> otherwise they tend to get lost in the wind.


    Unruh> OK. Will do.

    I saw that bug get filed - thanks a bunch!
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  5. Re: ntpdate.c unsafe buffer write

    Harlan Stenn writes:

    >>>> In article , Unruh writes:


    >Unruh> Harlan Stenn writes:
    >>> Bill,


    >>> ntpdate is being deprecated.


    >Unruh> Maybe, but it should still not have bugs if it is actually still part
    >Unruh> of the distro.


    >I mostly agree with you. And one reason there are a bunch of outstanding
    >bugs in ntpdate is that nobody has stepped forward to maintain it,
    >especially after the last round of bugs where we decided that the best thing
    >to do for ntpdate was kill it off and replace it with sntp.


    >Speaking of which, I need to ping the folks who volunteered to work on the
    >SNTP code and see what the status is.


    >>> And it is *much* better to file reports like this using bugs.ntp.org as
    >>> otherwise they tend to get lost in the wind.


    >Unruh> OK. Will do.


    >I saw that bug get filed - thanks a bunch!


    Where it met with the same reaction-- ntpdate is deprecated so why fix the
    bug. Do you want to bet that ntpdate will still be there in 2010?


  6. Re: ntpdate.c unsafe buffer write

    Bill,

    Unruh wrote:
    > Harlan Stenn writes:
    >>I saw that bug get filed - thanks a bunch!

    >
    > Where it met with the same reaction-- ntpdate is deprecated so why fix the
    > bug. Do you want to bet that ntpdate will still be there in 2010?


    As already mentioned in bugzilla, I'll prepare a patch to fix this.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  7. Re: ntpdate.c unsafe buffer write

    Harlan,

    My position on ntpdate and sntp has always been clear. Remove them both
    from the distribution and let other folks contribute sntp products. The
    standards labs in various contries do not recommend the NTP reference
    implementation, they recommend other shrinkwrap products. There is no
    need for folks to download the reference implementatino only to bring up
    an sntp product.

    The matter of concern is an sntp product that strictly conforms to the
    NTPv4 specification as it applies to sntp. There is at least one
    contributor testing the kiss-o'-death rate limit and has apparently
    actually read rfc 2030. On the other hand, there are numerous examples
    of clients that casually violate the rate rules both at servers we
    operate here and at the national labs. What we should be doing is
    supporting those products that play by the rules and that are maintained
    by other players.

    Dave

    Harlan Stenn wrote:
    > Bill,
    >
    > ntpdate is being deprecated.
    >
    > And it is *much* better to file reports like this using bugs.ntp.org as
    > otherwise they tend to get lost in the wind.
    >
    > H
    > --
    >
    >>>>In article <4FIqj.1315$FO1.16@edtnps82>, Unruh writes:

    >
    >
    > Unruh> In ntpdate.c around line 542 (4.2.4p4)is the sequence if
    > Unruh> (!authistrusted(sys_authkey)) { char buf[10];
    >
    > Unruh> (void) sprintf(buf, "%lu", (unsigned long)sys_authkey);
    > Unruh> msyslog(LOG_ERR, "authentication key %s unknown", buf); exit(1);
    > Unruh> }
    >
    > Unruh> Since unsigned long does not have a definite length on all machines,
    > Unruh> and with the trailing zero certainly is potentially longer than 10
    > Unruh> bytes, that buf is ripe for buffer overflow. It should be something
    > Unruh> like char buf[(sizeof(unsigned long)*12/5+2)]; And/or the sprintf
    > Unruh> should be an snprintf.
    >
    >
    >


  8. Re: ntpdate.c unsafe buffer write

    >>> In article , "David L. Mills" writes:

    David> Harlan, My position on ntpdate and sntp has always been clear. Remove
    David> them both from the distribution and let other folks contribute sntp
    David> products.

    Yes, your position has been clear and your opinion has been noted.

    David> The standards labs in various contries do not recommend the
    David> NTP reference implementation, they recommend other shrinkwrap
    David> products.

    I'd appreciate references on this point. And how it is germane to this
    discussion?

    David> There is no need for folks to download the reference
    David> implementatino only to bring up an sntp product.

    Yes, which is why the sntp code can be trivially bundled separately.

    The feedback I have received is that the majority of folks want the
    distribution to contain both ntp and sntp.

    David> The matter of concern is an sntp product that strictly conforms to
    David> the NTPv4 specification as it applies to sntp. There is at least one
    David> contributor testing the kiss-o'-death rate limit and has apparently
    David> actually read rfc 2030. On the other hand, there are numerous
    David> examples of clients that casually violate the rate rules both at
    David> servers we operate here and at the national labs.

    Yup.

    David> What we should be
    David> doing is supporting those products that play by the rules and that
    David> are maintained by other players.

    This depends first on the definition of "we", and then on the definition of
    "supporting".

    The people who talk to me want an SNTP implementation from the NTP Project.

    Nobody is expecting you to ride herd over any SNTP code that may or may not
    be part of the same tarball that includes NTP. I am mulling over different
    ideas in this regard.

    Two obvious ways to go on NTP/SNTP are to have shared code, or completely
    separate codebases. There is some middle ground regarding "support"
    libraries.

    I see difficult tradeoffs with either approach.
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  9. Re: ntpdate.c unsafe buffer write

    "David L. Mills" writes:

    >Harlan,


    >My position on ntpdate and sntp has always been clear. Remove them both
    >from the distribution and let other folks contribute sntp products. The
    >standards labs in various contries do not recommend the NTP reference
    >implementation, they recommend other shrinkwrap products. There is no
    >need for folks to download the reference implementatino only to bring up
    >an sntp product.


    Surely supplying a properly working sntp client is better than relying on
    others to do so ( or rather not to do so). Ie, you write a client which
    works well, and since you are the ntp source, yours wins out over the bad
    ones. Otherwise you rely on the others to badly impliment the protocol.


    >The matter of concern is an sntp product that strictly conforms to the
    >NTPv4 specification as it applies to sntp. There is at least one
    >contributor testing the kiss-o'-death rate limit and has apparently
    >actually read rfc 2030. On the other hand, there are numerous examples
    >of clients that casually violate the rate rules both at servers we
    >operate here and at the national labs. What we should be doing is
    >supporting those products that play by the rules and that are maintained
    >by other players.


    >Dave


    >Harlan Stenn wrote:
    >> Bill,
    >>
    >> ntpdate is being deprecated.
    >>
    >> And it is *much* better to file reports like this using bugs.ntp.org as
    >> otherwise they tend to get lost in the wind.
    >>
    >> H
    >> --
    >>
    >>>>>In article <4FIqj.1315$FO1.16@edtnps82>, Unruh writes:

    >>
    >>
    >> Unruh> In ntpdate.c around line 542 (4.2.4p4)is the sequence if
    >> Unruh> (!authistrusted(sys_authkey)) { char buf[10];
    >>
    >> Unruh> (void) sprintf(buf, "%lu", (unsigned long)sys_authkey);
    >> Unruh> msyslog(LOG_ERR, "authentication key %s unknown", buf); exit(1);
    >> Unruh> }
    >>
    >> Unruh> Since unsigned long does not have a definite length on all machines,
    >> Unruh> and with the trailing zero certainly is potentially longer than 10
    >> Unruh> bytes, that buf is ripe for buffer overflow. It should be something
    >> Unruh> like char buf[(sizeof(unsigned long)*12/5+2)]; And/or the sprintf
    >> Unruh> should be an snprintf.
    >>
    >>
    >>


  10. Re: ntpdate.c unsafe buffer write

    Harlan,

    You make some good points. However, if folks want SNTP from here I think
    they would prefer it in its own distribution rather than bundle it with
    the huge NTP distribution. You can make a strong argument to host here
    if the claim that both NTP and SNTP are strictly specification
    conformant. That's why I rewrote the SNTP documentation to take out all
    mention that it could be used as a server.

    The three of us that wrote rfc 2030 had just come down from a massive
    clogging situation at UWisc and NIST and were frantic to get across the
    need for polite client behavior. This has to do with DNS lookups, poll
    intervals and behavior when no response is received. Even so, there
    remains at least three violators of those principles right now on two of
    our public servers. Therefore, if an SNTP product leaves here, it really
    and surely should compley with the on-wire protocol in the NTPv4 spec
    and these best practices.

    A aside, I should reveal my biases. At the moment, to configure the
    current software on an Sun Ultra 5 takse 12 minutes, 6 minutes for NTP
    and 6 minutes for SNTP. But, it takes only 8 minutes to compile and link
    all programs, including both NTP and SNTP. It is not now possible to
    build either separately.

    As I have said privately before, the NTP daemon can be operated in SNTP
    mode which does everything NTP does, but terminates just after the clock
    has been set for the first time. Yes, it has a rather large footprint,
    but it lasts only about 11 seconds. The downside is that it requires a
    configuration file containing a list of servers. If this were done on
    the command line, NTP in SNTP mode would be indistinguishable from SNTP
    other than a command line option.

    So, the ideal solution would seem to include a list of links on the NTP
    home page to external sites and in addition internal links to the NTP
    and SNTP distributions along with a statement that both are strictly
    specification conformant. That might inspire other wannabees to make and
    enforce similar claims.

    Dave

    Harlan Stenn wrote:
    >>>>In article , "David L. Mills" writes:

    >
    >
    > David> Harlan, My position on ntpdate and sntp has always been clear. Remove
    > David> them both from the distribution and let other folks contribute sntp
    > David> products.
    >
    > Yes, your position has been clear and your opinion has been noted.
    >
    > David> The standards labs in various contries do not recommend the
    > David> NTP reference implementation, they recommend other shrinkwrap
    > David> products.
    >
    > I'd appreciate references on this point. And how it is germane to this
    > discussion?
    >
    > David> There is no need for folks to download the reference
    > David> implementatino only to bring up an sntp product.
    >
    > Yes, which is why the sntp code can be trivially bundled separately.
    >
    > The feedback I have received is that the majority of folks want the
    > distribution to contain both ntp and sntp.
    >
    > David> The matter of concern is an sntp product that strictly conforms to
    > David> the NTPv4 specification as it applies to sntp. There is at least one
    > David> contributor testing the kiss-o'-death rate limit and has apparently
    > David> actually read rfc 2030. On the other hand, there are numerous
    > David> examples of clients that casually violate the rate rules both at
    > David> servers we operate here and at the national labs.
    >
    > Yup.
    >
    > David> What we should be
    > David> doing is supporting those products that play by the rules and that
    > David> are maintained by other players.
    >
    > This depends first on the definition of "we", and then on the definition of
    > "supporting".
    >
    > The people who talk to me want an SNTP implementation from the NTP Project.
    >
    > Nobody is expecting you to ride herd over any SNTP code that may or may not
    > be part of the same tarball that includes NTP. I am mulling over different
    > ideas in this regard.
    >
    > Two obvious ways to go on NTP/SNTP are to have shared code, or completely
    > separate codebases. There is some middle ground regarding "support"
    > libraries.
    >
    > I see difficult tradeoffs with either approach.


  11. Re: ntpdate.c unsafe buffer write

    David L. Mills wrote:
    > Harlan,
    >
    > You make some good points. However, if folks want SNTP from here I think
    > they would prefer it in its own distribution rather than bundle it with
    > the huge NTP distribution. You can make a strong argument to host here


    I don't think you are ever going to get rid of ntpdate from the
    distribution (as supplied by packagers and vendors) until ntpd offers a
    mode which sets the time within about one second of being started. I'm
    not convinced that SNTP will displace ntpdate for this purpose. People
    don't want to delay boot sequences, but they also don't want to start
    applications until the time has been set.

  12. Re: ntpdate.c unsafe buffer write

    David Woolley wrote:
    > David L. Mills wrote:
    >
    >> Harlan,
    >>
    >> You make some good points. However, if folks want SNTP from here I
    >> think they would prefer it in its own distribution rather than bundle
    >> it with the huge NTP distribution. You can make a strong argument to
    >> host here

    >
    >
    > I don't think you are ever going to get rid of ntpdate from the
    > distribution (as supplied by packagers and vendors) until ntpd offers a
    > mode which sets the time within about one second of being started. I'm
    > not convinced that SNTP will displace ntpdate for this purpose. People
    > don't want to delay boot sequences, but they also don't want to start
    > applications until the time has been set.


    How long does "ntpd -g" take to set the time? As I understand it, it's
    supposed to query the configured servers, make a "best guess" as to what
    time it is, set that, and then go to normal operation.

    That should put you within a second or so. If you need better, either
    wait for it, or keep your server alive 24x7x365. I think most data
    centers do run 24x7x365. If you're talking about a "data center" that
    lives under the boss's desk, consider buying a UPS and hope that the
    power doesn't fail for longer than the run time.



  13. Re: ntpdate.c unsafe buffer write

    Richard B. Gilbert wrote:
    > David Woolley wrote:
    >> David L. Mills wrote:
    >>
    >>> Harlan,
    >>>
    >>> You make some good points. However, if folks want SNTP from here I
    >>> think they would prefer it in its own distribution rather than bundle
    >>> it with the huge NTP distribution. You can make a strong argument to
    >>> host here

    >>
    >>
    >> I don't think you are ever going to get rid of ntpdate from the
    >> distribution (as supplied by packagers and vendors) until ntpd offers
    >> a mode which sets the time within about one second of being started.
    >> I'm not convinced that SNTP will displace ntpdate for this purpose.
    >> People don't want to delay boot sequences, but they also don't want to
    >> start applications until the time has been set.

    >
    > How long does "ntpd -g" take to set the time? As I understand it, it's
    > supposed to query the configured servers, make a "best guess" as to what
    > time it is, set that, and then go to normal operation.
    >
    > That should put you within a second or so. If you need better, either
    > wait for it, or keep your server alive 24x7x365. I think most data
    > centers do run 24x7x365. If you're talking about a "data center" that
    > lives under the boss's desk, consider buying a UPS and hope that the
    > power doesn't fail for longer than the run time.


    David is right.

    He means be done with it, including hard-setting the clock, within a second.
    The accuracy expected, based on "ntpdate -b" as the benchmark you are trying to
    replace, is within a small number of milliseconds of the specified servers.

    Sorry, "ntpd -q" doesn't meet the requirements.

    -Tom

  14. Re: ntpdate.c unsafe buffer write

    On 2008-02-09, Tom Smith wrote:

    > He means be done with it, including hard-setting the clock, within a
    > second. The accuracy expected, based on "ntpdate -b" as the benchmark
    > you are trying to replace, is within a small number of milliseconds of
    > the specified servers.
    >
    > Sorry, "ntpd -q" doesn't meet the requirements.


    You need to be realistic about your requirements.

    In the case of systems which run time sensitive services, or are rarely
    rebooted, an ~11 second pause, which is _is_ about the amount of time it
    takes for 'ntpq -gq' to do a quick sanity check on your configured time
    servers and set the clock, is not unreasonable.

    In the case of systems which do not run time critical services there
    is no reason why ntpd can not be started with -g and be allowed to set
    the clock as the boot progresses. In most cases the clock will be set
    before, or very shortly after, the boot sequence is completed.

    The big issue in the "ntpdate vs ntpd -gq" debate is the fact that the
    former may be used over unprivileged ports while the latter can not.
    This gives ntpdate the advantage in situtations where a firewall is
    blocking port 123/UDP.

    That's what you should be complaining about, not some trivial 11 second
    delay.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  15. Re: ntpdate.c unsafe buffer write

    >>> In article <47ad8971$0$514$5a6aecb4@news.aaisp.net.uk>, David Woolley writes:

    David> I don't think you are ever going to get rid of ntpdate from the
    David> distribution (as supplied by packagers and vendors) until ntpd offers
    David> a mode which sets the time within about one second of being started.

    The current sntp code can do this now.

    David> I'm not convinced that SNTP will displace ntpdate for this purpose.

    Why not?

    David> People don't want to delay boot sequences, but they also don't want
    David> to start applications until the time has been set.

    Then I submit you are focusing a bit too deeply on the details and invite
    you to take a step back.

    I believe the current set of tools can be used in a variety of combinations
    that will handle the various cases to the best that we know how to do them.

    If you want to get the time set *now* and then start, regardless of how well
    the system can maintain that time, we can do that (sntp/ntpdate+ntpd).

    If you want to set the time ASAP and have stable system time before starting
    your apps, in the usual case you are talking about 11 seconds for this to
    happen (ntpd -g, with iburst, early in the boot sequence, using ntp-wait
    later in the boot sequence, just before starting time-critical services).

    Near as I can recall, any other cases have looser constraints so they're not
    particularly interesting for this conversation.
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  16. Re: ntpdate.c unsafe buffer write

    Guys,

    This is all discussed pretty well at:

    http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate

    So far everything I have seen in this thread has already been covered on
    that page.
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  17. Re: ntpdate.c unsafe buffer write

    Harlan Stenn wrote:
    > Guys,
    >
    > This is all discussed pretty well at:
    >
    > http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
    >
    > So far everything I have seen in this thread has already been covered on
    > that page.



    I just followed the above link. I see ONE feature missing!

    ntpdate -Du (I think it's -D) does NOT set the clock, it simply tells
    you what it would have done had it been permitted to do so. I suppose
    this feature is not essential but I've used it a time or two to find out
    how my time agreed, or disagreed, with some other server.


  18. Re: ntpdate.c unsafe buffer write

    Harlan Stenn wrote:
    >>>> In article <47ad8971$0$514$5a6aecb4@news.aaisp.net.uk>, David Woolley writes:

    >


    > David> I'm not convinced that SNTP will displace ntpdate for this purpose.
    >
    > Why not?


    Because ntpdate is fixed in the popular culture and, for the ordinary
    user, SNTP doesn't offer any obvious advantages.
    >


    > If you want to get the time set *now* and then start, regardless of how well
    > the system can maintain that time, we can do that (sntp/ntpdate+ntpd).


    Not in Dave Mills future of ntpd, as you don't get ntpdate or SNTP.

    >
    > If you want to set the time ASAP and have stable system time before starting
    > your apps, in the usual case you are talking about 11 seconds for this to
    > happen (ntpd -g, with iburst, early in the boot sequence, using ntp-wait
    > later in the boot sequence, just before starting time-critical services).


    I suspect that only sets the time to the nearest 128ms, unless it does
    something that ntpd doesn't normally do.

  19. Re: ntpdate.c unsafe buffer write

    >>> In article , "David L. Mills" writes:

    David> Harlan, You make some good points. However, if folks want SNTP from
    David> here I think they would prefer it in its own distribution rather than
    David> bundle it with the huge NTP distribution.

    That's not the feedback I have received, but I will note it would be
    possible to have an "ntp+sntp" distribution and a separate "sntp"
    distribution. It would take a couple of days' time to do this, and I have
    much hotter fires to put out first. Additionally, there will be significant
    changes in the code layout as the sntp code is overhauled, so I'd prefer to
    wait on this additional distribution tarball until that effort is completed.

    David> You can make a strong
    David> argument to host here if the claim that both NTP and SNTP are
    David> strictly specification conformant. That's why I rewrote the SNTP
    David> documentation to take out all mention that it could be used as a
    David> server.

    OK.

    David> The three of us that wrote rfc 2030 had just come down from a massive
    David> clogging situation at UWisc and NIST and were frantic to get across
    David> the need for polite client behavior. This has to do with DNS lookups,
    David> poll intervals and behavior when no response is received. Even so,
    David> there remains at least three violators of those principles right now
    David> on two of our public servers. Therefore, if an SNTP product leaves
    David> here, it really and surely should compley with the on-wire protocol
    David> in the NTPv4 spec and these best practices.

    We're on the same page.

    David> A aside, I should reveal my biases. At the moment, to configure the
    David> current software on an Sun Ultra 5 takse 12 minutes, 6 minutes for
    David> NTP and 6 minutes for SNTP. But, it takes only 8 minutes to compile
    David> and link all programs, including both NTP and SNTP. It is not now
    David> possible to build either separately.

    I'm not sure what you mean about building separately.

    We *used* to be able to build:

    - ntp + sntp:
    configure ; make

    - ntp only:
    configure --without-sntp ; make

    - sntp only:
    cd sntp ; configure ; make

    About a year and a half ago we got the SNTP code to the point where it would
    build on Unix (nobody has done the work for Windows, but apparently nobody
    is asking for it there either - http://bugs.ntp.org/500 has the details).

    Since we've been announcing that ntpdate will be deprecated because its
    functionality can be replaced by various combinations of ntpd and sntp, we
    made sntp a 'required' part of the NTP build.

    David> As I have said privately before, the NTP daemon can be operated in
    David> SNTP mode which does everything NTP does, but terminates just after
    David> the clock has been set for the first time. Yes, it has a rather large
    David> footprint, but it lasts only about 11 seconds. The downside is that
    David> it requires a configuration file containing a list of servers. If
    David> this were done on the command line, NTP in SNTP mode would be
    David> indistinguishable from SNTP other than a command line option.

    You have provided a mechanism for doing this. It will be an acceptable
    choice for a good number of people. But there is a significant group of
    people for whom this particular mechanism will not work.

    They require any or all of the following:

    - a small footprint
    - set the time with the smallest possible delay

    While we might be able to achieve the "smallest delay" with ntpd, I don't
    currently see how we can do that while also offering full NTP support from a
    single binary and achieve the small footprint.

    David> So, the ideal solution would seem to include a list of links on the
    David> NTP home page to external sites and in addition internal links to the
    David> NTP and SNTP distributions along with a statement that both are
    David> strictly specification conformant. That might inspire other wannabees
    David> to make and enforce similar claims.

    We already have internal and external links on the ntp.org site.

    And if somebody wants additional or different information there, contact
    information is also listed in what should be obvious places.
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  20. Re: ntpdate.c unsafe buffer write

    >>> In article <47AE13D7.9050902@comcast.net>, "Richard B. Gilbert" writes:

    Richard> Harlan Stenn wrote:
    >> Guys, This is all discussed pretty well at:
    >> http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate So far everything
    >> I have seen in this thread has already been covered on that page.


    Richard> I just followed the above link. I see ONE feature missing!

    Richard> ntpdate -Du (I think it's -D) does NOT set the clock, it simply
    Richard> tells you what it would have done had it been permitted to do so.
    Richard> I suppose this feature is not essential but I've used it a time or
    Richard> two to find out how my time agreed, or disagreed, with some other
    Richard> server.

    I am not familiar with ntpdate -D, but -u is listed and 'sntp -u hostname'
    will tell you the offset without setting the clock,

    I believe we have the capability you describe. It's not yet explicitly
    on the "Functionality List", though.

    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

+ Reply to Thread
Page 1 of 5 1 2 3 ... LastLast