Re: git: b1c95af45488 - main - rc.conf: correct $ntp_leapfile_sources
Date: Fri, 08 Dec 2023 17:17:12 UTC
Warner Losh wrote in <CANCZdfrQU-7yXbzMT8fCmBp=w=CqTVWCgwdXJNXXcHBiOb7vvw@mail.gmail.com>: |On Thu, Dec 7, 2023 at 6:07 PM Steffen Nurpmeso <steffen@sdaoden.eu> wrote: |> Warner Losh wrote in |> <CANCZdfpHWRECi=DyhxJAW4MkA-CyPLK=OSdSwBdKQJ57MyPwNA@mail.gmail.com>: |>|On Thu, Dec 7, 2023 at 3:27 PM Steffen Nurpmeso <steffen@sdaoden.eu> |> wrote: |>|> Xin Li wrote in |>|> <d75b041f-05f8-44c1-8de6-1fef89b7e537@delphij.net>: |>|>|On 2023-12-06 22:34, Philip Paeps wrote: |>|>|> On 2023-12-07 14:26:05 (+0800), Warner Losh wrote: |>|>|>> We should point to bipm |>|>|>> https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list since |>|> they |>|>|>> are |>|>|>> the source of truth, no? |>|>|> |>|>|> I went for the IANA copy because data.iana.org is a much shorter and |>|>|> trustworthy looking URL. And it's also where other operating systems |>|>|> get their copies. |>|>| |>|>|My understanding is that IANA's copy is part of tzdata and it's only |>|>|updated when a new set of zone data is released, so it's sometimes |>|>|outdated. It is actually going to be outdated really soon by the way. |>|> |>|> But nothing will change. |>|> It is only about the included end-of-life tag why there is |>|> discussion at all. |>|> The IANA TZ data is always updated as necessary, "early enough". |>| |>|Yes. TZ data updates multiple times a year. The lead time on NIST/BIPM |>|updating the file usually is within days or weeks after the new leap is |>|announced. |>|But ntpd can't possibly use it for about 5 months. TZ updates are plenty |>|fast. |>| |>|The bigger problem is that we have to do a EN to get a new set of zone |>|files. If we had a way to fetch them, we could just copy this file from |> the |>|updated |>|zone files. |> |> I never spoke against fetching the plain file (who is my role in |> this project in the end?), i only spoke against using the server |> of the french institute directly. |> | |The French institute is the source of truth. The BIPM defines what |UTC is, based on atomic clock measurements from all over the world. |A subagency, the IERS, measures the delta between UTC and |the earth's orientation and makes the determination of when a |leap second is scheduled. | |There's no cryptographic signature of this file. There is a hash |that ensures it's not corrupted, but it can't be verified as authoritative |since it's just a SHA hash. By grabbing it from BIPM, the source |of truth for time, we at least get their TLS certs to back up the file. |Grabbing it from anywhere else means our users have to trust the |other places. While the IETF/IANA are trustworthy, it's one level |removed. | |Then again, given this file, in this context, is only used when ntpd |can't otherwise determine the leap seconds, so maybe that high |level of trust isn't strictly needed. The lack of easy verification |of this file has been discussed in the time community on and off |for the last 25 or more years. Sorry i do not get your road in the context of this thread. Anyhow, as another point, this is what Paul Eggert of TZ said today on the thread on the IANA list: TZDB uses the NIST version of leap-seconds.list rather than the IERS version, as the NIST version is clearly public domain and so this way we don't have to worry about copyright issues. However, the IERS version should work fine with either NTPsec or with other downstream uses, such as TZDB itself (that is, if you're not worried about copyright). --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | | Only in December: lightful Dubai COP28 Narendra Modi quote: | A small part of humanity has ruthlessly exploited nature. | But the entire humanity is bearing the cost of it, | especially the inhabitants of the Global South. | The selfishness of a few will lead the world into darkness, | not just for themselves but for the entire world.