The entry was imported from the termcap source that Ghostty generates
with infotocap during its build. To fit within 1023 bytes, the
conversion dropped a number of capabilities, most notably all color
support, so termcap consumers such as ls -G and ncurses applications
treated Ghostty as a monochrome terminal.
Split the entry into xterm-ghostty and a ghostty+common fragment, and
restore the following from Ghostty's terminfo definition:
- colors: Co, pa, AF, AB, op, oc, ut, AX
- keys: End, keypad Enter, F10-F12, back tab, mouse prefix
- attributes: italics (ZH/ZR), invisible (mk), acsc map (ac)
- misc: cb, ch, cv, SA/RA, r1, bs, NP, 5i
AF and AB use the plain 256-color form, like xterm-256color, because
termcap cannot express the conditional used by the terminfo entry.
Fixes: 804f961c5c ("share/termcap: add xterm-ghostty entry")
MFC after: 1 week
Commit 1a296762b3 made libcasper pass PD_NOWAITPID to pdfork(2).
Kernels predating the flag (15.1 and earlier, since the flag first
ships in 15.2) reject it with EINVAL, which makes cap_init() and every
service fork fail when a newer world runs on an older kernel, for
example in a poudriere jail.
Add casper_pdfork(), which retries without the flag on EINVAL, and use
it at both pdfork(2) call sites. The retry is safe because the kernel
validates pdfork flags before creating a child. On such kernels the
zombie must still be reaped with waitpid(2), as before the flag was
introduced.
The fallback is compiled out once __FreeBSD_version reaches 1700000,
so it disappears from main when stable/16 branches while remaining in
the stable/15 and stable/16 branches that need it.
Reviewed by: kib
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D60401
file 5.48 added swap.c and swap.h for byte-swapping operations, which are
required on hosts that lack <byteswap.h> or <sys/bswap.h> (e.g. macOS cross-building
or older FreeBSD bootstrap environments).
Also add magic.h to SRCS so object files depend on the generated header
before compiling, avoiding falling back to the host's /usr/include/magic.h
during parallel builds.
Reported by: wosch
MFC after: 1 week
Fixes: 7af41682a9 ("MFV: file 5.48")
Build a 4.5 GiB FAT32 image whose LOST.DIR cluster sits exactly 4 GiB above
the single cluster of a PAYLOAD.BIN, so that truncating the offset of the
former to 32 bits yields the offset of the latter, then inject a lost cluster
chain and let fsck_msdosfs(8) reconnect it.
The test asserts both halves of the bug fixed in the previous commit: that
PAYLOAD.BIN's cluster is unchanged, and that a second pass no longer reports
the chain as lost, which it only stops doing once the directory entry reaches
the real LOST.DIR.
newfs_msdos(8) -C only calls ftruncate(2) and nothing outside the reserved
area, the FATs and a handful of clusters is ever written, so the image stays
sparse and costs about 2 MiB on disk.
The geometry is read back out of the BPB rather than assumed, so
newfs_msdos(8) stays free to lay the file system out differently; the test
fails with a clear message if the volume ever becomes too small to hold a
cluster a full 4 GiB beyond the data area.
MFC after: 1 week
Exercise each of the 32-bit BIOS Parameter Block and FSInfo fields that
readboot() decodes, using values whose most significant byte has its high
bit set. Each case checks two things: that fsck_msdosfs(8) reports the
full unsigned 32-bit value back on stdout, and that nothing writes a
sanitizer runtime error to stderr.
The second check is what catches a byte-at-a-time decode. Shifting such
a byte left by 24 is undefined, but every compiler we use wraps it into
the same bit pattern, so the decoded value alone cannot tell a correct
decode from an overflowing one. In a WITH_UBSAN build bsd.sanitizer.mk
compiles with -fsanitize=undefined and -fsanitize-recover=undefined, so
the shift is reported on stderr and execution continues, which the test
can then assert on. Against the byte-at-a-time decode these cases fail
in a WITH_UBSAN build and pass without it.
Note that the stderr check also fails on unrelated undefined behavior
that these images reach anywhere in fsck_msdosfs(8), which is intended.
MFC after: 1 week
Add an ATF test suite covering Phase 3 ("Checking for Lost Files")
error accounting. Test images are created using newfs_msdos(8),
and lost cluster chains are injected directly into FAT copies at
offsets derived from the BPB. The LOST.DIR directory required by
reconnect() is constructed similarly: a root directory entry with
ATTR_DIRECTORY set and its first cluster pointing to a zero-filled
cluster containing "." and ".." entries.
The lost_chain_cleared and corrupted_lost_chain_reconnected test
cases provide regression coverage for the preceding commit:
- lost_chain_cleared verifies that clearing a lost chain (the fallback
taken when LOST.DIR is absent) exits with status 0 rather than 8
(unrecovered error).
- corrupted_lost_chain_reconnected verifies that FAT modifications
from a chain truncated by checkchain() prior to reconnection are
written back to disk, requiring "Update FATs? yes" and ensuring a
clean second pass.
Additionally, lost_chain_left_alone, lost_chain_preen, and
corrupted_lost_chain_left_alone cover scenarios that must continue to
report unrecovered errors: read-only mode (-n), which performs no
repairs and leaves the image byte-for-byte unchanged, and preen mode
(-p), which attempts reconnection but does not clear lost chains.
MFC after: 1 week
Google Cloud recommends migrating from gsutil to gcloud storage CLI.
Update gce-do-upload target to use `gcloud storage buckets create` and
`gcloud storage cp` instead of `gsutil mb` and `gsutil cp` commands.
PR: conf/297016
Reviewed by: lwhsu
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D58464
Update the GCE image creation process to automatically apply the
'public-image=true' label when publishing new images. This aligns
with standard labeling expectations for images hosted in public
projects.
MFC after: 3 days
Some upstream result files introduced in file 5.47 (e.g., bgcode.result)
lack a trailing newline, causing the contrib_file_tests ATF test to
fail with "cmp: EOF on bgcode.result". Generate normalized copies
of the expected results and install those instead.
MFC after: 3 days
Fixes: e949ce9dc0
Extend PAM integration beyond account checks to include credential
establishment and session management, allowing PAM modules to configure
the execution environment for user cron jobs.
Previously, cron only called pam_acct_mgmt() to verify account validity
but immediately terminated the PAM handle before job execution. This
prevented PAM modules from establishing sessions, setting credentials
(e.g., Kerberos tickets), or exporting environment variables needed by
jobs.
The PAM handle now persists in the intermediate process throughout the
job execution, enabling proper session open/close pairing. Credentials
are established and sessions opened while still running as root, before
dropping privileges in the grandchild. PAM environment variables are
exported in the job process with user crontab variables taking precedence.
A session rule (pam_permit.so) is added to /etc/pam.d/cron to enable
session support without changing default behavior. Administrators can
replace this with other modules as needed.
System crontab entries continue to bypass all PAM operations.
PR: bin/244844
Reviewed by: des
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D54415
NO_FP_LIBC was added in 2004 to save space by disabling FP support in
*printf()/*scanf(). The size benefit is negligible on modern systems
and conflicts with assumptions made by current base utilities.
Remove the option and always build libc with floating-point support.
Reported by: Oskar Holmlund <eovholmlund at gmail com>
MFC after: 2 weeks
Apply OpenBSD env.c,v 1.24 and 1.25, which replaces manual size
calculations with reallocarray() to prevent possible integer
overflow.
MFC after: 3 days
Add generation of a bzip2.pc file for use with pkg-config and create
a basic template as bzip2.pc.in.
This allows other software to easily locate and link against libbz2
using standard pkg-config mechanisms instead of manual compiler and
linker flags.
The version number is extracted automatically from bzlib.h to keep
it consistent with the library sources.
Tested: pkg-config --exists --print-errors "bzip2 >= 1.0.9" (fail, expected)
pkg-config --exists --print-errors "bzip2 >= 1.0" (succeeded)
pkg-config --libs bzip2 (-lbz2)
pkg-config --cflags bzip2 ()
MFC after: 3 days
The -c command-line option, which allowed setting a global compression
method, is removed in favor of the <compress> directive in newsyslog.conf.
The motivation of this change is to eliminate a source of potential confusion.
Since newsyslog(8) is typically invoked by cron(8), having a command line
option that can override it could cause inconsistent behavior (specifying
in crontab would take precedence).
Suggested by: karels
Differential Revision: https://reviews.freebsd.org/D43466
A script that does the following:
cd "${dir}" || exit 1
would incorrectly remain in the current directory when `${dir}` is
an empty string under the current implementation. This behavior,
while historical, is potentially dangerous, as it is likely not
what the script author intended.
Change the command to treat an empty string as an error and emit a
diagnostic message to standard error, as required by
IEEE Std 1003.1-2024.
PR: standards/287440
Test Plan: kyua test bin/sh
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D50974
Historically, newsyslog compressed rotated log files to save disk space.
This was helpful when storage was limited. However, with modern files
systems like ZFS providing built-in compression and with larger disks
now common, the benefits of additional log compression have diminished,
especially given the inconvenience of needing to decompress logs when
searching for specific patterns.
This change updates the default /etc/newsyslog.conf to specify:
<compress> none
disabling compression for new installations or default setups.
It does not modify the behavior of the newsyslog utility itself; users
can still enable compression as needed via configuration.
MFC: never
Reviewed by: zlei, dvl, otis
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D43169
byteswap.h is introduced in FreeBSD 13.2 but was not available in
earlier versions. In order to support upgrading from an earlier
FreeBSD release we would need to tell the build system that fact.
PR: bin/273736
Reported by: philip
MFC after: 3 days
This commit reverts 8db56defa7,
rolling back the vendor import of xz 5.6.0 and restoring the
package to version 5.4.5.
The revert was not directly due to the attack (CVE-2024-3094):
our import process have removed the test cases and build scripts
that would have enabled the attack. However, reverting would
help to reduce potential confusion and false positives from
security scanners that assess risk based solely on version
numbers.
Another commit will follow to restore binary compatibility with
the liblzma 5.6.0 library by making the previously private
symbol (lzma_mt_block_size) public.
PR: 278127
MFC after: 3 days
The LIT_MEM option uses slightly more memory (for base gzip(1),
about 16kiB; according to the author, about 6% for default deflate
settings) for a small speedup.
The performance gain is more noticeable for input data with higher
entropy and less significant for data that is highly compressible,
such as source code and logs.
MFC after: 1 month
The amd64 and arm64 images supported UEFI, mark it as so users can take
advantage of UEFI boot on GCE. This is already done on FreeBSD
14.0-RELEASE but never codified into the release tools (and should).
PR: conf/276532
Reviewed by: lwhsu
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D43557
This marks FreeBSD GCE images as gVNIC capable by adding the
--guest-os-features=GVNIC flag at creation time as suggested in GCE
documentation[1]. This allows Generation 3 and newer GCE instances
to leverage advanced networking capabilities and performance
enhancements provided by gVNIC. Users will benefit from these
improvements without needing to create custom images.
[1] https://cloud.google.com/compute/docs/networking/using-gvnic#create_a_vm_with_gvnic_support
Reviewed by: cperciva
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D43411
Administrators can now specify a global compression method directly
at the beginning of the newsyslog.conf file, for example:
<compress> none
Relnotes: yes
Reviewed by: dvl
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43174
Historically, newsyslog compressed rotated log files to save disk space.
This was useful in the early days. However, with modern file systems like
ZFS offering native compression, and with the availability of larger hard
drives, the benefits of additional compression have become less significant.
This is particularly true considering the inconvenience of decompressing
log files when searching for specific patterns.
Additionally, the original implementation of compression methods was not
future-proof. As a result, we have redefined the J, X, Y, Z flags to
signify "treat the file as compressible" rather than "compress the file
with that specific method."
A new command-line option, -c, has been introduced to allow overriding
these settings in a more future-proof way. The available choices are:
* none - do not compress, regardless of flag.
* legacy - historical behavior: J=bzip2, X=xz, Y=zstd, Z=gzip.
* bzip2, xz, zstd, gzip - apply the specified compression method.
Currently, the default is set to 'legacy' to preserve historical behavior.
However, our intention is to change this default to 'none' in FreeBSD 15.0.
Additionally, this update changes the default settings for zstd to use
multithreading and long-range options, better aligning with its intended
use.
Inspired by D42961 .
Reviewed by: debdrup (earlier version, mdoc(7))
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43165
when ntpd is enabled.
The leap-seconds.list is used exclusively by ntpd, therefore, do not bother
to perform the fetch when ntpd is not enabled.
PR: conf/275419
Reviewed by: cy, michaelo, imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D42875
Ideally we should be testing __FreeBSD_version (1400079) and/or
BOOTSTRAPPING from an older version, but restore compatibility to
older FreeBSD versions and macOS while we find out a better way to
fix it.
Xin LI