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
