Re: git: b1c95af45488 - main - rc.conf: correct $ntp_leapfile_sources

On 2023-12-08 13:33:08 (+0800), Xin Li wrote:

> On 2023-12-07 17:07, Steffen Nurpmeso wrote:
>> Warner Losh wrote in
> [...]
>>   |>|The bundled version was from NIST ftp, but fetching from ftp for 
>> every
>>   |>|FreeBSD system out there was too scary for me.
>>   |>|
>>   |>|There may be some security / privacy concerns if we direct users 
>> to a
>>   |>|place that we do not have control, by the way.
>>   |>
>>   |> Interesting aspect!
>>   |
>>   |There might be, but this sounds somewhat speculative. What's the 
>> anticip\
>>   |ated
>>   |concerns?
>>
>> Maybe Xin Li has stumbled over the same thread as i after that
>> publicsuffix CVE of cURL (first sentence of the quoted message):
>>
>>   https://lists.gnu.org/archive/html/bug-wget/2014-03/msg00113.html
>>
>> What i mean is, the FreeBSD project and its pkg database, isn't
>> this a natural place for such a thing?  With guaranteed /
>> controlled availability.
>
> It could be me being too paranoid, just my $0.02 --
>
> Fetching the file would make a http request with "libfetch/2.0", and 
> the server knows the IP address, etc., if they log it somewhere.
>
> On the other hand, by fetching the file, it means that the periodic 
> script detected that the local leap-seconds file is outdated and NTP 
> leap-seconds file is also outdated.
>
> If we deliver leap-seconds using freebsd-update, this could mean the 
> user is running something old; with my recent change it means they are 
> running ntpd, which could be too much of information.
>
> Another concern is that it's somewhat vague if the URL would stay 
> valid.  Should they move (it happened to us for the NIST file, for 
> example, that gets moved to a different host), it would be both a loss 
> of functionality (file can't be updated) and a leak of information 
> (running an older version of configuration).
>
> These may be not really a high impact security concern, but some users 
> may be not very happy with this.  If we are hosting it at e.g. 
> www.freebsd.org, then we can make sure that the URL is always valid 
> and we have control of logging (e.g. we could exclude certain paths 
> from getting logged).

That was my reasoning for putting it on download.freebsd.org (or 
creating a data.freebsd.org).

I think the bikeshed is pretty liberally coated in paint by now.

- The previous implementation hardcoded a single URL: ietf.org
- My commit replaced it with another URL: iana.org

The only difference between the two URLs is that the previous one 
returns 404, while the new one is live.  Additionally, the new one has a 
chance of being updated before it expires.

Note that there is no polling here.  See src/libexec/rc/rc.d/ntpd.  When 
ntpd starts (i.e. when the system boots or the user runs "service ntpd 
fetch" or similar), the system's best guess at the current time is 
compared to the expiry date of the file on the filesystem.  If we're 
within the window before expiry or the file has expired, we attempt a 
fetch.

I don't think there's much risk of every FreeBSD system in the world 
starting at the same time.  Nevertheless, I don't like the idea of 
pointing every FreeBSD installation at a URL that isn't ours.  It's bad 
manners.  And we're victims of others doing that to us: a non-trivial 
fraction of traffic to www.FreeBSD.org is htpdate/1.0.  It will never go 
away.

While it feels like over-engineering to put this on our infrastructure, 
it's the polite thing to do.  I can set up a well-behaved cronjob on our 
infrastructure to poll the authoritative source.

I also have interesting opinions and trivia to share about leap seconds, 
but I don't think they're relevant to this particular discussion.  The 
only problem I want to solve today is the ugly 404 from "service ntpd 
fetch".

Philip

-- 
Philip Paeps
Senior Reality Engineer
Alternative Enterprises