Re: Fssh_kex_exchange_identification: Connection closed by remote host (anon...@git.freebsd.org)
On 2022-07-04 23:19:07 (+0800), John Kennedy wrote: Sometime this AM (> 07:10:39 PST8PDT, < 08:15 2022/7/4) the anonymous git repo seems to have developed an issue: # git remote -v freebsd anon...@git.freebsd.org:src.git (fetch) freebsd anon...@git.freebsd.org:src.git (push) # git pull -v Fssh_kex_exchange_identification: Connection closed by remote host Connection closed by 149.20.1.203 port 22 fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. I've been upgrading cluster machines this week. The GeoDNS should have directed you to another mirror. Perhaps something was cached for longer than expected. That mirror should be up again now though. Please let me know if the problem persists. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Re: ntpd: leap-seconds.list expiration
On 2023-12-13 12:03:02 (+0800), Michael Proto wrote: Noticed recently (in both my upgraded and newly-installed hosts) that the leap-seconds.list file is in danger of expiration very soon (12/28). Note that there is no actual "danger" here. No leap second will be introduced at the end of 2023, so the contents of the current leap-seconds.list are accurate. Nothing bad will happen. Moreover, ntpd only uses leap-seconds.list as a last resort. If peers have leap second information, ntpd will pick that up. Having said that, we should do something about the scary warning. Xin submitted a draft EN. The security-officer team will pick that up. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Re: pkg_https:// failures related to, for example, "SSL certificate problem: certificate is not yet valid"
On 2024-07-04 01:27:03 (+0800), Mark Millard wrote: Bootstrapping pkg from pkg+https://pkg.FreeBSD.org/FreeBSD:14:aarch64/quarterly, please wait... Certificate verification failed for /CN=pkg.freebsd.org 0020616CE168:error:0A86:SSL routines:tls_post_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1890: As far as I can tell, at the time of this writing, all fifteen pkg.freebsd.org sites have the same certificate, and OpenSSL is happy with it. Note the "pkg+https://";. I had separate problems yesterday that I side stepped by testing use of just "pkg+http://";, which worked. See: Use pkg+http. This is the default. Packages are signed. Transport layer security does not provide any additional security. (Anticipating the usual argument: it doesn't provide privacy either - packages are trivially fingerprinted by file size.) pkg with -d for the https context had its debug output reporting: * SSL certificate problem: certificate is not yet valid Does the system being bootstrapped have a real-time clock? Common causes for this error are clocks set to 1970-01-01 or 2000-01-01. It happened to be using 204.15.11.66:443 for the https activity. For what it's worth: 204.15.11.66 = pkg0.tuk.freebsd.org. r...@pkg0.tuk:~ # openssl x509 -noout -in /etc/clusteradm/acme-certs/pkg.freebsd.org.crt -dates notBefore=Jun 1 20:26:18 2024 GMT notAfter=Aug 30 20:26:17 2024 GMT Philip
Re: pkg_https:// failures related to, for example, "SSL certificate problem: certificate is not yet valid"
On 2024-07-04 09:51:53 (+0800), Mark Millard wrote:
On Jul 3, 2024, at 17:47, Philip Paeps wrote:
On 2024-07-04 01:27:03 (+0800), Mark Millard wrote:
Bootstrapping pkg from
pkg+https://pkg.FreeBSD.org/FreeBSD:14:aarch64/quarterly, please
wait...
Certificate verification failed for /CN=pkg.freebsd.org
0020616CE168:error:0A86:SSL
routines:tls_post_process_server_certificate:certificate verify
failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1890:
As far as I can tell, at the time of this writing, all fifteen
pkg.freebsd.org sites have the same certificate, and OpenSSL is happy
with it.
Note the "pkg+https://";.
I had separate problems yesterday that I side stepped by
testing use of just "pkg+http://";, which worked. See:
Use pkg+http. This is the default.
Hmm:
# grep http /usr/src/usr.sbin/pkg/FreeBSD.conf.*
/usr/src/usr.sbin/pkg/FreeBSD.conf.latest: url:
"pkg+https://pkg.FreeBSD.org/${ABI}/latest";,
/usr/src/usr.sbin/pkg/FreeBSD.conf.quarterly: url:
"pkg+https://pkg.FreeBSD.org/${ABI}/quarterly";,
Releases, snapshots, pkgbase, and artifacts all explicitly
end up with https in /etc/pkg/FreeBSD.conf
Sorry. The default does seem to have changed to HTTPS since I last
looked. The commit log suggests it was done only because it is now
possible. I don't think it's a good idea. It only adds work (and work
is heat) for no benefit.
pkg with -d for the https context had its debug output
reporting:
* SSL certificate problem: certificate is not yet valid
Does the system being bootstrapped have a real-time clock? Common
causes for this error are clocks set to 1970-01-01 or 2000-01-01.
/var/log/messages confirms the time issue for my example
boots that had the problem: it stayed back at Mar 16, not
updating via ntpd as it normally does. (That date is
probably from UFS. The system had not been booted since
back then.)
That's what I suspected.
And this is another reason why HTTPS is a terrible default for pkg. I
don't think we should require a system to keep (reasonably) accurate
time in order to be able to download packages.
It does seem that /etc/pkg/FreeBSD.conf should avoid
the https notation so that it presents an appropriate
default.
I agree. Adding bapt@ to Cc:. I think this needs to be reverted. It
should probably also be an errata candidate so folks running releases
can update packages even when their clocks get out of sync.
In addition to needlessly generating heat, pkg+https reduces the overall
security of the system by making it more difficult for some
installations to receive updates.
For the avoidance of doubt: I completely support HTTPS as a default for
web traffic. Privacy is important. But pkg downloads are not web
traffic.
Philip
Typo in EN-25:06 URL (was: Re: FreeBSD Errata Notice FreeBSD-EN-25:06.daemon)
On 2025-04-11 02:30:35 (+0800), Lucas Holt wrote: I think the current URL for the the daemon patch is (with the period before patch) https://www.freebsd.org/security/patches/EN-25:06/daemon.patch Good catch! Git blame awards the pointy hat to me. :) We'll put a revised advisory on https://www.freebsd.org/security/. Thanks for reporting this. Philip
