security/openpgp-card-tools-git: [NEW PORT] Git signing and verification with a focus on OpenPGP cards
The openpgp-card-tools-git package provides 'oct-git', a tool for Git
commit and tag signing and verification with a focus on OpenPGP cards.
It can be configured as Git's gpg.program, keeping signing keys on
hardware tokens instead of on disk.
WWW: https://codeberg.org/openpgp-card/oct-git
PR: 293961
libthr: Cache recent pshared_key
For a pshare key, we can actually cache the last one as a fast path
instead of trapping into kernel directly. It makes sense as a lock and
unlock should be a pair on the same key and at the same time. For
example, lock(A) -> unlock(A) -> lock(B) -> unlock(B). Each unlock is
a hit and refresh later (50% hit).
For a single pshare lock, it is evne a 100% hit as the key never
changed.
For nested lock lock(A) -> lock(B) -> lock(C) -> unlock(C) ->
unlock(B) -> unlock(A). It only cache the last one. However, we should
really think about rewritting this logic as it is a pshare lock shared
by many processes and nested should be uncommon.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D60957
security/keychain: Small updates
Point at new GH location (old redirects to new), modernize pkg-descr,
and adopt my personal preferences (the port has been around for 21
years, we can probably stop guarding against its name changing.)
Note that keychain 3.x, which has been out for a couple months, is a
Python rewrite. It needs no third-party modules, but it's definitely
a change from the "one portable shell script" ethos I recall from
decades ago. I'm working on that update, and from what I can tell it
should require basically no adjustment on the end-user side of things,
so I'm unlikely to create a keychain298 port (happy to take input on
that!).
Tools/scripts/update-plist.py: Bugfix
Remove stale pkg-plist lines preceded by an OPTIONS_SUB. E.g.: remove
%%FOO%%include/bar.h if it is no longer packaged.
MFH: 2026Q4
(cherry picked from commit 97856031311db3350b2e1428d7a9b00f9c2e5b85)
Tools/scripts/update-plist.py: Bugfix
Remove stale pkg-plist lines preceded by an OPTIONS_SUB. E.g.: remove
%%FOO%%include/bar.h if it is no longer packaged.
MFH: 2026Q4
gve: Page-align DQO descriptor and completion rings
Currently, gve_rx_alloc_ring_dqo() and gve_tx_alloc_ring_dqo() request
CACHE_LINE_SIZE alignment when allocating DMA memory for the DQO TX/RX
descriptor and completion rings. The device requires stronger alignment
than cache line alignment, which was incidentally being met due to how
the kernel allocates memory. Explicitly meet this requirement by
requesting page aligned memory.
Signed-off-by: Tim Hostetler <thostet at google.com>
Reviewed by: markj, Jasper Tran O'Leary <jtranoleary at google.com>
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D61211
gve: Fix AdminQ buffer DMA sync directions
In gve_verify_driver_compatibility(), the driver populates the
gve_driver_info buffer for the device to read. Sync this buffer with
BUS_DMASYNC_PREWRITE instead of BUS_DMASYNC_PREREAD before issuing
the command.
In gve_adminq_describe_device(), the device populates the
gve_device_descriptor buffer for the driver to read. Sync this buffer
with BUS_DMASYNC_PREREAD instead of BUS_DMASYNC_PREWRITE before
issuing the command.
In gve_adminq_get_ptype_map_dqo(), the device populates the
gve_ptype_map buffer for the driver to read. Add the missing
BUS_DMASYNC_PREREAD and BUS_DMASYNC_POSTREAD syncs around the
command.
In normal GCP environments this did not cause a functional failure
because the underlying platforms are DMA cache-coherent and
[12 lines not shown]
ioctl: Add a macro for extracting the ioctl number from a command
Sprinkle it in various drivers which hard-coded the command layout.
No functional change intended.
Reviewed by: dumbbell, emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D61045
www/caddy: Update to 2.11.8
This contains numerous fixes to handling broken-by-design scenarios,
such as PHP. All users should update, especially if caddy drives a
php_fastcgi backend.
Read the Changes for details.
Changes: https://github.com/caddyserver/caddy/releases/tag/v2.11.8
libsecureboot: add support for more signatures
For 2027 we need to support new, stronger signatures and hashes.
Re-work Makefile.inc and local.trust.mk to define
VE_SIGN_URL_LIST or VE_SIGNATURE_LIST (can be derrived from
VE_SIGN_URL_LIST) containing tuples of sig/method/hash/flags and
for VE_SIGN_URL_LIST the same plus /url.
From VE_SIGNATURE_LIST we derrive VE_SIGNATURE_EXT_LIST used to populate
signature_ext_list which defines the order in which we look for
signatures for a manifest.
We also populate signature_info_list which maps a signature ext to the
needed hash and flags to indicate whether that hash needs to be repeated.
verify_sig will lookup signature_info_list, no match means not
supported. For asc we just call verify_asc() otherwise we call
verify_ec() or verify_rsa() depending on the key type found in the
[15 lines not shown]
nfs_clrpcops.c: Fix typo in commit db8444c1b7e4
Reported by: markj
MFC after: 1 month
Fixes: 884ee8d6c9b4 ("nfscl: Add some glue for client side NFS over RDMA")
LinuxKPI: set pci_dev msi_cap and msix_cap
Linux drivers find their MSI and MSI-X registers through pdev->msi_cap and
pdev->msix_cap, which hold where those capabilities start in PCI config
space. LinuxKPI never set them, so they stayed 0, and every access meant
for the MSI registers went to the start of config space instead.
Drivers using these fields, e.g. ath11k and amdgpu, are affected.
Fill in both fields from the capability offsets that the native PCI code
already records.
Reviewed by: dumbbell
Differential Revision: https://reviews.freebsd.org/D61125
Event: NetApp/Vendor Summit Hackathon 202611
mandoc: Drop obsolete files
These were removed by upstream long ago. Nothing in the
tree uses them. Remove them to reduce our diff to upstream.
Reviewed by: carlavilla, wosch
Reported by: Ingo Schwarze <schwarze at openbsd.org>
Differential Revision: https://reviews.freebsd.org/D61198
