# pkg_admin -K /usr/pkg/pkgdb fetch-pkg-vulnerabilities
# pkg_admin audit
Package perl-5.38.2 has a symlink-attack vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2011-4116
Package perl-5.38.2 has a sensitive-information-disclosure vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2023-31484
Package perl-5.38.2 has a sensitive-information-disclosure vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2023-31486
Package libxml2-2.10.4nb6 has a use-after-free vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2023-45322
Package gnutls-3.8.2 has a timing-side-channel vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2023-0553
Package pcre-8.45 has reached end-of-life (eol), see http://cdn.NetBSD.org/pub/NetBSD/packages/vulns/eol-packages
Package libssh2-1.11.0nb2 has a integer-overflow vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2019-17498
Package gnupg2-2.4.3nb2 has a out-of-bounds-write vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2022-3219
Package wget-1.21.4nb2 has a sensitive-information-disclosure vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2021-31879 rg ONLY_FOR_ARCHS= /usr/ports/ | rg --invert-match i386 > /tmp/not_for_i386.lst rg NOT_FOR_ARCHS= /usr/ports/ | rg i386 >> /tmp/not_for_i386.lst cat /tmp/not_for_i386.lst | cut -f 1 -d : | sort | uniq | wc -l rg is textproc/ripgrep. (rg(1))Not a Apple user. But I read from people that Apple is contributing to tech trash and many other nasty things willingly and unnecessarily. Apple pushes proprietary software and does not respect user freedom. If FreeBSD follows Apple to bring ease of use, I'd be understanding. But I don't think FreeBSD should follow Apple's example in deprecating hardware.
Even on Void and Devuan/Debian I noticed there are some packages that had issues and had to provide older versions for a while. This is not the fault of the OS, but rather those software projects. Once they are solved, latest versions are included back in. This is normal in 32-bit OSs I have used.
Marty McFly asks, what is a Gigawatt? Answer: savings to get with new Green hardware.
32-bit time_t is difficult to circumvent. And if it's changed to 64-bit, all legacy i386 apps break. There is no easy way forward without breaking something i386.
Really?
For code respecting the C standard (recap:
time_t representation format and size are completely unspecified, you should only ever use it to store time in memory and process it with time.h functions), rebuilding is really all that's needed.
We did this, about 20 years ago, for off_t, when we allowed file sizes (offsets) to go from 32 to 64 bits. It worked, and at no point in the middle was everything broken. It was incredibly tedious and painful (and expensive), but it can be done.
It worked, yes. But some ports broke. While other third party apps also broke. At the time I maintained the Digital Mars D language in FreeBSD ports. This broke DMD D because the DMD upstream maintained copies of FreeBSD library calls and internal structures in their library in order that D calls appear native to the D language. Perl, python and other languages do the same. It was more of a problem with D which was a low level C-like language with classes, vaguely similar to C++. The versioned symbols worked great with C and C++ apps but languages that needed to duplicate what we did, didn't work so well. To this day DMD D developers still haven't managed to figure out versioned symbols for DMD D and thus 32-bit and 64-bit off_t. It worked great for us but third party apps such as languages, not so much. This is why DMD D is no longer in ports.
It may be a problem when porting a C library to a high-level programming language. A typical case that can and will cause issues is the size of
long int, which is 4 bytes in 32-bit systems and 8 bytes in 64-bit (while normal int has the same size). And that's just a quick example. C actually has means to make this more portable with headers such as stdint.h - but good luck finding a C library that uses them.
Perhaps because we ask too much of them? (3 major branches times N architectures?)