Re: [update] gnupg-2.4.3

[Renato Aguiar]

I found out that my Yubikey works on gnupg-2.4.3 after disabling CCID in
scdaemon by adding "disable-ccid" to "~/.gnupg/scdaemon.conf" :)

$ man scdaemon
[...]
   --disable-ccid
  Disable the integrated support for CCID compliant readers.  This
  allows falling back to one of the other drivers even if the
  internal CCID driver can handle the reader.  Note, that CCID
  support is only available if libusb was available at build time.
[...]

$ cat ~/.gnupg/scdaemon.conf
reader-port "Yubico YubiKey FIDO+CCID 00 00"
disable-ccid
$

For some reason that wasn't needed in previous versions. Maybe we should
mention that option in the pkg/README.

--
Renato Aguiar

powerpc bulk build report

[gkoehler]

Bulk build on macppc-0.ports.openbsd.org

Started : Mon Jun 19 13:16:48 MDT 2023
Finished: Mon Jul 10 22:44:25 MDT 2023
Duration: 21 Days 9 hours 28 minutes

Built using OpenBSD 7.3-current (GENERIC) #129: Sat Jun 17 07:01:53 MDT 2023

Built 8739 packages

Number of packages built each day:
Jun 19: 769
Jun 20: 125
Jun 21: 265
Jun 22: 624
Jun 23: 437
Jun 24: 465
Jun 25: 339
Jun 26: 278
Jun 27: 123
Jun 28: 260
Jun 29: 180
Jun 30: 311
Jul 1: 1908
Jul 2: 464
Jul 3: 382
Jul 4: 240
Jul 5: 282
Jul 6: 250
Jul 7: 271
Jul 8: 357
Jul 9: 409
Jul 10: 1745



Critical path missing pkgs:
http://build-failures.rhaalovely.net/powerpc/2023-06-19/summary.log

Build failures: 931
http://build-failures.rhaalovely.net/powerpc/2023-06-19/archivers/arc.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/archivers/deco.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/archivers/freeze.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/archivers/macutil.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/archivers/par1cmdline.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/archivers/ripole.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/archivers/unarj.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/astro/ansiweather.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/astro/jday.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/abcde.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/alac_decoder.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/checkmate.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/disc-cover.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/midish.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/mp3cut.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/p5-Audio-CD.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/p5-Audio-Scan.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/p5-Audio-Scrobbler.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/p5-Audio-WMA.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/p5-MP3-ID3v1Tag.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/p5-MP3-Info.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/p5-MP4-Info.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/p5-Music-Audioscrobbler-MPD.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/p5-Music-Audioscrobbler-Submit.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/p5-Ogg-Vorbis-Header-PurePerl.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/p5-Ogg-Vorbis-Header.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/p5-cddb.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/squeezecenter.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/audio/vlorb.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/benchmarks/netpipe.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/benchmarks/siege.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/biology/AcePerl,opt.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/biology/p5-Bio-DB-EMBL.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/biology/p5-Bio-Variation.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/books/AsteriskTFOT.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/books/clisp-hyperspec.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/books/diveintopython3.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/books/grokking-the-gimp.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/books/progit.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/books/wndw,-ar.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/cad/necpp.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/chinese/cless.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/comms/birda.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/comms/conserver,net.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/comms/lrzsz.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/comms/p5-Device-Gsm.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/comms/p5-Device-SerialPort.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/comms/picocom.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/comms/qpage.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/comms/sredird.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/comms/zmtx-zmrx.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/converters/html2text.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/converters/p5-CBOR-Free.log
http://build-failures.rhaalovely.net/powerpc/2023-06-19/converters/p5-Convert-Binary-C.log

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2023/07/10 22:21:48

Modified files:
x11/qt5/qtwebengine: Makefile 

Log message:
Use QT5_WEBENGINE_VERSION

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2023/07/10 22:20:12

Modified files:
x11/qt5/qtwebengine: Makefile 
Added files:
x11/qt5/qtwebengine/patches: 
 
patch-src_3rdparty_chromium_third_party_ffmpeg_libavutil_x86_x86inc_asm 

Log message:
Add missing patch

[NEW]textproc/typst

[wen heping]

Hi, ports@

   Here is a patch to create new port textproc/typst.

   Typst is a new markup-based typsetting system that is designed to be as
powerful as LaTeX while being much easier to learn and use. Typst has:
Built-in markup for the most common formatting tasks
Flexible functions for everything else
A tightly integrated scripting system
Math typesetting, bibliography management, and more
Fast compile times thanks to incremental compilation
Friendly error messages in case something goes wrong.

   It build and run well on amd64-current system.


Cheers !
wen

typst-0.6.0.tar.gz
Description: typst-0.6.0.tar.gz

CVS: cvs.openbsd.org: ports

[Daniel Jakots]

CVSROOT:/cvs
Module name:ports
Changes by: d...@cvs.openbsd.org2023/07/10 19:40:18

Modified files:
databases/redis: Makefile distinfo 
databases/redis/patches: patch-deps_Makefile 

Log message:
Update to redis-6.2.13

Fix CVE-2022-24834: A specially crafted Lua script executing in
Redis can trigger a heap overflow in the cjson and cmsgpack
libraries, and result in heap corruption and potentially remote code
execution. The problem exists in all versions of Redis with Lua
scripting support, starting from 2.6, and affects only authenticated
and authorized users.

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2023/07/10 13:55:06

Modified files:
x11/qt5/qtwebengine: Makefile distinfo 
x11/qt5/qtwebengine/files: openbsd.pri sndio_input.cc 
x11/qt5/qtwebengine/patches: 
 patch-mkspecs_features_functions_prf 
 patch-src_3rdparty_chromium_BUILD_gn 
 patch-src_3rdparty_chromium_base_BUILD_gn 
 
patch-src_3rdparty_chromium_base_allocator_allocator_gni 
 
patch-src_3rdparty_chromium_base_base_paths_posix_cc 
 
patch-src_3rdparty_chromium_base_base_switches_cc 
 
patch-src_3rdparty_chromium_base_base_switches_h 
 
patch-src_3rdparty_chromium_base_debug_debugger_posix_cc 
 
patch-src_3rdparty_chromium_base_debug_elf_reader_cc 
 
patch-src_3rdparty_chromium_base_debug_proc_maps_linux_cc 
 
patch-src_3rdparty_chromium_base_debug_stack_trace_posix_cc 
 
patch-src_3rdparty_chromium_base_files_file_util_posix_cc 
 
patch-src_3rdparty_chromium_base_files_scoped_file_cc 
 
patch-src_3rdparty_chromium_base_i18n_icu_util_cc 
 
patch-src_3rdparty_chromium_base_linux_util_cc 
 
patch-src_3rdparty_chromium_base_memory_discardable_memory_cc 
 
patch-src_3rdparty_chromium_base_memory_discardable_memory_internal_h 
 
patch-src_3rdparty_chromium_base_memory_madv_free_discardable_memory_posix_cc 
 
patch-src_3rdparty_chromium_base_memory_platform_shared_memory_region_h 
 
patch-src_3rdparty_chromium_base_memory_platform_shared_memory_region_posix_cc 
 
patch-src_3rdparty_chromium_base_posix_unix_domain_socket_cc 
 
patch-src_3rdparty_chromium_base_process_kill_h 
 
patch-src_3rdparty_chromium_base_process_kill_posix_cc 
 
patch-src_3rdparty_chromium_base_process_launch_h 
 
patch-src_3rdparty_chromium_base_process_memory_cc 
 
patch-src_3rdparty_chromium_base_process_process_handle_cc 
 
patch-src_3rdparty_chromium_base_process_process_handle_h 
 
patch-src_3rdparty_chromium_base_process_process_metrics_cc 
 
patch-src_3rdparty_chromium_base_process_process_metrics_h 
 
patch-src_3rdparty_chromium_base_process_process_metrics_openbsd_cc 
 
patch-src_3rdparty_chromium_base_process_process_metrics_posix_cc 
 
patch-src_3rdparty_chromium_base_process_process_posix_cc 
 
patch-src_3rdparty_chromium_base_rand_util_posix_cc 
 
patch-src_3rdparty_chromium_base_syslog_logging_cc 
 
patch-src_3rdparty_chromium_base_system_sys_info_cc 
 
patch-src_3rdparty_chromium_base_system_sys_info_h 
 
patch-src_3rdparty_chromium_base_system_sys_info_openbsd_cc 
 
patch-src_3rdparty_chromium_base_system_sys_info_posix_cc 
 
patch-src_3rdparty_chromium_base_threading_platform_thread_h 
 
patch-src_3rdparty_chromium_base_threading_platform_thread_linux_cc 
 
patch-src_3rdparty_chromium_base_threading_platform_thread_posix_cc 
 
patch-src_3rdparty_chromium_base_trace_event_malloc_dump_provider_cc 
 
patch-src_3rdparty_chromium_base_trace_event_memory_dump_manager_cc 
 
patch-src_3rdparty_chromium_base_trace_event_process_memory_dump_cc 
 
patch-src_3rdparty_chromium_build_config_BUILDCONFIG_gn 
 
patch-src_3rdparty_chromium_build_config_BUILD_gn 
 
patch-src_3rdparty_chromium_build_config_c++_c++_gni 
 
patch-src_3rdparty_chromium_build_config_compiler_BUILD_gn 
 
patch-src_3rdparty_chromium_build_config_features_gni 

CVS: cvs.openbsd.org: ports

[Theo Buehler]

CVSROOT:/cvs
Module name:ports
Changes by: t...@cvs.openbsd.org2023/07/10 13:50:52

Modified files:
security/boringssl/head: Makefile distinfo 
security/boringssl/head/pkg: PLIST 
Removed files:
security/boringssl/head/patches: 
 
patch-crypto_chacha_asm_chacha-x86_64_pl 
 
patch-crypto_cipher_extra_asm_aes128gcmsiv-x86_64_pl 
 
patch-crypto_cipher_extra_asm_chacha20_poly1305_x86_64_pl 
 
patch-crypto_fipsmodule_aes_asm_aesni-x86_64_pl 
 
patch-crypto_fipsmodule_aes_asm_vpaes-x86_64_pl 
 
patch-crypto_fipsmodule_bn_asm_rsaz-avx2_pl 
 
patch-crypto_fipsmodule_bn_asm_x86_64-mont5_pl 
 
patch-crypto_fipsmodule_bn_asm_x86_64-mont_pl 
 
patch-crypto_fipsmodule_ec_asm_p256-x86_64-asm_pl 
 
patch-crypto_fipsmodule_ec_asm_p256_beeu-x86_64-asm_pl 
 
patch-crypto_fipsmodule_md5_asm_md5-x86_64_pl 
 
patch-crypto_fipsmodule_modes_asm_aesni-gcm-x86_64_pl 
 
patch-crypto_fipsmodule_modes_asm_ghash-ssse3-x86_64_pl 
 
patch-crypto_fipsmodule_modes_asm_ghash-x86_64_pl 
 
patch-crypto_fipsmodule_rand_asm_rdrand-x86_64_pl 
 
patch-crypto_fipsmodule_sha_asm_sha1-x86_64_pl 
 
patch-crypto_fipsmodule_sha_asm_sha512-x86_64_pl 
 patch-crypto_perlasm_x86_64-xlate_pl 
 
patch-crypto_test_asm_trampoline-x86_64_pl 

Log message:
Update boringssl to 20230710

beck and kettenis upstreamed the endbr64 changes, so we are again without
patches.

CVS: cvs.openbsd.org: ports

[Theo Buehler]

CVSROOT:/cvs
Module name:ports
Changes by: t...@cvs.openbsd.org2023/07/10 13:35:14

Modified files:
audio/ncspot   : Makefile 
devel/maturin  : Makefile 
lang/deno  : Makefile 
lang/gleam : Makefile 
mail/meli  : Makefile 
mail/stalwart/cli: Makefile 
mail/stalwart/imap: Makefile 
mail/stalwart/jmap: Makefile 
mail/stalwart/smtp: Makefile 
net/routinator : Makefile 
net/rrdpit : Makefile 
security/pizauth: Makefile 
security/rbw   : Makefile 
security/sn0int: Makefile 
security/vaultwarden: Makefile 
sysutils/rustic: Makefile 
www/libreddit  : Makefile 
www/nextcloud_notify_push: Makefile 
www/py-adblock : Makefile 
www/zola   : Makefile 

Log message:
Bump revision in rust-ring consumers

CVS: cvs.openbsd.org: ports

[Theo Buehler]

CVSROOT:/cvs
Module name:ports
Changes by: t...@cvs.openbsd.org2023/07/10 13:35:02

Modified files:
security/rust-ring: Makefile 
security/rust-ring/patches: 
patch-pregenerated_aesni-gcm-x86_64-elf_S 
patch-pregenerated_aesni-x86_64-elf_S 
patch-pregenerated_chacha-x86_64-elf_S 

patch-pregenerated_chacha20_poly1305_x86_64-elf_S 
patch-pregenerated_ghash-x86_64-elf_S 
patch-pregenerated_p256-x86_64-asm-elf_S 
patch-pregenerated_sha256-x86_64-elf_S 
patch-pregenerated_sha512-x86_64-elf_S 
patch-pregenerated_x86_64-mont5-elf_S 
Added files:
security/rust-ring/patches: 
patch-pregenerated_vpaes-x86_64-elf_S 
patch-pregenerated_x86_64-mont-elf_S 

Log message:
rust-ring: backport endbr64 patches from boringssl/head

IBT breakage reported by and patch tested by Matthias Schmidt

Re: [update] gnupg-2.4.3

[Renato Aguiar]

"Jeremie Courreges-Anglas"  writes:

>
> Indeed, it looks like there was some regression in scdaemon.  Can you
> please confirm that your yubikey was usable and useful with
> gnupg-2.2.41?
>

Yes, it was and it is now working again after reinstalling gnupg-2.2.41
using ports.

>
> With a borrowed and otherwise virgin (I think) Yubikey 5 NFC with
> firmware version 5.1.2, I get:
>
> shannon ~$ usbdevs -v
> [...]
> addr 04: 1050:0407 Yubico, YubiKey OTP+FIDO+CCID
>  full speed, power 30 mA, config 1, rev 5.12
> [...]
> shannon ~$ ykman info
> WARNING: No OTP HID backend available. OTP protocols will not function.
> ERROR: Unable to list devices for connection
> Device type: YubiKey 5 NFC
> Serial number: 
> Firmware version: 5.1.2
> Form factor: Keychain (USB-A)
> Enabled USB interfaces: OTP, FIDO, CCID
> NFC transport is enabled.
>
> ApplicationsUSB NFC
> OTP Enabled Enabled
> FIDO U2FEnabled Enabled
> FIDO2   Enabled Enabled
> OATHEnabled Enabled
> PIV Enabled Disabled
> OpenPGP Enabled Enabled
> YubiHSM AuthNot available   Not available
>
> shannon ~$ LC_ALL=C.UTF-8 gpg --card-status
> Reader ...: Yubico YubiKey OTP FIDO CCID 00 00
> Application ID ...: 
> Application type .: OpenPGP
> Version ..: 2.1
> Manufacturer .: Yubico
> Serial number : 
> Name of cardholder: [not set]
> Language prefs ...: [not set]
> Salutation ...:
> URL of public key : [not set]
> Login data ...: [not set]
> Signature PIN : not forced
> Key attributes ...: rsa2048 rsa2048 rsa2048
> Max. PIN lengths .: 127 127 127
> PIN retry counter : 3 0 3
> Signature counter : 0
> Signature key : [none]
> Encryption key: [none]
> Authentication key: [none]
> General key info..: [none]

Was that output using gnupg-2.4.3?

My Yubikey has a newer firmware (5.4.3). Here is what I get:

$ usbdevs -v
[...]
addr 03: 1050:0406 Yubico, YubiKey FIDO+CCID
 full speed, power 30 mA, config 1, rev 5.43
 driver: uhidev0
 driver: ugen0
[...]


$ ykman info
WARNING: No OTP HID backend available. OTP protocols will not function.
Device type: YubiKey 5C Nano
Serial number: 
Firmware version: 5.4.3
Form factor: Nano (USB-C)
Enabled USB interfaces: FIDO, CCID

Applications
OTP Disabled
FIDO U2FEnabled
FIDO2   Enabled
OATHEnabled
PIV Enabled
OpenPGP Enabled
YubiHSM AuthDisabled


$ gpg --card-status
Reader ...: Yubico YubiKey FIDO CCID 00 00
Application ID ...: 
Application type .: OpenPGP
Version ..: 3.4
Manufacturer .: Yubico
Serial number : 
Name of cardholder: 
Language prefs ...: [not set]
Salutation ...:
URL of public key : [not set]
Login data ...: [not set]
Signature PIN : not forced
Key attributes ...: ed25519 cv25519 ed25519
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 0
KDF setting ..: off
Signature key : 
Encryption key: 
Authentication key: 
General key info..: 


$ gpg --version
gpg (GnuPG) 2.2.41
libgcrypt 1.10.2
Copyright (C) 2022 g10 Code GmbH
License GNU GPL-3.0-or-later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: 
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2


--
Renato Aguiar

CVS: cvs.openbsd.org: ports

[Klemens Nanni]

CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2023/07/10 12:52:13

Modified files:
net/catgirl: Makefile distinfo 

Log message:
update to catgirl 2.2

Re: [update] gnupg-2.4.3

[Jeremie Courreges-Anglas]

On Sun, Jul 09 2023, Renato Aguiar  wrote:
> I can't use OpenPGP card (Yubikey) after upgrading it to 2.4.3:
>
> $ gpg --card-status
> gpg: selecting card failed: Operation not supported by device
> gpg: OpenPGP card not available: Operation not supported by device

Indeed, it looks like there was some regression in scdaemon.  Can you
please confirm that your yubikey was usable and useful with
gnupg-2.2.41?

With a borrowed and otherwise virgin (I think) Yubikey 5 NFC with
firmware version 5.1.2, I get:

shannon ~$ usbdevs -v
[...]
addr 04: 1050:0407 Yubico, YubiKey OTP+FIDO+CCID
 full speed, power 30 mA, config 1, rev 5.12
[...]
shannon ~$ ykman info
WARNING: No OTP HID backend available. OTP protocols will not function.
ERROR: Unable to list devices for connection
Device type: YubiKey 5 NFC
Serial number: 
Firmware version: 5.1.2
Form factor: Keychain (USB-A)
Enabled USB interfaces: OTP, FIDO, CCID
NFC transport is enabled.

ApplicationsUSB NFC
OTP Enabled Enabled
FIDO U2FEnabled Enabled
FIDO2   Enabled Enabled
OATHEnabled Enabled
PIV Enabled Disabled
OpenPGP Enabled Enabled
YubiHSM AuthNot available   Not available

shannon ~$ LC_ALL=C.UTF-8 gpg --card-status
Reader ...: Yubico YubiKey OTP FIDO CCID 00 00
Application ID ...: 
Application type .: OpenPGP
Version ..: 2.1
Manufacturer .: Yubico
Serial number : 
Name of cardholder: [not set]
Language prefs ...: [not set]
Salutation ...:
URL of public key : [not set]
Login data ...: [not set]
Signature PIN : not forced
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 0
Signature key : [none]
Encryption key: [none]
Authentication key: [none]
General key info..: [none]



-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

CVS: cvs.openbsd.org: ports

[Bjorn Ketelaars]

CVSROOT:/cvs
Module name:ports
Changes by: b...@cvs.openbsd.org2023/07/10 12:22:31

Modified files:
news/sabnzbd   : Makefile distinfo 
news/sabnzbd/pkg: PLIST 

Log message:
Update to sabnzbd-4.0.3

Changes: https://github.com/sabnzbd/sabnzbd/releases/tag/4.0.3

Re: Maintaining multiple PHP-FPM versions on the same host

[Mike Fischer]

Ok, I understand what you are saying. Your replies where helpful in that I now 
know what workaround options I have.

I agree this is ultimately a more general rcctl(8) or rc(8) issue. And I don’t 
have any ideas on how to improve that.

But given that a somewhat high level interface such as rcctl(8) exists, I feel 
editing the low level /etc/rc.conf.local directly is much more fragile. (And I 
shudder when I hear vi — but let’s not start a discussion/war about editor 
preferences.) But that all comes down to personal preference I guess.


Thanks!
Mike

> Am 10.07.2023 um 16:31 schrieb Stuart Henderson :
> 
> On 2023/07/10 15:57, Mike Fischer wrote:
 (Note: I know this could be further reduced to just one master process for 
 each version with a chroot(2) and a non-chroot(2) pool defined in the 
 single php-fpm.conf for each PHP version. But that is irrelevant to the 
 issue at hand.)
>>> 
>>> Actually I think that is relevant. At least, if you just had one running
>>> php-fpm daemon per version, you totally avoid the problem.
>> 
>> That would only solve the chroot/non-chroot problem, not the multiple 
>> versions of PHP. If you want, then just reduce my issue to one web server 
>> (either one). Then this is indeed irrelevant as I stated.
> 
> It absolutely does solve the multiple versions of PHP problem, I use it
> exactly that way.
> 
>>> With a single daemon per version, remove the extra added phpXX_fpm
>>> copies, instead follow the suggestion after "If you need to run multiple
>>> versions of PHP on one machine" in php's pkg-readme.
>> 
>> Actually that is effectively what I did.
>> Ok to be fair the strict pkg-readme method would store the config file paths 
>> in /etc/rc.conf.local which means the scripts in /etc/rc.d/ do not need to 
>> be modified. That does help with the update issue but then I loose my 
>> settings when I disable and later re-enable the service. So it opens another 
>> issue.
> 
> Putting the daemon flags in rc.conf.local is the key to it.
> 
> The "lose settings when disabling and re-enabling" is an rcctl
> limitation, and affects everything not just php. You can however
> add/remove phpXX_fpm from the pkg_scripts line yourself i.e.
> not use rcctl(8) for that part..
> 
> (IIRC the reason for that in the first place is because base daemons
> use xxx_flags=NO so there would be no way to "save" the old flags when
> disabling them, and generally base+pkg daemons should be treated the
> same)..
> 
 2) Would it make sense to include the more specific pexp in the PHP ports? 
 (I don’t think doing so would hurt the default use case, but maybe I’m 
 overlooking something?)
>>> 
>>> This is a bit awkward to do; the rc script would then need to
>>> parse the phpXX_fpm_flags variable and figure out what string php-fpm
>>> will use when it sets the process name (i.e. look for -y or --fpm-config
>>> and parse them the same way that php-fpm itself does).
>> 
>> No not really. Just adding »/etc/php-fpm.conf.*« to the pexp in the default 
>> rc.d script for the PHP version works for all versions of php-fpm and solves 
>> the problem. E.g.:
>> pexp="php-fpm-8.2: master process .*/etc/php-fpm.conf.*“
> 
> That breaks my use case (which is also the use case suggested in the
> pkg-readme, so others probably use it too):
> 
> $ pgrep -lf php.*process
> 65701 php-fpm-8.0: master process (/etc/php-fpm-8.0.conf)
> 28288 php-fpm-8.2: master process (/etc/php-fpm.conf)
> 
>>> Though the existing pexp is slightly less flexible, IMHO it's enough for
>>> most use cases, and it doesn't really seem worth the extra fragility to
>>> do this differently.
>> 
>> Is my suggestion really more fragile?
> 
> Yes, because you need to parse the command-line string from
> phpXX_fpm_flags to figure out how the process string will look,
> i.e. what config filename is used.
> 
>> Is there any chance the default install would not use /etc/php-fpm.conf as 
>> the php-fpm config file?
> 
> Yes, if someone sets phpXX_fpm_flags.
> 
>> Ok, I do see that someone strictly using the pkg-readme method would run 
>> into issues as the matched pattern would not always match the the manually 
>> configured config file. So I guess I’m left with the strict pkg-readme 
>> method, /etc/rc.conf.local and the fact that my settings get lost on 
>> disable. Sigh…
>> 
>> Maybe I need to write scripts to enable the services and automatically 
>> restore the settings. Something like:
>> 
>> # cat /root/bin/enable_php74_fpm.sh
>> #!/bin/sh
>> service='php74_fpm'
>> /usr/sbin/rcctl enable "$service" && \
>> /usr/sbin/rcctl set "$service" flags '-c /etc/php-7.4.ini -y 
>> /etc/php-fpm-74.conf'
>> # EOF.
>> # cat /root/bin/enable_php80_fpm.sh
>> #!/bin/sh
>> service='php80_fpm'
>> /usr/sbin/rcctl enable "$service" && \
>> /usr/sbin/rcctl set "$service" flags '-c /etc/php-8.0.ini -y 
>> /etc/php-fpm-80.conf'
>> # EOF.
>> # cat /root/bin/enable_php81_fpm.sh
>> #!/bin/sh
>> service='php81_fpm'
>> /usr/sbin/rcctl enable 

CVS: cvs.openbsd.org: ports

[Ian Darwin]

CVSROOT:/cvs
Module name:ports
Changes by: i...@cvs.openbsd.org2023/07/10 09:04:31

Modified files:
net/openfire   : Makefile distinfo 
net/openfire/pkg: PLIST openfire.rc 

Log message:
4.6.8 stable fixes several  CVEs, most recently CVE-2023-32315
Use precompiled, until maven is easier to use in ports.
Take maintainer. Looks right & ok sthen@

update openfire 4.2.3->4.6.8

[Ian Darwin]

4.6.8 stable fixes several  CVEs, most recently CVE-2023-32315
Use precompiled, until maven is easier to use in ports.
Take maintainer.

OK?

4.7.5 is available but staying on "stable" for time being.

Index: Makefile
===
RCS file: /cvs/ports/net/openfire/Makefile,v
retrieving revision 1.56
diff -u -p -r1.56 Makefile
--- Makefile8 Nov 2022 11:16:59 -   1.56
+++ Makefile10 Jul 2023 14:28:36 -
@@ -1,7 +1,6 @@
 COMMENT=   XMPP real time collaboration server
-V= 4.2.3
-REVISION=  2
-DISTNAME=  openfire_src_${V:S/./_/g}
+V= 4.6.8
+DISTNAME=  openfire_${V:S/./_/g}
 PKGNAME=   openfire-$V
 CATEGORIES=net
 
@@ -9,46 +8,44 @@ MASTER_SITES= https://www.igniterealtime
 
 HOMEPAGE=  https://www.igniterealtime.org/projects/openfire/index.jsp
 
+MAINTAINER=Ian Darwin 
+
 # ASL 2.0
 PERMIT_PACKAGE=Yes
 
+NO_BUILD=  yes
 NO_TEST=   yes
 
 MODULES=   java
-MODJAVA_VER=   1.8
+MODJAVA_VER=   17
 MODJAVA_JRE=   Yes
-MODJAVA_BUILD= ant
 
 RUN_DEPENDS=   java/javaPathHelper
 
-WRKDIST=   ${WRKDIR}/openfire_src
-WRKSRC=${WRKDIST}/build
+WRKDIST=   ${WRKDIR}/openfire
 
 OPENFIREDEST=  ${PREFIX}/openfire
-DATADIRS=  lib logs plugins resources
-
-pre-install:
-   rm -rf ${WRKDIST}/target/openfire/resources/nativeAuth
-   mv ${WRKDIST}/target/openfire/resources/security ${WRKBUILD}
+DATADIRS=  lib plugins resources
+DOCDIRS=   documentation
 
 do-install:
-   cd ${WRKDIST}/target/openfire && \
+   rm -rf ${WRKDIST}/resources/nativeAuth
+   cd ${WRKDIST} && \
find ${DATADIRS} -type d \
-exec ${INSTALL_DATA_DIR} ${OPENFIREDEST}/{} \; && \
find ${DATADIRS} ! -type d \
-exec ${INSTALL_DATA} -m 644 {} ${OPENFIREDEST}/{} \;
-   ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/openfire
-   ${INSTALL_DATA} ${WRKDIST}/documentation/docs/*-guide.html \
-   ${PREFIX}/share/doc/openfire
-   ${INSTALL_DATA} ${WRKDIST}/documentation/docs/database.html \
-   ${PREFIX}/share/doc/openfire
-   ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/openfire/security
+   cd ${WRKDIST} && \
+   find ${DOCDIRS} -type d \
+   -exec ${INSTALL_DATA_DIR} 
${PREFIX}/share/doc/openfire/{} \; && \
+   find ${DOCDIRS}/* ! -type d \
+   -exec ${INSTALL_DATA} -m 644 {} 
${PREFIX}/share/doc/openfire \;
+   ${INSTALL_DATA_DIR} ${OPENFIREDEST}/logs
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/openfire/
-   ${INSTALL_DATA} ${WRKDIST}/target/openfire/conf/openfire.xml \
+   ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/openfire/security
+   ${INSTALL_DATA} ${WRKDIST}/conf/openfire.xml \
${PREFIX}/share/examples/openfire/
-   ${INSTALL_DATA} ${WRKDIST}/target/openfire/conf/security.xml \
+   ${INSTALL_DATA} ${WRKDIST}/conf/security.xml \
${PREFIX}/share/examples/openfire/
-   ${INSTALL_DATA} ${WRKBUILD}/security/* \
-   ${PREFIX}/share/examples/openfire/security
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/net/openfire/distinfo,v
retrieving revision 1.19
diff -u -p -r1.19 distinfo
--- distinfo1 Oct 2018 20:08:53 -   1.19
+++ distinfo10 Jul 2023 14:28:36 -
@@ -1,2 +1,2 @@
-SHA256 (openfire_src_4_2_3.tar.gz) = 
mpAbzQaSDMtbQXUX2wKaSiC3ddSao52RipltSq9HQww=
-SIZE (openfire_src_4_2_3.tar.gz) = 113557155
+SHA256 (openfire_4_6_8.tar.gz) = si/OmTvOSTA0YYPV7cHp44gnpH7Y9kxBSGoQX1dMwRY=
+SIZE (openfire_4_6_8.tar.gz) = 48730297
Index: pkg/PLIST
===
RCS file: /cvs/ports/net/openfire/pkg/PLIST,v
retrieving revision 1.14
diff -u -p -r1.14 PLIST
--- pkg/PLIST   8 Nov 2022 11:16:59 -   1.14
+++ pkg/PLIST   10 Jul 2023 14:28:36 -
@@ -12,20 +12,116 @@ openfire/
 @owner
 @group
 openfire/lib/
-openfire/lib/bcpg-jdk15on.jar
-openfire/lib/bcpkix-jdk15on.jar
-openfire/lib/bcprov-jdk15on.jar
-openfire/lib/hsqldb.jar
-openfire/lib/javax.websocket-api.jar
-openfire/lib/jtds.jar
-openfire/lib/log4j.xml
-openfire/lib/mail.jar
-openfire/lib/mysql.jar
-openfire/lib/npn-boot.jar
-openfire/lib/openfire.jar
-openfire/lib/postgres.jar
-openfire/lib/slf4j-log4j12.jar
+openfire/lib/FastInfoset-1.2.16.jar
+openfire/lib/activation-1.1.jar
+openfire/lib/ant-1.10.9.jar
+openfire/lib/ant-launcher-1.10.9.jar
+openfire/lib/apache-el-8.5.54.jar
+openfire/lib/apache-jsp-8.5.54.jar
+openfire/lib/apache-jsp-9.4.35.v20201120.jar
+openfire/lib/asm-9.0.jar
+openfire/lib/asm-analysis-9.0.jar
+openfire/lib/asm-commons-9.0.jar
+openfire/lib/asm-tree-9.0.jar
+openfire/lib/bcpg-jdk15on-1.68.jar
+openfire/lib/bcpkix-jdk15on-1.68.jar
+openfire/lib/bcprov-jdk15on-1.68.jar
+openfire/lib/caffeine-2.7.0.jar

Re: Maintaining multiple PHP-FPM versions on the same host

[Stuart Henderson]

On 2023/07/10 15:57, Mike Fischer wrote:
> >> (Note: I know this could be further reduced to just one master process for 
> >> each version with a chroot(2) and a non-chroot(2) pool defined in the 
> >> single php-fpm.conf for each PHP version. But that is irrelevant to the 
> >> issue at hand.)
> > 
> > Actually I think that is relevant. At least, if you just had one running
> > php-fpm daemon per version, you totally avoid the problem.
> 
> That would only solve the chroot/non-chroot problem, not the multiple 
> versions of PHP. If you want, then just reduce my issue to one web server 
> (either one). Then this is indeed irrelevant as I stated.

It absolutely does solve the multiple versions of PHP problem, I use it
exactly that way.

> > With a single daemon per version, remove the extra added phpXX_fpm
> > copies, instead follow the suggestion after "If you need to run multiple
> > versions of PHP on one machine" in php's pkg-readme.
> 
> Actually that is effectively what I did.
> Ok to be fair the strict pkg-readme method would store the config file paths 
> in /etc/rc.conf.local which means the scripts in /etc/rc.d/ do not need to be 
> modified. That does help with the update issue but then I loose my settings 
> when I disable and later re-enable the service. So it opens another issue.

Putting the daemon flags in rc.conf.local is the key to it.

The "lose settings when disabling and re-enabling" is an rcctl
limitation, and affects everything not just php. You can however
add/remove phpXX_fpm from the pkg_scripts line yourself i.e.
not use rcctl(8) for that part..

(IIRC the reason for that in the first place is because base daemons
use xxx_flags=NO so there would be no way to "save" the old flags when
disabling them, and generally base+pkg daemons should be treated the
same)..

> >> 2) Would it make sense to include the more specific pexp in the PHP ports? 
> >> (I don’t think doing so would hurt the default use case, but maybe I’m 
> >> overlooking something?)
> > 
> > This is a bit awkward to do; the rc script would then need to
> > parse the phpXX_fpm_flags variable and figure out what string php-fpm
> > will use when it sets the process name (i.e. look for -y or --fpm-config
> > and parse them the same way that php-fpm itself does).
> 
> No not really. Just adding »/etc/php-fpm.conf.*« to the pexp in the default 
> rc.d script for the PHP version works for all versions of php-fpm and solves 
> the problem. E.g.:
> pexp="php-fpm-8.2: master process .*/etc/php-fpm.conf.*“

That breaks my use case (which is also the use case suggested in the
pkg-readme, so others probably use it too):

$ pgrep -lf php.*process
65701 php-fpm-8.0: master process (/etc/php-fpm-8.0.conf)
28288 php-fpm-8.2: master process (/etc/php-fpm.conf)

> > Though the existing pexp is slightly less flexible, IMHO it's enough for
> > most use cases, and it doesn't really seem worth the extra fragility to
> > do this differently.
> 
> Is my suggestion really more fragile?

Yes, because you need to parse the command-line string from
phpXX_fpm_flags to figure out how the process string will look,
i.e. what config filename is used.

> Is there any chance the default install would not use /etc/php-fpm.conf as 
> the php-fpm config file?

Yes, if someone sets phpXX_fpm_flags.

> Ok, I do see that someone strictly using the pkg-readme method would run into 
> issues as the matched pattern would not always match the the manually 
> configured config file. So I guess I’m left with the strict pkg-readme 
> method, /etc/rc.conf.local and the fact that my settings get lost on disable. 
> Sigh…
> 
> Maybe I need to write scripts to enable the services and automatically 
> restore the settings. Something like:
> 
> # cat /root/bin/enable_php74_fpm.sh
> #!/bin/sh
> service='php74_fpm'
> /usr/sbin/rcctl enable "$service" && \
> /usr/sbin/rcctl set "$service" flags '-c /etc/php-7.4.ini -y 
> /etc/php-fpm-74.conf'
> # EOF.
> # cat /root/bin/enable_php80_fpm.sh
> #!/bin/sh
> service='php80_fpm'
> /usr/sbin/rcctl enable "$service" && \
> /usr/sbin/rcctl set "$service" flags '-c /etc/php-8.0.ini -y 
> /etc/php-fpm-80.conf'
> # EOF.
> # cat /root/bin/enable_php81_fpm.sh
> #!/bin/sh
> service='php81_fpm'
> /usr/sbin/rcctl enable "$service" && \
> /usr/sbin/rcctl set "$service" flags '-c /etc/php-8.1.ini -y 
> /etc/php-fpm-81.conf'
> # EOF.
> # cat /root/bin/enable_php82_fpm.sh
> #!/bin/sh
> service='php82_fpm'
> /usr/sbin/rcctl enable "$service" && \
> /usr/sbin/rcctl set "$service" flags '-c /etc/php-8.2.ini -y 
> /etc/php-fpm-82.conf'
> # EOF.
> # 

honestly I would just "vi /etc/rc.conf.local" to disable/enable by
adding or removing from the pkg_scripts line...

> Then I only need to remember to use the script instead of the standard rcctl 
> enable phpXX_fpm. But at least I don’t need to memorize the flags for each 
> version.
> 
> 
> Thanks for your help!
> 
> Mike

Re: Maintaining multiple PHP-FPM versions on the same host

[Mike Fischer]

Hi Stuart,

thanks for your response. Please see my inline comments below…

> Am 10.07.2023 um 13:26 schrieb Stuart Henderson :
> 
> (moving to ports@, reply-to set)
> 
> 
> On 2023-07-10, Mike Fischer  wrote:
>> Hi!
>> 
>> I’m trying to figure out the best way to maintain multiple php-fpm setups at 
>> the same time and ran into a somewhat annoying issue.
>> 
>> I’m not sure how many other users might have a similar situation? If this 
>> something too non-standard, let me know and I’ll shut up ;-)
>> 
>> 
>> Background
>> ==
>> 
>> The server supports multiple versions of PHP for websites using php-fpm. 
>> There are also multiple web servers running at the same time (on different 
>> IP/port combinations obviously). Specifically OpenBSD httpd and Apache httpd 
>> from ports.
>> 
>> OpenBSD httpd runs in its normal chroot(2) environment. Apache httpd does 
>> not use chroot(2). This requires corresponding setups for php-fpm as well. 
>> Using e.g. a non-chroot(2) php-fpm with OpenBSD httpd does not work.
>> 
>> Each php-fpm variant uses its own socket. So changing the PHP version for a 
>> web server (or even for just certain paths on that server) is as easy as 
>> pointing to the correct socket for the FastCGI mechanism of the web server.
>> 
>> 
>> Setup
>> =
>> 
>> All available PHP Versions are supported and configured. I.e. 7.4, 8.0, 8.1 
>> and 8.2 for OpenBSD 7.3.
>> 
>> I have adjusted /etc/php-7.4.ini, /etc/php-8.0.ini, etc. as required
>> 
>> I have created and modified /etc/php-fpm-7.4cr.conf, 
>> /etc/php-fpm-7.4ncr.conf, /etc/php-fpm-8.0cr.conf, /etc/php-fpm-8.0ncr.conf, 
>> etc. The default /etc/php-fpm.conf is not actively used.
>> 
>> I have copied the /etc/rc.d/phpXX_fpm files and modified them to:
>> - use the appropriate /etc/php-fpm.conf (/etc/php-fpm-7.4cr.conf, 
>> /etc/php-fpm-7.4ncr.conf, /etc/php-fpm-8.0cr.conf, /etc/php-fpm-8.0ncr.conf, 
>> etc.)
>> - use the appropriate /etc/php.ini (/etc/php-7.4.ini, /etc/php-8.0.ini, 
>> /etc/php-8.1.ini and /etc/php-8.2.ini)
>> - adjust the pexp to match the php-fpm.conf in addition to "php-fpm-7.4: 
>> master process", e.g. "php-fpm-7.4: master process 
>> .*/etc/php-fpm-7.4cr.conf.*", etc.
>> 
>> Thus I have:
>> /etc/rc.d/php74cr_fpm
>> /etc/rc.d/php74ncr_fpm
>> /etc/rc.d/php80cr_fpm
>> /etc/rc.d/php80ncr_fpm
>> /etc/rc.d/php81cr_fpm
>> /etc/rc.d/php81ncr_fpm
>> /etc/rc.d/php82cr_fpm
>> /etc/rc.d/php82ncr_fpm
>> 
>> And all of these have been enabled using `rcctl enable php74cr_fpm 
>> php74ncr_fpm php80cr_fpm php80ncr_fpm php81cr_fpm php81ncr_fpm php82cr_fpm 
>> php82ncr_fpm` and of course started using `rcctl start …`.
>> 
>> For example:
>> # cat /etc/rc.d/php82cr_fpm
>> #!/bin/ksh
>> 
>> daemon="/usr/local/sbin/php-fpm-8.2"
>> daemon_flags="-c /etc/php-8.2-cr.ini -y /etc/php-fpm-82cr.conf"
>> 
>> . /etc/rc.d/rc.subr
>> 
>> pexp="php-fpm-8.2: master process .*/etc/php-fpm-82cr.conf.*"
>> rc_reload=NO
>> 
>> rc_cmd $1
>> # 
>> 
>> 
>> (Note: I know this could be further reduced to just one master process for 
>> each version with a chroot(2) and a non-chroot(2) pool defined in the single 
>> php-fpm.conf for each PHP version. But that is irrelevant to the issue at 
>> hand.)
> 
> Actually I think that is relevant. At least, if you just had one running
> php-fpm daemon per version, you totally avoid the problem.

That would only solve the chroot/non-chroot problem, not the multiple versions 
of PHP. If you want, then just reduce my issue to one web server (either one). 
Then this is indeed irrelevant as I stated.


> 
>> 
>> Issue
>> =
>> 
>> `rcctl ls started` lists php74_fpm, php80_fpm, php81_fpm and php82_fpm as 
>> started even though they are neither enabled nor started!
>> 
>> The reason this happens is the pexp which is too general. E.g. for php74_fpm 
>> it is pexp="php-fpm-7.4: master process .*"
>> 
>> Modifying this to e.g. pexp="php-fpm-7.4: master process 
>> .*/etc/php-fpm.conf.*" solves the problem.
>> 
>> BUT: /etc/rc.d/php74_fpm will be overwritten when the php-7.4 port ist 
>> updated. (Same for the other versions of course.) So my change is lost and 
>> has to be reapplied. If I forget about this then at a later time I’ll become 
>> confused by the output of `rcctl ls started`.
>> 
>> 
>> Questions
>> =
>> 
>> 1) Is there a better, update-proof way to solve this problem?
> 
> With a single daemon per version, remove the extra added phpXX_fpm
> copies, instead follow the suggestion after "If you need to run multiple
> versions of PHP on one machine" in php's pkg-readme.

Actually that is effectively what I did.
Ok to be fair the strict pkg-readme method would store the config file paths in 
/etc/rc.conf.local which means the scripts in /etc/rc.d/ do not need to be 
modified. That does help with the update issue but then I loose my settings 
when I disable and later re-enable the service. So it opens another issue.


> 
>> 2) Would it make sense to include the more specific pexp in the PHP ports? 

Re: lang/* BTI breakage

[Theo de Raadt]

Brian Callahan  wrote:

> On 7/10/2023 9:33 AM, Theo de Raadt wrote:
> > Brian Callahan  wrote:
> > 
> >> Pushed a nobtcfi fix for DMD.
> > 
> > nobtcfi should never be considered a "fix".  It is a workaround we make
> > available to allow laggard software to continue running -- nothing more.
> > 
> > 
> > 
> 
> Agreed. And I made the same clear to them.


Let me explain this in a different way, which may help conversations with
upstreams.


In OpenBSD, we are experimenting with mandatory BTI (arm64) /IBT (x86).

In Linux, they have started a 20 year experiment with per-page BTI, and
elective IBT. 

On arm64, you can do BTI on a per-page basis.  One code page may have
BTI, and another page won't.  That allows a crappy shared library
without BTI to "work' inside a binary that has BTI.  One .so will be
labelled as "I am not ready for BTI enforcement", another .so will be
labelled as "OK to enforce BTI here". Obviously an attacker will use JOP
methodology inside the crappy library.  Such a scheme does not lead to
eventually having BTI everywhere, and JOP will remain alive.

On x86, you cannot do it perform it page-by page.  So if anything in the
process's address cannot accept BTI enforcement, you won't get BTI in that
process.  JOP will remain alive.


The mandatory behaviour will arrive in Linux eventually because openbsd
developers have pushed upstream library and application authors.

Eventually (adv)
10 years or more into the future

Re: lang/* BTI breakage

[Brian Callahan]

On 7/10/2023 9:33 AM, Theo de Raadt wrote:
> Brian Callahan  wrote:
> 
>> Pushed a nobtcfi fix for DMD.
> 
> nobtcfi should never be considered a "fix".  It is a workaround we make
> available to allow laggard software to continue running -- nothing more.
> 
> 
> 

Agreed. And I made the same clear to them.

Re: lang/* BTI breakage

[Theo de Raadt]

Brian Callahan  wrote:

> Pushed a nobtcfi fix for DMD.

nobtcfi should never be considered a "fix".  It is a workaround we make
available to allow laggard software to continue running -- nothing more.

Re: lang/* BTI breakage

[Brian Callahan]

On 7/9/2023 5:56 PM, Christian Weisgerber wrote:
> The remaining build failures are:
> 
> lang/crystal
> lang/dmd
> lang/gprolog
> lang/ldc
> lang/mono
> lang/ocaml
> lang/racket-minimal
> 

Pushed a nobtcfi fix for DMD. I will work with upstream to get them to
fix things, but DMD has a custom backend and that might take a bit.

Am working with LDC now to get things to work. As LDC is just LLVM, I
suspect this one might be a lot easier.

~Brian

CVS: cvs.openbsd.org: ports

[Brian Callahan]

CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2023/07/10 07:27:33

Modified files:
lang/dmd   : Makefile distinfo 
Added files:
lang/dmd/patches: patch-dmd_compiler_src_dmd_link_d 

Log message:
Disable BT CFI with DMD. Will work with upstream to try to get BT CFI
working with DMD. Regen bootstrap.

Re: Maintaining multiple PHP-FPM versions on the same host

[Stuart Henderson]

(moving to ports@, reply-to set)


On 2023-07-10, Mike Fischer  wrote:
> Hi!
>
> I’m trying to figure out the best way to maintain multiple php-fpm setups at 
> the same time and ran into a somewhat annoying issue.
>
> I’m not sure how many other users might have a similar situation? If this 
> something too non-standard, let me know and I’ll shut up ;-)
>
>
> Background
>==
>
> The server supports multiple versions of PHP for websites using php-fpm. 
> There are also multiple web servers running at the same time (on different 
> IP/port combinations obviously). Specifically OpenBSD httpd and Apache httpd 
> from ports.
>
> OpenBSD httpd runs in its normal chroot(2) environment. Apache httpd does not 
> use chroot(2). This requires corresponding setups for php-fpm as well. Using 
> e.g. a non-chroot(2) php-fpm with OpenBSD httpd does not work.
>
> Each php-fpm variant uses its own socket. So changing the PHP version for a 
> web server (or even for just certain paths on that server) is as easy as 
> pointing to the correct socket for the FastCGI mechanism of the web server.
>
>
> Setup
>=
>
> All available PHP Versions are supported and configured. I.e. 7.4, 8.0, 8.1 
> and 8.2 for OpenBSD 7.3.
>
> I have adjusted /etc/php-7.4.ini, /etc/php-8.0.ini, etc. as required
>
> I have created and modified /etc/php-fpm-7.4cr.conf, 
> /etc/php-fpm-7.4ncr.conf, /etc/php-fpm-8.0cr.conf, /etc/php-fpm-8.0ncr.conf, 
> etc. The default /etc/php-fpm.conf is not actively used.
>
> I have copied the /etc/rc.d/phpXX_fpm files and modified them to:
> - use the appropriate /etc/php-fpm.conf (/etc/php-fpm-7.4cr.conf, 
> /etc/php-fpm-7.4ncr.conf, /etc/php-fpm-8.0cr.conf, /etc/php-fpm-8.0ncr.conf, 
> etc.)
> - use the appropriate /etc/php.ini (/etc/php-7.4.ini, /etc/php-8.0.ini, 
> /etc/php-8.1.ini and /etc/php-8.2.ini)
> - adjust the pexp to match the php-fpm.conf in addition to "php-fpm-7.4: 
> master process", e.g. "php-fpm-7.4: master process 
> .*/etc/php-fpm-7.4cr.conf.*", etc.
>
> Thus I have:
> /etc/rc.d/php74cr_fpm
> /etc/rc.d/php74ncr_fpm
> /etc/rc.d/php80cr_fpm
> /etc/rc.d/php80ncr_fpm
> /etc/rc.d/php81cr_fpm
> /etc/rc.d/php81ncr_fpm
> /etc/rc.d/php82cr_fpm
> /etc/rc.d/php82ncr_fpm
>
> And all of these have been enabled using `rcctl enable php74cr_fpm 
> php74ncr_fpm php80cr_fpm php80ncr_fpm php81cr_fpm php81ncr_fpm php82cr_fpm 
> php82ncr_fpm` and of course started using `rcctl start …`.
>
> For example:
> # cat /etc/rc.d/php82cr_fpm
> #!/bin/ksh
>
> daemon="/usr/local/sbin/php-fpm-8.2"
> daemon_flags="-c /etc/php-8.2-cr.ini -y /etc/php-fpm-82cr.conf"
>
> . /etc/rc.d/rc.subr
>
> pexp="php-fpm-8.2: master process .*/etc/php-fpm-82cr.conf.*"
> rc_reload=NO
>
> rc_cmd $1
> # 
>
>
> (Note: I know this could be further reduced to just one master process for 
> each version with a chroot(2) and a non-chroot(2) pool defined in the single 
> php-fpm.conf for each PHP version. But that is irrelevant to the issue at 
> hand.)

Actually I think that is relevant. At least, if you just had one running
php-fpm daemon per version, you totally avoid the problem.

>
> Issue
>=
>
> `rcctl ls started` lists php74_fpm, php80_fpm, php81_fpm and php82_fpm as 
> started even though they are neither enabled nor started!
>
> The reason this happens is the pexp which is too general. E.g. for php74_fpm 
> it is pexp="php-fpm-7.4: master process .*"
>
> Modifying this to e.g. pexp="php-fpm-7.4: master process 
> .*/etc/php-fpm.conf.*" solves the problem.
>
> BUT: /etc/rc.d/php74_fpm will be overwritten when the php-7.4 port ist 
> updated. (Same for the other versions of course.) So my change is lost and 
> has to be reapplied. If I forget about this then at a later time I’ll become 
> confused by the output of `rcctl ls started`.
>
>
> Questions
>=
>
> 1) Is there a better, update-proof way to solve this problem?

With a single daemon per version, remove the extra added phpXX_fpm
copies, instead follow the suggestion after "If you need to run multiple
versions of PHP on one machine" in php's pkg-readme.

> 2) Would it make sense to include the more specific pexp in the PHP ports? (I 
> don’t think doing so would hurt the default use case, but maybe I’m 
> overlooking something?)

This is a bit awkward to do; the rc script would then need to
parse the phpXX_fpm_flags variable and figure out what string php-fpm
will use when it sets the process name (i.e. look for -y or --fpm-config
and parse them the same way that php-fpm itself does).

Yes it is possible to do that, but it's definitely more fragile, and
considering that the main purpose of php-fpm is to run multiple copies
of php for different environments anyway, it seems a bit redundant to
run multiple copies of the same version of php-fpm.

Though the existing pexp is slightly less flexible, IMHO it's enough for
most use cases, and it doesn't really seem worth the extra fragility to
do this differently.

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2023/07/10 06:09:54

Modified files:
cad/pcb2gcode  : Makefile distinfo 
cad/pcb2gcode/patches: patch-geos_helpers_cpp 
Removed files:
cad/pcb2gcode/patches: patch-bg_operators_cpp 

Log message:
update to pcb2gcode-2.5.0 plus an upstream patch to unbreak with newer geos

Re: lang/* BTI breakage

[Theo de Raadt]

Christian Weisgerber  wrote:

> The remaining build failures are:
> 
> lang/crystal
> lang/dmd
> lang/gprolog
> lang/ldc
> lang/mono
> lang/ocaml
> lang/racket-minimal

Have the upstreams been told that IBT/BTI instructions are going to
be required in all software (sometime in the future).

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2023/07/10 05:12:00

Modified files:
lang/php/7.4   : Makefile 
lang/php/8.0   : Makefile 
lang/php/8.1   : Makefile 
lang/php/8.2   : Makefile 
lang/php/files : README-main 

Log message:
zap stray space in pkg-readme

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2023/07/10 04:46:35

Modified files:
print/qpdf : Makefile distinfo 
print/qpdf/patches: patch-CMakeLists_txt 

Log message:
Update to qpdf-11.5.0.

[Update]devel/p5-Moo: Update to 2.005005

[wen heping]

Hi, ports@:

Here is a patch for devel/p5-Moo:
 i) Update to 2.005005
 ii) Update RUN_DEPENDS and TEST_DEPENDS
 iii) Remove  devel/p5-strictures from TEST_DEPENDS since
it is RUN_DEPENDS

It build well and pass all tests on amd64-current system.

Many ports (30+) depends on p5-Moo, I tested some of them,
no problem meet.
 

Cheers !
wenIndex: Makefile
===
RCS file: /cvs/ports/devel/p5-Moo/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile11 Mar 2022 18:51:45 -  1.11
+++ Makefile10 Jul 2023 07:56:41 -
@@ -3,7 +3,7 @@ COMMENT =   Minimalist Object Orientation 
 
 MODULES =  cpan
 PKG_ARCH = *
-DISTNAME = Moo-2.004004
+DISTNAME = Moo-2.005005
 CATEGORIES =   devel
 
 CPAN_AUTHOR =  HAARG
@@ -12,19 +12,15 @@ CPAN_AUTHOR =   HAARG
 PERMIT_PACKAGE =   Yes
 
 
-RUN_DEPENDS =  devel/p5-Class-Method-Modifiers>=1.1 \
-   devel/p5-Devel-GlobalDestruction>=0.11 \
+RUN_DEPENDS =  devel/p5-Class-Method-Modifiers>=1.10 \
devel/p5-Module-Runtime>=0.014 \
-   devel/p5-Role-Tiny>=2.04 \
-   devel/p5-Sub-Quote>=2.003001
+   devel/p5-Role-Tiny>=2.002003 \
+   devel/p5-Sub-Quote>=2.006006
 
 # p5-strictures in RUN_DEPENDS because although not required
 # it will be less confusing.
 RUN_DEPENDS += devel/p5-strictures>=2
 
-TEST_DEPENDS = devel/p5-Class-XSAccessor>=1.18 \
-   devel/p5-Sub-Name>=0.08 \
-   devel/p5-Test-Fatal>=0.003 \
-   devel/p5-strictures>=2
+TEST_DEPENDS = devel/p5-Class-XSAccessor>=1.18
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/devel/p5-Moo/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo17 Jan 2021 11:15:40 -  1.6
+++ distinfo10 Jul 2023 07:56:41 -
@@ -1,2 +1,2 @@
-SHA256 (Moo-2.004004.tar.gz) = cUt3sRV4hwjG2KtvGO6hc/gQnTl67NNOMsxxoP/PIkY=
-SIZE (Moo-2.004004.tar.gz) = 108386
+SHA256 (Moo-2.005005.tar.gz) = +1opUmSfrtBzc/Igt4AEqcaro4dzkTN0DBdw6bH0sQg=
+SIZE (Moo-2.005005.tar.gz) = 108583
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/p5-Moo/pkg/PLIST,v
retrieving revision 1.5
diff -u -p -r1.5 PLIST
--- pkg/PLIST   11 Mar 2022 18:51:45 -  1.5
+++ pkg/PLIST   10 Jul 2023 07:56:41 -
@@ -13,8 +13,6 @@ ${P5SITE}/Moo/HandleMoose/_TypeMap.pm
 ${P5SITE}/Moo/Object.pm
 ${P5SITE}/Moo/Role.pm
 ${P5SITE}/Moo/_Utils.pm
-${P5SITE}/Moo/_mro.pm
-${P5SITE}/Moo/_strictures.pm
 ${P5SITE}/Moo/sification.pm
 ${P5SITE}/oo.pm
 @man man/man3p/Moo.3p