From nobody Mon Aug 25 08:00:07 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9NWH15Cjz65N3T for ; Mon, 25 Aug 2025 08:00:11 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9NWH02tQz3d8P; Mon, 25 Aug 2025 08:00:11 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756108811; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=RNqb4wLN/DBJDz+zVDEUAZ2qQcEcM/fOMdwWq/vEN/c=; b=LKOtjRJXj2D1sJ6fgqMlYhMwvTn20goU9OM3lAfWd+KUB88AK8/FyaWtHEg2lCLT/GEmyQ 7jwKf//jfelxyWMgyuBnhCSjHIJYPqrtXh5HGlLwk5UXRWI+tTo91V6D0zvuHLqBhLL4zw JWlZJ0FioaqHdhJHfuN+RwzdKZrPbRk/tmrR96YnxzG9tqEfUB0iJkgfo+Ex4/i8aCJqH1 jZZEVfzdu86UGRE1iF6/0dIHg6VdQadOXXy4RO3pnOpXA2nTDNfbJtb2l/p5uQLOtLMCWX eqJmmexwnEwmn9zzhTRoi+trlEm1lcqFD/QbhDyl1CO4S27bhTDDoX8GWKC/VA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756108811; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=RNqb4wLN/DBJDz+zVDEUAZ2qQcEcM/fOMdwWq/vEN/c=; b=UdAoOYGCfz0iaso61/MAsh5gvqRNx9RUyu096JkEXSivMAa9Sr5MdwcE7PCL1Hw85a6buZ JLc1z+jPU+keLrr24AM8UAuassEP1nh2cForFnN2Ycvs1ttsAIPOKTGipYZFoeqG7FES0g Bd0wLLZWAN6cJDWXWUyjfAiDnnhEBPgoOgAD+4xmQPbcXR4iKP9Ag9CEpamxgWgTFdVQXK SLZIfNsGDZuUVY1sil/n080Li9M/lHYTuvhHUjYHRdxCDvYe3yZEl+ofMrFzWQeGQA+Cdk J53MU83A4dl6/rksCD/7quQx8YgtWz7xWNz2epWu8eEiQKuQtc9o0IJEFex5EA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756108811; a=rsa-sha256; cv=none; b=WcfjtQSSs6xXi7Bytx9OH/h/31rVyw2UQe+dHjtP8XeMQmjid0dAxkDx7GKMpTy013BD4q tvU6shWxRWKcw8fjsN6TgBh+iB8ONX+NSQjzhZajMtINTWjyHC6vYkxqnNzpKyS34NW/HX IxwD3W2FwGqYhuAgR/of5qzLJD1gfdW486OpNfMALW9+oH6EJRZc/iTpHgWIs0vjUjaR48 A0SYAQOU8TevgKmoBkCsvoNFyxC0T+4+6ofwFyp8FLrieWVKPPlexSWNsVAq5G9WlRQIi0 702ssUrl0PPLKWV91CfJnmjpK8x/n2vqoi4srFBG8w39gDsIoP2Tm4GwyRSF1Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4c9NWG4XhPz1MHk; Mon, 25 Aug 2025 08:00:10 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Mon, 25 Aug 2025 01:00:07 -0700 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: August 2025 stabilization week Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi FreeBSD/main users & developers: This is an automated email to inform you that the August 2025 stabilization week started with FreeBSD/main at main-n279838-6c45a5dad0a0, which was tagged as main-stabweek-2025-Aug. Those who want to participate in the stabilization week are encouraged to update to the above revision/tag and test their systems. The tag main-stabweek-2025-Aug has been published at Gleb Smirnoff's github repo. To connect this repo as an additional remote you need to run: git remote add glebius https://github.com/glebius/FreeBSD Once remote is configured, to checkout the tag run: git fetch glebius --tags git checkout main-stabweek-2025-Aug If you want to use only the official FreeBSD repo, then update to the revision: git pull git checkout 6c45a5dad0a0 Developers are encouraged to avoid pushing new features to FreeBSD/main during the stabilization week, but focus on bugfixes instead. The stabilization week runs up to Friday 18:00 UTC, but if there is consensus that any regressions discovered by participants have been fixed, it will end early. Once that happens, the advisory freeze of FreeBSD/main branch is thawed. -- Gleb Smirnoff From nobody Mon Aug 25 08:44:39 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9PVn5rKmz65Qq8 for ; Mon, 25 Aug 2025 08:44:49 +0000 (UTC) (envelope-from saper@saper.info) Received: from q.saper.info (q.saper.info [IPv6:2605:2700:0:2:a800:ff:fec7:5c61]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (secp384r1) client-digest SHA384) (Client CN "q.saper.info", Issuer "E6" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9PVm5589z3jsH; Mon, 25 Aug 2025 08:44:48 +0000 (UTC) (envelope-from saper@saper.info) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=saper.info header.s=Sep2014 header.b=av94mJ2L; dmarc=none; spf=none (mx1.freebsd.org: domain of saper@saper.info has no SPF policy when checking 2605:2700:0:2:a800:ff:fec7:5c61) smtp.mailfrom=saper@saper.info Received: from q.saper.info (localhost [127.0.0.1]) by q.saper.info (8.18.1/8.18.1) with ESMTPS id 57P8ieIU049135 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 25 Aug 2025 08:44:40 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1756111480; bh=Z3vzYNzkUuo1T/4dj62NdFDwUcL3RftSPGjdORgmrH0=; h=Date:From:To:cc:Subject; b=av94mJ2LtxyO+Jr5Oa5/Lrtvy8HiC6f7pfExOSnDD26WBjSWPueS+9TBys1fFMbjz 3fZcObd2OGaen4cA6wjxYtZH1UccD4wdemfcs+iYNfNBjKbwDZ+ZkBnH2SOgcyOaYr 1mYkWeJ2MRAJan7zuzS1rAK442QerCeoonT8MlDw= Received: from localhost (saper@localhost) by q.saper.info (8.18.1/8.18.1/Submit) with ESMTP id 57P8idQl049132; Mon, 25 Aug 2025 08:44:40 GMT (envelope-from saper@saper.info) X-Authentication-Warning: q.saper.info: saper owned process doing -bs Date: Mon, 25 Aug 2025 08:44:39 +0000 From: Marcin Cieslak To: Alexander Leidinger cc: Kyle Evans , Xin LI , Current , Gleb Smirnoff Subject: UPDATING stuff Message-ID: <2r579os7-29n7-890r-9210-s3s1n4r0s4qo@fncre.vasb> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="2201072851-873589413-1756111480=:995" X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.39 / 15.00]; SIGNED_SMIME(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.986]; R_DKIM_ALLOW(-0.20)[saper.info:s=Sep2014]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_ALL(0.00)[]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[saper.info]; RECEIVED_HELO_LOCALHOST(0.00)[]; DKIM_TRACE(0.00)[saper.info:+]; R_SPF_NA(0.00)[no SPF record]; MISSING_XM_UA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_XAW(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ASN(0.00)[asn:47066, ipnet:2605:2700::/32, country:US]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4c9PVm5589z3jsH --2201072851-873589413-1756111480=:995 Content-Type: text/plain; format=flowed; charset=ISO-8859-2 Content-Transfer-Encoding: 8BIT On Thu, 21 Aug 2025, Alexander Leidinger wrote: >>> COMPAT_FREEBSD14? (Recently [gs]etgroups were changed, with compatibility >>> syscalls moved to COMPAT_FREEBSD14). > > UPDATING only mentions VMM stuff for COMPAT_FREEBSD14. I give this a try > tomorrow. But would this also affect the zfs dataset stuff? This thread could have been a simple UPDATING update. I think this is the fourth time or so I have run into problems, because the changes were not explained. UPDATING entry on VMM got only there after I've spent 2 days+ troubleshooting my wifibox failures. When I read your message I was immediately thinking you might need "COMPAT_FREEBSD14", but, again, I couldn't find any obvious entry neither in the docs nor in the git log I was looking at. @glebus - maybe during the stabilization effort the changes done to the tree could be reviewed and documented? - where the FreeBSD_version got bumped and why - ABI changes - .... For example it could be useful to be able to find the information "what does COMPAT_FREEBSD14 do exactly" in the UPDATING/release notes file. Otherwise I can't be sure if I need that option or "is my system fresh enough" to remove it from the kernel. Marcin Cielak --2201072851-873589413-1756111480=:995 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIOdgYJKoZIhvcNAQcCoIIOZzCCDmMCAQExDzANBglghkgBZQMEAgEFADAL BgkqhkiG9w0BBwGgggq9MIIEvDCCA6SgAwIBAgIQeEqpEhjRpCYIUTzTZlVD ozANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3Qg Q0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFs U2lnbjAeFw0yMDA5MTYwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFsxCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhH bG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24gMSBDQSAyMDIwMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvxvJBqEapaux2/z3J7fFslRO WjKVJ5rCMfWGsg17dmD7NSnG7Spoa8d3htXsls1IMxoO8PyouQajNQqYmlYo xinlqenMNv7CJyEKMOAtglBmD6C/QC7kT+dSx4HfSTs8xmv8veJOldMzF8S/ BEn/tD4w/Dvpg+oXOqDyOiHPTacRFK0QHoq5eEbBmVS8W0rwcaRotO9fGTA+ NjF0My7GLRNK0eMPGh2hcPZURQhXy7wRQ8XFIfEA6kaQHHN22ncnVtwqiTmA wTR+4GNNVinG3KjNZLAVSnGrdCvT2I4Zo19hKy5PX6o7wrVXvMR4zV5VBFwV 6ZDM+xewao7Mup+SbwIDAQABo4IBiTCCAYUwDgYDVR0PAQH/BAQDAgGGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBSFu/DMxDa1CmJ2o5kuj7s6aq3FUTAfBgNVHSMEGDAW gBSP8Et/qC5FJK5NUPpjmove4t0bvDB6BggrBgEFBQcBAQRuMGwwLQYIKwYB BQUHMAGGIWh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL3Jvb3RyMzA7Bggr BgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQv cm9vdC1yMy5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9i YWxzaWduLmNvbS9yb290LXIzLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIB KDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9y ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAWWtqju12g524FdD2HwUX U1rSxeM5aSU1cUC1V/xBjXW0IjA7/3/vG2cietPPP/g3lpoQePVJpQAKZml8 1fHwPPivFK9Ja41jJkgqGzkORSC0xYkh2gGeQg1JVaCzcrRzJElRjT442m6F pbLHCebxIHLu0WBNjLZreB6MYMaqdPL6ItbXtD/BU4k517cEuUbczoBFZAra jq7oUBWXuroln5AMnRwVNwgJN4Np0s4kkJ94KepzbFOLzcbnfUB0+xT4foXm bM0GmmcPGOy0qvqEHJsBwDZXDxIk8oqCnnLngi7N94Sn4eTcmpZ9NH2dDN1O TEPVXgRG5X1pBcNtMWG6MDCCBfkwggThoAMCAQICDCKqoJRMYYx5sYJHGzAN BgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFs U2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMgUGVyc29u YWxTaWduIDEgQ0EgMjAyMDAeFw0yMzAzMDcxNjExMDlaFw0yNjAzMDcxNjEx MDlaMDwxGTAXBgNVBAMMEHNhcGVyQHNhcGVyLmluZm8xHzAdBgkqhkiG9w0B CQEWEHNhcGVyQHNhcGVyLmluZm8wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw ggIKAoICAQC8MB3fTYVrTadH5qE2CIa4VLvlL6QHgDriMRLkTA49SPszYCO0 fZTEpdSw8fc6kK9p2fD63LAfOHeD7jzey5aHBzpIGlxeFkn0Ce2BCYY5yLxK i9byoCwrpLchTR1Itpk1w+zy5E4T9KBTL1+c+w+TKpaIvFLXtjZtz4wQGi0p e/nRkRK9htGG3mETh+APitedl+ImGaI8NK9PELxuSkXnYAvGPpnXir8vbszk tJU1b0TevL/i3Sy6fhOhunZmTo1QDM7Zw4UyVjkQgTvL3y4I0tIrVjlam08x XZeMp+i/Gl51eHGvRVfvdJUJAjrWhrFEp8+2FZouWxWzAlHdd2sRp1AekNdP CeRgHeIF6uNtSseL1grKAjU+4BiixWPp1y1niB0humoQHoub/6fO/mU+//rW l3gTwZNu4FuKgZlfPw+qnvuka0c9dUNIZRCE5z8yXjS8R9yZWirnHNhYxf/e R2y4jaiHzPAjZlZZ2rGx8xVfB2n2JsAicj2+ZxmXlQ1yd5RW1pfxG3cdNNC5 uZ+j4JIN2ElsIjEKmMn9gHdoaEMAy/ENwNiMDBadLnc8qWirq/Ktp2dBSf2y /sH9xMpVyk8wuYjpbCnX4xslAensno5A20MYdKGPRFaItEhNPNbfzc1+4br8 exoXFX1F9ZJK9gGUO2nLbdRycphdyzxzgQIDAQABo4IB2jCCAdYwDgYDVR0P AQH/BAQDAgWgMIGjBggrBgEFBQcBAQSBljCBkzBOBggrBgEFBQcwAoZCaHR0 cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NnY2NyM3BlcnNv bmFsc2lnbjFjYTIwMjAuY3J0MEEGCCsGAQUFBzABhjVodHRwOi8vb2NzcC5n bG9iYWxzaWduLmNvbS9nc2djY3IzcGVyc29uYWxzaWduMWNhMjAyMDBMBgNV HSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3 dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEkGA1Ud HwRCMEAwPqA8oDqGOGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NnY2Ny M3BlcnNvbmFsc2lnbjFjYTIwMjAuY3JsMBsGA1UdEQQUMBKBEHNhcGVyQHNh cGVyLmluZm8wHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB8GA1Ud IwQYMBaAFIW78MzENrUKYnajmS6PuzpqrcVRMB0GA1UdDgQWBBTW/RrdlRFR y6MgS7liTThMnQA5ozANBgkqhkiG9w0BAQsFAAOCAQEAAwoUJShHMueocVlD 1+vYJbTTTbk9tabr2L4Iyyy4Btu1d1wwl6d9Yx2N9qaVERWcEeP0aR+NB2B7 xIKl/ZnZVuSxep0Raw4s284a/jSIJlsAi4SJItDCU2VrYJDWxP7MxzZHnzPI MLDoTHXPV18gvYTewoNk5/Yo89Kb0v/GpPTpP2sVdrWLHa4uKUHYrAZ0aByp kNw6lXp6o6DXvXaOd6KDTQN5XhmmHwLnuLceODF1t9gicsZIOY+KAxN6YZ6t EqwN48b4OFMpckDE3fm1iTZRqnEIqUHOKOcoCImkub1woEN0zXDQmLXaZigl uVztWSTM4/fapWLrlHBNxfjs1TGCA30wggN5AgEBMGswWzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMTAvBgNVBAMTKEdsb2Jh bFNpZ24gR0NDIFIzIFBlcnNvbmFsU2lnbiAxIENBIDIwMjACDCKqoJRMYYx5 sYJHGzANBglghkgBZQMEAgEFAKCB5DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0yNTA4MjUwODQ0MzlaMC8GCSqGSIb3DQEJ BDEiBCDXOZrxkAqUfbkTt+XD8vOFoF99yp1me3N9yr2AuMhaNjB5BgkqhkiG 9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUD BAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAgCm iemxsv7zX7zRJ0uIikEriA07dud0rXKd8gF4f1bW8/K7gJkmwoMq52OXzmob q/7pKZ8pKQEPyx+V91yFcOBeb991bUrQGc9xzYtB8rwGjOhAAAWVp0gAOhqC lG/1OZqmCc+RaRJN+AQz48xhAA1CTh2qV86XT6/Av4lPm5E9SjbBpLZNB++4 gNQligpQOfMy5Wjxhdxo9xWmRjM5BanuPewSXj+ew21xnyBX1wKerZ4I/i14 Qs+1AOG/0FpqIofdiHy8Bx+NyyG3BDYwQo00DlGFE/90Uf2Anh3AqAuhlrHx eLjQSb4ER9/kHAT3sdx0d4QLR/BI4wEfVgrfrVoBMbDyptuqKannAMRbzxom T775Qoe0eSdVE2hj/VqdXG4ZDmklgjXqq/w792Nuna3TgVyoS6Kp/LVrVipV g+A4S0Jwsdc21GosMs/TGZP7DxYtgkC3drQcmU5Dv1+DIUit0ZpTyVEs7kvf pWY4TEiQ0OdpxgqWqhOeSPx5WF3nFehsKceN2GplYjc7UeWOd1Lxh7kqnUOU AbwE483IkbrDwk4MsVEr6RDfksu0NJ2e93o8kua7zV1ntqykCdl/EDwO+bRw L8YPClFeC9qm2NDBrdyC4jYPm9ChzFPjCARWs9y80Rp8+PuuZWWHJqjIf2XD CdiNCnnz/TpvJRzZiulFxg== --2201072851-873589413-1756111480=:995-- From nobody Mon Aug 25 09:11:51 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9Q7C36LDz65Svm for ; Mon, 25 Aug 2025 09:12:55 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (prime256v1) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9Q7B5nlSz3sKd; Mon, 25 Aug 2025 09:12:54 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1756113167; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ETAtV8UpyQm4riKzwkbKCgnpXtkStzA6vdwHjpfG0/k=; b=hR/75S/gFz56mUZbyAi9XFy2Q6oEpZ0C13jTPqrS51CxJmq9bVtRgnfSWITKsaIj9Q4j1y MYNFRAwactz5BjjfxAwIa7EfC1Q/kKzD9D3FUhN2xEyCKL9zOw55pZTFVsd5d+E75eZc/2 kSHAnZY+obgK9RhRsIR0Tc7lHdJ1o+yUaQ1SFrDjijTQaE+j6FVncBnbRTi5TdSOnjWRlS /71oPICrS9isaXbVEjAlm7XozqexFALbG/a1MgfLVJ5B7iUWtyWxwZzt+TZNFCtgifgP56 gw5BBPNY19TAx3wNieMsHRZqUJikQF989RvnmxtnOYBkeRgym9B6xDSGXxpmOw== Date: Mon, 25 Aug 2025 11:11:51 +0200 From: Alexander Leidinger To: Marcin Cieslak Cc: Kyle Evans , Xin LI , Current , Gleb Smirnoff Subject: Re: UPDATING stuff In-Reply-To: <2r579os7-29n7-890r-9210-s3s1n4r0s4qo@fncre.vasb> References: <2r579os7-29n7-890r-9210-s3s1n4r0s4qo@fncre.vasb> Message-ID: <548137ff7d2289fa60a1cba14afa4957@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_f78c7ee47996da30feb57c953522600d"; micalg=pgp-sha256 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4c9Q7B5nlSz3sKd This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_f78c7ee47996da30feb57c953522600d Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2025-08-25 10:44, schrieb Marcin Cieslak: > On Thu, 21 Aug 2025, Alexander Leidinger wrote: > >>>> COMPAT_FREEBSD14? (Recently [gs]etgroups were changed, with >>>> compatibility syscalls moved to COMPAT_FREEBSD14). >> >> UPDATING only mentions VMM stuff for COMPAT_FREEBSD14. I give this a >> try tomorrow. But would this also affect the zfs dataset stuff? > > This thread could have been a simple UPDATING update. I think this is > the fourth > time or so I have run into problems, because the changes were not > explained. > > UPDATING entry on VMM got only there after I've spent 2 days+ > troubleshooting > my wifibox failures. > > When I read your message I was immediately thinking you might need > "COMPAT_FREEBSD14", > but, again, I couldn't find any obvious entry neither in the docs nor > in > the git log I was looking at. > > @glebus - maybe during the stabilization effort the changes done to the > tree > could be reviewed and documented? > > - where the FreeBSD_version got bumped and why This is normally documented in https://docs.freebsd.org/en/books/porters-handbook/versions/ (intended to be updated at the time when the FreeBSD_versions is increased), but I can agree that the info there is a bit terse sometimes. > - ABI changes > - .... > > For example it could be useful to be able to find the information "what > does COMPAT_FREEBSD14 do exactly" in the UPDATING/release notes file. > Otherwise I can't be sure if I need that option or "is my system fresh > enough" > to remove it from the kernel. What do you think about this? diff --git UPDATING UPDATING index ddb2e7603b2a..e197940c6431 100644 --- UPDATING +++ UPDATING @@ -73,6 +73,12 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 15.x IS SLOW: If you only have FreeBSD-sendmail installed for applications that require libmilter, you can now remove it. +20250815: + The [gs}etgroups(2)syscalls have changed. To maintain backwards + compatibility with existing programs, you need COMPAT_FREEBSD14 in + your kernel config until all applications which use this are + rebuild/reinstalled. + 20250815: jemalloc 5.3.0 has been committed to the tree. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_f78c7ee47996da30feb57c953522600d Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmisKOYACgkQEg2wmwP4 2Ib/zBAAgqPHJL7ipKhOXRq9n7UsD0mAr5i1vc/wHDfaKNocdsSqi/9nHn0NVGBI jZ8jcl0SHvjFqk0Aw7GRfOFU/qdKc1obdjisWGLHv82gJ47oskGOPSarrAoP4idD y//EiBvHOQu9dixiisFS/4s2pzN6TV8gVdqdTRrBVAn0sTf5nDmK1oEjTJWkaGPL MxpeYgdoA+LP0Jo1PBj/csSpIRBvasPrmyVftVtPoAN/NXvOOfBZJXdCIJyZJgbd 856v5IwYXN8ywmfUVwrxGo32i/R03TXGvMLPRV3GZNk13AxvUBDgbCAVexV7nhm8 sJzsicvD+wSHtjJJbccmWy53foW7wiDWpCqoc1IxYa6obeI+nVcmZHqE1vBYNXYq iw7tVOlk1RkdoEb8jBOn787w0UHq1xJvEv+qWBTHhUj3qE36a1p+e80uQr8dxB35 2U/zUnnQpc0r9/oJ+40Dks5lZMeI81YdXLEAE7H/JbHJIfXcO+yKrAsh1+lkO2xv Ig7l5eQXYLb7V+kGbY34Y9/4uDqbSchb5Gp3Nj+s2cIRbUpMS7iZo0w14mmhrs5G 3rubT9vRECWRTZJ2H/9ZLGDflCSeDIINPyJfDRkWlvozN94erdwv1eoCsGHotdpn wD+XrMjtSS2y2wMJlV2a/CDfOH0eh/Evy3kR2wbKfsYqjHjb8RA= =9PZy -----END PGP SIGNATURE----- --=_f78c7ee47996da30feb57c953522600d-- From nobody Mon Aug 25 10:48:26 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9SFm5k0Nz65Zy2 for ; Mon, 25 Aug 2025 10:48:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9SFm2jw8z45Qn for ; Mon, 25 Aug 2025 10:48:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-7704799d798so998847b3a.3 for ; Mon, 25 Aug 2025 03:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1756118918; x=1756723718; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jEziDS9/04StT2c/zujj4nhSMiCtbd9KSuWtdJJti08=; b=EhB08JrBnLCj7TwH5BXeM3kxgJ0yopSO1f4Mfz/SPc38sAfS5gMFkIyrqEoJFphupn PjyQ6YIQcYk+TD9vdfF1OeVs2iDaRW+q6E3ayZK/B3SOhU81fHXhgyEOINivup79qDu2 8Dr7ry1Z+G9aF8JJ4xcqZZ1rWK5fQ3kJOPIZnF0J7A92fV7opAL/Ol1vI64UqWVFCfhH 0EQBS2jP51h+BQ9eh6HlScYxtkptRAmP98zjbxf6grd0IHrx2IOoyMIoRydJevSoerQ2 j6yOHcjs42Bac+CefDMSV8a8Vt3QxCuXzEogbgaC3Cj12gr3oqrHkViy3DUgbnqZHBWy U7SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756118918; x=1756723718; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jEziDS9/04StT2c/zujj4nhSMiCtbd9KSuWtdJJti08=; b=usKuW6L8JQZP1oQHYXBm7rVwSbCRAHpkyADh0NUVZ2kWxa2JrFZSRdpOazqaQXLwA/ blYaRBnmKcMkbKXr5Jo80r94+OkkV8JpAiY1Y76SQwAeNyFYRFeyuA8ABQWcgMMuauVK qnkaMsFTqhWX+zjqcGhM1IkiHMZ3QeUWf6YY2/dFeruzfp76tKMYm37sBdt0vGMeFU9a V3W8StPUm3BGvRCNu0ANm5ytZkqEuLFWy7bwqWHyECh0n7QrFq9NgrcKEFrR4Wofe5Te Itlq2lnaUFLYQPkQafbSgAvcS7JXsJQXeiGv6KzhdkAIEQwZP3dZF5WV/LCZ697CDvDX 5sfQ== X-Forwarded-Encrypted: i=1; AJvYcCXPGvZheQsFw0JhPwokjrsLE7XXS5Dyvihx43R/tm2y6FCXqgYlq0GtoyufcLV1gmSWTjcZWPRP@freebsd.org X-Gm-Message-State: AOJu0YyICqMyT1kBealPeuPS/CLmGPv43K6bM7EIWyAumrZVggyDeo35 1T5Af+/O49I6TBd8OkM2QgyWuISuapMKzr/DUazSFSfxVNlC//xtAVW9OAqbuyjszkv29YO7tzX TchBNaDK/yaeQkeE6swVmdHh5poGn550yqivb1ppPgQ== X-Gm-Gg: ASbGncvY4SuBDhWHTmbzH/60xGG4lmCCSAbtlQ6gDCZL/zw9s8Yv0hdif9a04qfRXdX XfeR3x0JaknzQO/cpTMXXCAIaL7iEXSi1kvNhaKTYbPj0HfYc5Xw+jlNzfjcIFUo6phFlBbw1L+ 9dsAxXtEIO0ErVUVJ0TeOLUiKA8oxhn9GZ0MvWtjh3zCnlut6pepPCk7GL5n54kkIr9wlu1SN2J afdVFFDrzVkJB3qyam6BtVI0iLkDb3TxHGb2yg= X-Google-Smtp-Source: AGHT+IFyZnxACOBkXxf7Ga43DgdxD/5lU8Hw4h8vab8B8HDDWS/QbW9m+p7HHHrggPc4thVudb/LwHbV/5m5ncvRupc= X-Received: by 2002:a05:6a21:999f:b0:240:116b:cc41 with SMTP id adf61e73a8af0-24340b2757bmr16403676637.16.1756118918089; Mon, 25 Aug 2025 03:48:38 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <2r579os7-29n7-890r-9210-s3s1n4r0s4qo@fncre.vasb> <548137ff7d2289fa60a1cba14afa4957@Leidinger.net> In-Reply-To: <548137ff7d2289fa60a1cba14afa4957@Leidinger.net> From: Warner Losh Date: Mon, 25 Aug 2025 04:48:26 -0600 X-Gm-Features: Ac12FXzJ8aeBpw_EcEoTEGrhDWCy04013yPpb0WQzxdsAVMBBhBzTiN5EcUI4Cs Message-ID: Subject: Re: UPDATING stuff To: Alexander Leidinger Cc: Marcin Cieslak , Kyle Evans , Xin LI , Current , Gleb Smirnoff Content-Type: multipart/alternative; boundary="0000000000004be665063d2e4c13" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4c9SFm2jw8z45Qn --0000000000004be665063d2e4c13 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 25, 2025 at 3:13=E2=80=AFAM Alexander Leidinger wrote: > Am 2025-08-25 10:44, schrieb Marcin Cieslak: > > On Thu, 21 Aug 2025, Alexander Leidinger wrote: > > > >>>> COMPAT_FREEBSD14? (Recently [gs]etgroups were changed, with > >>>> compatibility syscalls moved to COMPAT_FREEBSD14). > >> > >> UPDATING only mentions VMM stuff for COMPAT_FREEBSD14. I give this a > >> try tomorrow. But would this also affect the zfs dataset stuff? > > > > This thread could have been a simple UPDATING update. I think this is > > the fourth > > time or so I have run into problems, because the changes were not > > explained. > > > > UPDATING entry on VMM got only there after I've spent 2 days+ > > troubleshooting > > my wifibox failures. > > > > When I read your message I was immediately thinking you might need > > "COMPAT_FREEBSD14", > > but, again, I couldn't find any obvious entry neither in the docs nor > > in > > the git log I was looking at. > > > > @glebus - maybe during the stabilization effort the changes done to the > > tree > > could be reviewed and documented? > > > > - where the FreeBSD_version got bumped and why > > This is normally documented in > https://docs.freebsd.org/en/books/porters-handbook/versions/ (intended > to be updated at the time when the FreeBSD_versions is increased), but I > can agree that the info there is a bit terse sometimes. > > > - ABI changes > > - .... > > > > For example it could be useful to be able to find the information "what > > does COMPAT_FREEBSD14 do exactly" in the UPDATING/release notes file. > > Otherwise I can't be sure if I need that option or "is my system fresh > > enough" > > to remove it from the kernel. > It provides the system call interface as of FreeBSD 14. As new system calls are added that replace old ones, they are moved to being conditional on COMPAT_FREEBSD14. You should never remove the COMPAT_FREEBSDX when you are on current X+1. It's a recipe for pain. FreeBSD 14 binaries still might not always work (there are companion issues with shared library bumps for our non-symbol-versioned libraries too: there you have to wait for new compat14 package and/or play libmap games since the major bump usually is compatible enough to run most old programs but not always and not perfectly... libmap is at best a stop-gap). > What do you think about this? > diff --git UPDATING UPDATING > index ddb2e7603b2a..e197940c6431 100644 > --- UPDATING > +++ UPDATING > @@ -73,6 +73,12 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 15.x IS SLOW: > If you only have FreeBSD-sendmail installed for applications > that > require libmilter, you can now remove it. > > +20250815: > + The [gs}etgroups(2)syscalls have changed. To maintain backwards > + compatibility with existing programs, you need COMPAT_FREEBSD14 > in > + your kernel config until all applications which use this are > + rebuild/reinstalled. > + > 20250815: > jemalloc 5.3.0 has been committed to the tree. > I'd make it stronger. We should proactively create a COMPAT_FREEBSD15 just after the branch and add it to GENERIC. You 100% of the time want this if you aren't updating every last binary on your system each and every time you update. We should add that to our checklist to do eary, rather than late, as needed. It shouldn't be buried in an obscure entry, but advice we always give for everybody, all the time. GENERIC has it in there, which is why most people won't see this issue. Warner --0000000000004be665063d2e4c13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 25,= 2025 at 3:13=E2=80=AFAM Alexander Leidinger <Alexander@leidinger.net> wrote:
Am 2025-08-25 10:44, schrieb Marcin= Cieslak:
> On Thu, 21 Aug 2025, Alexander Leidinger wrote:
>
>>>> COMPAT_FREEBSD14?=C2=A0 (Recently [gs]etgroups were change= d, with
>>>> compatibility syscalls moved to COMPAT_FREEBSD14).
>>
>> UPDATING only mentions VMM stuff for COMPAT_FREEBSD14. I give this= a
>> try tomorrow. But would this also affect the zfs dataset stuff? >
> This thread could have been a simple UPDATING update.=C2=A0 I think th= is is
> the fourth
> time or so I have run into problems, because the changes were not
> explained.
>
> UPDATING entry on VMM got only there after I've spent 2 days+
> troubleshooting
> my wifibox failures.
>
> When I read your message I was immediately thinking you might need > "COMPAT_FREEBSD14",
> but, again, I couldn't find any obvious entry neither in the docs = nor
> in
> the git log I was looking at.
>
> @glebus - maybe during the stabilization effort the changes done to th= e
> tree
> could be reviewed and documented?
>
>=C2=A0 - where the FreeBSD_version got bumped and why

This is normally documented in
https://docs.freebsd.org/en/books/porter= s-handbook/versions/ (intended
to be updated at the time when the FreeBSD_versions is increased), but I can agree that the info there is a bit terse sometimes.

>=C2=A0 - ABI changes
>=C2=A0 - ....
>
> For example it could be useful to be able to find the information &quo= t;what
> does COMPAT_FREEBSD14 do exactly" in the UPDATING/release notes f= ile.
> Otherwise I can't be sure if I need that option or "is my sys= tem fresh
> enough"
> to remove it from the kernel.

It p= rovides the system call interface as of FreeBSD 14. As new system calls are= added that replace old ones, they are moved to being conditional on COMPAT= _FREEBSD14. You should never remove the COMPAT_FREEBSDX when you are on cur= rent X+1. It's a recipe for pain. FreeBSD 14 binaries still might not a= lways work (there are companion issues with shared library bumps for our no= n-symbol-versioned libraries too: there you have to wait for new compat14 p= ackage and/or play libmap games since the major bump usually is compatible = enough to run most old programs but not always and not perfectly... libmap = is at best a stop-gap).
=C2=A0
What do you think about this?
diff --git UPDATING UPDATING
index ddb2e7603b2a..e197940c6431 100644
--- UPDATING
+++ UPDATING
@@ -73,6 +73,12 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 15.x IS SLOW:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If you only have FreeBSD-sendmail install= ed for applications
that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0require libmilter, you can now remove it.=

+20250815:
+=C2=A0 =C2=A0 =C2=A0 =C2=A0The [gs}etgroups(2)syscalls have changed. To ma= intain backwards
+=C2=A0 =C2=A0 =C2=A0 =C2=A0compatibility with existing programs, you need = COMPAT_FREEBSD14
in
+=C2=A0 =C2=A0 =C2=A0 =C2=A0your kernel config until all applications which= use this are
+=C2=A0 =C2=A0 =C2=A0 =C2=A0rebuild/reinstalled.
+
=C2=A0 20250815:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0jemalloc 5.3.0 has been committed to the = tree.

I'd make it stronger. We shou= ld proactively create a COMPAT_FREEBSD15 just after the branch and add it t= o GENERIC. You 100% of the time want this if you aren't updating every = last binary on your system each and every time you update. We should add th= at to our checklist to do eary, rather than late, as needed. It shouldn'= ;t be buried in an obscure entry, but advice we always give for everybody, = all the time. GENERIC has it in there, which is why most people won't s= ee this issue.

Warner
--0000000000004be665063d2e4c13-- From nobody Mon Aug 25 11:30:55 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9TBm13drz65dWS for ; Mon, 25 Aug 2025 11:31:12 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9TBk6Wknz4D9d; Mon, 25 Aug 2025 11:31:10 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=R863cXCq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of oleglelchuk@gmail.com designates 2a00:1450:4864:20::32c as permitted sender) smtp.mailfrom=oleglelchuk@gmail.com Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-45b627ea5f3so2397005e9.1; Mon, 25 Aug 2025 04:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756121468; x=1756726268; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/VsO2D93h6x4G5yCviFa4mV+9rnpAmNemmrLSVeRK44=; b=R863cXCqiNG28hyT7K35oHsn76kQdXyrf38UyegmnwaQgiQJBdUMh7b6sIPbtezafO zEelRCJAq5pyWOk7M+NfySBjTbX24mcCz/qhQqihz/i4Nd8SnBTikU+yFQk0liBCnofP uoNnzPqz9ic79zk49B4dERkQEzCxGGt6FOMzQwj+CXBCfxAEN49iijpnM0WBRbq+jL1t zNEELE4gZIPPazwsrpWsBg/wXFU5puqZLIxIUUrkZG8v/5r7E/hAzdvu/1SaBNNcNZri h8i2z6nW+6R8qq/NZb/S8vnPn1uF+PB60WeiPc5G/r1d2dBCCoJmXFYyR6sZToBfvGLc rxRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756121468; x=1756726268; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/VsO2D93h6x4G5yCviFa4mV+9rnpAmNemmrLSVeRK44=; b=WXPZcL0hboMFN9CS4gF1/vgIgtg/M7VU442E/4QHyflZpsVRcN7T1RyPunvI51BRy4 2eeSKslgkhv36MO6yKdQS6uO9IwlBof3umVKYtfhah84BiCd0WX6rYgnqpDi7MjFvW1e sV7umvM5kOYt5Hz3d0xVUoXoQ2bCtm8o1Yt4/IDF+OqZtAwadsNM+ORGwL4puQdcK//E M5tOgs7nJibLE/JZ3hmaTjlhTROzhNVzNzi/oehINifUBGBb+20ygBHHB9janbeVcES1 qlX+gQ/HruYzvaWqadndXuAQgyiBx4VJu0du1IP6aDZto4TiEjgKYwzEXD8af5qUPGYD v7ag== X-Forwarded-Encrypted: i=1; AJvYcCUZ/slAiLV2eoliN7IGTVGDSUGAioSpnCMp+thxcyvtN+Zuflj061csSGwtXSGWMpG0SqZmK86A@freebsd.org X-Gm-Message-State: AOJu0YzRqLiUolsoXRHdnUbntAIN24OdwenemC3wFyRjThwcHhQDxE/e Brc7DnVqLtviUhjoMTZssf8qGdgfddcdOmTRWOHeqXyyE0ydUN/6LU0bDsB3wPFTUpcsjGQQIzX zPwn28M6fVTyKC4Iy0OBMQZOmt4hIWXc= X-Gm-Gg: ASbGncsoNOjsx5G5EiogXvNtnqCWkpamD28BMsJTkfOOa5rB4nSjEIqkcnGAXd8MezU y+Cs6fQDC8oFHHn2SdtcKD36RzL/3S7iWFC8+7nH2mKJjslcIJuLQWiu4zb77paTctfYjZtibuh HECUJrdF4LRQWEg7ASdhLcdCTNICcQT/nHGlfCEd6Hoc0ZeTGq4gD0Ry8EqvoGlIURPc35QqYJA RFuRuI= X-Google-Smtp-Source: AGHT+IHLCeVyFPpuoG7l6i5lXBRrdFGpfJt2w2pUaxzQamPshpIBSKaLtUC/dp94ZUW6c2lsRsFbVGxroBLvun2GPgc= X-Received: by 2002:a05:600c:c87:b0:456:f1e:205c with SMTP id 5b1f17b1804b1-45b5179f338mr97362955e9.4.1756121467808; Mon, 25 Aug 2025 04:31:07 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Oleg Lelchuk Date: Mon, 25 Aug 2025 07:30:55 -0400 X-Gm-Features: Ac12FXxUqtghahZidy7gTOYF4HbQBGCPqLdE-HPpRLLe4eau-DcggtxWu4GmsYU Message-ID: Subject: Re: CFT: evdev-awared moused To: Jordan Gordeev Cc: Vladimir Kondratyev , current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000456e73063d2ee435" X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32c:from]; DKIM_TRACE(0.00)[gmail.com:+] X-Rspamd-Queue-Id: 4c9TBk6Wknz4D9d --000000000000456e73063d2ee435 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I started using Vladimir's evdev-aware moused a long time ago, and I am a big fan of it. I just realized that hms had become the default driver in FreeBSD 15 and the ums driver would soon be a thing of the past. Yep, now we just have to remove the old moused program from the base system and replace it with Vladimir's moused. On Sat, Aug 2, 2025 at 2:14=E2=80=AFPM Jordan Gordeev wrote: > With this new moused there is apparently some fundamental change happenin= g. > > I'd like to see a document describing the overall design of the new > infrastructure for handling pointer events. Ideally, that document would > contain a comparison with the older way of doing things. > > I'm also curious why the existing moused had to be heavily modified, with > loss of functionality, instead of introducing a new daemon that can work > together with the existing moused. > > Best regards, > Jordan Gordeev > > --000000000000456e73063d2ee435 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I started using Vladimir's evdev-aware moused a long t= ime ago, and I am a big fan of it. I just realized that hms had become the = default driver in FreeBSD 15 and the ums driver would soon be a thing of th= e past. Yep, now we just have to remove the old moused program from the bas= e system and replace it with Vladimir's moused.

On Sat, Aug 2, 2025 at 2= :14=E2=80=AFPM Jordan Gordeev <jgopensource@proton.me> wrote:
With this new moused there is appa= rently some fundamental change happening.

I'd like to see a document describing the overall design of the new inf= rastructure for handling pointer events. Ideally, that document would conta= in a comparison with the older way of doing things.

I'm also curious why the existing moused had to be heavily modified, wi= th loss of functionality, instead of introducing a new daemon that can work= together with the existing moused.

Best regards,
Jordan Gordeev

--000000000000456e73063d2ee435-- From nobody Mon Aug 25 11:39:08 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9TN41Np8z65fYY for ; Mon, 25 Aug 2025 11:39:16 +0000 (UTC) (envelope-from cyric@mm.st) Received: from fhigh-b5-smtp.messagingengine.com (fhigh-b5-smtp.messagingengine.com [202.12.124.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9TN34jfpz4FLT for ; Mon, 25 Aug 2025 11:39:15 +0000 (UTC) (envelope-from cyric@mm.st) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mm.st header.s=fm3 header.b=Ng0TO3Lr; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="LeWec/my"; dmarc=pass (policy=none) header.from=mm.st; spf=pass (mx1.freebsd.org: domain of cyric@mm.st designates 202.12.124.156 as permitted sender) smtp.mailfrom=cyric@mm.st Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfhigh.stl.internal (Postfix) with ESMTP id 52C817A013F for ; Mon, 25 Aug 2025 07:39:15 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Mon, 25 Aug 2025 07:39:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mm.st; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1756121955; x=1756208355; bh=ctYaAThofT2wPADcrhWIi5s0G79g4QZCCuuxK0LEfMc=; b= Ng0TO3Lr9pru67NWFUMLD9KwnkX/7t22G/DHwxSd25A+budi0svm2TkHkieVcAEv TN0NXuSqpgfjcyuUprcAv/BLoT9WA3wF2jOM/Q2ED8VNXKLsMrSZOh0q2EOJTnnH zcht4xN9H2W/FW3HT31MYU/9I7ok35dY8qL09UPAQryNFyzwp3oNJjCCPnMHlrxh MPeodq3hkIKuXIKjdn2EtO43kPsOQQM+P0gXqphKz1Y8+NlSlDNj0G+Ahyrt1DYl eHjIE5qXPLIDXBfXKvbiccZ58X0+x7Ef69MYS6dpzFLdIKcKh2WYp+3cKlRlmBPm BBxqa38DCIkIJKRyg9CLKg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1756121955; x=1756208355; bh=c tYaAThofT2wPADcrhWIi5s0G79g4QZCCuuxK0LEfMc=; b=LeWec/myySIZCx4pk mAvoANsM+w2grBOleCC0miEHrpDrIWZ42WwXQoJw/VfouSQrYAxK8M7J6uw9PF2p K1lgynrAj2WS2VtqCKcIkNfxR0Sxsqerbk3VTGVa71h9KufFHR6yBTvbgSCkJY4Y IFIKa+8uu+VwKhhreWTkrVJeQSJDyXPKmlexbHvNIZsb2rk41zRa6zxJMfZUvA72 +I2CaVE0jH/H2FDwucofPnLA4T4RA6W/72jJKAFLj8qsH7PAEUCaYaIrJ+cnN+F3 cGf6IvntqpY72bxIf/hIi4m/fF4HgvUzwcdiAnX5JkFXCSJ2i0GMgaEouVq4CQdF N0W/w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddujedvvdelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtkeertd dtvdejnecuhfhrohhmpegthihrihgtsehmmhdrshhtnecuggftrfgrthhtvghrnhepgeff jeffudfffeeuleefkedtgfekjeetledtledvudethfeugeefieethfdutedunecuffhomh grihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomheptgihrhhitgesmhhmrdhsthdpnhgspghrtghpthhtohepud dpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghn thesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: icc3648d4:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 25 Aug 2025 07:39:14 -0400 (EDT) Message-ID: <1684d15d-c0eb-4206-832c-f59c582a6d67@mm.st> Date: Mon, 25 Aug 2025 18:39:08 +0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: UPDATING stuff To: freebsd-current@freebsd.org References: <2r579os7-29n7-890r-9210-s3s1n4r0s4qo@fncre.vasb> <548137ff7d2289fa60a1cba14afa4957@Leidinger.net> Content-Language: en-US From: cyric@mm.st In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[mm.st,none]; R_DKIM_ALLOW(-0.20)[mm.st:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.156:from]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_FROM(0.00)[mm.st]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[mm.st]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[mm.st:+,messagingengine.com:+]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:151847, ipnet:202.12.124.0/24, country:AU]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_NO_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4c9TN34jfpz4FLT Warner Losh wrote: > > > On Mon, Aug 25, 2025 at 3:13 AM Alexander Leidinger > > wrote: > > Am 2025-08-25 10:44, schrieb Marcin Cieslak: > > On Thu, 21 Aug 2025, Alexander Leidinger wrote: > > > >>>> COMPAT_FREEBSD14?  (Recently [gs]etgroups were changed, with > >>>> compatibility syscalls moved to COMPAT_FREEBSD14). > >> > >> UPDATING only mentions VMM stuff for COMPAT_FREEBSD14. I give this a > >> try tomorrow. But would this also affect the zfs dataset stuff? > > > > This thread could have been a simple UPDATING update.  I think > this is > > the fourth > > time or so I have run into problems, because the changes were not > > explained. > > > > UPDATING entry on VMM got only there after I've spent 2 days+ > > troubleshooting > > my wifibox failures. > > > > When I read your message I was immediately thinking you might need > > "COMPAT_FREEBSD14", > > but, again, I couldn't find any obvious entry neither in the docs nor > > in > > the git log I was looking at. > > > > @glebus - maybe during the stabilization effort the changes done > to the > > tree > > could be reviewed and documented? > > > >  - where the FreeBSD_version got bumped and why > > This is normally documented in > https://docs.freebsd.org/en/books/porters-handbook/versions/ > > (intended > to be updated at the time when the FreeBSD_versions is increased), > but I > can agree that the info there is a bit terse sometimes. > > >  - ABI changes > >  - .... > > > > For example it could be useful to be able to find the information > "what > > does COMPAT_FREEBSD14 do exactly" in the UPDATING/release notes file. > > Otherwise I can't be sure if I need that option or "is my system > fresh > > enough" > > to remove it from the kernel. > > > It provides the system call interface as of FreeBSD 14. As new system > calls are added that replace old ones, they are moved to being > conditional on COMPAT_FREEBSD14. You should never remove the > COMPAT_FREEBSDX when you are on current X+1. It's a recipe for pain. > FreeBSD 14 binaries still might not always work (there are companion > issues with shared library bumps for our non-symbol-versioned libraries > too: there you have to wait for new compat14 package and/or play libmap > games since the major bump usually is compatible enough to run most old > programs but not always and not perfectly... libmap is at best a stop-gap). >   > > What do you think about this? > diff --git UPDATING UPDATING > index ddb2e7603b2a..e197940c6431 100644 > --- UPDATING > +++ UPDATING > @@ -73,6 +73,12 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 15.x IS SLOW: >          If you only have FreeBSD-sendmail installed for applications > that >          require libmilter, you can now remove it. > > +20250815: > +       The [gs}etgroups(2)syscalls have changed. To maintain backwards > +       compatibility with existing programs, you need COMPAT_FREEBSD14 > in > +       your kernel config until all applications which use this are > +       rebuild/reinstalled. > + >   20250815: >          jemalloc 5.3.0 has been committed to the tree. > > > I'd make it stronger. We should proactively create a COMPAT_FREEBSD15 > just after the branch and add it to GENERIC. You 100% of the time want > this if you aren't updating every last binary on your system each and > every time you update. We should add that to our checklist to do eary, > rather than late, as needed. It shouldn't be buried in an obscure entry, > but advice we always give for everybody, all the time. GENERIC has it in > there, which is why most people won't see this issue. I wonder why it's not done the other way around, having the options to *exclude* the compat bits so there are no surprises for users with custom kernel configs. From nobody Mon Aug 25 11:53:54 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9Tj84Wyzz65gXn for ; Mon, 25 Aug 2025 11:54:04 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (prime256v1) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E6" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9Tj81dDXz4JpQ for ; Mon, 25 Aug 2025 11:54:03 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; none Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id D21A8A64805; Mon, 25 Aug 2025 11:53:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zabbadoz.net; s=20240622; t=1756122828; bh=Leytm5LlxwdQ8VBg3pasSLL44lCDIzVLD5fU+2QHQ8c=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=HZmrNr7ee0r9dxlvBNS2p1onhch4gLpXmqR4eloxaf1L9a4XRwSpBLTTTQqxaMiZ/ cdhvt5RPsFZgiH/rIKtvM50VEO02vqjMZbyIYTjXz8j+qG2yoZgV6NSrElvWnAL8OA acNrBzs226P3aV46ootgzLgraFpH2iJksJ6ReDSvR0KIw+6NMobPVI6pI9BJEvaLiS mRjmR/4lUR9aRNs6Jc4atzBjj3oJRCHKBtc6mTmi9kFaia7CvY963mAZxH2uwq/JCU jUUGSwwmwVVqxPSh7Hkw2V0W5k8hJdNqJIu6GYTXyfV35MSRArE9uWS5ASnNbW57Vs 3set+PgP2sIEd8+9vr89nkpHJExX16t3B4Afp645smPALwtSfnnWIssUCB2E36936w xaVdug+pU3czrPIq/0cybEdWLsTgSuXJ0fOAsq8VcDde+mfHDOuhT9wca9XjOxD3qg AlnwcKrfPBUOlC2D4pFQmS9/MAgY2Ei4jLiEkh7rS7f+csE3udsMFar8s8YfCLsEQn 1uvRNEKvqAUHJ8MbVI9cQdzBEM5LmdiNliMaiWL8fPwNuarEIFveRLlEVilwpppyDl 33pSlJXUtmhEeQliRyJ4r3RQba/XTlHHkwSPzS/1AfaCUZxz9rBolTjRyIynX9hSw3 CRaWGZwkbSdjxzhpxtZ5I18A= Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A0A7C2D029E3; Mon, 25 Aug 2025 11:53:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id ZpYfsyohoAHg; Mon, 25 Aug 2025 11:53:54 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:a66b:b6ff:fe40:39a9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 9EED82D029D8; Mon, 25 Aug 2025 11:53:54 +0000 (UTC) Date: Mon, 25 Aug 2025 11:53:54 +0000 (UTC) From: "Bjoern A. Zeeb" To: Kevin Oberman cc: current Subject: Re: Reporting lock order reversals on current In-Reply-To: Message-ID: <5r5618p1-n9p2-s6o9-8296-5qno9s441nos@yvfgf.mnoonqbm.arg> References: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3320, ipnet:2003::/19, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4c9Tj81dDXz4JpQ On Sun, 24 Aug 2025, Kevin Oberman wrote: > Is there still a place to check on and report lock order reversals on main? > I get a couple of them regularly. One looks like a VFS issue and the > other one may be related, though it is tied to autofs, which I use rather > frequently. Appropriate mailing list or open a PR. The lock order reversal list I once maintained has long been out of date (decade?). The netowrking ones I kept seeing for months and reported once or twice got ignored on the mailing lists... I hope you'll be more blessed. /bz -- Bjoern A. Zeeb r15:7 From nobody Mon Aug 25 12:09:29 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9V390BJpz65hch for ; Mon, 25 Aug 2025 12:09:41 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9V3836Rjz4Mqk for ; Mon, 25 Aug 2025 12:09:40 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 57PC9TLa074162; Mon, 25 Aug 2025 21:09:30 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1756123770; bh=C+hvbCgzRKrs7GtpjYmtZ7J/SyLo2IoImzVrwZMUwTg=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=C9QYgFE9SHRo7By4s6ToPWV4bCefGAicV58zE18s5CesdsqAkQrSFIrexnb1WLZ5f 6+8EgEsz89AsnDjRKUGNhshsloO0VbzBV5KEcGrcyWRPR1bO9ZhY/MdWHH0kcEyn0e hZL9vOt9b01Qg5MwpUponyeVzAYqodtKmJ2XglTw= Date: Mon, 25 Aug 2025 21:09:29 +0900 From: Tomoaki AOKI To: cyric@mm.st Cc: freebsd-current@freebsd.org Subject: Re: UPDATING stuff Message-Id: <20250825210929.b12e4cca5f799935c1ae3e00@dec.sakura.ne.jp> In-Reply-To: <1684d15d-c0eb-4206-832c-f59c582a6d67@mm.st> References: <2r579os7-29n7-890r-9210-s3s1n4r0s4qo@fncre.vasb> <548137ff7d2289fa60a1cba14afa4957@Leidinger.net> <1684d15d-c0eb-4206-832c-f59c582a6d67@mm.st> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.3) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4c9V3836Rjz4Mqk On Mon, 25 Aug 2025 18:39:08 +0700 cyric@mm.st wrote: > Warner Losh wrote: > > > > > > On Mon, Aug 25, 2025 at 3:13 AM Alexander Leidinger > > > wrote: > > > > Am 2025-08-25 10:44, schrieb Marcin Cieslak: > > > On Thu, 21 Aug 2025, Alexander Leidinger wrote: > > > > > >>>> COMPAT_FREEBSD14?  (Recently [gs]etgroups were changed, with > > >>>> compatibility syscalls moved to COMPAT_FREEBSD14). > > >> > > >> UPDATING only mentions VMM stuff for COMPAT_FREEBSD14. I give this a > > >> try tomorrow. But would this also affect the zfs dataset stuff? > > > > > > This thread could have been a simple UPDATING update.  I think > > this is > > > the fourth > > > time or so I have run into problems, because the changes were not > > > explained. > > > > > > UPDATING entry on VMM got only there after I've spent 2 days+ > > > troubleshooting > > > my wifibox failures. > > > > > > When I read your message I was immediately thinking you might need > > > "COMPAT_FREEBSD14", > > > but, again, I couldn't find any obvious entry neither in the docs nor > > > in > > > the git log I was looking at. > > > > > > @glebus - maybe during the stabilization effort the changes done > > to the > > > tree > > > could be reviewed and documented? > > > > > >  - where the FreeBSD_version got bumped and why > > > > This is normally documented in > > https://docs.freebsd.org/en/books/porters-handbook/versions/ > > > > (intended > > to be updated at the time when the FreeBSD_versions is increased), > > but I > > can agree that the info there is a bit terse sometimes. > > > > >  - ABI changes > > >  - .... > > > > > > For example it could be useful to be able to find the information > > "what > > > does COMPAT_FREEBSD14 do exactly" in the UPDATING/release notes file. > > > Otherwise I can't be sure if I need that option or "is my system > > fresh > > > enough" > > > to remove it from the kernel. > > > > > > It provides the system call interface as of FreeBSD 14. As new system > > calls are added that replace old ones, they are moved to being > > conditional on COMPAT_FREEBSD14. You should never remove the > > COMPAT_FREEBSDX when you are on current X+1. It's a recipe for pain. > > FreeBSD 14 binaries still might not always work (there are companion > > issues with shared library bumps for our non-symbol-versioned libraries > > too: there you have to wait for new compat14 package and/or play libmap > > games since the major bump usually is compatible enough to run most old > > programs but not always and not perfectly... libmap is at best a stop-gap). > >   > > > > What do you think about this? > > diff --git UPDATING UPDATING > > index ddb2e7603b2a..e197940c6431 100644 > > --- UPDATING > > +++ UPDATING > > @@ -73,6 +73,12 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 15.x IS SLOW: > >          If you only have FreeBSD-sendmail installed for applications > > that > >          require libmilter, you can now remove it. > > > > +20250815: > > +       The [gs}etgroups(2)syscalls have changed. To maintain backwards > > +       compatibility with existing programs, you need COMPAT_FREEBSD14 > > in > > +       your kernel config until all applications which use this are > > +       rebuild/reinstalled. > > + > >   20250815: > >          jemalloc 5.3.0 has been committed to the tree. > > > > > > I'd make it stronger. We should proactively create a COMPAT_FREEBSD15 > > just after the branch and add it to GENERIC. You 100% of the time want > > this if you aren't updating every last binary on your system each and > > every time you update. We should add that to our checklist to do eary, > > rather than late, as needed. It shouldn't be buried in an obscure entry, > > but advice we always give for everybody, all the time. GENERIC has it in > > there, which is why most people won't see this issue. > I wonder why it's not done the other way around, having the options to > *exclude* the compat bits so there are no surprises for users with > custom kernel configs. Creating kernel config from scratch is discouraged now. Why not including such as GENERIC, GENERIC-NODEBUG, MINIMAL and MINIMAL-NODEBUG (there are more candidates exist) and add or remove options / devices by options / nooptions and device / nodevice? For example, GENERIC-NODEBUG on main simply includes GENERIC, disables unneeded options via including std.nodebug and name itself as GENERIC-NODEBUG. https://cgit.freebsd.org/src/tree/sys/amd64/conf/GENERIC-NODEBUG https://cgit.freebsd.org/src/tree/sys/conf/std.nodebug Now you can create, for example, a config file that includes GENERIC, name it by ident line and "nooptions COMPAT_FREEBSD14" line to drop FreeBSD 14 compatibility support. ===== Example ===== include GENERIC ident NO14SUPPORT nooptions COMPAT_FREEBSD14 ===== End example ===== Not 100% sure, but IIRC, ancient kernel configs which needed separate config process on building kernel didn't have include functionality, thus, needed to create full config. But it's not needed now. -- Tomoaki AOKI From nobody Mon Aug 25 12:53:22 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9W1d3mDgz65l77 for ; Mon, 25 Aug 2025 12:53:25 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9W1d2DBtz3CNs; Mon, 25 Aug 2025 12:53:25 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756126405; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NmLK1Tv0aF20O0XN6ZNqSAZQdOgP/XuFvhFk7cr95zw=; b=JmaSNUsdOQSFcT0fxsjmJgy/WwW6Ofy9yt72rV1WXryFCTvx/Kr6mK0k6UoE7llJITowct v5Xf+x5h9bnNi1n8aYT+yNe4qrbTq/nz6iJhw1E+fMoYVITOfemHqjPFgxN5fRUQF4u/Oj byQIzeW8ZjX0nB31gz0dVqV6DaLLZNn2SkbzmWvx5MJwlhJTDHCSVXL0G5RK4i66zlbEVj r9WmW+nojH5Wyfy/GTuS5qK41sx75Zkfz2ZlmW0F0pD2YLPWz1T6wPVjxpy5LHVJ3MMsRY LnfA4mSot0GxtRGxGf5/Cd9CMti8ROOvf4/xpU2vbC+JodVye/gsoMLTm2mziQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756126405; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NmLK1Tv0aF20O0XN6ZNqSAZQdOgP/XuFvhFk7cr95zw=; b=jWvJyuonDSYS1sFjZYXIF8y4g7bMEVnWfk20mG/2ZCGuelCnAPLYqP5lW50m48vfu/weWE QViIJs9zc1qmJTE47op18vYx4xZA59dnoaGIlXzioCW+kRzLREtVNjgJeNg/vjzRM25Tnh XlhhDZoOYRB3BUo2wmVBwA1AvpXuNa6ltD3xE0j5jMRPL8Q8M9oMLg0G7b5Hhgg2i97YDr 44O0kwVAigQZz+xE45q2+lnOAFGY7zn+wFe6BG3Da6dapq9oiEu3S3o55xkN+QsNSfRj1g DJhrccp8Q4k32FhurGdg5ucc4XZb/z+kF10BsFJX4vi8M7pkgSvm0xb/iCTY4g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756126405; a=rsa-sha256; cv=none; b=oOTpaWXYlDiXFAJTY0V4179aw5wqhKwLzhVmWB0sPRElqCVbfh1qTjysu1jxTauAFDPGi/ qRG6Ow0gKuicHRzAQyI4J5jgRc9uWZ0AoYUXR6UiPAE6DZ19Vgxcllm4ASYU6SAkMx89+U n0N4IsHc9OBg+GizLSAKzdVBV3eh3f1cuy6wp7C4xQqk+ofJAM3Ku3duBSR2MGiGqQiEVJ HL/qsvaNLPLxcM4it+dHpTs1TRiU+hrzvH80SKVWDGlQNqb8gTW9HT0Cguj3pt6wbwZeXJ mO5J2pp3yfyNl9S+heYjbKcxLdFrcXGHsPlFX2Q2JVuj0UijLlSB++IPUwGyVw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4c9W1c6FVCz1RXx; Mon, 25 Aug 2025 12:53:24 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Mon, 25 Aug 2025 05:53:22 -0700 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: August 2025 stabilization week Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi, On Mon, Aug 25, 2025 at 01:00:07AM -0700, Gleb Smirnoff wrote: T> This is an automated email to inform you that the August 2025 stabilization week T> started with FreeBSD/main at main-n279838-6c45a5dad0a0, which was tagged as T> main-stabweek-2025-Aug. This stabilization cycle is expected to be more bumpy than usually. 1) We got major upgrade - OpenSSL 3.5.1. One known issue is that the legacy provider is broken. 2) The default Kerberos now is MIT. We have already checked that a Kerberized NFS client can migrate from Heimdal to MIT. We did not check Kerberized NFS server, but should be fine. There is no yet an official way to migrate kdc from Heimdal to MIT. So, if you are upgrading a machine that is kdc, you need WITHOUT_MITKRB5="yes" in your src.conf. 3) The official pkg repo is now almost empty, see email from Colin [1]. So, do not rush with 'make delete-old-libs', unless you are ready to build a lot of packages yourself. 4) The unfortunate coincidence with 3) is ABI breakage in the setgroups(2)/getgroups(2) syscalls compared to the July stabilization point. Some packages would dump core. These packages need to be rebuilt. 5) At Netflix our A/B testing capacities are overloaded, and we may not be able to start testing immediately today. Anyway, all this challenges are not a reason to delay or skip the stabilization week. The purpose of the week is to get CURRENT in a good shape, so let's dive in and focus on fixing problems. This week is also more important than usually, since we are approaching 15.0-RELEASE. [1] https://lists.freebsd.org/archives/freebsd-current/2025-August/008458.html -- Gleb Smirnoff From nobody Mon Aug 25 13:28:34 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9WpF1kTRz65nVk for ; Mon, 25 Aug 2025 13:28:37 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9WpD5XkKz3HKj; Mon, 25 Aug 2025 13:28:36 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756128516; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3MxZgXVe7vAlvsYvPYXY7RVijWoOH/OZNOVsf1p7iu4=; b=wl7UFyW10vQJyMmBNrIlNOGg7+tBuIFrhKJm1CuHNK9IGcN1QPLj37EP3azBHbo36DcEM/ yU1s3jiTumLYptyz/PZBnk0INQ4nSdzlPe042BjzIDwY6Lac83aB86x/I5K9ySPX7eDzK2 i8JHQlSvAJWiSNTsZca38YLVENvVbK8JJR0kUVkbBSL3PHs7TzT3oKwiz1TW4zdLY7PhzK RnoVQoAKo81cgUDTFAal9FURRmHuRotvjlQpUI0H1we9wzrqJiYsgNL0SMoHAHJzXLlXpt lTdUTcwPmjX10Y9ExYYHOljVjLkyzZK++lR8OKy4N1oKwY19nOH2FKAEZGlrlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756128516; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3MxZgXVe7vAlvsYvPYXY7RVijWoOH/OZNOVsf1p7iu4=; b=oTXYHt0H9f1pvIg5KiiWOvuFVWAvhYvCewBu0dzb9nPmMubGkA7OHgdahfMVA13PUxurwg 0cAOnpcXYsNnig/CQ8t6+Ef1prJKrQHkW/ChaRAogaqcEILFDArH+c5G/a+C2j1jWGnJRK aHMVRSIkfy0M8EemYwOe1ND8qAPPNqDPiOQJtId4d9urRe8xbSUd+qMWOfDnpZBPZacOxY YV5PklF7m9aCmsxHAayo47YkM9KxttkxfqLUmVcSA7cTovsCIpP/W4Gidvov2UHzdRRorV pWs6nGeO2yMcnZNhFZlDQ4e4PKksBoqopIFBryre5RX5fR/+E4wNpTmpDS/19w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756128516; a=rsa-sha256; cv=none; b=NcBgDztRc9eQjk9IjURK6hOvMDsdMvyPJpyoo85hHrLz70JpM0nS/SIo8j1UtqCLu1vppS OlRzr4jBJw5LAag9ZbLw1i5rPHp7FY2jWrUVfyVPq4JsXwq/sbyS3j5jRmy5FYQyNr0/iY X0ZtaGyaXCoK6SmhWhPGid89j5cy4ZbLIzIHKSxbDgDQpxAjB0MPyEw/GRE/3YIMgitVyv KGqbaoNSLLHu+byUkfxpe7ogeXk5akU9z2+0iAF4J6KNPRookgb22gJ0y3yGoXYg13/rDS bJ8EBQzId+qtIjdpcYvh3KJZP5RtddeHf8rSq4mQjdlyYfvanjbHm9RYaSlNIg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4c9WpD0wwnz1Rlk; Mon, 25 Aug 2025 13:28:36 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: Date: Mon, 25 Aug 2025 08:28:34 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: UPDATING stuff To: Warner Losh , Alexander Leidinger Cc: Marcin Cieslak , Xin LI , Current , Gleb Smirnoff References: <2r579os7-29n7-890r-9210-s3s1n4r0s4qo@fncre.vasb> <548137ff7d2289fa60a1cba14afa4957@Leidinger.net> Content-Language: en-US From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/25/25 05:48, Warner Losh wrote: > > > On Mon, Aug 25, 2025 at 3:13 AM Alexander Leidinger > wrote: > > Am 2025-08-25 10:44, schrieb Marcin Cieslak: > > On Thu, 21 Aug 2025, Alexander Leidinger wrote: > > > >>>> COMPAT_FREEBSD14?  (Recently [gs]etgroups were changed, with > >>>> compatibility syscalls moved to COMPAT_FREEBSD14). > >> > >> UPDATING only mentions VMM stuff for COMPAT_FREEBSD14. I give this a > >> try tomorrow. But would this also affect the zfs dataset stuff? > > > > This thread could have been a simple UPDATING update.  I think this is > > the fourth > > time or so I have run into problems, because the changes were not > > explained. > > > > UPDATING entry on VMM got only there after I've spent 2 days+ > > troubleshooting > > my wifibox failures. > > > > When I read your message I was immediately thinking you might need > > "COMPAT_FREEBSD14", > > but, again, I couldn't find any obvious entry neither in the docs nor > > in > > the git log I was looking at. > > > > @glebus - maybe during the stabilization effort the changes done to the > > tree > > could be reviewed and documented? > > > >  - where the FreeBSD_version got bumped and why > > This is normally documented in > https://docs.freebsd.org/en/books/porters-handbook/versions/ (intended > to be updated at the time when the FreeBSD_versions is increased), but I > can agree that the info there is a bit terse sometimes. > > >  - ABI changes > >  - .... > > > > For example it could be useful to be able to find the information "what > > does COMPAT_FREEBSD14 do exactly" in the UPDATING/release notes file. > > Otherwise I can't be sure if I need that option or "is my system fresh > > enough" > > to remove it from the kernel. > > > It provides the system call interface as of FreeBSD 14. As new system calls are added that replace old ones, they are moved to being conditional on COMPAT_FREEBSD14. You should never remove the COMPAT_FREEBSDX when you are on current X+1. It's a recipe for pain. FreeBSD 14 binaries still might not always work (there are companion issues with shared library bumps for our non-symbol-versioned libraries too: there you have to wait for new compat14 package and/or play libmap games since the major bump usually is compatible enough to run most old programs but not always and not perfectly... libmap is at best a stop-gap). > > What do you think about this? > diff --git UPDATING UPDATING > index ddb2e7603b2a..e197940c6431 100644 > --- UPDATING > +++ UPDATING > @@ -73,6 +73,12 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 15.x IS SLOW: >          If you only have FreeBSD-sendmail installed for applications > that >          require libmilter, you can now remove it. > > +20250815: > +       The [gs}etgroups(2)syscalls have changed. To maintain backwards > +       compatibility with existing programs, you need COMPAT_FREEBSD14 > in > +       your kernel config until all applications which use this are > +       rebuild/reinstalled. > + >   20250815: >          jemalloc 5.3.0 has been committed to the tree. > > > I'd make it stronger. We should proactively create a COMPAT_FREEBSD15 just after the branch and add it to GENERIC. You 100% of the time want this if you aren't updating every last binary on your system each and every time you update. We should add that to our checklist to do eary, rather than late, as needed. It shouldn't be buried in an obscure entry, but advice we always give for everybody, all the time. GENERIC has it in there, which is why most people won't see this issue. > > Warner +1; I don't think it makes sense to have to document every single transitional period for things like the recent getgroups/setgroups and vmm changes. The simple fact of living on -CURRENT is that you either need to more strictly control your image update process and package builders, or you need COMPAT_FREEBSD(X - 1) until it approaches the first release on the new branch. If it was a long-term dependency on a COMPAT option for a feature that we're keeping then that clearly should be documented (though should likely be reconsidered), but for transient conditions that only last until your galaxy has been rebuilt- those kinds of activities are going to keep happening, and it's 100% better to condition users to expect that for living on a development branch rather than trying to enumerate all of the scenarios where they might need it every time. Thanks, Kyle Evans From nobody Mon Aug 25 14:15:31 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9XrX2V8dz65qkw for ; Mon, 25 Aug 2025 14:15:40 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9XrX0ZzNz3PRv; Mon, 25 Aug 2025 14:15:40 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756131340; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=52oyZcvB2OX1BQ2bB4HxA4As9A5lWYpXFf+9sYxkmKw=; b=ObsGutphoSmwkWhqar3GtfdDiYv5eJLrwAU5cuzCYjJSsVQuOR3hwrP60QHJ2tH31oe4xm LXjBc78ezIM3L6t8tfVrMNttHpTfClljTYoK+REZR1QdRXWs4FXdJCDGRrMZnVZ/jO9bR2 4jEZz3sjdL/uYBLKgrdCCHpkUs32iqsmoKRqqeScXhUZOvvtfoSJ1wVpYtS4JbYhUtAqqK VJN1QsOA+Y7RMhoWi0htR+iGyJZuomO9fLK9SIK7OSJ1e4bFpR/PyZmAGVHKmPSgm3JUkX kk/8V9Dy/xORPfHkYzc0TsjDYcibi0D9SLRc403G8zUqaF3G8VZC52xdT+rEHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756131340; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=52oyZcvB2OX1BQ2bB4HxA4As9A5lWYpXFf+9sYxkmKw=; b=dNwqxFEdWweYra8DpP9Ql1QaHZeX8xMi55IYsnVxX96ctXCiN+QLIb9HoufngK8CDuEOxo he0UUd43t9woxjp2mJJ+glieQwKZE66sgr9m3dM4J4cfNd7I09rxRu++B6i60xYRZgLJqZ 5ItQRu7WwP2UwEh9EheaCo6fSKlrUjPT6AgYoVKV7mGyQ47GpT4WwPb+0mEJemNMuQa86S wiiktWWAnvEvAW+uTgYkbs++brLKS3pR0IDk9KAkqbL9eegrkvnfl0jx6YwTQXnWYNYurr oBmBmJNlJP6zGw0FYMDlnWPNjDZeoaTbABXoMbk513oYtH7qUrTVse9gVCpw6g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756131340; a=rsa-sha256; cv=none; b=CmbacML8sQgTCuxr5EV153GtYD19fXBcD7dC+lNzhlV4tnJkxVuayokmMIdLXIHkA4nTyc nfq/eQsFWGXosVCeVVlB6QASb0wpShgHU4YItfuxCOCqlZ7QNH/QXvwDg4umAC5Q2PUzCh n3ugf33AFdAd4zQAG1OhhYdvcoD7oGtNwbtMdSdwRUMjVxev6W4p1H7R1PH5/5jiNxqw0R rlX5sUTZh85paKuKZE2MXK0+uPJGvCuZrXoJt03S0dQNF6sAg8o7wxP1L/0v3wscR0ePEu P0fbV6WNBxvc7IQkTyd1R1LO7UwG/1viFu+YPkn8ChQ5ooauKXlVmyId+8+XaQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from francois.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4c9XrW0XY4zlN; Mon, 25 Aug 2025 14:15:38 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Warner Losh , Kyle Evans Cc: Alexander Leidinger , Marcin Cieslak , Xin LI , Current , Gleb Smirnoff Subject: Re: UPDATING stuff Date: Mon, 25 Aug 2025 16:15:31 +0200 Message-ID: <2398435.mfXeX5GmMH@francois> Organization: FreeBSD In-Reply-To: References: <2r579os7-29n7-890r-9210-s3s1n4r0s4qo@fncre.vasb> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3036800.slGk94SIus"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart3036800.slGk94SIus Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Olivier Certner To: Warner Losh , Kyle Evans Subject: Re: UPDATING stuff Date: Mon, 25 Aug 2025 16:15:31 +0200 Message-ID: <2398435.mfXeX5GmMH@francois> Organization: FreeBSD In-Reply-To: MIME-Version: 1.0 Hi, I'll second both Warner and Kyle. 1. Unconditionally add COMPAT_FREEBSDx to GENERIC when creating branch stable/(x+1). Avoids trouble with a base upgrade in place without upgrading other programs. 2. On -CURRENT, compat' breakage can and will happen. Documenting it should not be mandatory (best effort basis). People just need to add COMPAT_FREEBSDx as they see fit (if not upgrading anything). This should save us a non-negligible amount of time in doing support. Thanks and regards. -- Olivier Certner --nextPart3036800.slGk94SIus Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmiscAMACgkQjKEwQJce JicP5hAAsTkBvp16EygC4zNQXIlaAlTO0hYxXq7FbM40M9qzqvxrxnnlUOF4lXvG eW0/K6nqH6vC1TYrueWokzp5bAHdNagkSvPvczax78yWVd80WUglOPKULUFnFLUl y4SbxAhWIT5lU5TDVrV6stMot8/CNzu2iUm3bjcpzbMGiavfjPTAPCzisY4NQKJS Aq57sgMnzjwYohz5uQdua5e6EWd2YusTUmGAY2p2wL418KjbMl9I0+UfuSBCMGpz WKNjGzOBOQV6OD5OOaAV/k78/4/diFHTmgFKxDyIGwlCVTX1LUh7SsYD/pt5EILR qFswjhhNfnxAzw8rjapNQLDJpUDN7u4oEGlgAJqtbGxSoMWX5GEPugKNe2nwRJ88 GmdvdbLVO0wAMTIThA5hiKTY/PhsCWyZSpT6WbDkqg3+Nkf0qaqx26acpybJ+PAg hY0r1wRKM3ngt2gPdl+7YfvGVV7R1KSz6lyxrlHtTe1FZHN4nvQ5QVZWMg5UrvHb M/sUGMS5zwHwYQoAxfHGbD21dVH57u2e/0jh6mFHHiVA69l6RTsnqYPjygoGD1Jx cTA+HLEegXG4fi0FQ1CoGCQuCaqPd81okdntz5ufJUdJlV7eikDw0mHf/4GrGkC2 zscidXL62asBx7+YwDwZRnpciRWE9ne3Uw6gH8eQjKsirQzuosk= =UPQe -----END PGP SIGNATURE----- --nextPart3036800.slGk94SIus-- From nobody Mon Aug 25 15:49:16 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9ZwZ0vn4z65xyS for ; Mon, 25 Aug 2025 15:49:18 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9ZwZ05zLz3fBd; Mon, 25 Aug 2025 15:49:18 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756136958; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hbQ38pwkLbrZ+cs/FNHHNDEITiOWIgjq3FxMR8o3dxM=; b=PSU4Ji5eEMKMitJqpS0MUqivwsga+BRjahEJVI0ABO1j7Eq8MYJadDCwehY+pyjAr/YhT9 eZnwuqTuivbAfWUAnCX7xXvBwiWzESXq7Q09RYRDMw4hpzH29wr1IzYFNY/W4lT5Y/9urk 9cCQpSx4ydmxsTJKNMekRGUQaEBfkz/r8/G2e7C20pCMs9bSv7I4MCgNyyK0xSj6LpqoQV /7GekOarH4uOhnL/tM5jH6MYUvufgRCCCO/hzci/ZCpqTyCxjuGVNHKxXnMgSNp1/o7ER8 xstK9p9gl/Ps2UnPbMlph4MJnlh48rNUBDxoZuQ0CysSSsGjOUpyHR0H2X3QRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756136958; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hbQ38pwkLbrZ+cs/FNHHNDEITiOWIgjq3FxMR8o3dxM=; b=sq9dxRIKE/Ur9JRjWXIbmzd0twcGmlDEfDDgKB+aGVbxlHh0jEt/NmwUM27OSqgg13dZWs PxbXyMDGFj9yULpeH8AO9npkmfYkpeErQVvmF3JguLB73aL3NuiLI8Ysk/nfwC0sebYJRj VtyXgGmtsxfDFAChJCPoxw0403caaf1lfcEICWDKbjvjp5GxFIkWoYeuNvPHDL91nmdHab 16/+NKYeQk4V8jjEf3gtTY1Ftt1Yml7+BuNCXzlGB0kWO2eQjCjmQsK521j7et5bX5vQiA V2zLEkX8WpvB1+ArgA/hlEq+tcO9KvxMM/34s9UCbCdYIzf654r6ytc90djHAQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756136958; a=rsa-sha256; cv=none; b=dwVwqAbVCTDrjojj8Vvu+wrAgjAHmgC/vErU/q4157iGX5lrZSestnNLHwguCuhbNC+6+A rfb9jdMwgiPYm9qNRmV+Zhi+BDY9ukgDmj2qvhPtz7U4U2FHvgvlZ5TPml79szmzhjwO4O HYOWBxFh48G/dQeY6rc/awjUXm6mIAWtIjaicPvC1TDfeJDM1WQ1Bwh/bMREjfQ22CIauG Lk2V0XpPfV5z/bUC6S9K58HBm3Uyr3LJZLo5J3S43Y5F6cjVN3VakLOT8aJ+fk6ukXnXHn I82lPgKfUvbBAAokcwbT9UDb4Y2ICxIhELew7LQ/6rFLX/OjJym8AERQABU0lw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (88-177-82-251.subs.proxad.net [88.177.82.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4c9ZwY5gd6z2vL; Mon, 25 Aug 2025 15:49:17 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 708B43C22E; Mon, 25 Aug 2025 17:49:16 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Olivier Certner Cc: Warner Losh , Kyle Evans , Alexander Leidinger , Marcin Cieslak , Xin LI , Current , Gleb Smirnoff Subject: Re: UPDATING stuff In-Reply-To: <2398435.mfXeX5GmMH@francois> (Olivier Certner's message of "Mon, 25 Aug 2025 16:15:31 +0200") References: <2r579os7-29n7-890r-9210-s3s1n4r0s4qo@fncre.vasb> <2398435.mfXeX5GmMH@francois> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Mon, 25 Aug 2025 17:49:16 +0200 Message-ID: <86ms7nv1tv.fsf@ltc.des.dev> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Olivier Certner writes: > 1. Unconditionally add COMPAT_FREEBSDx to GENERIC when creating branch > stable/(x+1). Avoids trouble with a base upgrade in place without > upgrading other programs. If you mean =E2=80=9Cadd COMPAT_FREEBSD14 to GENERIC when creating branch stable/15=E2=80=9D then you're way behind. COMPAT_FREEBSD14 was added to N= OTES, GENERIC and MINIMAL in October 2023. The only people who were affected by the recent syscall changes were people running CURRENT with custom kernels not based on GENERIC or MINIMAL, which is not something I'd recommend. I can understand not wanting to run GENERIC, but there is very little fat in MINIMAL, and whatever there is can easily be trimmed using nooptions / nodevice. (Coincidentally, I believe there's work underway to make kernel configs more modular, so MINIMAL can become even more minimal without raising the bar much for people who need more than just the minimum. For instance, instead of having Xen in MINIMAL or creating a config that includes MINIMAL and adds Xen, you would just use KERNCONF=3DMINIMAL-XEN and you'd automatically get a MINIMAL kernel with Xen support added.) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Mon Aug 25 16:09:36 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9bN22S0gz65FXj for ; Mon, 25 Aug 2025 16:09:38 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9bN21hwhz3hnn; Mon, 25 Aug 2025 16:09:38 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756138178; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wApRLsaEgum8BLL2ImXOhytIja6lExHOsDrYDPsLHNw=; b=GsuH7ADvs8zNadlIoxWz/KBZil9P7dC1/qPibDbn+Q2el4YGYmDaAD45B/5copB3uUnOWq U8oZtA2MmDeNsTi1GHVAQgBWic7OaHJJKlB6e5f0OJTNlhbhwmhk3gThoWQlF2GpMt6F1Q CydkA0m7GGkINW2coMHuyaF2Q4kqrQghKTss69rZVYNblrhGvtFmKamyXyPCRCcmJj4+Mg Eg2TPj4ARsiCYFY7aAC2z3RMTIoT6H/mhlrqR2CWNmXU76Sz28t3ytYn4se/0b/GN7sVnV OqUIX5jkVL9tZW6VvOe51/doDrL6FkMHZWFksbPtQS2PXVY2iSR2dZnZEimPBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756138178; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wApRLsaEgum8BLL2ImXOhytIja6lExHOsDrYDPsLHNw=; b=MZuXd2yNaLXpYCO33pmxR63oFSGlMsbERAt7+d+jbut7pXLhbH7XR45n3LB4cmuw5qjCtL tolfTrKFgy6oIYtNXNM+ikhkBl3jVpsG5l2dr3njpqVtuLnr7wKIlF6SGYBDXqmrqdYbm7 agjik9HDLoA5CQpfMZOhsU+06IMJGV6x2DfzL1QaGKo+JVjcPwHUAhxUYDiJVv0tG9ybZW PKYTZm2eHMB0gMtlDfOujQsnhj9kg5FO4Ntmzp5dAhMMRCQT9Y5jxNvvvf5D0z+pCDUh1U H7DVSMNp6Hchg6QI0O7P6XdeyVDBfpuWKrx0/fS1gP37kilu3QgyWfEcwunzhg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756138178; a=rsa-sha256; cv=none; b=eijrCuXC4BUTrQ5riASAfSSUOTsORB+FI/pmKzZ1V5iXr0IoDyLT/b81wV47XyAuGC5RAl NbylL0rqr3NwAmqzjp7l0nC/SHL11pjqZ63iNspp1DNBGFhGke5Uysw0F+QPfDPXT1DPom uckGhD8AihYdEH8AqPruQsJpMAqq9AKps6IS6KDqXsJguUPE/sUQWo2F00cOqiyzmIlVpa QvRltreirKheWEeQDQbjDyfANNryOGZb0xBn7JHLTZLK3GLAtpBOZNBTwusYGiGB38KVVY okEpqCYWSsH+l3GnTe/07ehEvmp9P8m9dUN665/olgqXWOYLnjG16IoTBGhk0A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4c9bN1554nz3nl; Mon, 25 Aug 2025 16:09:37 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> Date: Mon, 25 Aug 2025 11:09:36 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: August 2025 stabilization week To: Gleb Smirnoff , freebsd-current@freebsd.org, src-committers@freebsd.org References: Content-Language: en-US From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/25/25 07:53, Gleb Smirnoff wrote: > Hi, > > On Mon, Aug 25, 2025 at 01:00:07AM -0700, Gleb Smirnoff wrote: > T> This is an automated email to inform you that the August 2025 stabilization week > T> started with FreeBSD/main at main-n279838-6c45a5dad0a0, which was tagged as > T> main-stabweek-2025-Aug. > > This stabilization cycle is expected to be more bumpy than usually. > > 1) We got major upgrade - OpenSSL 3.5.1. One known issue is that the legacy > provider is broken. > > 2) The default Kerberos now is MIT. We have already checked that a Kerberized > NFS client can migrate from Heimdal to MIT. We did not check Kerberized NFS > server, but should be fine. There is no yet an official way to migrate kdc > from Heimdal to MIT. So, if you are upgrading a machine that is kdc, you need > WITHOUT_MITKRB5="yes" in your src.conf. > > 3) The official pkg repo is now almost empty, see email from Colin [1]. So, do > not rush with 'make delete-old-libs', unless you are ready to build a lot of > packages yourself. > > 4) The unfortunate coincidence with 3) is ABI breakage in the > setgroups(2)/getgroups(2) syscalls compared to the July stabilization point. > Some packages would dump core. These packages need to be rebuilt. > This should be mitigated if you have COMPAT_FREEBSD14 enabled? Old packages would reference the old compat symbol versions in libc, which should use the COMPAT_FREEBSD14 variants of setgroups/getgroups. If you have a pointer to scenarios where that isn't the case, that'd be helpful- old packages should be fine in the GENERIC case. Thanks, Kyle Evans From nobody Mon Aug 25 16:18:01 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9bYz2Fsmz65G1j for ; Mon, 25 Aug 2025 16:18:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9bYz03Kyz3kM6 for ; Mon, 25 Aug 2025 16:18:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-323267bc2eeso3487860a91.1 for ; Mon, 25 Aug 2025 09:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1756138693; x=1756743493; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=J1kZ2d5sxlLrosOJU1Ws2JhL9TU/K5PkF8HIUHf3t1s=; b=wtcDmcsTCV1t0QyFf+2pfzuQ3NweIhwfG16S5LiMc+34flzTgi3duj/WfNR1vnUd/L xnvRuPR0rKgcrttE64dKC3FQeNP+PRRl7jfyyJjVWiH7t9KS2TdtIWr3p0SyW441NTGq VQoPPtL41jcA0WzwyRM766en4VF91/EDR6yJFd7gyEtj8VlKdColL6/KHNiGKSglx2sY CuCeXHYEIDMpXc8tS5uMVn4/ownFG/w+Yd6XQn3fJYhWxib+nKcvFWEGliFKGZB8Wzp2 1G2TaGFNDSSk6Ni9G4HhCSeT8n9mVtzAgBNXOdcH+yUVDsZLyG0xxYutt1Nah+nGruO4 2QhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756138693; x=1756743493; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=J1kZ2d5sxlLrosOJU1Ws2JhL9TU/K5PkF8HIUHf3t1s=; b=SFL9ccpQlcIbb4SMEjnTrVkcKEDjXSdHm9vdxlsIcDG7G4wEpqi6fij/igfbmq7Xe2 yaBHWUXDEipxiyAUqVzINesr27cE3DCo70CjPjaFV3aG0L36mfoJlBATrzKHQKbqBPdu sJsG16+tvl2nfDx0ysOqxs+rCwNVspRxdBRZjTjmmQbeHF/H/dVG9Q9Y6Djw9dFToVH0 87bNqMGa1zIUKgf1cpBfALTtGH48JN/nh6OHhEYAa78FY8RCP6n5b4Yjd6iGSxz/rLuV DkCSYkQHOgRBXiCmFFd7GnUXhn3vakwIdNBLXmoy2khaAAFYyQJ4P6O7PBkC3AburNeU SUtw== X-Forwarded-Encrypted: i=1; AJvYcCWMu2miAzNpmBU5fdC5ayii5pTY82Xlt6sUCDaJIZz4VlUYp3Y8LgwhMsioxiwRnCNjenqcswAcqhD8Z8yrAqg=@freebsd.org X-Gm-Message-State: AOJu0YytblXYrcNYE27EwBRroeme6nzVD07WCSx4rb/SMMRRVOZp/nO4 Pq1yATD0pxgMmXscfzsIXwQETdGqDGjUl0+N24AASuorr/a7tYH/8DWa6ACSVvdzLCV+QIXvRlU kcP1iOiqzEjD2he9IvNwmrkCzVUJL9SFB5SPsyBkxv3xd/UjAsAdb1yA= X-Gm-Gg: ASbGncsLhczg/Je6WzbBYqrtw9nWltLwNi7p2HTTUFuLOg3SCEltXeD8iUrwPBepEQZ Htl3zAY5GNcoT5LIGmAJek1VQkyEHhEynMp08Z4moknTpxCQ/GEttWXjhzMRfhQC81Pt152oNQz ALQtRJpEXQ/aDkLZVvxdEc9k+m5iWcYrZcEgvBkRYsYe9pJ9yb5ow6Ijji7Y5ODn2rOzOmF/MGm Z38QDYaZqlXntFOezBfVODTCFZqOqPP9kXbuJA= X-Google-Smtp-Source: AGHT+IGiQhkkJ8bG1fGrNV7605kQLxGYiCyFIgsU/am6dPXOgvaT9sS/WOC4F67D5q4qIRYO5E3A2pOjhFO1IQ/bVDw= X-Received: by 2002:a17:90b:2ccf:b0:321:1df6:97d3 with SMTP id 98e67ed59e1d1-32515ead940mr15550169a91.4.1756138692833; Mon, 25 Aug 2025 09:18:12 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> In-Reply-To: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> From: Warner Losh Date: Mon, 25 Aug 2025 10:18:01 -0600 X-Gm-Features: Ac12FXy-w0f97fUForv6sDOLOoaMz5sGWuohtz6cd-vJT5J7Z976JJTnqfLkeWw Message-ID: Subject: Re: August 2025 stabilization week To: Kyle Evans Cc: Gleb Smirnoff , freebsd-current@freebsd.org, src-committers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000f682c1063d32e6f8" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4c9bYz03Kyz3kM6 --000000000000f682c1063d32e6f8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 25, 2025 at 10:09=E2=80=AFAM Kyle Evans wr= ote: > On 8/25/25 07:53, Gleb Smirnoff wrote: > > Hi, > > > > On Mon, Aug 25, 2025 at 01:00:07AM -0700, Gleb Smirnoff wrote: > > T> This is an automated email to inform you that the August 2025 > stabilization week > > T> started with FreeBSD/main at main-n279838-6c45a5dad0a0, which was > tagged as > > T> main-stabweek-2025-Aug. > > > > This stabilization cycle is expected to be more bumpy than usually. > > > > 1) We got major upgrade - OpenSSL 3.5.1. One known issue is that the > legacy > > provider is broken. > > > > 2) The default Kerberos now is MIT. We have already checked that a > Kerberized > > NFS client can migrate from Heimdal to MIT. We did not check Kerberize= d > NFS > > server, but should be fine. There is no yet an official way to migrate > kdc > > from Heimdal to MIT. So, if you are upgrading a machine that is kdc, > you need > > WITHOUT_MITKRB5=3D"yes" in your src.conf. > > > > 3) The official pkg repo is now almost empty, see email from Colin [1]. > So, do > > not rush with 'make delete-old-libs', unless you are ready to build a > lot of > > packages yourself. > > > > 4) The unfortunate coincidence with 3) is ABI breakage in the > > setgroups(2)/getgroups(2) syscalls compared to the July stabilization > point. > > Some packages would dump core. These packages need to be rebuilt. > > > > This should be mitigated if you have COMPAT_FREEBSD14 enabled? Old > packages would > reference the old compat symbol versions in libc, which should use the > COMPAT_FREEBSD14 > variants of setgroups/getgroups. If you have a pointer to scenarios wher= e > that isn't > the case, that'd be helpful- old packages should be fine in the GENERIC > case. > The packages that have been core dumping have so far all been SIGSYS not SIGSEGV which means Kyle's analysis is spot on. It's a fundamental use case that we powered through with even more radical changes like ino64. The only real problem one might encounter is if you install the new world, it uses the new system calls, but you have to revert the kernel to a one that only had the old version. Thankfully, regressions like this these days are are. I have another: 5) jemalloc was updated to 5.3.0, which in the past have had issues, but so far the only email has been a variation on thanking me for finally finding the time to get it in. Warner --000000000000f682c1063d32e6f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 25,= 2025 at 10:09=E2=80=AFAM Kyle Evans <kevans@freebsd.org> wrote:
On 8/25/25 07:53, Gleb Smirnoff wrote:
>=C2=A0 =C2=A0 Hi,
>
> On Mon, Aug 25, 2025 at 01:00:07AM -0700, Gleb Smirnoff wrote:
> T> This is an automated email to inform you that the August 2025 st= abilization week
> T> started with FreeBSD/main at main-n279838-6c45a5dad0a0, which wa= s tagged as
> T> main-stabweek-2025-Aug.
>
> This stabilization cycle is expected to be more bumpy than usually. >
> 1) We got major upgrade - OpenSSL 3.5.1. One known issue is that the l= egacy
> provider is broken.
>
> 2) The default Kerberos now is MIT.=C2=A0 We have already checked that= a Kerberized
> NFS client can migrate from Heimdal to MIT.=C2=A0 We did not check Ker= berized NFS
> server, but should be fine.=C2=A0 There is no yet an official way to m= igrate kdc
> from Heimdal to MIT.=C2=A0 So, if you are upgrading a machine that is = kdc, you need
> WITHOUT_MITKRB5=3D"yes" in your src.conf.
>
> 3) The official pkg repo is now almost empty, see email from Colin [1]= . So, do
> not rush with 'make delete-old-libs', unless you are ready to = build a lot of
> packages yourself.
>
> 4) The unfortunate coincidence with 3) is ABI breakage in the
> setgroups(2)/getgroups(2) syscalls compared to the July stabilization = point.
> Some packages would dump core.=C2=A0 These packages need to be rebuilt= .
>

This should be mitigated if you have COMPAT_FREEBSD14 enabled?=C2=A0 Old pa= ckages would
reference the old compat symbol versions in libc, which should use the COMP= AT_FREEBSD14
variants of setgroups/getgroups.=C2=A0 If you have a pointer to scenarios w= here that isn't
the case, that'd be helpful- old packages should be fine in the GENERIC= case.

The packages that have been core= dumping have so far all been SIGSYS not SIGSEGV which means Kyle's ana= lysis is spot on. It's a fundamental use case that we powered through w= ith even more radical changes like ino64. The only real problem one might e= ncounter is if you install the new world, it uses the new system calls, but= you have to revert the kernel to a one that only had the old version. Than= kfully, regressions like this these days are are.

= I have another:

5) jemalloc was updated to 5.3.0, = which in the past have had issues, but so far the only email has been a var= iation on thanking me for finally finding the time to get it in.
=
Warner
--000000000000f682c1063d32e6f8-- From nobody Mon Aug 25 17:06:15 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9cdN6wsMz65Kb4 for ; Mon, 25 Aug 2025 17:06:16 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9cdN4pdRz3q2L; Mon, 25 Aug 2025 17:06:16 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756141576; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vaelDAfh2g34sEf3XzXGfWvbEodOsrzetJPPSc5ytqA=; b=WVDb+zRcy8e7bQvbSA61OddojKd+YAOqUgroiBmt+ksKkL5p5XeJkxMr9UGATwtSA0c7s2 aNnkVEULZ8v0B2e/KQJK9n1oUMRtkp8w1AhV8dlg4gc5dZpPr8NVnGIMIfJ8dD/Guydvk0 S8oFqkOpBt4091eV7EJM2IpR4Wtv9WGQK4PkJjApv3YjA/1nq+sHvrGaZu30/qYjvGTw2X KOc+RSfl0ktQ9l05gQU+NlVyy3Va+8GqhGjTE0LpPud2FG2VBagbf0Itla5tPf1J2EjbJo Obgx5M0NO0ED71Y4Qr7KBzLMrEHt2Jo8vdEWniyLGyA8ty8s0dpYldZ5zVAV2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756141576; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vaelDAfh2g34sEf3XzXGfWvbEodOsrzetJPPSc5ytqA=; b=LezYOBOf10bWPGVnHYFiiDd3sN70iXJWorf//p5iM1qHkxYZZdb7yyFccYD08Ee+pOhj+b YxR+PeqkRYwC7/K5acEQpt7n/skjGIbkU3xCqBwu/1HPyTM+sPbDUJKvN86jt5qhl96Xu9 1AW9/kHnBKQuOx014IrtDJCJMxNa78nk6yw50RLHRD1wMuiEwf6I1eC78kPmTBGcQwBX2j 8xQjOqtBmoAmKXZ6bTIJ/IrVUg95kKsV+pxnt5cFs1ic16WVw1BxG9awvSSzwIN1TOMJPw vF4DHR0MI3RHLZqPQDev0QFRygdR7EWxvDHWe58ZktbESjWyVPNSaVPOn7zccg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756141576; a=rsa-sha256; cv=none; b=mT7r3gLTF5kv7mrHYhSyybuGDq6wKgN6XgxQlb8Acirv76e1+8mpg/zm2Eh4wsIyS62klH mJuns0m5DFYEsv1RcwwXxyYJgdQcPyZSnO0AGEKTKnPS7C2F4czdtVBaCk2ZVY8LhsAIfC EoLMJP+QGWooICCYRDak7wZP2sa2mS/jO462CQcyZopkZNz8c+cQBXqtQDYVR8/PqieGtQ YMZqAelY+trdycrLL0Xy4XLdiC+Lw7bWiFS661U7E2NOxpVtJjZTz5H3aXdLL8mqWnjOhG Xv+OjexglQlM7lnqUwpfy1JwBhZOcE+z/6RTy4QuAtH+65/q/f7gS0kCDt5egw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4c9cdM6ypqz4Df; Mon, 25 Aug 2025 17:06:15 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <49c53e4c-d44c-4254-bd6c-b37a94e47b56@FreeBSD.org> Date: Mon, 25 Aug 2025 12:06:15 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: UPDATING stuff To: =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , Olivier Certner Cc: Warner Losh , Alexander Leidinger , Marcin Cieslak , Xin LI , Current , Gleb Smirnoff References: <2r579os7-29n7-890r-9210-s3s1n4r0s4qo@fncre.vasb> <2398435.mfXeX5GmMH@francois> <86ms7nv1tv.fsf@ltc.des.dev> Content-Language: en-US From: Kyle Evans In-Reply-To: <86ms7nv1tv.fsf@ltc.des.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/25/25 10:49, Dag-Erling Smørgrav wrote: > Olivier Certner writes: >> 1. Unconditionally add COMPAT_FREEBSDx to GENERIC when creating branch >> stable/(x+1). Avoids trouble with a base upgrade in place without >> upgrading other programs. > > If you mean “add COMPAT_FREEBSD14 to GENERIC when creating branch > stable/15” then you're way behind. COMPAT_FREEBSD14 was added to NOTES, > GENERIC and MINIMAL in October 2023. The only people who were affected > by the recent syscall changes were people running CURRENT with custom > kernels not based on GENERIC or MINIMAL, which is not something I'd > recommend. I can understand not wanting to run GENERIC, but there is > very little fat in MINIMAL, and whatever there is can easily be trimmed > using nooptions / nodevice. > To be fair, there is a sense of policy shift here in that we, at least in the past 8-9 years, have normally only added COMPAT_FREEBSD options at the point that we have an actual user of it. The suggestion is that we be more proactive under the assumption that we'll likely find a consumer, and it would be helpful to advertise to custom kernel folks that it's more or less a requirement from the beginning until the branch has been stabilized if they really insist on not inheriting from one of our default configs. Thanks, Kyle Evans From nobody Mon Aug 25 18:53:14 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9g0s3pSgz65RsC for ; Mon, 25 Aug 2025 18:53:17 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9g0s35rzz47T8; Mon, 25 Aug 2025 18:53:17 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756147997; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Kb/YN6QTRGW7rW1ottUIGOXzk+e+/rcBQnjuQua0QTc=; b=SGrrMXdrwjFgmBcs9MXh/m+rPc9pebY43tGXIMZ7oina90dSiR3WUSQ5lpAuOpxKk9/j14 zw05dsnBaEe64f3TdfROTH/1ytqq2L3eg0kBHU+bPT1lB9OZm1YmNrtZj1B79eOBbstSQv V2Ua2qkzVLrndWdTO6ks2MXzJAgFPlAKrOKn90WnqOVW1AEZjNv/sEQ6YWa5hhmoEcPDTr T0W5zneBJTUSpLkcMd9nsWWf7zvnbJKBMq6UOVwsD9IxKAW4yC3EUJoYZLmFB/OnGE/4t6 ht8XZORR+OEAi4OClZ8DmuqLkcmAkdJg7c41MJD+oh6Lr6p9EcQlKvnd2RgQfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756147997; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Kb/YN6QTRGW7rW1ottUIGOXzk+e+/rcBQnjuQua0QTc=; b=YBMxv/gHRqQJkw920ovCUoKxknomWWXN4qWMGiJewlLNCiKZ0sL47qb/h5hi1QLe+k4rnK BibBi+w4je1KO80zUXV/6xLyKQd/slipjMRoAzY0GWMZ9HKSCKDaw8D0YRBZc/GGY/mpxV VMb3jMse1nrV3CuvompmJcVIO41yGrLPMIjPuOGiKJ33wKN8lo3DzmE0Tn4KV/6e2d7nX7 G6y7w3cEhpYjIhn80qIlXU123vWfnIcO3K2I//6pBneL/r8fVO7/0Fb05wZu7lNY81HXMO mA1aUsKur15EIFP9V1UR8B4hc4TGPQQsi7Mct3RwH+W0KWJOWrDtPaOu1aReOg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756147997; a=rsa-sha256; cv=none; b=grET+Aeo4KoG4z0Ce6UciVK5I+NH8Gz8EE8Vr8PXxaGj63FEpiDZj2W7iBRPRFzUNbSdrV yL71ccmtP74E7cPF7qPtOLkq+ZNtr01+Zb+N+96idLuw1NamPtr7+/dloXaH1m1jEx43Kb YwhteXcfDC9l2bbB/zdWyzOUJb4Ofoffp+EXsv7WzikluehTHqwkEk9/YXDuCQLGJV/cjb M9zxcJM+F9j9XtcKcvgteyjNFCjiFGWl9n+ijptYd3CaBZQ+O7ufiZlkmpixeI1SQA/LdH +J3lsQgionEw6uaQ/2YaWN4gPoQUmXci2lpV8a/dm7Gi2vE3bGD/Y0g25+nRJg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4c9g0r6vtLz7Cy; Mon, 25 Aug 2025 18:53:16 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Mon, 25 Aug 2025 11:53:14 -0700 From: Gleb Smirnoff To: Kyle Evans Cc: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: August 2025 stabilization week Message-ID: References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> On Mon, Aug 25, 2025 at 11:09:36AM -0500, Kyle Evans wrote: K> > 4) The unfortunate coincidence with 3) is ABI breakage in the K> > setgroups(2)/getgroups(2) syscalls compared to the July stabilization point. K> > Some packages would dump core. These packages need to be rebuilt. K> K> This should be mitigated if you have COMPAT_FREEBSD14 enabled? Old packages would K> reference the old compat symbol versions in libc, which should use the COMPAT_FREEBSD14 K> variants of setgroups/getgroups. If you have a pointer to scenarios where that isn't K> the case, that'd be helpful- old packages should be fine in the GENERIC case. You are correct. This affects only people who run custom kernels without COMPAT_FREEBSD14. -- Gleb Smirnoff From nobody Mon Aug 25 20:27:47 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9j6G4GqKz65bFZ for ; Mon, 25 Aug 2025 20:28:06 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9j6G1JSLz3KVN; Mon, 25 Aug 2025 20:28:06 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-61c325a4d83so3486138a12.0; Mon, 25 Aug 2025 13:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756153680; x=1756758480; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=O9IeRQe1zzsk0WGxDE7UW6K8G/oBN72+Emmx5m6T6Qw=; b=VyoDeg8sF9cpKCYQ7gDmIBSka6Onrd9hIZOgT3N9LaXN/pMF1gmMIFa3I0au5qaAn2 Xoa9eG/AZt7v20MltkSxUpndCcpGuvJEmtqNlnpx+MpyMt77rw9qJMPBe0SOMEbbIdx7 ewpJ6P4jlNAino7xbraPTYfNQ7coI+eC8fm6dOf/HTkFnv7WWTdy+XbcNTARfhkl78KX 16KPSBzaGBurdhMxkyd/82hmNW6roJcYtP0/tbe9iCWxulc9tfLG6czueT+mAuXVhC/d 251KlWPCt7jiyhxSIMBL+Hf8jMbuzYQ+YHofMYa1dZf+04vgJeS1WCMU0jUB4baNXSjt eqkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756153680; x=1756758480; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=O9IeRQe1zzsk0WGxDE7UW6K8G/oBN72+Emmx5m6T6Qw=; b=AHxEJvXaMt8uRHyb86wZkuoR10IS6aTUDtqExRbrgHkXQpFpG380u9mG6kqs00iBPB 1mkUOFgRxFLt897Xz81Yp2PQsZrXi87qEYatDCUFhkx5K8pF14EP4JdaSrQeDdBjflYm 8tawUdFdqJIR7c349W2/p46gCTKsCWSCkikOhWA8mlgF/A4p2Q3kyPuP6hv/kU0YbU/z wvnl6R0BAq95+ePjuCj7COFVAlxOYkJAlKjoS7MmjO+YM2XpTbvRzOnKpIrepS7FqcbN WXG3LUIsAWYc7dfiDSosNI92TfAm0B5Xagt91qK95dTXH8iNtXmTS/p6PG5cvn8e38od sq7A== X-Forwarded-Encrypted: i=1; AJvYcCXB+sO26GgLOVhADwUWD7zpBo+o9EhNTAgHhXABM7GyTHNIIk4xAJeR3/5AKGkWNgL6aPVQfa2LrqqxxwdISQE=@freebsd.org, AJvYcCXU97XpGmFtxjMH+YnclnGPyvI0h81eSkYoNrExluVQzXufL3xVNIreFWcpIUEgcI5wTbsNqa/wgvKbyspOqwE=@freebsd.org X-Gm-Message-State: AOJu0YxDvdNgpphuyqRzQSI+O8pKGGQnIX/nGOUP1RKrNZRorLaqvneT bANx80rhH+B0DB3zYYrWWAOp6TNvVmOJkEH2pZY4woq5aBjR5DzrluAl3PimwIZ+1L5d/JErT/8 NKuckFjEODjdodHGqZKGZiE9geE1lPv4M X-Gm-Gg: ASbGncu337SU/6i/EA05d3qzMbwsl4tvrB6+IMFNCtzyjDthQ/2FzF3w/9SL/A0KRld ASZBmKSAPur+Mj8K/v2pJs1UR2R5nOiWpdARRlhoBeCCO7QD1i4ryvmCDBPlYHdmeAPY/Ehfk8Z ut8JHfDYtTVvV43c/b4c0b27bjQwmO7HHWYexClrHChseaLgxBcpY7YLkbd5mvBIvjc4Z5YIf7x RbGhcuEJwUMrbN/H5LK55iBHs60AXglScPpg8Q= X-Google-Smtp-Source: AGHT+IHzvQP61YVfAdiWYwXsO2bpHR51eyL2VUlZrzo9jApM8hR0zAoPRe1Xa43nQGw5sAm99Cs00hCmH9SaHmqi/qk= X-Received: by 2002:a05:6402:5c8:b0:615:957f:416b with SMTP id 4fb4d7f45d1cf-61c1b3b93e2mr11200312a12.6.1756153679476; Mon, 25 Aug 2025 13:27:59 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> In-Reply-To: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> From: Rick Macklem Date: Mon, 25 Aug 2025 13:27:47 -0700 X-Gm-Features: Ac12FXwZP8zAwStKMCGa-pMN1fT9LCVYOVEzYmLviDwx_7o5u8LXfDdtGJHw4lo Message-ID: Subject: Re: August 2025 stabilization week To: Kyle Evans Cc: Gleb Smirnoff , freebsd-current@freebsd.org, src-committers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4c9j6G1JSLz3KVN On Mon, Aug 25, 2025 at 9:09=E2=80=AFAM Kyle Evans wro= te: > > CAUTION: This email originated from outside of the University of Guelph. = Do not click links or open attachments unless you recognize the sender and = know the content is safe. If in doubt, forward suspicious emails to IThelp@= uoguelph.ca. > > On 8/25/25 07:53, Gleb Smirnoff wrote: > > Hi, > > > > On Mon, Aug 25, 2025 at 01:00:07AM -0700, Gleb Smirnoff wrote: > > T> This is an automated email to inform you that the August 2025 stabil= ization week > > T> started with FreeBSD/main at main-n279838-6c45a5dad0a0, which was ta= gged as > > T> main-stabweek-2025-Aug. > > > > This stabilization cycle is expected to be more bumpy than usually. > > > > 1) We got major upgrade - OpenSSL 3.5.1. One known issue is that the le= gacy > > provider is broken. I believe that KTLS support isn't yet enabled for it? (If so, NFS over TLS wo't work.) > > > > 2) The default Kerberos now is MIT. We have already checked that a Ker= berized > > NFS client can migrate from Heimdal to MIT. We did not check Kerberize= d NFS > > server, but should be fine. I tested the server a couple of days ago and it was fine. > There is no yet an official way to migrate kdc > > from Heimdal to MIT. Yea. One possibility is to install Heimdal-7.8 from ports/packages and then use it to dump the KDC's database in MIT format. (Although Cy seemed to find it didn't work, doing this with the "--decrypt" option might retain th= e passwords.) I'll give this a try and report back if it worked for me. rick > So, if you are upgrading a machine that is kdc, you need > > WITHOUT_MITKRB5=3D"yes" in your src.conf. > > > > 3) The official pkg repo is now almost empty, see email from Colin [1].= So, do > > not rush with 'make delete-old-libs', unless you are ready to build a l= ot of > > packages yourself. > > > > 4) The unfortunate coincidence with 3) is ABI breakage in the > > setgroups(2)/getgroups(2) syscalls compared to the July stabilization p= oint. > > Some packages would dump core. These packages need to be rebuilt. > > > > This should be mitigated if you have COMPAT_FREEBSD14 enabled? Old packa= ges would > reference the old compat symbol versions in libc, which should use the CO= MPAT_FREEBSD14 > variants of setgroups/getgroups. If you have a pointer to scenarios wher= e that isn't > the case, that'd be helpful- old packages should be fine in the GENERIC c= ase. > > Thanks, > > Kyle Evans From nobody Mon Aug 25 23:11:03 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9mkN1Bsvz65p74 for ; Mon, 25 Aug 2025 23:11:08 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9mkN0k3Tz3bGH; Mon, 25 Aug 2025 23:11:08 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756163468; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eAD/T1jFsCKp8uWT1n1/zoqk+idWFFB7eq31PZPZMpc=; b=Lr+m0N0NfvWBpyNy6n7TGcop3KDLQkIzLzbeKqNDwLtXN3k/1CbUtRTscksgTq8xFbjqhv syd9um/AGD2kRzZVhEijWf9kp4wND/Y3+uozi+eKiw3Vxqci6DeObRs+eu6Tl8uSkvCn1D CJFi7L34Td7B3WS3IERUFNhn6V2usNr7HEXxaWCy9M+TXrA5ZQqc5g6yyg6r8mcWZt2QPe yL0C+vXM+pPRyW5A4975BYk+FtrWkzD+VS8oXGqk4IFy5SDA+FUATta5e5MRuGMWoMzbaw iCcq5MXh6IfZJbGiShvLRVSHffn/HpcyPK04NtqKCgArEN+EwR2bPO3TqS7Q8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756163468; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eAD/T1jFsCKp8uWT1n1/zoqk+idWFFB7eq31PZPZMpc=; b=ELGafGcusOpYrTXRwoD/GO5UMDMxldF9LMqTSTXGOvzIRkZhVsu76dgery/LvMnHPAwpHA baqPA5lCN3xXqBpDfPaTgdXZjZwVf79JbjP8DIFU+81SOLe6wfiGOIpLCz91zfNGi6yz5R nwawLpZVpxSoz3qJA3k3e1yLI5FC5h3jTqEOPQp60ggsPSNuAvXyHjClMihqP53A4pTTn8 sbzXg0E1xdAnSHD/CbJEh44NkBIe8ZaHlGVaxuTTRzioSpFQLCllaU/RFv+DdvdqDbucbq wE2VDhBcE614IjwbFEDIufoiLUsRyUN5/IPqxVNSMrAOlzZrBMpNSeAFu8guxA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756163468; a=rsa-sha256; cv=none; b=xRIlcPAlMQ2UdDZVqA/AkTEPrUgGgkp+D4tTswyhROgMCuAvxy0Xcum/KjUT66XUW73G7y Pt9XmHJNWiJB3VcFfsNaq5x29zN0ArzSrTiuJ0Q/d5Tu64lOEIJD1MQPtZqhBlcSCq4K52 ur81HHg+WS1v1l5r/9n40tKdng6KqhfCzT2+Tieb4ZqI4FDU6LSuwhHXQJC9l1Yda0Hroh CEcljp4M3ZNX0eREmtZgBRoyqbP55y/++kSJvlPO8g8nQqihQj0k/Lk9GCxvOo+weC+myg RhhGuw8/EQ8V0IvmbykJRp2NfE6Ah5dFDF/ym5pseHZRYOtY21YfsIA+3DG9QQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4c9mkM3btjzBPx; Mon, 25 Aug 2025 23:11:07 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Mon, 25 Aug 2025 16:11:03 -0700 From: Gleb Smirnoff To: Rick Macklem Cc: Kyle Evans , freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: August 2025 stabilization week Message-ID: References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Aug 25, 2025 at 01:27:47PM -0700, Rick Macklem wrote: R> I believe that KTLS support isn't yet enabled for it? I think it was enabled by 267f8c1f4b09431b335d5f48d84586047471f978. -- Gleb Smirnoff From nobody Tue Aug 26 04:25:47 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c9vjl3vhFz66Bnt for ; Tue, 26 Aug 2025 04:26:03 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c9vjk4qwTz3Fd3; Tue, 26 Aug 2025 04:26:02 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=eIJ5Ncun; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-61c22dceb25so5872159a12.2; Mon, 25 Aug 2025 21:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756182360; x=1756787160; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=scBMHkSXOAYtlqzF1XT8s89W+eFH6MCB9woY3pk+/rQ=; b=eIJ5NcunM6yh+nAoiPN4QPIGNX2yaFJGRyBvCaOcScoRW47DV1p8EOqQVqKG+ONf5J GtmSW28FhTZKmqebZ+b9YQmJ9+iQUKGkR1Ak9wos22HbIaS+uyzMUTL0qwB5hoxrniqQ bvXUp1jlIXbk33YMm5aRaO5F3/bf8fqIyEx8m9qldfGmwHzy3kqJPFXDAgR3SFNeCcOY dzK9s4PB7JoUxdU2ctA8gIHM4kNcHRcTiJOXTN9cNyExYDaoXD6eLzljhX87m4t4Xj53 NnoDGKtaqDFLm+PjF+x4ixuOx+9t4Xll3owy6aT2HYadE8cpG5KJ6jRLPHELv2YtuZId EQQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756182360; x=1756787160; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=scBMHkSXOAYtlqzF1XT8s89W+eFH6MCB9woY3pk+/rQ=; b=olTLH/KLgpgqX9B9wQsCUYJeWmo9DgrILvc41HEdTpqqq3G1hFobVgFE9HEsOkYsqC GTvfv3vQoS9Be+T6ragb+CbeWbkGo68HKAyEc2IurR8It/kRCMhotXbS3vREkBvPWb4L GWKBBbithssH/9fmTZ2NNsHf4/UL7GXm81HCvTg6e1JJPHdsCoUm0zPxwcNKAK51hfsC Fwgykc4h2qZe4Z74WHZrS4lnMXGmPFHGJDwQ1LiINhk9BSkDYpbW5GAga9Jv80JADV39 yEOxKJzOT7krWMPVMduyP3b/rYuyCAiafJYphbGYA0fIcQFSz62wdPWVwEaM30BmdLpN XGyw== X-Forwarded-Encrypted: i=1; AJvYcCUoJ6rfvj6WOuKunY3xkpXVW76v7cCD1wUIo8V5ZNxp0zBW0P2paHYd7W1Aly+IhsTIEtPcyANQnGDIU4X/Huw=@freebsd.org, AJvYcCWzYuBHhC1e9vSDCZvmWUCRtPgBMhDkqxjCY/dAa7alOmEwaNj98bKZHVr6i4fYONUOC2YRXikOfjn8t2gAZ94=@freebsd.org X-Gm-Message-State: AOJu0YwNGjcFKD6rLtdebJ1nMAbKJCBBwBL4pA+XounabQ7BPJuodku9 KFL56OPZIhe0QsXVnAPyyNuSHoTIaxN8ONM+vw0G8JAni2cPMbxoXY3IXvtoXqm7dWzzyQFRQ/Q yioL7sBfVy304EzcPuZ0NJqPFEFQ9wsEM X-Gm-Gg: ASbGncv1No+a3fH1fk69kDsh8B3c/KgNjBGNSG/ubzr/ZhFDV35DUIdUBez9DKnvZh4 ymaNpMsgrPxT41gIx9Tbd8odWEoNJFGLxLRu/FwvZHaxQhhtxhBIF5drzd160J9/iJ5+vkJJrBX APM4I7pIc52GZ2gpd+mcIuX1HILs+urZC3tJCuFjyRUziOJy5RgPImCL8DyHF1lZ2EorakBUvZk f9LN88I/TOlghPH5Lz/68lJarLRKmPQLjr7YUw= X-Google-Smtp-Source: AGHT+IEJlXTWoeQAkWkyQWhtjzTcl/zGps4kO1B4hlctFcpGB8+BP1oxGD50X7RBROoWLZd7GamWhLNPg5mvgbkGoZ0= X-Received: by 2002:a05:6402:13d4:b0:61c:4436:a0eb with SMTP id 4fb4d7f45d1cf-61c4437049dmr8639745a12.26.1756182359888; Mon, 25 Aug 2025 21:25:59 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> In-Reply-To: From: Rick Macklem Date: Mon, 25 Aug 2025 21:25:47 -0700 X-Gm-Features: Ac12FXxMttSn3riFiqPC5gZnesGZoDRnSi_eTbP9g0bO_HTc8_pHbZ5fuikLS5k Message-ID: Subject: Re: August 2025 stabilization week To: Kyle Evans Cc: Gleb Smirnoff , freebsd-current@freebsd.org, src-committers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4c9vjk4qwTz3Fd3 On Mon, Aug 25, 2025 at 1:27=E2=80=AFPM Rick Macklem wrote: > > On Mon, Aug 25, 2025 at 9:09=E2=80=AFAM Kyle Evans w= rote: > > > > CAUTION: This email originated from outside of the University of Guelph= . Do not click links or open attachments unless you recognize the sender an= d know the content is safe. If in doubt, forward suspicious emails to IThel= p@uoguelph.ca. > > > > On 8/25/25 07:53, Gleb Smirnoff wrote: > > > Hi, > > > > > > On Mon, Aug 25, 2025 at 01:00:07AM -0700, Gleb Smirnoff wrote: > > > T> This is an automated email to inform you that the August 2025 stab= ilization week > > > T> started with FreeBSD/main at main-n279838-6c45a5dad0a0, which was = tagged as > > > T> main-stabweek-2025-Aug. > > > > > > This stabilization cycle is expected to be more bumpy than usually. > > > > > > 1) We got major upgrade - OpenSSL 3.5.1. One known issue is that the = legacy > > > provider is broken. > I believe that KTLS support isn't yet enabled for it? > (If so, NFS over TLS wo't work.) > > > > > > > 2) The default Kerberos now is MIT. We have already checked that a K= erberized > > > NFS client can migrate from Heimdal to MIT. We did not check Kerberi= zed NFS > > > server, but should be fine. > I tested the server a couple of days ago and it was fine. > > > There is no yet an official way to migrate kdc > > > from Heimdal to MIT. > Yea. One possibility is to install Heimdal-7.8 from ports/packages and th= en > use it to dump the KDC's database in MIT format. (Although Cy seemed to > find it didn't work, doing this with the "--decrypt" option might retain = the > passwords.) > > I'll give this a try and report back if it worked for me. Well, I'm not having any luck. Every time I try and use Heimdal-7.8 to load the database from Heimdal-1.5.= 2, "kadmin -l" throws this error and exits. kadmin: rc4 8: EVP_CipherInit_ex einit I need the Heimdal-7.8 kadmin to work to try and convert the database to MIT format. So, does anyone know the trick to fixing this? rick > > rick > > > So, if you are upgrading a machine that is kdc, you need > > > WITHOUT_MITKRB5=3D"yes" in your src.conf. > > > > > > 3) The official pkg repo is now almost empty, see email from Colin [1= ]. So, do > > > not rush with 'make delete-old-libs', unless you are ready to build a= lot of > > > packages yourself. > > > > > > 4) The unfortunate coincidence with 3) is ABI breakage in the > > > setgroups(2)/getgroups(2) syscalls compared to the July stabilization= point. > > > Some packages would dump core. These packages need to be rebuilt. > > > > > > > This should be mitigated if you have COMPAT_FREEBSD14 enabled? Old pac= kages would > > reference the old compat symbol versions in libc, which should use the = COMPAT_FREEBSD14 > > variants of setgroups/getgroups. If you have a pointer to scenarios wh= ere that isn't > > the case, that'd be helpful- old packages should be fine in the GENERIC= case. > > > > Thanks, > > > > Kyle Evans From nobody Tue Aug 26 08:22:17 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cB0yV53jsz66SB1 for ; Tue, 26 Aug 2025 08:22:26 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cB0yV4JRJz3dBT; Tue, 26 Aug 2025 08:22:26 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756196546; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=daBsXD2jrgg7VQhKIgm+SFzCZl9iqSj/RRorT3ve+dU=; b=FjCKBJGQViIlH2sw8raN6TMs19H86jagzRETHP2GpK4vbXXNUV1+ignaP+W6ZRNTAdY6Jx wnEvw0ecQseNYzsDK0ncC9C1+j2NxcEtdG9/herzMdWFDm/F/4M6m2Ql2Igt7dvAwm963X G56l1y2pv/CFrI2dalb+LDpAXltPPjrlLqATUYB+8aRdxU0pTIsuwrCAVReqkKFeY0g7Y3 QzkDOXaTGA4SjLFJbdT0D6FMvbYcG09LKPhjghOov2CU9A7JqZksqBWfMoMA4+Q0Wd+B3a n4KwlDmp9xKL/r1/Qf3NkPGSxs0Ah0DSiFhSQ1A0L0MBSFpQzJXVD713QUFAyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756196546; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=daBsXD2jrgg7VQhKIgm+SFzCZl9iqSj/RRorT3ve+dU=; b=vQ0TlwfZ1ZnfZzpquRXI6n+9YC/arC5XG6FD7eh9BHAxcs36ADQnm8uGhFN+75HdpR+BY3 wdtZcSAPt/S6FWf1eyHqI6zt28HclctP+6NLgMK/zyTLAFeYEZLcr34v/oRARYBPP28KVZ wODMxWxl4UHpcpspSPQTPWquVTufrrdWJI5Vd8gJAIXocRMHInahjaSSJrC+uvhqCJiOIp L2864xwuBAxKlDatv/ExU14aZqTi9bo9hbN4pE2IM/6tJLQZgoFa/H/E3MQOyxDowNdnJU oPZP7+QwNQW1qaCug9K0b+NIz5VT2buc7JP7WDG1ShAIXvvqMN5x+01vt+WzuQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756196546; a=rsa-sha256; cv=none; b=PYhBZNFP6RvscrVG983pHMzF4mDk0MdV41cWLal2C/W0PUYAwoYnfjNpfarxPvB5laNRPy kZXl20eBBxw7ZFj7PLEv49xi+qyVy2QkPaQB7FD+KYlRbPyoo4rXG55JuDvT7P+3mAVP2p T3cbsEB+MiCHpWJl1rKAQwJ8aJfEEmKjOfmIJJVxgvclyg+hDzeJTi+QQDo4CyvFFRnbtz buLWOCUYvy8h/wGKWiP5qxCNKH7FNHOGQupSBkpyB51/+GpBDDiwvHD1B7cw6yt3Jqxx4s cxvZ8NzO/hPYJ39LkwOmB0vMTiZ8iLZQKaQwLpZJtf+AM9bP2xHIvrL8rfWWKw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from francois.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cB0yT3tcYzPS1; Tue, 26 Aug 2025 08:22:25 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Dag-Erling =?UTF-8?B?U23DuHJncmF2?= Cc: Warner Losh , Kyle Evans , Alexander Leidinger , Marcin Cieslak , Xin LI , Current , Gleb Smirnoff Subject: Re: UPDATING stuff Date: Tue, 26 Aug 2025 10:22:17 +0200 Message-ID: <4075052.kAAoriTUSa@francois> Organization: FreeBSD In-Reply-To: <86ms7nv1tv.fsf@ltc.des.dev> References: <2r579os7-29n7-890r-9210-s3s1n4r0s4qo@fncre.vasb> <2398435.mfXeX5GmMH@francois> <86ms7nv1tv.fsf@ltc.des.dev> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2902739.iL6vRArjjl"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart2902739.iL6vRArjjl Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Olivier Certner To: Dag-Erling =?UTF-8?B?U23DuHJncmF2?= Subject: Re: UPDATING stuff Date: Tue, 26 Aug 2025 10:22:17 +0200 Message-ID: <4075052.kAAoriTUSa@francois> Organization: FreeBSD In-Reply-To: <86ms7nv1tv.fsf@ltc.des.dev> MIME-Version: 1.0 > If you mean =E2=80=9Cadd COMPAT_FREEBSD14 to GENERIC when creating branch > stable/15=E2=80=9D then you're way behind.=20 That isn't my point, which is about policy. See also Kyle's last reply. > The only people who were affected by the recent syscall changes were peop= le > running CURRENT with custom kernels not based on GENERIC or MINIMAL, > which is not something I'd recommend. This specific "problem" was addressed by point 2. Thus, it should have bee= n obvious that point 1. wasn't about that use case. Did you bother carefully reading and understanding what I wrote, as well as= the mails I referred to, before replying? =2D-=20 Olivier Certner --nextPart2902739.iL6vRArjjl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmitbrkACgkQjKEwQJce Jif9PxAAjNEZCIihPgdd4p9LVv+RxsyfpaVOFh5vEhGEDyTccnqaGNzbyCxWeH/m dQ1Lm7MdpygPrcdi1MzmU9CCfkw+8qNnIlmv465Tv+fHfuPVvbwob2IwHJ8SeP31 rAdq9UBMKuEseHlm62LzAHV04qL7ONacK9RUQyuSJT2qMa5Bl9NAyYlCYNKd2tuO 5O5D5wiqor7NC/xUadVrD3pLHfpn+PR28tvRmUgveA+znJNFFtGNwZecwZcMrkTK ixOq1A30cx+Jy1gaw3lwCiFN7gQFdCOZAzz319OWmLkRmmsaQJyFao6WErxLjbq9 aRirYcDy5alK4R7Nm0R819oPbU0JU42OJyz95isLkTjFbpbfUl9AysAbNr0No8A/ 3EARaSZM7h8K5MAM8iWBQsUXSkwnwtkUWRCW8OT6x4xwWW4gGBc/Kn6b2ENS5gxb E2X3n1uBfjUOghIbmddj/WobuQ0fzC68QDwz6u1yE35wcBqDE/js5TcOgYyAY8pa dyX7KdKZk0rr0xux++nfMkruTJy6vaYe3146f4DtWR5+Avp8zd6Zkw/X174YETgG oiRjplywTdmHWgEgsuR7ykKhDCsY+l7FqBINjZHaLMus2geJ7zv5vz+wre3G0huw +5ieKUoPkVs9f3u8BtB1ulE8rmeSQF67OBXrHGyMg8BkQ9DCzRA= =tWsb -----END PGP SIGNATURE----- --nextPart2902739.iL6vRArjjl-- From nobody Tue Aug 26 09:16:11 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cB28Y2D6Dz65HTY for ; Tue, 26 Aug 2025 09:16:13 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cB28Y1Sskz3lfl; Tue, 26 Aug 2025 09:16:13 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756199773; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lelQpBNpXdA7Tx8lzcrIdABIswXrH8uBFX/cD7zg/W8=; b=w68SvIw/ljczx2aJpuT7TC83sldC0Ypdc45eeblnvwvph3WoQvemu4UmWcKypUWeZdFgDE DenRaDSVHVPTUQgqieMMGtcE52iIoXTCvuUOyBnErKoR4qc2NotDRLS+vM4f/Weq8o90P1 ZUIf5NQkT7j8e1D7U6uwh/4FIkGRhIUsxWMfhywAeKqBlnUw9glM/Iun8D6F2bHKVraqoI 8P4qFx6VnDHX3v2jUbVB/tTRacKh7QxQ+2I9AALst6B4oZijPJ+2TQwmUJwmFL6/R8oIY8 7hE2LP5l5HD5NRbcevX77ApDRDFBsJvziuGOYwCRO8OSCn2jGtXyqXKoOFAp+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756199773; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lelQpBNpXdA7Tx8lzcrIdABIswXrH8uBFX/cD7zg/W8=; b=DguMdQ7kUAetFarOo68Z66EknZ0LwjRBQrwpvZuqtdmxDzsJ/fg1q+OmRP3A2qvRrgo9/l ifKg6cNCAJyex81nGvNTqCjeIXmpkjxH3R99lTdf5YGZP9I6haC4pssOCgUviYk89euOVl /8aQU+5fTdyAeFqMssX6NbZFi+c8EdJslZqSGl5PIjhghQu7QTdwagQYAj81mmnppnSQW6 C2CXdUEW9Z/JdHp4b5c8TdCLbiu7aaLef/+nJH9QgZFDrdC2akJwpDsCOkwK2fbsV+OyKF HAzwwq8f8nYJQ08GVh21TNwmCt02ZQEqcv9d4Fa7x6M/9EiaJAhEIZewl+EyGQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756199773; a=rsa-sha256; cv=none; b=hBoZ6P7KBy+Y5e+Uu+k6vHkyMioNlh8FVO0Yapkhz8GZcNXSKUvVjVior73Ue3STWRKfO4 RTOA03oe5UqbNfzDcGSHoWmuwhzRpujVxskoFhFu7u3oO4j9eNnER5Kom7+HwYZLkI6LXg o4j/cy9a7AXG6KQo3fUepwik62F4oLbd1SnnxwbLePRP8cuCY9pItARc8BM+KiBn/RgxbA aKeLPHx5yzMCel+d724W64YTr5i4XM8NBzOxgTpHD00GcrUFRSM6uN9eNVG349bXYIHuvi +xyGfL9jHwqOIGFbFNrmfZe5qdvQ2PwC+HBvYtrS5+zrLsU6KQdUPOxgxSlOeQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (unknown [IPv6:2a01:e0a:c54:bed0:922e:16ff:fef1:acef]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cB28Y08zzzNsq; Tue, 26 Aug 2025 09:16:12 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id D77A13BFB3; Tue, 26 Aug 2025 11:16:11 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Olivier Certner Cc: Warner Losh , Kyle Evans , Alexander Leidinger , Marcin Cieslak , Xin LI , Current , Gleb Smirnoff Subject: Re: UPDATING stuff In-Reply-To: <4075052.kAAoriTUSa@francois> (Olivier Certner's message of "Tue, 26 Aug 2025 10:22:17 +0200") References: <2r579os7-29n7-890r-9210-s3s1n4r0s4qo@fncre.vasb> <2398435.mfXeX5GmMH@francois> <86ms7nv1tv.fsf@ltc.des.dev> <4075052.kAAoriTUSa@francois> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Tue, 26 Aug 2025 11:16:11 +0200 Message-ID: <86a53mv3xg.fsf@ltc.des.dev> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Olivier Certner writes: > Did you bother carefully reading and understanding what I wrote, as > well as the mails I referred to, before replying? I did, yes. Have you considered that perhaps your point wasn't as well made as you think it was? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Tue Aug 26 09:32:58 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cB2Yh5cNKz65JYC for ; Tue, 26 Aug 2025 09:34:32 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (prime256v1) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cB2Yf4bVsz3pPD; Tue, 26 Aug 2025 09:34:30 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=P4ytvGEB; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1756200832; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dnThfABFmnY5yD6WBqdx+va4c97EgbByjMp12F1wPWU=; b=P4ytvGEBGVsnNI8QA1YezSnE48GuE5yx+DpnJA64Mae83OmLcWNPuIWhlkOaVsGPovvGVb 9IZz00DSq52AOBDrhuMhXYjepsUyq7o1DJc5rA9kY6TR/nSgaoUc0V9xDHZ7FydA8KKv2J Hzvi27ncf9oSuZV8Qo695tZLvRDj6C9/iefN10cJIpdDdeWAPcLC9fJgK2Ot5cJ+ie5h9G xR4eV+41KiYNQBm+Ue6FMFVFy0Evd8EgmJ6+R/V0TStnurIlQZJmrgRcLG4bgvZPhVzg3Y /WdHInuv6Yk9XZXG3Wr4pL3ZFt8VISiPV4KnqphnhFDio5KWycMM00VVme3o8g== Date: Tue, 26 Aug 2025 11:32:58 +0200 From: Alexander Leidinger To: Rick Macklem Cc: Kyle Evans , Gleb Smirnoff , freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: August 2025 stabilization week In-Reply-To: References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> Message-ID: <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_18994ccde09114cd2899c604a070c8fe"; micalg=pgp-sha256 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.97 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.971]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; ONCE_RECEIVED(0.10)[]; DKIM_TRACE(0.00)[leidinger.net:+]; HAS_ATTACHMENT(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; HAS_ORG_HEADER(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4cB2Yf4bVsz3pPD This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_18994ccde09114cd2899c604a070c8fe Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2025-08-26 06:25, schrieb Rick Macklem: > On Mon, Aug 25, 2025 at 1:27 PM Rick Macklem > wrote: >> >> On Mon, Aug 25, 2025 at 9:09 AM Kyle Evans wrote: >> > There is no yet an official way to migrate kdc >> > > from Heimdal to MIT. >> Yea. One possibility is to install Heimdal-7.8 from ports/packages and >> then >> use it to dump the KDC's database in MIT format. (Although Cy seemed >> to >> find it didn't work, doing this with the "--decrypt" option might >> retain the >> passwords.) >> >> I'll give this a try and report back if it worked for me. > Well, I'm not having any luck. > Every time I try and use Heimdal-7.8 to load the database from > Heimdal-1.5.2, > "kadmin -l" throws this error and exits. > > kadmin: rc4 8: EVP_CipherInit_ex einit > > I need the Heimdal-7.8 kadmin to work to try and convert the database > to > MIT format. > > So, does anyone know the trick to fixing this? rick I migrated a while ago... don't remember if this year or last year. And I don't have my notes about this anymore. But I exported everything from base-heimdal and imported into MIT. A quick google gave mit this: https://serverfault.com/questions/1000332/migrating-from-heimdal-to-mit-kerberos This can be done with the base-heimdal + ports-heimdal + mit-krb. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_18994ccde09114cd2899c604a070c8fe Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmitf1kACgkQEg2wmwP4 2IbyLQ/9H/NmW8C/+MqI4BzlokwADxbSQWC6mEka3o3mFefD3T61mGq9+BA+P1mG XB09rSbHQblV3ymbTM0yl7gxY+00V0UVdA2Lxmilx/qMEcK+7VDSMWMkIhcfOS59 Zy5aa9RwTnqWix+znFtzgAEVmqLi9a5ZHQDfBeqont+zrv6YnU3KLtnGgZdO6xB9 KfQMvsFxWCg/UwvL+LyxkneCppEiLH6bafNu25aTPDsNMKKY5XGOhl3gBnwoOWMD fHu9B5VRzqqzYbpw2ptuVd8ah3N5lBxwBkO2RZ8B/Ei922KaD+cKwjU98ccAE9xu 6yEYKyjl5388WLlUMfdBqwUxx/lM36pvPOUctGtZl8HEQpNodqTrpOevn1nj8g7a OhQujIKno6ZdSgiReDfkmf1PTjG+CFEBus+Qp3N99mcoHDS70ezZxj53yRcNMD6V vh/HK4zqJJJp3boqCgotiboIHi1BSsr3zM7tNRdj2/T12lPSOSpFIMXWYqecdB// hb+bP0n/8jxlMNtZpmjOSu6vZMDSu3r333yYpZymFtaZmc7/swHMff0oDunw2Zv8 R/Zt2BH4rpK9/RAPK5Fth9LOaQMaSy3/TpV6Dl4wwy6NaCn8ql88XCmh//2g0lNf rUI+26iodWhgHtzLziuEP7qdnsGsgvGW+kgTH+m2frpCRju9phA= =kA2N -----END PGP SIGNATURE----- --=_18994ccde09114cd2899c604a070c8fe-- From nobody Tue Aug 26 09:38:16 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cB2fB2qFdz65JwD for ; Tue, 26 Aug 2025 09:38:26 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cB2fB2Dt5z3qkL; Tue, 26 Aug 2025 09:38:26 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756201106; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zABCf+3nlijvaqP4nx8uFF2czaTVE7hKy+YiCsqKnnw=; b=A0461tMdKSTjUfGA3i70zAMMK0Fp8Yly2Tilg7v5IjXSaQviilw4VAlzQmnGxV46FVTrgG gLSf9OEyo8Nly725HlvBWsIjgLvlnGoQIOyigwPKhczDFM6EWmK23fWCVefzpfuaWjxSU4 qaCx67BwRu5Zu4DTONSLpppllUvcO+HzTOpsJLIoyjcofQkJt6BfIB/nYjP+wbYU4PvK1w fhaI1sITx/mbZ0C2I7N5ZKCa5Sfa0LpaI4kCjPGYUD6ajxp2h5wNi2qoAzB7Ln9h5UcZ9L Bw+gyN3OtlBCTYXoyqtYhBbV/66x4S932hejNe1sXORZ0+vMY+gjiPfPG6OabA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756201106; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zABCf+3nlijvaqP4nx8uFF2czaTVE7hKy+YiCsqKnnw=; b=FC37WIrruspEnMcbr5UEp00lYPoJeUFag4bYNP1OOIQf0sp+hfcpXyq+aoh2H3ikdGB5Ex +r0NsJXFQrJtDLrEPXo1MxAucaDaKEc68pECFUI7UOfH0sQ8KECHAWqG5kzxMXoEvQlE8e J03aD72BMQVOYOFOJEbhjuRoXqdRHIGEVKH4RSN/+zgOuY2/mtcGpdYK8mDtFmLVKfgAzo jQqh/JecG0oHLiNXz9VFTHXj6HgNzflayBriYTl6yke6oKvUkRwqgzmXHAg4/27l3zle8q 7HsJgGn1YwUbpMddYTLsEf1g6PRtQ0m+KXeXkLx2DN6hdA/YE3xWF3gEa3D3/Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756201106; a=rsa-sha256; cv=none; b=xZEQBppis9gDFST0n4Yv0FLTKWz7438s/cQouzB7DXgKbdSFju0v4Pfp0grKmTmOQOVqWD Xemty+VTga+ng07mXQTo4qKuZGw7vWpdldXcKt6To5dFoKFtEGmuFyXz8daBP5cAVG1IpR pquzIT7QwBRE02Od9Eu6AGKOD1aDvjdCN4tP12hR+0ydKnKZqWPsJCZM4KYC7Kn0RRmrBQ fGxZBL9sNltZ2Pv78dei4FNjRpAOoHOulZP2M5BzpWbS5ojGSCZwypFuGcVBu2A0bVXZLu TysE3PnSPlccyksjoOTHM4V3JxPbmkitIrrQsgyNKSW7JDLB8dRS2h3tgOgunA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from francois.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cB2f91kv0zNsx; Tue, 26 Aug 2025 09:38:25 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Dag-Erling =?UTF-8?B?U23DuHJncmF2?= Cc: Warner Losh , Kyle Evans , Alexander Leidinger , Marcin Cieslak , Xin LI , Current , Gleb Smirnoff Subject: Re: UPDATING stuff Date: Tue, 26 Aug 2025 11:38:16 +0200 Message-ID: <6031679.8T7jmnknE8@francois> Organization: FreeBSD In-Reply-To: <86a53mv3xg.fsf@ltc.des.dev> References: <2r579os7-29n7-890r-9210-s3s1n4r0s4qo@fncre.vasb> <4075052.kAAoriTUSa@francois> <86a53mv3xg.fsf@ltc.des.dev> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4249332.O2WMGSuNBG"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart4249332.O2WMGSuNBG Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Olivier Certner To: Dag-Erling =?UTF-8?B?U23DuHJncmF2?= Subject: Re: UPDATING stuff Date: Tue, 26 Aug 2025 11:38:16 +0200 Message-ID: <6031679.8T7jmnknE8@francois> Organization: FreeBSD In-Reply-To: <86a53mv3xg.fsf@ltc.des.dev> MIME-Version: 1.0 > Have you considered that perhaps your point wasn't as well > made as you think it was? Yes. I still think it was reasonably clear. I rather suspect(ed) that your misinterpretation in part comes from the fact that the mail that started this thread was a rant on a breakage after updating -CURRENT, but since then the conversation has broadened, which is why I asked if you had properly digested the relevant mails. -- Olivier Certner --nextPart4249332.O2WMGSuNBG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmitgIgACgkQjKEwQJce JicwsA/+Lv5lUDcb9GBaIYYmxJRR7LZCuoXsoLdesocftHxaPSH/B7B/VDT+3bAD mDufqwD1RhoHVfOQa0++dl1AGfgxeYpE/2IS7xyiHaOiObwvVLtNJfAW142RwQ48 cNBnWCd/a758vTli9708Nk4SIjZ01x+LPcwUVly4uz2lSwqg6DZ6AY4r8vLFZYyd ah5EoK6wa1NvG+ONsk20Ftg96o6XpnIqVjugA7KrZrxG5rC0t4pvK0TqrSAN4BOG 4nad3ecRCgAVKBW2T3Hsdg3X1ZfHS1wckHVgc9Lv0XTCwJAsgs2JhkWY5iw3mbqI XUXmYxAnUuf1FysC3Fz1RgcCiMra7eRuOlHpguN0AEnGd3JROzEAGMDHoRMAre1o yBYrkJ7MOSOJhzgzb78eVyomiYKM3ahcYlWjnj4KTbgWpnP5EO2uYcvmfFV88RNo L0UAdqesoFkE/Ke3vcB37R6dXoeAEp9zHp1m+x1PpT+/l9K4o2Uv/30nwIgn2on0 ivo8Yg3xVcndZtozW/qHDrL0GUeRnOefmMIi+AzKMBs3/WvQp0dhYqAKXFte5X+R 1mC9chnHahvj4ergbFEdVK1KBUpC+YTxNYhawkYZXq0iZ1v+HT0kF+TK17WlxL1K aohi0u/E35fxp8FTBSMsUnSVZEqg2/76QNyPUEp1zoG+6f+rWIo= =Jg/K -----END PGP SIGNATURE----- --nextPart4249332.O2WMGSuNBG-- From nobody Tue Aug 26 09:44:19 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cB2pV0FJ0z65KdR for ; Tue, 26 Aug 2025 09:45:38 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature ECDSA (prime256v1)) (Client CN "mailgate.leidinger.net", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cB2pT5Pdmz3rfX; Tue, 26 Aug 2025 09:45:37 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1756201506; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3ofiNo4kPUrKzvIm9G9+ByN6v7iP/a6Pv1Y1OuJp5lI=; b=gbor54T2hz3sUDB8wzFJFJ6HNT+ra04ywSufvORjwfLIf11o+1w0AiwMs6tX9T9fL9OwU2 VHJM1nb4zolC/4BlG3TnzxdchNcoG8umS4cGVEG26qTs/KEYqabiG0lIPh9KYOBsGcWw6t kIB1eKa0eNkbLqb9X2pahfwvHzaxT+CEKBcT2BREzBsNDlQ0b/sUoKIXVQBMwbWQXC1wL6 S6ooIpSxPf37JVq8f1MwWOpzirUcoHFyL0Mc39POWJcRaUHU/d6nDjUtLHwMgrhRu6RaKj ewcyLIEHS46ZxjqEmL5CO3AuGpQdJlptHN2pL6f5Gaj5O/vdGKokeN1ofCWPbQ== Date: Tue, 26 Aug 2025 11:44:19 +0200 From: Alexander Leidinger To: Gleb Smirnoff Cc: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: August 2025 stabilization week In-Reply-To: References: Message-ID: <3fc8a77ac961de040dc35a7fb5562319@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_d4a54e7de09950634487834fe8330e42"; micalg=pgp-sha256 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cB2pT5Pdmz3rfX This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_d4a54e7de09950634487834fe8330e42 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2025-08-25 14:53, schrieb Gleb Smirnoff: > Hi, > > On Mon, Aug 25, 2025 at 01:00:07AM -0700, Gleb Smirnoff wrote: > T> This is an automated email to inform you that the August 2025 > stabilization week > T> started with FreeBSD/main at main-n279838-6c45a5dad0a0, which was > tagged as > T> main-stabweek-2025-Aug. > > This stabilization cycle is expected to be more bumpy than usually. > > 1) We got major upgrade - OpenSSL 3.5.1. One known issue is that the > legacy > provider is broken. > > 2) The default Kerberos now is MIT. We have already checked that a > Kerberized > NFS client can migrate from Heimdal to MIT. We did not check > Kerberized NFS > server, but should be fine. There is no yet an official way to migrate > kdc > from Heimdal to MIT. So, if you are upgrading a machine that is kdc, > you need > WITHOUT_MITKRB5="yes" in your src.conf. > > 3) The official pkg repo is now almost empty, see email from Colin [1]. > So, do > not rush with 'make delete-old-libs', unless you are ready to build a > lot of > packages yourself. > > 4) The unfortunate coincidence with 3) is ABI breakage in the > setgroups(2)/getgroups(2) syscalls compared to the July stabilization > point. > Some packages would dump core. These packages need to be rebuilt. In my local poudriere builds I had to switch to ports-mit-krb for p5-GSSAPI. The normal build with base-krb failed with: ---snip--- Searching krb5-config command... using krb5-config command '/bin/krb5-config'. ---------------------------------------------------------- using GSSAPI implementation /bin/krb5-config does not respond libconf! at ./Makefile.PL line 116. ---snip--- krb5-config is in /usr/bin... This is with -current as of 2025-08-21-223348 and an up-to-date ports tree. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_d4a54e7de09950634487834fe8330e42 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmitggEACgkQEg2wmwP4 2IZi3RAAq6db1CLr8yvJORN/6IFxsfRLBQFmqlqed7ERkkBBpu84MUOiXA6YDrZx /EPhhkekcXTKv1Uo2PZ571ASYrwr5M6gtgXDfv2C7spK1qh8ziPs28Z2xgtoxQUe hjmGJEgDx3y7Mw5tX3XTYjoQbnGgxaWzgIuhP2xduRIo7hj1eBlgEeR/0A41E4ln m1ChO0yVOJChXfmOCRp1qRV/wLGH4rwzWbEGvhL55yMrhDq4NdowyqdMlGsLZ8sV RUE6T2WNKNucaN5WeHzhfJeusA9+MUyy5lFL5LCIDEVpkvoAsTsElg9UsRLC8rpQ qFRZvdc6/eg2xTJdpZbvSYoIsp0UkaFlSTX1QOzdCp5+pCQ8Fd1a9/juK+MR2yP/ +fHxUxKgBEfV9IBn9KSPi+P4xblgbT+L5MIlUhvjg1uI4G9pMZsjdMTxdrKwGy1p 2KxI4NcU9nHIaQ5PWbQVtZf6ojvl/Dsn0aMkZWj6AMfgsQb5pE1f+9rxLp+LPPz5 y36fcM5xn+LYXZR4g50T4sEGFUU6m5MxQX0rZzp/0qQaPARWT742ncpXbXry353p mLkeGaLXbFSZzCxhgXUk++d8FSM0kqxoF9S9ePAwCRGNxgQ6uZsEqgTkN6J9r364 gLFWGznHH3Hof8gSNjL6nnX67D1biOYeqOQ3AGC+I4FGaNPw6lw= =17hx -----END PGP SIGNATURE----- --=_d4a54e7de09950634487834fe8330e42-- From nobody Tue Aug 26 13:05:23 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cB7F26SLSz65XQv for ; Tue, 26 Aug 2025 13:05:26 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [138.201.35.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cB7F212Cbz3CVn for ; Tue, 26 Aug 2025 13:05:26 +0000 (UTC) (envelope-from crest@rlwinm.de) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of crest@rlwinm.de designates 138.201.35.217 as permitted sender) smtp.mailfrom=crest@rlwinm.de Received: from [IPV6:2003:fc:d715:3000:7118:232f:9374:dfa] (p200300fcd71530007118232f93740dfa.dip0.t-ipconnect.de [IPv6:2003:fc:d715:3000:7118:232f:9374:dfa]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id 3BCCA11A9 for ; Tue, 26 Aug 2025 13:05:24 +0000 (UTC) Message-ID: <31931c62-b125-4b28-b2df-b8f3e741d2bd@rlwinm.de> Date: Tue, 26 Aug 2025 15:05:23 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: August 2025 stabilization week To: freebsd-current@freebsd.org References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> Content-Language: en-US From: Jan Bramkamp In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: / X-Spamd-Result: default: False [-0.54 / 15.00]; NEURAL_SPAM_LONG(0.99)[0.988]; NEURAL_HAM_MEDIUM(-0.81)[-0.813]; NEURAL_HAM_SHORT(-0.42)[-0.418]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:24940, ipnet:138.201.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; DMARC_NA(0.00)[rlwinm.de]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1] X-Rspamd-Queue-Id: 4cB7F212Cbz3CVn On 26.08.25 06:25, Rick Macklem wrote: > On Mon, Aug 25, 2025 at 1:27 PM Rick Macklem wrote: >> On Mon, Aug 25, 2025 at 9:09 AM Kyle Evans wrote: >>> CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca. >>> >>> On 8/25/25 07:53, Gleb Smirnoff wrote: >>>> Hi, >>>> >>>> On Mon, Aug 25, 2025 at 01:00:07AM -0700, Gleb Smirnoff wrote: >>>> T> This is an automated email to inform you that the August 2025 stabilization week >>>> T> started with FreeBSD/main at main-n279838-6c45a5dad0a0, which was tagged as >>>> T> main-stabweek-2025-Aug. >>>> >>>> This stabilization cycle is expected to be more bumpy than usually. >>>> >>>> 1) We got major upgrade - OpenSSL 3.5.1. One known issue is that the legacy >>>> provider is broken. >> I believe that KTLS support isn't yet enabled for it? >> (If so, NFS over TLS wo't work.) >> >>>> 2) The default Kerberos now is MIT. We have already checked that a Kerberized >>>> NFS client can migrate from Heimdal to MIT. We did not check Kerberized NFS >>>> server, but should be fine. >> I tested the server a couple of days ago and it was fine. >> >>> There is no yet an official way to migrate kdc >>>> from Heimdal to MIT. >> Yea. One possibility is to install Heimdal-7.8 from ports/packages and then >> use it to dump the KDC's database in MIT format. (Although Cy seemed to >> find it didn't work, doing this with the "--decrypt" option might retain the >> passwords.) >> >> I'll give this a try and report back if it worked for me. > Well, I'm not having any luck. > Every time I try and use Heimdal-7.8 to load the database from Heimdal-1.5.2, > "kadmin -l" throws this error and exits. > > kadmin: rc4 8: EVP_CipherInit_ex einit > > I need the Heimdal-7.8 kadmin to work to try and convert the database to > MIT format. > > So, does anyone know the trick to fixing this? rick This looks very similar to a problem I had when upgrading to the first FreeBSD release using OpenSSL 3.x. In that case the issues was that the cryptographically broken old RC4 ciphersuite is no longer supported at all. In Heimdal you could disable it in the configuration and so it wouldn't even probe for the removed cipher. From nobody Tue Aug 26 13:08:13 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cB7JQ4H7Jz65Y13 for ; Tue, 26 Aug 2025 13:08:22 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [IPv6:2a01:4f8:171:f902::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cB7JP5zdnz3DXl for ; Tue, 26 Aug 2025 13:08:21 +0000 (UTC) (envelope-from crest@rlwinm.de) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of crest@rlwinm.de designates 2a01:4f8:171:f902::5 as permitted sender) smtp.mailfrom=crest@rlwinm.de Received: from [IPV6:2003:fc:d715:3000:7118:232f:9374:dfa] (p200300fcd71530007118232f93740dfa.dip0.t-ipconnect.de [IPv6:2003:fc:d715:3000:7118:232f:9374:dfa]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id 7D14C127E for ; Tue, 26 Aug 2025 13:08:13 +0000 (UTC) Message-ID: <638395fe-688f-43ec-be67-a239cdaaa08b@rlwinm.de> Date: Tue, 26 Aug 2025 15:08:13 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: August 2025 stabilization week To: freebsd-current@freebsd.org References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <31931c62-b125-4b28-b2df-b8f3e741d2bd@rlwinm.de> Content-Language: en-US From: Jan Bramkamp In-Reply-To: <31931c62-b125-4b28-b2df-b8f3e741d2bd@rlwinm.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: / X-Spamd-Result: default: False [-0.54 / 15.00]; NEURAL_SPAM_LONG(0.99)[0.987]; NEURAL_HAM_MEDIUM(-0.81)[-0.812]; NEURAL_HAM_SHORT(-0.41)[-0.415]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; DMARC_NA(0.00)[rlwinm.de]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1] X-Rspamd-Queue-Id: 4cB7JP5zdnz3DXl On 26.08.25 15:05, Jan Bramkamp wrote: > On 26.08.25 06:25, Rick Macklem wrote: >> On Mon, Aug 25, 2025 at 1:27 PM Rick Macklem >> wrote: >>> On Mon, Aug 25, 2025 at 9:09 AM Kyle Evans wrote: >>>> CAUTION: This email originated from outside of the University of >>>> Guelph. Do not click links or open attachments unless you recognize >>>> the sender and know the content is safe. If in doubt, forward >>>> suspicious emails to IThelp@uoguelph.ca. >>>> >>>> On 8/25/25 07:53, Gleb Smirnoff wrote: >>>>>     Hi, >>>>> >>>>> On Mon, Aug 25, 2025 at 01:00:07AM -0700, Gleb Smirnoff wrote: >>>>> T> This is an automated email to inform you that the August 2025 >>>>> stabilization week >>>>> T> started with FreeBSD/main at main-n279838-6c45a5dad0a0, which >>>>> was tagged as >>>>> T> main-stabweek-2025-Aug. >>>>> >>>>> This stabilization cycle is expected to be more bumpy than usually. >>>>> >>>>> 1) We got major upgrade - OpenSSL 3.5.1. One known issue is that >>>>> the legacy >>>>> provider is broken. >>> I believe that KTLS support isn't yet enabled for it? >>> (If so, NFS over TLS wo't work.) >>> >>>>> 2) The default Kerberos now is MIT. We have already checked that a >>>>> Kerberized >>>>> NFS client can migrate from Heimdal to MIT.  We did not check >>>>> Kerberized NFS >>>>> server, but should be fine. >>> I tested the server a couple of days ago and it was fine. >>> >>>>   There is no yet an official way to migrate kdc >>>>> from Heimdal to MIT. >>> Yea. One possibility is to install Heimdal-7.8 from ports/packages >>> and then >>> use it to dump the KDC's database in MIT format. (Although Cy seemed to >>> find it didn't work, doing this with the "--decrypt" option might >>> retain the >>> passwords.) >>> >>> I'll give this a try and report back if it worked for me. >> Well, I'm not having any luck. >> Every time I try and use Heimdal-7.8 to load the database from >> Heimdal-1.5.2, >> "kadmin -l" throws this error and exits. >> >> kadmin: rc4 8: EVP_CipherInit_ex einit >> >> I need the Heimdal-7.8 kadmin to work to try and convert the database to >> MIT format. >> >> So, does anyone know the trick to fixing this? rick > > This looks very similar to a problem I had when upgrading to the first > FreeBSD release using OpenSSL 3.x. > > In that case the issues was that the cryptographically broken old RC4 > ciphersuite is no longer supported at all. > > In Heimdal you could disable it in the configuration and so it > wouldn't even probe for the removed cipher. > > Sorry I forgot to include the relevant /etc/krb5.conf lines: [libdefaults]         default_keys        = aes256-cts-hmac-sha1-96:pw-salt         default_etypes      = aes256-cts-hmac-sha1-96         default_etypes_des  = [kadmin]         default_keys    = aes256-cts-hmac-sha1-96:pw-salt From nobody Tue Aug 26 13:28:50 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cB7mM3J3sz65Z7w for ; Tue, 26 Aug 2025 13:29:07 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cB7mM1KWvz3H8G; Tue, 26 Aug 2025 13:29:07 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-61ca9a5b41bso8637a12.1; Tue, 26 Aug 2025 06:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756214944; x=1756819744; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xKXXNgpraWZZaZeADdQ2nXYBCqLIp9ag0ew3w5GhzVg=; b=BglEWUGE3PvipH1m9py6nm4J1b7BNbbaI4nZFJ4oxxHj21XHTekPANX4bZ+zIQY/gJ b2s4IeybbpYnqx+O+ircX2YESSrLpJrLn5pTrKh2nWTotEkizLEbyqv+kvrIXVX21meW 8CZkt6a/xqjjLq6HyWJ14YQ91+R5SN9mGx4M9xy68cEjt3nBQMWj4AueAb4GmLf1Z5VT WHOJIE5RWS3wXafyrDkHiE3QhojcsnYdVoWRoYApkf7Ee5X2H1cVVHIgwHQEuwLnu8P+ MyJEoz0zyeC1mHIK0PtI6CZG7SdEbokcTEgTRCnBQPX9oLHROcXVwO2C76gEJmtKt0Ut nlLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756214944; x=1756819744; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xKXXNgpraWZZaZeADdQ2nXYBCqLIp9ag0ew3w5GhzVg=; b=JiJ39zD5P6x7MNdn8yCXs7FEjZCLnPMLNKxIoS+9A0yTFHpvL5TrL+UJVPqjHIKJu8 Eo8YivusPr87TVtH8mA6Ie5KUI/eoV7yYo+8Z1n2IpSRmsV2ZseCTQYrCzndTX1Kzzug T/wMwiXZuWlGt5+dBTnba1sWh7FwoC3wu67zw6wyFSjaEtWvPNW8SUoN0xzHQRkTh7yH T3Az2DzgU5gdGlpOwtziXdtjlLG7t5/ZKUpJs50eJOFpUMywEK3ukBaCfGUK5OG5a+x2 vF31+dn9JjxA4gqEdbII2MFPiR2Lv0Cn1gwdIuKxRaJ0NsP30HS95Wq9+Y6qXtwrD8NF +4UA== X-Forwarded-Encrypted: i=1; AJvYcCV0AWW3Wn+/3pO3uy+yJmsQ1WSBa3JbbvDJhuFZUYWc+ecL/+01hcKTEw47l5A7KQPodO68xcYIEQ==@freebsd.org, AJvYcCVTMzNIt6ODDRxt0VCKx7381t6Aeor4gfhVOwsFNnaJSDTQdAYR+lErDzIQCUqI0PHYtL2iqXfLFAk62LsspCU=@freebsd.org, AJvYcCW330Tkjrdo+xx4ot83nUFMzxa9B23HVDRfZ+Nnz1ZLFpESa7+tuO0NUskpNrF43KypvfkrtXYx9kJBfLAxK0A=@freebsd.org X-Gm-Message-State: AOJu0YyGiuPtkIrJSHlBhLdyrbs+2gwMPQJIC16wdOqoZ7OEBQ6I4FKL 8vGOa3yB+R6so+omab8UX0qPI8d85lZ/kCiWqdXuQON1uu/zgyPDzwk2GuX/d0YQIMzuD4zUqS2 13G+P2IdRho1MZJBEXpZmeEJwBOAzulU1 X-Gm-Gg: ASbGncvEFWoyY5lyiaIQbOkOkTbebrFa4DEUJ04EBG8kARiJBkUP5S+Yg3Zo96WKqWk /szaAUP7cIrDRe/dLfgFjhWPajEaI2fKoVltt72ZCOINFgvK11ji7xRtB9yRrWaniRIlOBa/Yo2 8nGz4I3fwgYrl62a+nm+Zsrwpa+VBA0eYqYyq4SV7BE3bTfH7SFjf4NrOf6jbpTTUXb+b7wG8dL iJFB5HyK5eKg0iDwery3dudTiL22fn44XBs53sq1tLMdrmEJw== X-Google-Smtp-Source: AGHT+IFzYi+jKRaqokM6YLkcIS0eys2ocQ2T7UCmqyxYBF2poa+mjxEOBNrw/Bkpk+r4+komaVCPGRMJ/8g6DOi6+j8= X-Received: by 2002:a05:6402:42c3:b0:61c:7336:67d9 with SMTP id 4fb4d7f45d1cf-61c7336722bmr5140363a12.26.1756214943446; Tue, 26 Aug 2025 06:29:03 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> In-Reply-To: <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> From: Rick Macklem Date: Tue, 26 Aug 2025 06:28:50 -0700 X-Gm-Features: Ac12FXzkFU4-7w_Z3X6DZ48jMLd7B-DAvOIHZyZOfvJcvm-g3KQmJFFIYQzdWiE Message-ID: Subject: Re: August 2025 stabilization week To: Alexander Leidinger Cc: Kyle Evans , Gleb Smirnoff , freebsd-current@freebsd.org, src-committers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cB7mM1KWvz3H8G On Tue, Aug 26, 2025 at 2:34=E2=80=AFAM Alexander Leidinger wrote: > > Am 2025-08-26 06:25, schrieb Rick Macklem: > > On Mon, Aug 25, 2025 at 1:27=E2=80=AFPM Rick Macklem > > wrote: > >> > >> On Mon, Aug 25, 2025 at 9:09=E2=80=AFAM Kyle Evans wrote: > > >> > There is no yet an official way to migrate kdc > >> > > from Heimdal to MIT. > >> Yea. One possibility is to install Heimdal-7.8 from ports/packages and > >> then > >> use it to dump the KDC's database in MIT format. (Although Cy seemed > >> to > >> find it didn't work, doing this with the "--decrypt" option might > >> retain the > >> passwords.) > >> > >> I'll give this a try and report back if it worked for me. > > Well, I'm not having any luck. > > Every time I try and use Heimdal-7.8 to load the database from > > Heimdal-1.5.2, > > "kadmin -l" throws this error and exits. > > > > kadmin: rc4 8: EVP_CipherInit_ex einit > > > > I need the Heimdal-7.8 kadmin to work to try and convert the database > > to > > MIT format. > > > > So, does anyone know the trick to fixing this? rick > > I migrated a while ago... don't remember if this year or last year. And > I don't have my notes about this anymore. But I exported everything from > base-heimdal and imported into MIT. > A quick google gave mit this: > https://serverfault.com/questions/1000332/migrating-from-heimdal-to-mit-k= erberos > This can be done with the base-heimdal + ports-heimdal + mit-krb. Yes. That was basically what I am trying to do. However, I cannot get the ports-heimdal to work, due to that rc4 related problem. (I've tried 15 and 14. Maybe I'll try 13?) Because there are several principals created when the MIT database is creat= ed, I think the last step might need "-update" ("kdb5_util load -update mit.dum= p"). rick > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From nobody Tue Aug 26 13:40:09 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cB81W19w5z65b8P for ; Tue, 26 Aug 2025 13:40:31 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cB81V6MYRz3KWT for ; Tue, 26 Aug 2025 13:40:30 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-61c4f73cfa0so4586570a12.0 for ; Tue, 26 Aug 2025 06:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756215624; x=1756820424; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=s9UFxmgaTmUBSZqjdMKr9WKgL5+3cGISv9vxl+62IvE=; b=RSMmuaGwplz4TjFZR7nWt+VcCJzzvWast0YCFYmNkENb0y78ybkx+S8AhAfOq1SKlJ 1e4fQFS6mekD+jvipZmi3zNrxXgNQ0hHs3yBOoMCMehl8rlUhhrkTyqKdlQ5aopTJMzw Yecfz8PeGGaYknwREIqZEp2scfM9P/p+ExPUUvmix1MPhWG/8W+hl9TrpSkBNYrp113W oYp6bX/+Gas8WvDJA75SRW5t561xuXi4yU7mavkVbMBN0smCVS/7VqPsRIXYzhik0VVP IuIp0vWrj6Ifl40V3nIWw5w58e9f+F8emwSYzYZpY7usycXrhlpQOBRLVOS+pt0npcqn hvCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756215624; x=1756820424; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=s9UFxmgaTmUBSZqjdMKr9WKgL5+3cGISv9vxl+62IvE=; b=ms8VTRkh2+drrY5I/WRu7NFP/E6WcQYS+3rnmr7+mUZR1zLE5ghU6gpl4uHgRp+/jn n6uvsOTnf2sUOLnqSRTqrwtye2xNA/6SoMgFuvc2djVykS2WjdgNltq1QrIuWV991npN yty+5o87tobygkN1lZzE+JWi8zmc/TaNiand+lWXIuOzOSB44ztLLU/dlWENhhqRooTY oDXqT3uGVdKxQTTVdKwEjUHnX/q2vYOgtEV3/w/gz6sJR4OsC6SHMtQw1R5VoBUk9TFe j6uiDPM0kadBn+yHkOHgZNj4e0kAlywOIoGddk00e4WloSbhwFoAWbuRSWnivfALI++q a09g== X-Gm-Message-State: AOJu0YwKkypB9+Jqg9w+EenHjGzeLx8BnoJ3EqcT7PVxwnbVwEyKpCfD OSLUMTytYUnU/POqTeLU6YRfutOFdEVgkS/lBcbtzOtBuZ3tYv9e/Gol1TsXJh+8tpvRf806+h2 RKhHhXObiIMICK4/czRcQC8lCmqBsXTnu X-Gm-Gg: ASbGncvYv9ajLEedaRuiIxVtf2jKtjenxPmBd69BBrI6RPzQGatKC3GpSDuTTIuyTUu q2/1XVceRnnjtJBeLqeIf+cfYUqYIK/VZ0GGaKCHRpIbOL7bgip+wg6zN5iCz2iFUOMqivQLdpz swngU4q344kBJnWwh8NtuirdIG8/U0EUZl3b9xUGcsLZtotGiGdFTrsIwO1u+ucPJ2zIfkGmHTe YDx7uTStG+Gh7cA8FX4BichQKeFZVBteQIL6VOwkfM+kJaF2A== X-Google-Smtp-Source: AGHT+IFbhsksa5SnZxrLZ+UTZuqVKpvjOMZ7wSKEimA+yHSactSoNK04CcqycViWxta1PYPeJMkP/QcpPTvnwgbd588= X-Received: by 2002:a05:6402:34d2:b0:61c:979a:e7a1 with SMTP id 4fb4d7f45d1cf-61c979ae911mr1432919a12.16.1756215624315; Tue, 26 Aug 2025 06:40:24 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <31931c62-b125-4b28-b2df-b8f3e741d2bd@rlwinm.de> <638395fe-688f-43ec-be67-a239cdaaa08b@rlwinm.de> In-Reply-To: <638395fe-688f-43ec-be67-a239cdaaa08b@rlwinm.de> From: Rick Macklem Date: Tue, 26 Aug 2025 06:40:09 -0700 X-Gm-Features: Ac12FXylhN6i3K9ddS5Umr3w9mbqPvkU_AA-MC6rI81Fk-107XSEq73ynBfGSoo Message-ID: Subject: Re: August 2025 stabilization week To: Jan Bramkamp Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cB81V6MYRz3KWT On Tue, Aug 26, 2025 at 6:08=E2=80=AFAM Jan Bramkamp wrot= e: > > > On 26.08.25 15:05, Jan Bramkamp wrote: > > On 26.08.25 06:25, Rick Macklem wrote: > >> On Mon, Aug 25, 2025 at 1:27=E2=80=AFPM Rick Macklem > >> wrote: > >>> On Mon, Aug 25, 2025 at 9:09=E2=80=AFAM Kyle Evans wrote: > >>>> CAUTION: This email originated from outside of the University of > >>>> Guelph. Do not click links or open attachments unless you recognize > >>>> the sender and know the content is safe. If in doubt, forward > >>>> suspicious emails to IThelp@uoguelph.ca. > >>>> > >>>> On 8/25/25 07:53, Gleb Smirnoff wrote: > >>>>> Hi, > >>>>> > >>>>> On Mon, Aug 25, 2025 at 01:00:07AM -0700, Gleb Smirnoff wrote: > >>>>> T> This is an automated email to inform you that the August 2025 > >>>>> stabilization week > >>>>> T> started with FreeBSD/main at main-n279838-6c45a5dad0a0, which > >>>>> was tagged as > >>>>> T> main-stabweek-2025-Aug. > >>>>> > >>>>> This stabilization cycle is expected to be more bumpy than usually. > >>>>> > >>>>> 1) We got major upgrade - OpenSSL 3.5.1. One known issue is that > >>>>> the legacy > >>>>> provider is broken. > >>> I believe that KTLS support isn't yet enabled for it? > >>> (If so, NFS over TLS wo't work.) > >>> > >>>>> 2) The default Kerberos now is MIT. We have already checked that a > >>>>> Kerberized > >>>>> NFS client can migrate from Heimdal to MIT. We did not check > >>>>> Kerberized NFS > >>>>> server, but should be fine. > >>> I tested the server a couple of days ago and it was fine. > >>> > >>>> There is no yet an official way to migrate kdc > >>>>> from Heimdal to MIT. > >>> Yea. One possibility is to install Heimdal-7.8 from ports/packages > >>> and then > >>> use it to dump the KDC's database in MIT format. (Although Cy seemed = to > >>> find it didn't work, doing this with the "--decrypt" option might > >>> retain the > >>> passwords.) > >>> > >>> I'll give this a try and report back if it worked for me. > >> Well, I'm not having any luck. > >> Every time I try and use Heimdal-7.8 to load the database from > >> Heimdal-1.5.2, > >> "kadmin -l" throws this error and exits. > >> > >> kadmin: rc4 8: EVP_CipherInit_ex einit > >> > >> I need the Heimdal-7.8 kadmin to work to try and convert the database = to > >> MIT format. > >> > >> So, does anyone know the trick to fixing this? rick > > > > This looks very similar to a problem I had when upgrading to the first > > FreeBSD release using OpenSSL 3.x. > > > > In that case the issues was that the cryptographically broken old RC4 > > ciphersuite is no longer supported at all. > > > > In Heimdal you could disable it in the configuration and so it > > wouldn't even probe for the removed cipher. > > > > > Sorry I forgot to include the relevant /etc/krb5.conf lines: > > [libdefaults] > > default_keys =3D aes256-cts-hmac-sha1-96:pw-salt > default_etypes =3D aes256-cts-hmac-sha1-96 > > default_etypes_des =3D > > [kadmin] > default_keys =3D aes256-cts-hmac-sha1-96:pw-salt > > Thanks for the suggestion, but adding the above to /etc/krb5.conf didn't help (I had tried a couple of variants of the above already). I think I'll try a FreeBSD-13 next. Thanks, rick From nobody Tue Aug 26 15:13:26 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBB5912SDz65hy4 for ; Tue, 26 Aug 2025 15:13:49 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBB5800BSz3Xjk; Tue, 26 Aug 2025 15:13:47 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=Oq1tfN3z; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-61a8c134609so7188872a12.3; Tue, 26 Aug 2025 08:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756221222; x=1756826022; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=aHawaz4q0r7t3jd+/KHWqUjAP5gsUjllF7GIxbRAUWU=; b=Oq1tfN3z3ElLnjt2Fqndq2SmxhoA4YQ9FSx+nZx3uC6ejIAlieFEGSf3g25gspGU5J 5mFK8BhfwDCxbTIqJdK/J9lfBq5OwwwZacFpZFgPDSEbG70IxWQ5W2WFt8F8QhlO0gKt +nbCnEbLa1t1sQ+iFTlfSls9FTLKAHhnINZFJWWoWSK3rX/OCpNR9wJQ4vCFKekzukzr YKuWa3jeclm4uvisk1qbm9mYkPKqjTbLLann8XhExK7T+mF71dY9XitB6h04QwtiSVYF 7X/Tc0nztrHDYbhCKWBlbmEIMZ/hLc2VT8d9/gWw3zLQYv1wLcRN6/i6iz2KxEmBjw0u YD/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756221222; x=1756826022; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=aHawaz4q0r7t3jd+/KHWqUjAP5gsUjllF7GIxbRAUWU=; b=ShugRM486dTEfiBXhODRWcp4mT8H7TkgITzVeuEjl1rOiky+/dgllYfWumqE8yWlO3 j4Y78N4TbFKncjzHDULKHFO/KFs5cgC7VpZjHPDIA0YgI3O/bbB1VuznVqOr59KULoX4 jFyAaPdRbQFCyAX+7oPBwMuTr5BK5ARyXtWR3YippErLa6DLFxu5J6W75gvrWsWUax+H r4LYHB5AnNwq9eLQsVeCGzVLmap3Y8F8Donm1OanaOSeaDw9i90S85+PKwM74A+g6Mig Zt5NQhEhMpeMrOmFNotH4F+M/BU7tP0QMtWL+yupCr3dVscQMZ8cZ51lUbpHhIUdABgk ykGA== X-Forwarded-Encrypted: i=1; AJvYcCU/HbpfJCOn1EyWAAsz7U8rZnbat9z8X/cF3cCYPkPpKpWGC1p+wRCqjcZJoYS6dAYnI4aI/iZLXp0m6vHCdx0=@freebsd.org, AJvYcCVHe1ixKxB1fAvFzaOTH8vBD4J16peLj1tUm1iOJZYoUGiek09oo6nhia/1QGGDvHe5HN72Escaaw==@freebsd.org, AJvYcCXT+RC89DqXPEi2JdOq+l5jsWbcXEu6qeYONHNjV6xB5GPmZIXM0ZrNwyOuk7DLnFI/SBaMcJMz9oGtlA+APGQ=@freebsd.org X-Gm-Message-State: AOJu0Yw0QN+X0UuiIPKxn4Fa4sWAZjHbxvtyWOlzCMizCmC8dY1sbe0I SlbC20f5XP8n5zwbEi7rxs2KhKHit9CLZHpmfpcyh5Q5t3RJcG4YwNbz3Pm3IRhvGQWUxkRoXuW GCTj42uSjNtOxHWOzhglQWR7M82mcSQ== X-Gm-Gg: ASbGnctykRQcsMF0OfUkib43aR4KQr/261TIxleEwSgM5WKKRA4sXi0JeedamQS9BbA B1vRzxWJNkcTY6ii/E6qhTx+iXSrqWqeAtYa0WqLfDuA+CxeeXRkcSUWGWtCyPu6C24ORyVpNb6 cVQ1LiJX0yYQSPBwHUOn6sqPDQiwDECbPWW6M3PWgfWRUjv8AhoBBtf5hT+yNV5XqfT59nt72vF jWq1NmJTE7emtHkdoEgAgdt3+daXDUXfXrFop0= X-Google-Smtp-Source: AGHT+IFU8CzQ4mzLA3F0U0iNq6CtXiIgSks1ZjJks3Gv+Rq+jgq3/RwWhydkk7LQI151GelClhp7C022+RTwBB25QQE= X-Received: by 2002:a05:6402:5189:b0:61c:5379:4265 with SMTP id 4fb4d7f45d1cf-61c53794504mr6731765a12.1.1756221221313; Tue, 26 Aug 2025 08:13:41 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Tue, 26 Aug 2025 08:13:26 -0700 X-Gm-Features: Ac12FXz-9Frl93GCaqE6FzftVMRRQTT9udKz_yLGjDMU9iDX8CEokE6OKZmO1rU Message-ID: Subject: Re: August 2025 stabilization week To: Alexander Leidinger Cc: Kyle Evans , Gleb Smirnoff , freebsd-current@freebsd.org, src-committers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.966]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4cBB5800BSz3Xjk On Tue, Aug 26, 2025 at 6:28=E2=80=AFAM Rick Macklem wrote: > > On Tue, Aug 26, 2025 at 2:34=E2=80=AFAM Alexander Leidinger > wrote: > > > > Am 2025-08-26 06:25, schrieb Rick Macklem: > > > On Mon, Aug 25, 2025 at 1:27=E2=80=AFPM Rick Macklem > > > wrote: > > >> > > >> On Mon, Aug 25, 2025 at 9:09=E2=80=AFAM Kyle Evans wrote: > > > > >> > There is no yet an official way to migrate kdc > > >> > > from Heimdal to MIT. > > >> Yea. One possibility is to install Heimdal-7.8 from ports/packages a= nd > > >> then > > >> use it to dump the KDC's database in MIT format. (Although Cy seemed > > >> to > > >> find it didn't work, doing this with the "--decrypt" option might > > >> retain the > > >> passwords.) > > >> > > >> I'll give this a try and report back if it worked for me. > > > Well, I'm not having any luck. > > > Every time I try and use Heimdal-7.8 to load the database from > > > Heimdal-1.5.2, > > > "kadmin -l" throws this error and exits. > > > > > > kadmin: rc4 8: EVP_CipherInit_ex einit > > > > > > I need the Heimdal-7.8 kadmin to work to try and convert the database > > > to > > > MIT format. > > > > > > So, does anyone know the trick to fixing this? rick > > > > I migrated a while ago... don't remember if this year or last year. And > > I don't have my notes about this anymore. But I exported everything fro= m > > base-heimdal and imported into MIT. > > A quick google gave mit this: > > https://serverfault.com/questions/1000332/migrating-from-heimdal-to-mit= -kerberos > > This can be done with the base-heimdal + ports-heimdal + mit-krb. > Yes. That was basically what I am trying to do. However, I cannot get > the ports-heimdal > to work, due to that rc4 related problem. (I've tried 15 and 14. Maybe > I'll try 13?) Ok. If you install FreeBSD-13.5 and then "pkg install heimdal", you get a working Heimdal-7.8 in ports. Now, I have another challenge. Fixing the master passwords. I'll work on it later to-day. rick > > Because there are several principals created when the MIT database is cre= ated, > I think the last step might need "-update" ("kdb5_util load -update mit.d= ump"). > > rick > > > > > Bye, > > Alexander. > > > > -- > > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772B= F > > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772B= F From nobody Tue Aug 26 15:31:13 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBBTJ5gCVz65k6J for ; Tue, 26 Aug 2025 15:31:16 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBBTJ4mj3z3YnS; Tue, 26 Aug 2025 15:31:16 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756222276; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bKAdAtaBVq7hNDjKLCtTu9wKMo6b8CV7NfgRTS8Hlnk=; b=pFcqqGF6g2+q3a+hHMcSyt6J40mpZ715PFqluBBu0VHSvheYtH4aZgthl610SAogX5Z/T+ yfLvPuVkR9uGdybjSjZD1a7WoPVAK3z1QxW7vfQagsyCUcLzwv++LAXeevkRoSZBORPrc3 MP2Y9XOE6RLlj5VU+MUzB3qTuGi466MyIpbnE+Qh7270Zm7wU9Tzfpt4H/Ol7HmwihFUT5 WVxHBPrOToALuX6zTzBPrwPmUkS42APkcpMJ9gP0FBhzk+V0tvYFzZ5nBQ/8oCLUCktG0A ZUSNCKVlbFqZxnRs/GD2F86C/PO920C1YjSDWZEprrlWuo4EWdeQTMl9Y/lqMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756222276; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bKAdAtaBVq7hNDjKLCtTu9wKMo6b8CV7NfgRTS8Hlnk=; b=ow9VbXcJZgTK8WYDzwDHCxP5dysslXPWo7RmOOCMaGJYNiKLFNhXEUQ7Zz710+RAk9PSVj GQHSPFSl0TtXEBWDOQeDYCfCqzP1/+/JzTkajpbmxtURcemQ/OrX7Vxg0/erh+HiDQFfMp jEprxzgJMO+Z2EywOTFR+mRT81jGnwOETsUVq0gmN2Md/DJe9EHQOuPqDtnkuu8DTlmujb 5VzXkTd1K2Vkt75PKXxFqKtfXmF5dH0cCTKbez0IvFq/Hy6jN4jtJN1E5+yFqulErkc3HE Ud7U6THW/1ZVtHx1kVA5q0Q3BdOsTYe0WqvcqEyBQp/Ixa5Mmmx5Lf22o4626A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756222276; a=rsa-sha256; cv=none; b=voEZSjR2Owrdn6AD7nbhAZUXXPvdQzQJtfEE+1c9Bji89ofZ8mq94MxNCOi3zWhWcWFv1A RZmx5Hj7OuH+Ebygdl0Hyreq9AjuY9ixblei7oGC9v5irUAWxBrr6vkhMCoGNbENmfarrU aopMReQKlu5nRYAGtkjNWxForCypJFjDcaqlYpSkPVWPa+4XAexmYyUFA3lqO0HgNrzyGZ MYKzXwrE4YnBnjD6JXuD0TKtU8LGhVeBrBzWFlcumYF4yReo3TwARbmT7NqddzXpoHmNsJ lxAFnsusBFnNKmt7iBve87+q8+Mbqqb454Z5AD2aPuUTRPOEt8oBUigUd6TRGg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cBBTJ0007znfJ; Tue, 26 Aug 2025 15:31:15 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Tue, 26 Aug 2025 08:31:13 -0700 From: Gleb Smirnoff To: Rick Macklem Cc: Alexander Leidinger , Kyle Evans , freebsd-current@freebsd.org, src-committers@freebsd.org Subject: heimdal -> MIT kdc migration Was: August 2025 stabilization week Message-ID: References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem wrote: R> Ok. If you install FreeBSD-13.5 and then "pkg install heimdal", you get a R> working Heimdal-7.8 in ports. R> R> Now, I have another challenge. Fixing the master passwords. R> I'll work on it later to-day. I have applied two commits from Heimdal from 2012 that add 'kadmin dump -f MIT' feature to our base heimdal and polished them to compile. So far it doesn't work yet, either create an empty dump or create a core dump, instead of database dump :) I'll see how difficult it is going to further resolve that to a working condition. If I succeed, then having 'dump -f MIT' in base without any ports would be the best solution. Can also be merged to FreeBSD 14.4. -- Gleb Smirnoff From nobody Tue Aug 26 16:35:39 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBCvf1X4Qz65nrB for ; Tue, 26 Aug 2025 16:35:42 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBCvf0DN6z3kgy; Tue, 26 Aug 2025 16:35:42 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756226142; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/Sc2DZZ2Pcd1mfjOTtacuWBRwfAx/yQ9R5LS5Sjq3Cg=; b=Y2so3nZ2yw85hi5BFVf9EHEJmy2MQZ8BOCHHvRuzPVZKQ0K5ZbfG8lJd8Ecui55WYLCsdg gfBDPnno3Q2iR2n0n/7kqm7lKxs5nQehQyRRpSV10OjZLK/JGyRxeKYjRont1Qf7iysXyE S/KeXf3VAzS6F8hyecAPJ0giNhhI6tbV4J38p++LA4jW316UKtjQzP1m+OeURaNzGEXx8g 2IQ6PEsj6aWPnIroP6/zG2cpsGHopypQ1S0LPKpHNcHfdjZu9Se72zCYmfI8vi5phECnVO A60E9mDNAFrHrdo/jEA7Dr59W4Va/Hw4qluI6uR4rfMPAShVKQ0vAPIXbdeXCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756226142; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/Sc2DZZ2Pcd1mfjOTtacuWBRwfAx/yQ9R5LS5Sjq3Cg=; b=cROiaGRDQ3qNK2mdmjCHn+ZVcSBdN+mjWnM7jIaERIvbS2u+CZsDAD8gzi/m5xYLWx3cN3 mEHjWKPHGDTcoiQrKXTe3uQfWySF3nKkjV1i2HWoiWy8XRbknAmJXCWK3KBugtfshO2Ltm ctcgzbh2Tkk6nzyu58SVinVz8zUi3UiOpGfxyJNAbrpmYELvYKa9QqTTWEoqm9vxztc7fo GM+sN4qKE65KGoZhtL6oCp2bxo2doKd/+JVqQGVCZT2OpBqy6J5X3qjP73DkZLoDoZaCNM 4LVW9CXsfw0a+UbuN02rmsoBiBM0lnY0Qw2muSgdrwRbBAGcDCCHcYEpYz2jeg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756226142; a=rsa-sha256; cv=none; b=Kf9dgimUCc22geejTtajK4OzsCtCoawP0vBOO2c9whzOeAJ8LqohGU4oKBNyIHq3dEZVTT 90ypkkBADakwsjcvnnTlBXDGi5ndDsvbZBnjCcgWjEmUSNxvczMeCxFbSJqDvv1bcdD0IX bUka9aOShGHJ9XNO3PShkTVRXKpsueSWGTngDgdXctWewdhMwIjaX9nz6iIP1XVoPrQc2w +4qnIEuF14H5LsHG5VejcPRhgnSC4Pb/x4D7FZ0RqT58P7Q/1FJNx4AdMv59D0YALBdY7w 71a+yKinGYHsiPkBdB4rqLf0I6CHxM2Fh2bEXkvXSn059xN9dEYIB0O3JEQEQw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cBCvd3ftJzqYS; Tue, 26 Aug 2025 16:35:41 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Tue, 26 Aug 2025 09:35:39 -0700 From: Gleb Smirnoff To: Rick Macklem , Cy Schubert Cc: freebsd-current@freebsd.org Subject: Re: heimdal -> MIT kdc migration Message-ID: References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff wrote: T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem wrote: T> R> Ok. If you install FreeBSD-13.5 and then "pkg install heimdal", you get a T> R> working Heimdal-7.8 in ports. T> R> T> R> Now, I have another challenge. Fixing the master passwords. T> R> I'll work on it later to-day. T> T> I have applied two commits from Heimdal from 2012 that add 'kadmin dump -f MIT' T> feature to our base heimdal and polished them to compile. So far it doesn't T> work yet, either create an empty dump or create a core dump, instead of T> database dump :) I'll see how difficult it is going to further resolve that to T> a working condition. If I succeed, then having 'dump -f MIT' in base without T> any ports would be the best solution. Can also be merged to FreeBSD 14.4. Good news. In the above paragraph I was testing my change incorrectly - threw the new binary on a system running unpatched libraries. When run correctly, it successfully produced something that looks like a correct dump in MIT format. I haven't yet tried to load it into MIT kdc yet, though. I will finalize the branch promptly and share it. The above experience also indicated that I need to do a library version bump. -- Gleb Smirnoff From nobody Tue Aug 26 16:43:12 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBD4L535Nz65p3b for ; Tue, 26 Aug 2025 16:43:14 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBD4L4McMz3p9h; Tue, 26 Aug 2025 16:43:14 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756226594; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wdS9Oj2UW25ZVmOl/cY+L40fnbxsHojvBDqoi4dWsf4=; b=DhfYdrtDg2cjxTt58pj6JPBy7bA/fsKk0DPzRC0FEtivoGrxZ44gDqEhLqrzlfDwtiWvRI iWAqXUTizFlXGlCZAffgysV6A+bL8CBPQ8VASGFv0EXRSzruN7sSmt8XAZIGeZnXFppyiG Yw3xWnUSmxHsPr4wKXoLrnK8CYFxQ5af1lcCMOpyN6d8lUKxbc5Ki9dYWZy4ohoUTqnagb IhUtLfcRomuTbmfpUn5yLIaNngH6zysLhW5qrP0PNr1pA/7Zxxvxwait/rT7+IdD4QxNQM 4ZjioQ1S/D23CQwSBWSlwezm2+lB8dVRT2oSVhiaWiyBlAjZP3HdNVa4EuAnPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756226594; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wdS9Oj2UW25ZVmOl/cY+L40fnbxsHojvBDqoi4dWsf4=; b=lbrUAvfB58+2ykBL7KPy1ntvvJzWtvZGvuBTmFVaKTpEGGddGqv188J1Z4gi/Ak7BzN8X3 3xWrI/WdGGgepe2DcTfN3M7InrTkNgLncfkwSLiHCQgTZllpB6PHnFcCXq84NBs61J5iwM DBxZboF5mLLbBEQQcHcxB41FNIT+ILxZ8NNW99rlhqzrEYpiz7GB9Av+IYxUryjmJ2fdQx pev3Qd0lSuBPFfaMPRNeR7htEN0Ej841DpZYwiJm6eUUnCqEgM92NEkhOEPdvVhMx5vbbN dgw69KQI8QBAupygUJM5i9FIqUTiWLjljDxoca1JaHSCI3QueSs0AkPtg6x9gw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756226594; a=rsa-sha256; cv=none; b=B6emeFt5EQR/Bsud1vktpXfIS055nQzGuXcA4CG/lNTq76ZbaxJL3Rcv/9QVdVwZ8bsAuk o7Ls9rzr9BVg9n1hZOAlSFCSzkUIGbKTBeBDqHW04yLeCdFhFG63MajzubPgLlZp1cXcSb xHhCH4s1wmAB6eRk1IoP4vdGgNsc5O0bNwqhTku9eHuIdMMmQU95hYmnEerl/B8+BLDQJG wVqurEMX3hTUB2gtET08Kp1C0cdQ1IAY7gKwU8+lLufCTpFbA6500w4ETl3XMt5UtIZKC2 ULurelKtiEtM00Slx4TUpSwf8UIeX1ZuBN9lawQkvFYDT2OBV88aOWz2jmZp1g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cBD4L0zc0zqpk; Tue, 26 Aug 2025 16:43:14 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Tue, 26 Aug 2025 09:43:12 -0700 From: Gleb Smirnoff To: Rick Macklem , Cy Schubert Cc: freebsd-current@freebsd.org Subject: Re: heimdal -> MIT kdc migration Message-ID: References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Aug 26, 2025 at 09:35:39AM -0700, Gleb Smirnoff wrote: T> On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff wrote: T> T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem wrote: T> T> R> Ok. If you install FreeBSD-13.5 and then "pkg install heimdal", you get a T> T> R> working Heimdal-7.8 in ports. T> T> R> T> T> R> Now, I have another challenge. Fixing the master passwords. T> T> R> I'll work on it later to-day. T> T> T> T> I have applied two commits from Heimdal from 2012 that add 'kadmin dump -f MIT' T> T> feature to our base heimdal and polished them to compile. So far it doesn't T> T> work yet, either create an empty dump or create a core dump, instead of T> T> database dump :) I'll see how difficult it is going to further resolve that to T> T> a working condition. If I succeed, then having 'dump -f MIT' in base without T> T> any ports would be the best solution. Can also be merged to FreeBSD 14.4. T> T> Good news. In the above paragraph I was testing my change incorrectly - threw T> the new binary on a system running unpatched libraries. When run correctly, T> it successfully produced something that looks like a correct dump in MIT format. T> I haven't yet tried to load it into MIT kdc yet, though. Bad news: while kadmin -f MIT works, the library change broke kdc :) Looks like more work is needed here. I will probably get back to this only next week. The branch as is shared here: https://github.com/glebius/FreeBSD/tree/kadmin-dump-MIT -- Gleb Smirnoff From nobody Tue Aug 26 16:56:10 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBDMd1dlpz65q4Q for ; Tue, 26 Aug 2025 16:56:29 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBDMc6GF0z3shW; Tue, 26 Aug 2025 16:56:28 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-61c38da68ddso7727318a12.2; Tue, 26 Aug 2025 09:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756227385; x=1756832185; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=kCleWKnB2ibxGMj2jaBnozgMNrBNgRNT/kJJii7GHUY=; b=GEzA6TvCTywIR+gUYoTlo3cN/dlOuXjrG5aaMuOJenih3zPD9OtHikCe3sqWEerE4a DfUD/36XEad6Yf3JUiZEPO4CEvEE8rSRCeYeUVocmlSZojnNGUhpZthpw+owmDsLDF3E zwtqpbps2ok7t1sd59wqhB6yF/5N4hRLBQjmpWPShhEJc8VhU0foE/U0CpCb47U6e8zS PDK3fccfRwQfB6DFL+70cC9lltH8t7BCV2xqVcZBOR895/EXhg10SxLCwJd8AYWW+nLK H00bQXNU+LY1pmNnQIKL4Sf08y7VFY+Bc5bc5mFXk9cB0LWvHI4gZ/Ha2BSn8GAkEYCy q9vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756227385; x=1756832185; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kCleWKnB2ibxGMj2jaBnozgMNrBNgRNT/kJJii7GHUY=; b=COdfmhe31eYm/onwvy/iUZH9Cu2TL/fpogUS62P3khdHFE4284wlQTQrETzLXyRPDO +cZRxPakbIgl21FgEW47zL/TX/f56m35ALA6djGWZ4M8992EFnSsecX1frQQgPBPoTd/ dTmzLShluCBFT+FelDDNZwI3oGe7t4hJlMvNF18atOh1c2Ui9Q9V6JgGkKlS8gql/ScU fVhZEw3JxjeXIN2pmBl4IkufVxZ0k4DMbwZ6Ws3vYYvs+2ilr8nwV6KqGlnGMScHrmZf 0MOiY1ZY5eLIYn/sCCqAkgc4lr6+GnTb+r05xmTFaYyBN30HgMI8WfNyoI+W8YOBMqKx YwSQ== X-Forwarded-Encrypted: i=1; AJvYcCU3efgFRlSxZLKQdnThuVuTbUrMNWRc9N1q5DBufx8SrxyQqjbJlf2oe7DQUX7/taEhWe3UPRxJ@freebsd.org, AJvYcCVsORoYzBNm+v/8Hy87HcjbjsmYjy1q2jWwjdAxklBWyxewHTREiS+2mIkEcpALGeuWaAd4/nBICfTGzmGhLvU=@freebsd.org, AJvYcCW5/CcQEviBxbs0yg8EL0IyUTgVdeTYrcyWQ8Pd3pUQflujpODhelmohLzzq0UrpDWlOJm7g49FY1aziE4sfCw=@freebsd.org X-Gm-Message-State: AOJu0Yy1jc6bLW9OSP2rYuOBkSEsyP56MUCAyKmdW69/BwP1NpoHuzH2 W/HxkCf2qqZuEr+38Ec0/UsJ6o5J5RL1nmv6zrfKyrzz4rrl1d+nRrlIM9N56eigbhdEBnvk+YR CrlTg9XUvICcXzuaTL7Y7ukVgfYaNdOgq X-Gm-Gg: ASbGncvChDG9rerZE5rX8vpX2U516g9C4IRNzR3h3S+tYJf7bgA7FETM51KS8iJ17F0 DzhnKz9gZu3BsG/A/FdBHQj9aLklM4v2ZeDfYfJCUuX5ZmqROj0YiZ7SgADGa0xU5JpPZY5aoBo 3TOu9HCTFIfcaFZ0ywxDUBVrOr/DIHC0kpsA2klaFhc2BePpm9jCIyqtn9iZxILLMsIAbof2cwV rccaz5b4Mc2zTgMldrQ9UAx1yvn4xDPPlUz1Xc= X-Google-Smtp-Source: AGHT+IHgo4THfsnIyYaaJ3zDYJNEn1/pVVLIUc+4bx93qcjA2EHxaUqifuqIpUFsQ2o6vTkRlwxEodfGuhlhkRg5ejY= X-Received: by 2002:a05:6402:d0d:b0:61c:73f3:aa93 with SMTP id 4fb4d7f45d1cf-61c73f3af0cmr4990806a12.7.1756227384888; Tue, 26 Aug 2025 09:56:24 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Tue, 26 Aug 2025 09:56:10 -0700 X-Gm-Features: Ac12FXwzzVTYGAwI_AGiu3TrDNAbR5wjdXdBqd_B-QmJWTBoejDf3EUevciH0rE Message-ID: Subject: Re: heimdal -> MIT kdc migration Was: August 2025 stabilization week To: Gleb Smirnoff Cc: Alexander Leidinger , Kyle Evans , freebsd-current@freebsd.org, src-committers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cBDMc6GF0z3shW On Tue, Aug 26, 2025 at 8:31=E2=80=AFAM Gleb Smirnoff = wrote: > > On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem wrote: > R> Ok. If you install FreeBSD-13.5 and then "pkg install heimdal", you ge= t a > R> working Heimdal-7.8 in ports. > R> > R> Now, I have another challenge. Fixing the master passwords. > R> I'll work on it later to-day. Ok, I finally got the database to move over, (using Heimdal-7.8) but the passwords didn't work. kinit would complain that the password was wrong before it even prompted for the password. Doing a change_password in kadmin.local made it work, but changing everyone's password would be a pain. rick > > I have applied two commits from Heimdal from 2012 that add 'kadmin dump -= f MIT' > feature to our base heimdal and polished them to compile. So far it does= n't > work yet, either create an empty dump or create a core dump, instead of > database dump :) I'll see how difficult it is going to further resolve th= at to > a working condition. If I succeed, then having 'dump -f MIT' in base with= out > any ports would be the best solution. Can also be merged to FreeBSD 14.4= . > > -- > Gleb Smirnoff From nobody Tue Aug 26 17:21:16 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBDwf01tXz65rd6 for ; Tue, 26 Aug 2025 17:21:38 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBDwd33Rzz3xw9; Tue, 26 Aug 2025 17:21:37 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-61c4f73cf20so5813321a12.0; Tue, 26 Aug 2025 10:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756228891; x=1756833691; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=m2DOcNKI5j+ZBfqAIjwICepTOkd2gQG+wbVSO9ZYxh0=; b=AGmoI+sDBs2IDLS6Dw8UbvuAq+/1/W45B0UYAJ77qtEDDyIoZ1JWD9Oc7HmynAHc3n nV1OaxceXEXoXa3zbNrunHJ/bkZz/viI6pte/SfM26PYmwUCUY5PXNugF3lN0U/LSPgh LPYU8JMpFfcMPPItccLx1ZHIzdxG/eYHqn48vDtUq3LkDXKTpI2dWFqjF4bSf0aRJowA iPh98VCYPtclryduztKyiBfZvbFe3mG0IOIqH9lKQphBnFPPEIwp2CX2/fblJ6wLZ54+ z8829ch10Orf5DwM0fBPx0SdJ4/HoMvdi7ItAq6Nc/JAxGN8NdNogh7m8MnIGm33MFiW dfng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756228891; x=1756833691; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=m2DOcNKI5j+ZBfqAIjwICepTOkd2gQG+wbVSO9ZYxh0=; b=LEo3lQzHFElkWDGBs5gHbMOldyMDV6FI8l1MxsMqruCtzDMxdlT+aCNc52PZRHMs8m z16IZjH//RctUlrmIfMmYMeoKDr1VqCdcCahF2HYr+cSmba9XjqyKNeZNaiObm5dnUOo Hp19CSdJ5CG3IF6OrRQJGM4nZoYry5+IlyoaTIIxPRqbFyp3dXdc75N9xvEKGZWaVTXV GY9XBCTH35jP6uUKAtYJ1DdDYm04QaYVzJA1yDCiZcMACbUGNFkGmcSbRQXTti7xmvcV ONHemVrLujo/t0QbCmemPRptbuPi+ak3KB0XqKtNl1ruH4JYDLmprXtcrathnEBxSjqH fHdQ== X-Forwarded-Encrypted: i=1; AJvYcCWrzl6/yZhH+4PNsbN8uaqHSp6KaSRjOse1p1RI4cXoDnNK53eu55Dh/A8guUqZI2IN5Utt13cbE9uj0yRKM6s=@freebsd.org X-Gm-Message-State: AOJu0YxlMGmTzoUFMydElQ756LngyXb3yUQuPIw1/L4c0qc0JXKP1bI1 yMhd2ihFQR0N5VXUz4RCZZQiTooa729gNc0OdC4oE/vSx8xeZOQsW7KQ215HUe+8YPazdLLm+Wd NZn81ZMSCLU8/UYC6GlQGdoHOpcp02a+K X-Gm-Gg: ASbGncufeeWzRlnW735exd4Ztx0C5bz4jdTvdAErTrK2Vipgbh5dY8PZa2PRyMdOsD2 Siki7OYvYpBb+n1bKq8aoCct9Ke/G5IlxoWO8qR8JGRr08AmhJZqdktGT5Xx5dMaw26+Epj9kJK Hd1REDWpDhKdisNPRuW2lJBwQ/yp++CWl5tsJ0cd/WY3rbM3F5VtjiKdOKuHqIqIVIS4Gk3U5+V SZ2YIAqY6SCZa9jdlIcLRqwyrh+nWjqC85UBpcN7CZX+3A+BrQfoTGMZbgr X-Google-Smtp-Source: AGHT+IGYX1vzzrWrAoiJAKQV+fXOw9IJNtpJeLkz+obUkqifcX5lAIg8bO4q4IDfJbh/ebqSN/bJMKTY0GJekA2L7Zo= X-Received: by 2002:a05:6402:35c3:b0:61c:61bb:e836 with SMTP id 4fb4d7f45d1cf-61c61bbec87mr6574001a12.11.1756228890217; Tue, 26 Aug 2025 10:21:30 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Tue, 26 Aug 2025 10:21:16 -0700 X-Gm-Features: Ac12FXyJZw0w_mlUeJ3xzryqSrzM_Rf9RqP6dK2qnS9llHOpLhD8FY6r0BRZZLw Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Gleb Smirnoff Cc: Cy Schubert , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cBDwd33Rzz3xw9 On Tue, Aug 26, 2025 at 9:35=E2=80=AFAM Gleb Smirnoff = wrote: > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff wrote: > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem wrote: > T> R> Ok. If you install FreeBSD-13.5 and then "pkg install heimdal", you= get a > T> R> working Heimdal-7.8 in ports. > T> R> > T> R> Now, I have another challenge. Fixing the master passwords. > T> R> I'll work on it later to-day. > T> > T> I have applied two commits from Heimdal from 2012 that add 'kadmin dum= p -f MIT' > T> feature to our base heimdal and polished them to compile. So far it d= oesn't > T> work yet, either create an empty dump or create a core dump, instead o= f > T> database dump :) I'll see how difficult it is going to further resolve= that to > T> a working condition. If I succeed, then having 'dump -f MIT' in base w= ithout > T> any ports would be the best solution. Can also be merged to FreeBSD 1= 4.4. > > Good news. In the above paragraph I was testing my change incorrectly - = threw > the new binary on a system running unpatched libraries. When run correct= ly, > it successfully produced something that looks like a correct dump in MIT = format. > I haven't yet tried to load it into MIT kdc yet, though. You might have better luck than me, but if I just loaded it, "kadmin.local" wouldn't work. To get it loaded, I had to: - edit the mit.dump and remove the entries for K/M, kadmin/admin, kadmin/changepw and krbtgt/REALM. Then I... # kdb5_util create -s and # kdb5_util load -update mit.dump -after that, kadmin.local would find the prinicipals, but a "kinit" wouldn't work until I did a "change_password" on it. --> The MIT kinit would fail before prompting for a password, so there was something sketchy about the TGT. (kvno or ??) I'll probably piss around with it again tomorrow, rick ps: I'm using the Heimdal-7.8 I installed in 13.5. Good luck with patching the older one. As you might have noticed, there are now newer versions of the MIT dump format. Hopefully that isn't needed to get the passwords to work? > > I will finalize the branch promptly and share it. The above experience a= lso > indicated that I need to do a library version bump. > > -- > Gleb Smirnoff From nobody Tue Aug 26 17:32:42 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBF9T20Hkz65sWt for ; Tue, 26 Aug 2025 17:32:45 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBF9T0vRvz42BK; Tue, 26 Aug 2025 17:32:45 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756229565; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=o7VVSQkkohhYf56VAcjzXAmQCkbXv2t7OOJXglGAPb8=; b=G6dX437/WXtn4H+R9muNGjMJzx1ko2BwVXVfqtShrSiizf/iLQoLCwyI3VYxVg5IZT5a8F T9juHgCGiorAkHnM4dbIndycbWzIInCfnQV/L2ypT3rLsXoUOdTLZPIybJPMWB5CkjwC0Q +yz/KcSJHER/Udr1yUIRGv+vRVRUphFTHe7GSfLYN8Z9Tf1VJiDJl1yYI9KP/nCcbMWv2N q5q8tCghvRwrgKQ2Jywqt8Zc/SG+KHDCa2Z755zM2bwyRKkrrBqazWkhxYGQ2WqpWT04GD Q4CHwpOZlSirmT9MKLB5PKVHuIOpJJN5HnOAZAUn/FDTPsdkbP/G377r4ta2ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756229565; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=o7VVSQkkohhYf56VAcjzXAmQCkbXv2t7OOJXglGAPb8=; b=DUjUDRyK4hGi+IGgzjJ879BPYzFcy4OmvqIlhL7GoUfFdKYMo8qsrUBKDLrNp/thfYKuHy FFrO9jcTaRd/0I6bIvP/FX9coCwHiMVyYXEDLuL5t3km7GJAMTw74mp8HUbte/HHMbHdgm BZv32Ek5CVnqd3jv3tbj1a3cPMweRsHa7Ihqbk+P/ySCgdwXQ4LfWYnGUdV0HwL50WV4kj iaDKnA+Khs7j1GyhI9zat/ZkkTdOk6nPnwfe7pbW4+QbOwDOtAobdPLKk/FoRafN5sZWZE IBb6hPLoPcqZirWb3WWr1deH9a+aUkSGHZkvG6UgL3wwx05lwW6kF1gogZqEvQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756229565; a=rsa-sha256; cv=none; b=U7+5QDOQN4LCNoLYwlmyYEPeat9a+mj0k6V0jo5mFdIbSulW5N4KVheseeUo5jHW1lTsy1 xPeRM6+M552vzihqMewQthos1xeDcq5W/KtHJagKTGEt+MfBLXlLeTzk2PFilk7vqqhkzn 3lsMADSyTlA8xzte1ObpXUba42I/LRl/wDPFuJemKk93MKa1FW9aZUSEnZFx8el9zN2Vp4 srjrC5bjZ+u27+KjA/8cu/M/zA+TwimkzxgBSDJ18lOU19vaJbs2UhIciuN4LR2UN1TIuU Zsi8HClHeBqBd6PaNLOSWPurJ9eQ2xHBhuFvwhLZTckMcGGL2VP/BsrJB5AHhA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cBF9S4jwPzs7Y; Tue, 26 Aug 2025 17:32:44 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Tue, 26 Aug 2025 10:32:42 -0700 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org, Olivier Cochard Subject: Re: August 2025 stabilization week Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="acFtwv53KbkMMDQq" Content-Disposition: inline In-Reply-To: --acFtwv53KbkMMDQq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 25, 2025 at 01:00:07AM -0700, Gleb Smirnoff wrote: T> This is an automated email to inform you that the August 2025 stabilizat= ion week T> started with FreeBSD/main at main-n279838-6c45a5dad0a0, which was tagged= as T> main-stabweek-2025-Aug. Tuesday update: - A personal desktop (nVidia) update went fine. Also went through 'delete-old-libs' and no COMPAT_FREEBSD14 in kernel, thus rebuild a lot of packages. - A small home router update went fine, kept old libraries to not rebuild packages. Kerberos clients were tested to migrate successfully, but some scripting needs to be adjusted, e.g. kinit(1) syntax is different. A Kerberos controller doesn't yet have a migration path. If updating a machine that runs kdc, you need to stick to old Heimdal. To achieve that you need WITHOUT_MITKRB5=3D"yes" in your /etc/src.conf. Some software may need configuration tweaks due to OpenSSL upgrade. If you got a non-default /etc/ssl/openssl.cnf, some deprecated options may also fail. The performance & stability A/B testing at Netflix just started and we expect to have results tomorrow. I will be AFK for the rest of the week, and thus passing responsibility for the stabweek on Olivier Cochard olivier@. He will update on the A/B test results, collect any success/failure reports and close the week. --=20 Gleb Smirnoff --acFtwv53KbkMMDQq Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQT+rgtjiRzq3LbQ3Nn+/1jAXQXMIgUCaK3vsgAKCRD+/1jAXQXM IrZIAP9CFVoileZ8F6Di+X/+MXeCHALaT3CPdBIb+hsdUzApJwD/aRYFvORLKhyw fPIV3JC6GYv07HPWMwHMiq3RjTKWWwI= =/6nb -----END PGP SIGNATURE----- --acFtwv53KbkMMDQq-- From nobody Tue Aug 26 18:21:25 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBGFh5gCMz65vy3 for ; Tue, 26 Aug 2025 18:21:28 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta004.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBGFh2McWz47TP; Tue, 26 Aug 2025 18:21:28 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=permerror reason="p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com" header.from=cschubert.com (policy=permerror); spf=pass (mx1.freebsd.org: domain of cy.schubert@cschubert.com designates 3.97.99.33 as permitted sender) smtp.mailfrom=cy.schubert@cschubert.com Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTPS id qvnkuPpxn5MqyqyIRu8pxA; Tue, 26 Aug 2025 18:21:27 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id qyIPuEalGl5eGqyIQuUsag; Tue, 26 Aug 2025 18:21:27 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=EO6l0EZC c=1 sm=1 tr=0 ts=68adfb27 a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=2OwXVqhp2XgA:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=YxBL1-UpAAAA:8 a=1NtM8UMEt4vgi-bA37oA:9 a=CjuIK1q_8ugA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy.cwsent.com [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 883EF109; Tue, 26 Aug 2025 11:21:25 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 820AD388; Tue, 26 Aug 2025 11:21:25 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Rick Macklem cc: Gleb Smirnoff , Alexander Leidinger , Kyle Evans , freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: heimdal -> MIT kdc migration Was: August 2025 stabilization week In-reply-to: References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> Comments: In-reply-to Rick Macklem message dated "Tue, 26 Aug 2025 09:56:10 -0700." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Aug 2025 11:21:25 -0700 Message-Id: <20250826182125.820AD388@slippy.cwsent.com> X-CMAE-Envelope: MS4xfFj792bIfnLxZ9QAtnxpYAX2CmfbzFGADhUMi8kExF+zrcpVbwhP2oLQ+t9VWbBdPtYu3FeoD+FTkdnPmG5FlAoD9nO0RMzgT8YWhVwg9BYhq7rc5OXG ce8VsmRPXRIocPQ1OMfrFF0NADjvVOpS0Kxsc0Z4kZB5+WRXjvPY9fmZoNCjMmTFKn2asdAYsJtAIF+ruUV2jcBB+gPyu+qqDUyLK/fnuZroRNAOudVHuxI5 Ix8SBzPEf1Egjs9c/S7etJacRB/bKV4454Is/6Yqpmq2lwdVz8RAOU+Y4eEEj2/xd/lkk55Kqp1LKmyLJCHuUQim542Fa5d0ICZF1wTyvTdmk7PuA1ZvNOYy tGKYCOBZrPSLFvkYkqShrl3J57XQdw== X-Spamd-Bar: - X-Spamd-Result: default: False [-1.79 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; MV_CASE(0.50)[]; RWL_MAILSPIKE_EXCELLENT(-0.40)[3.97.99.33:from]; R_SPF_ALLOW(-0.20)[+ip4:3.97.99.32/31]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.33:from]; MIME_GOOD(-0.10)[text/plain]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; DMARC_BAD_POLICY(0.00)[cschubert.com : p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; REPLYTO_EQ_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TAGGED_RCPT(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com] X-Rspamd-Queue-Id: 4cBGFh2McWz47TP In message , Rick Macklem writes: > On Tue, Aug 26, 2025 at 8:31=E2=80=AFAM Gleb Smirnoff = > wrote: > > > > On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem wrote: > > R> Ok. If you install FreeBSD-13.5 and then "pkg install heimdal", you ge= > t a > > R> working Heimdal-7.8 in ports. > > R> > > R> Now, I have another challenge. Fixing the master passwords. > > R> I'll work on it later to-day. > Ok, I finally got the database to move over, (using Heimdal-7.8) but > the passwords didn't work. > kinit would complain that the password was wrong before it even prompted > for the password. > > Doing a change_password in kadmin.local made it work, but changing > everyone's password would be a pain. My initial testing when I did my first migration has shown this is correct. The process I used was to export from our Hiemdal 1.5.2 and import into Heimdal 7.8.0 (using the port). Then reinstall using WITH_MITKRB5 or using the security/krb5 port. The database imported correctly I could see the principals but the passwords did not decrypt. This was also a problem when exporting from our Heimdal 1.5.2 and using a Heimdal 7.8.0 kdc, i.e. performing the first step of the migration and using the Heimdal port as a kdc. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e**(i*pi)+1=0 From nobody Tue Aug 26 20:05:23 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBJYf5lmGz662sg for ; Tue, 26 Aug 2025 20:05:26 +0000 (UTC) (envelope-from ross@bisd.ro) Received: from ada.kiz.li (ada.kiz.li [38.45.72.165]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBJYd6k36z4LM9 for ; Tue, 26 Aug 2025 20:05:25 +0000 (UTC) (envelope-from ross@bisd.ro) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=bisd.ro; spf=pass (mx1.freebsd.org: domain of ross@bisd.ro designates 38.45.72.165 as permitted sender) smtp.mailfrom=ross@bisd.ro Received: from [192.168.1.225] (syn-072-182-130-191.res.spectrum.com [72.182.130.191]) by ada.kiz.li (OpenSMTPD) with ESMTPSA id f08745e7 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Tue, 26 Aug 2025 16:05:24 -0400 (EDT) Message-ID: <27174be9-3057-4e86-b21e-00fb133b77f9@bisd.ro> Date: Tue, 26 Aug 2025 15:05:23 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: freebsd-current@FreeBSD.org Content-Language: en-US From: "S. Ross Gohlke" Subject: hastd not working, getgroups failure, COMPAT_FREEBSD14 enabled Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: / X-Spamd-Result: default: False [0.44 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_SPAM_MEDIUM(0.98)[0.977]; NEURAL_HAM_SHORT(-0.93)[-0.933]; DMARC_POLICY_ALLOW(-0.50)[bisd.ro,reject]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:174, ipnet:38.45.72.0/24, country:US]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4cBJYd6k36z4LM9 I tried running the latest PRERELEASE snapshot obtained from , published on Aug. 22. The hastd rc service starts but "hastctl status" fails with the following error message: [CRIT] Assertion failed: (getgroups(0, NULL) == 1), function drop_privs, file /usr/src/sbin/hastd/subr.c, line 287. I have followed the "UPDATING stuff" thread on this list about 14 compatibility, and my understanding is that getgroups syscalls should work as long as the kernel has "options COMPAT_FREEBSD14" enabled. I am running a custom kernel, but it is based on MINIMAL, so "options COMPAT_FREEBSD14" is enabled. % sysctl kern.conftxt | grep COMPAT_FREEBSD14 options    COMPAT_FREEBSD14 Am I doing something wrong? Might this be fixed in the next snapshot (due Thursday)? Thanks, Ross From nobody Tue Aug 26 20:32:04 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBK8Q5Hvxz665Fb for ; Tue, 26 Aug 2025 20:32:06 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBK8Q4lGVz3DXN; Tue, 26 Aug 2025 20:32:06 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756240326; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Kge0Z6laiekLZHHZXV3l9l0Rc1NRbkIQ9dxZgYsVH7s=; b=miSPhad5Clj6aqBdFHffEzUNM/vPe42PuW1zGZzfPLj9J6jEbqoFJMVAoxlt75XrXhcp+m zWqbOcRavkghNmyohzLAG+aVgqSl6KQ2k4enA1+fXIvWwX6RMB/bESslqRbg+FaY77X+zQ aW2R9eXoyR1QIyTUtsc62gknDm1G8Rx8Sii1QDTPFFRh6gEsNVmhGD+yWq+lx7yw2GlAnh NgvUJUKHPsUYTj10z0/IN4IBc7GNe5hH/hKMUV3ZQTryasZlAZ+JoUliu0NYp4H7GxRqJK EITFrdrphtSUgTn2fuHzhfI8Nv9uQJI5T//yt45i4YrjaOHMHRae1RydfoBPKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756240326; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Kge0Z6laiekLZHHZXV3l9l0Rc1NRbkIQ9dxZgYsVH7s=; b=I24LmkdZgQv6eNAAghs/0HjEl/UKrImUZH/EIWFD0yTBXdHd1MI+ybXcR9R5+To1hwFCVm TPKN3XmoFh+GSF+Px8ox/4UStmK/AP/XNKj2GGzGFvBjcD451EEJmu65FnIBgqQRperaeE GjJPefJxvvtrfG4gin/jwC7W6P/aM+3lzKjGKnnigk4rL6Jzp5f2wkq7k/tfLKg0nVERez kQeXR/MpOOyH8Lfp2IygiXF7yphv3eOj3H3d8Ilr17lYG+5oLs/ueK+gMfUKBZfaSJF7Fy /O51UeMkbqSS6ZQkoWFAzuqcSl8PDiLvQlSOZlmqsJ14ObD5x7iG7FIE4lB3AQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756240326; a=rsa-sha256; cv=none; b=ojgiT5W3fVXxPnxqEOuPgNSCZmc2U1FCwHZqKQ3tj5cCESfozKpR97FsISyZTad/NkfiIf /z1nNNL9TJi5k0DWnyYPGeO6vTfjWlxOQqArx1m08L5w0eEYsotTNovY3yfEyvBHq9SnGx Nyj+NHEHock9qL+9Q3x5pj6k9LmoRaWmOiZofpXc7u6o0soIpWoPRfGiDvGAFuJqP2STsE SPmTHHqVaqaEyk4Hl60SCer6Mi8dPZjVU6du7keiu1BmvvEzBPOCqnnrVUUFcj3Nl8LrG0 cnh+DcwOBgLznEZlM+xeI6hBMjv3boPFfYTa7H+fV5slWanTY1hKYCEgbqWxKw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cBK8Q2bL4ztw5; Tue, 26 Aug 2025 20:32:06 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <943978ca-4825-43bf-94c2-9e539c56deab@FreeBSD.org> Date: Tue, 26 Aug 2025 15:32:04 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: hastd not working, getgroups failure, COMPAT_FREEBSD14 enabled To: "S. Ross Gohlke" , freebsd-current@FreeBSD.org References: <27174be9-3057-4e86-b21e-00fb133b77f9@bisd.ro> Content-Language: en-US From: Kyle Evans In-Reply-To: <27174be9-3057-4e86-b21e-00fb133b77f9@bisd.ro> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/26/25 15:05, S. Ross Gohlke wrote: > I tried running the latest PRERELEASE snapshot obtained from , published on Aug. 22. > > The hastd rc service starts but "hastctl status" fails with the following error message: > [CRIT] Assertion failed: (getgroups(0, NULL) == 1), function drop_privs, file /usr/src/sbin/hastd/subr.c, line 287. > > I have followed the "UPDATING stuff" thread on this list about 14 compatibility, and my understanding is that getgroups syscalls should work as long as the kernel has "options COMPAT_FREEBSD14" enabled. > > I am running a custom kernel, but it is based on MINIMAL, so "options COMPAT_FREEBSD14" is enabled. > > % sysctl kern.conftxt | grep COMPAT_FREEBSD14 > options    COMPAT_FREEBSD14 > > Am I doing something wrong? Might this be fixed in the next snapshot (due Thursday)? > Bah; I had adjusted the assertions, but overlooked one that doesn't make sense. The last two could probably be coalesced, but it's probably worth being sure that we don't still return one gid if room was created for whatever reason. Try this: diff --git a/sbin/hastd/subr.c b/sbin/hastd/subr.c index 284fb0d07647..add1280e960b 100644 --- a/sbin/hastd/subr.c +++ b/sbin/hastd/subr.c @@ -284,7 +284,7 @@ drop_privs(const struct hast_resource *res) PJDLOG_VERIFY(rgid == pw->pw_gid); PJDLOG_VERIFY(egid == pw->pw_gid); PJDLOG_VERIFY(sgid == pw->pw_gid); - PJDLOG_VERIFY(getgroups(0, NULL) == 1); + PJDLOG_VERIFY(getgroups(0, NULL) == 0); PJDLOG_VERIFY(getgroups(1, gidset) == 0); pjdlog_debug(1, From nobody Tue Aug 26 22:18:14 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBMVw6qTwz66CR9 for ; Tue, 26 Aug 2025 22:18:16 +0000 (UTC) (envelope-from ross@bisd.ro) Received: from ada.kiz.li (ada.kiz.li [38.45.72.165]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBMVw513dz3QVF; Tue, 26 Aug 2025 22:18:16 +0000 (UTC) (envelope-from ross@bisd.ro) Authentication-Results: mx1.freebsd.org; none Received: from [192.168.1.225] (syn-072-182-130-191.res.spectrum.com [72.182.130.191]) by ada.kiz.li (OpenSMTPD) with ESMTPSA id 542afcda (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 26 Aug 2025 18:18:15 -0400 (EDT) Message-ID: <6f584939-6639-436d-881d-f324b78511ed@bisd.ro> Date: Tue, 26 Aug 2025 17:18:14 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: hastd not working, getgroups failure, COMPAT_FREEBSD14 enabled SUCCESS To: Kyle Evans , freebsd-current@FreeBSD.org References: <27174be9-3057-4e86-b21e-00fb133b77f9@bisd.ro> <943978ca-4825-43bf-94c2-9e539c56deab@FreeBSD.org> Content-Language: en-US From: "S. Ross Gohlke" In-Reply-To: <943978ca-4825-43bf-94c2-9e539c56deab@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:174, ipnet:38.45.72.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cBMVw513dz3QVF On 8/26/25 15:32, Kyle Evans wrote: > On 8/26/25 15:05, S. Ross Gohlke wrote: >> I tried running the latest PRERELEASE snapshot obtained from >> , >> published on Aug. 22. >> >> The hastd rc service starts but "hastctl status" fails with the >> following error message: >> [CRIT] Assertion failed: (getgroups(0, NULL) == 1), function >> drop_privs, file /usr/src/sbin/hastd/subr.c, line 287. >> >> I have followed the "UPDATING stuff" thread on this list about 14 >> compatibility, and my understanding is that getgroups syscalls should >> work as long as the kernel has "options COMPAT_FREEBSD14" enabled. >> >> I am running a custom kernel, but it is based on MINIMAL, so "options >> COMPAT_FREEBSD14" is enabled. >> >> % sysctl kern.conftxt | grep COMPAT_FREEBSD14 >> options    COMPAT_FREEBSD14 >> >> Am I doing something wrong? Might this be fixed in the next snapshot >> (due Thursday)? >> > > Bah; I had adjusted the assertions, but overlooked one that doesn't > make sense.  The last > two could probably be coalesced, but it's probably worth being sure > that we don't still > return one gid if room was created for whatever reason.  Try this: > > diff --git a/sbin/hastd/subr.c b/sbin/hastd/subr.c > index 284fb0d07647..add1280e960b 100644 > --- a/sbin/hastd/subr.c > +++ b/sbin/hastd/subr.c > @@ -284,7 +284,7 @@ drop_privs(const struct hast_resource *res) >         PJDLOG_VERIFY(rgid == pw->pw_gid); >         PJDLOG_VERIFY(egid == pw->pw_gid); >         PJDLOG_VERIFY(sgid == pw->pw_gid); > -       PJDLOG_VERIFY(getgroups(0, NULL) == 1); > +       PJDLOG_VERIFY(getgroups(0, NULL) == 0); >         PJDLOG_VERIFY(getgroups(1, gidset) == 0); > >         pjdlog_debug(1, > I patched /usr/src/sbin/hastd/subr.c (just edited the file) and rebuilt hastctl and now it works. I did not have to rebuild hastd. # nano /usr/src/sbin/hastd/subr.c # cd /usr/src/sbin/hastctl # make -j8 # ./hastctl status Gives proper output and no error. Thanks for the help and prompt response, Ross From nobody Tue Aug 26 22:50:45 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBNDV106Nz65GZH for ; Tue, 26 Aug 2025 22:50:50 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBNDV0PZgz3V80; Tue, 26 Aug 2025 22:50:50 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756248650; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pCpR6bkdKd+BhfiH6BC0JEMJF5SMuK8QcINfOS3VWl4=; b=AzASvBRajlH5HYDVnIBMXyB9l5Ofwe1ed2WH0FN2L1pPAvgnpnjOUXn++582jG4i4sSUmn 4n047k9AKdj1W8eeSjkU3QZig33p0kVC6SInvQga0zYbvXiZGkf6E7D2OiTfbNlG2rs744 sQGtvjfSksxzo//Nhu822ypwjzqB2X/pgkjBCELVGf8oOKi+OeyGnDCEhk40K2sTWjx0Ta 1C8LLWO6pRMuELgDk2iFhU68uJ4lWtanzLt+ti+bvX6MtMZ7yZUlCocSMg1I1yj2ZsLeZ9 rf1iUFouICcebNu1L1NX50igPsqhfsYPTv3bQR8j2ndNxxluHWlOFveVX9hI+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756248650; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pCpR6bkdKd+BhfiH6BC0JEMJF5SMuK8QcINfOS3VWl4=; b=Ga88w6Dd6PaP5jQEUbdDO3/+5EwA6G9i8FAwuEMkSwH+qt2wHH78jJYXMkMqruy1yQ9Ror Zss0+4y12GajvHj9ama6Z5vltLnIj/zdndIoaVZm51ifkmbdIWDZ6vThaRLyVSfNquFrvO G1XBDZhiZn72zB4OoGwD2tKCJoMTYZnXsd+7uUGAc89fko/xPzVF16xEEmcc/jWZ/B5/j2 JlFtXOFlRuNygtL0G/D7b5VDm4XAfeG1AoM4rYoLrtNHPTgMD3Dp53bCD/5rbUctfvbIfB OfgVwVFomavyMVX15Pc14JbyKRZeZbgVUHXZCZk5YEd7wMWytKjqpwNZOoF8nQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756248650; a=rsa-sha256; cv=none; b=nRHMgxWmJkVuqtGNCSHpiW1jeTUVP2cV4rKPWL1RpkgA7Vb/iPUWf5E8n/7evu7k3RCgHo tvteJxdj6jeXsuBCQM0VXm/TFUGObEsOeUHf1ZnrYTBqfi+GflM18sNWXfjJPO4T3TEztQ k4bOYZ7Lbu4COW86jHbC+qeFA4qA8Pq2a178rc5Qekyn1D+x+RUQbXAhmgREuClMeDgrNr G2eJTZiHsD06PQf8egy/5qfkQMtlQisYLC1eq+AAqFI3Z8wCx6RSgYFaTCs9DGIhhVBCdE TwBydMNsGANQ6QAI1B2CMi6LcOydzurw9qh5LSvAPjyu2b5h2TrOHjniwolkdw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cBNDS4Mksz10cr; Tue, 26 Aug 2025 22:50:48 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: Date: Tue, 26 Aug 2025 17:50:45 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: hastd not working, getgroups failure, COMPAT_FREEBSD14 enabled SUCCESS To: "S. Ross Gohlke" , freebsd-current@FreeBSD.org References: <27174be9-3057-4e86-b21e-00fb133b77f9@bisd.ro> <943978ca-4825-43bf-94c2-9e539c56deab@FreeBSD.org> <6f584939-6639-436d-881d-f324b78511ed@bisd.ro> Content-Language: en-US From: Kyle Evans In-Reply-To: <6f584939-6639-436d-881d-f324b78511ed@bisd.ro> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/26/25 17:18, S. Ross Gohlke wrote: > > On 8/26/25 15:32, Kyle Evans wrote: >> On 8/26/25 15:05, S. Ross Gohlke wrote: >>> I tried running the latest PRERELEASE snapshot obtained from , published on Aug. 22. >>> >>> The hastd rc service starts but "hastctl status" fails with the following error message: >>> [CRIT] Assertion failed: (getgroups(0, NULL) == 1), function drop_privs, file /usr/src/sbin/hastd/subr.c, line 287. >>> >>> I have followed the "UPDATING stuff" thread on this list about 14 compatibility, and my understanding is that getgroups syscalls should work as long as the kernel has "options COMPAT_FREEBSD14" enabled. >>> >>> I am running a custom kernel, but it is based on MINIMAL, so "options COMPAT_FREEBSD14" is enabled. >>> >>> % sysctl kern.conftxt | grep COMPAT_FREEBSD14 >>> options    COMPAT_FREEBSD14 >>> >>> Am I doing something wrong? Might this be fixed in the next snapshot (due Thursday)? >>> >> >> Bah; I had adjusted the assertions, but overlooked one that doesn't make sense.  The last >> two could probably be coalesced, but it's probably worth being sure that we don't still >> return one gid if room was created for whatever reason.  Try this: >> >> diff --git a/sbin/hastd/subr.c b/sbin/hastd/subr.c >> index 284fb0d07647..add1280e960b 100644 >> --- a/sbin/hastd/subr.c >> +++ b/sbin/hastd/subr.c >> @@ -284,7 +284,7 @@ drop_privs(const struct hast_resource *res) >>         PJDLOG_VERIFY(rgid == pw->pw_gid); >>         PJDLOG_VERIFY(egid == pw->pw_gid); >>         PJDLOG_VERIFY(sgid == pw->pw_gid); >> -       PJDLOG_VERIFY(getgroups(0, NULL) == 1); >> +       PJDLOG_VERIFY(getgroups(0, NULL) == 0); >>         PJDLOG_VERIFY(getgroups(1, gidset) == 0); >> >>         pjdlog_debug(1, >> > I patched /usr/src/sbin/hastd/subr.c (just edited the file) and rebuilt hastctl and now it works. I did not have to rebuild hastd. > I don't really know enough about hastd here- it does have a few calls to drop_privs(), but I guess it may take a bit more to trip over that. Knowing that hastctl is fixed is enough to proceed with more confidence here -- committed as 0d843cc2e2a3 (and this week's snapshot builds won't start for another ~day). Thanks for the report! > # nano /usr/src/sbin/hastd/subr.c > > > > # cd /usr/src/sbin/hastctl > > # make -j8 > > # ./hastctl status > > Gives proper output and no error. > > > Thanks for the help and prompt response, > > Ross > From nobody Wed Aug 27 08:17:48 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBcq56F0kz65wC4 for ; Wed, 27 Aug 2025 08:18:09 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (prime256v1) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBcq40M9dz3Csj; Wed, 27 Aug 2025 08:18:08 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=MCNZ9Kqi; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1756282686; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2mvnwGYHReimW0nzWcDs1eXROrjh0ZBZeE4w+idNtTY=; b=MCNZ9KqibilkUYDh1Npc3jgbuXQrxg8I55gfkf30tinx2KtU3H8lmxSRHIlYUA/zsAPOj8 SMUjBjm738lwXCbnNBWZTYsnJ/qPOrECyx0FMnm9VoBU9Vn60dgNdC3hecrAb6Bg5Ui1i8 B9vOnAJLgBfgFIOTnmSYYvEiqzn4ZKiPNsqzyvVuPyZechjohJrpscXkQFtZn2Y8rJjWrf T86VVwoKmPKQiay42Jx86Si3bhBVTmkTB9pGnwaFbZ75PTT3KLvPakIcGErIj2pcnQ0eD0 +r5iBdAdQZdEYMfL5FFD2MWcl8koY/iC8TSjR0MzBcHTiu1TtxvQuVoo4KqHaw== Date: Wed, 27 Aug 2025 10:17:48 +0200 From: Alexander Leidinger To: Rick Macklem Cc: Gleb Smirnoff , Cy Schubert , freebsd-current@freebsd.org Subject: Re: heimdal -> MIT kdc migration In-Reply-To: References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> Message-ID: Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_9e7e285fbde4539ce8569cad53f2957e"; micalg=pgp-sha256 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.44 / 15.00]; SIGNED_PGP(-2.00)[]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.94)[-0.940]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; ONCE_RECEIVED(0.10)[]; HAS_ATTACHMENT(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; HAS_ORG_HEADER(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4cBcq40M9dz3Csj This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_9e7e285fbde4539ce8569cad53f2957e Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2025-08-26 19:21, schrieb Rick Macklem: > On Tue, Aug 26, 2025 at 9:35 AM Gleb Smirnoff > wrote: >> >> On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff wrote: >> T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem wrote: >> T> R> Ok. If you install FreeBSD-13.5 and then "pkg install heimdal", >> you get a >> T> R> working Heimdal-7.8 in ports. >> T> R> >> T> R> Now, I have another challenge. Fixing the master passwords. >> T> R> I'll work on it later to-day. >> T> >> T> I have applied two commits from Heimdal from 2012 that add 'kadmin >> dump -f MIT' >> T> feature to our base heimdal and polished them to compile. So far >> it doesn't >> T> work yet, either create an empty dump or create a core dump, >> instead of >> T> database dump :) I'll see how difficult it is going to further >> resolve that to >> T> a working condition. If I succeed, then having 'dump -f MIT' in >> base without >> T> any ports would be the best solution. Can also be merged to >> FreeBSD 14.4. >> >> Good news. In the above paragraph I was testing my change incorrectly >> - threw >> the new binary on a system running unpatched libraries. When run >> correctly, >> it successfully produced something that looks like a correct dump in >> MIT format. >> I haven't yet tried to load it into MIT kdc yet, though. > You might have better luck than me, but if I just loaded it, > "kadmin.local" wouldn't > work. > To get it loaded, I had to: > - edit the mit.dump and remove the entries for > K/M, kadmin/admin, kadmin/changepw and krbtgt/REALM. > Then I... > # kdb5_util create -s > and > # kdb5_util load -update mit.dump > -after that, kadmin.local would find the prinicipals, but > a "kinit" wouldn't work until I did a "change_password" on it. Have you tried "kadmin -l dump --decrypt --format=MIT"? Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_9e7e285fbde4539ce8569cad53f2957e Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmiuvzoACgkQEg2wmwP4 2Ia8xxAAhSdMopmOlkNjggHy/q+FVL6okWQu/CCfBaWfQ6m7pAH12IZMcyKf78Jg hQXBI3i2CXThU+RrQUWLy2bWHnC13ztP/3EubnpS1V/WoRcsytXFn2HdJLR3Y53D Y/B+sLEqbGIKu0EP9+2ake32OzlEarwxWRRN8IbAJBapKHqfsISVv+rDEtTJnFzh 8DnigaxiamKlgyU9RoEJaw8r1lwFOJZ+R0WR/43kFAgufaWcLPsRc3vqsqFq8Xck Oq2teR5FbwrlEVLvM93+FzRF+IKQc+4l+ztX/QVRR606gg4+MQ9VRFDvY8iy8FH2 tDrZnTx2LUyjWjmIxD65zPb8StRckaEskm0ZeNu7sE8V56RJ8LytxZ61VmTAUV// LnfX1+ikBegnv9ntdQs1TKcI0NgjRKCOE6y+sZVz5pPSmNA5W+V4RFcjbzPkp4Nv Vm0etWVgi3U1ZvLcGBUaWkKnA6VSBUb4UVl4puWU3Rzi2oxpLMRffo1iaJhyFAsJ CDTnuCoicjqCWIUo0YkFK2ciUJuRA6MzhhDhVp5vEAl3dGEgIpJKW4d3iWJAG4Xa f+l744e3UGSrzAt5kHytvsxnmvy/rJimJ+/2T4u5whZQ/yhxdMPWbxUKa4D2hMwY r+W3x11FGZaWJGBUB7/pK4yuz380Q5tboz39A8smm8UrdfEKIMw= =i27b -----END PGP SIGNATURE----- --=_9e7e285fbde4539ce8569cad53f2957e-- From nobody Wed Aug 27 11:41:31 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBjKr0H6rz668XN for ; Wed, 27 Aug 2025 11:41:36 +0000 (UTC) (envelope-from ross@bisd.ro) Received: from ada.kiz.li (ada.kiz.li [38.45.72.165]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBjKp2DFkz3ZWJ; Wed, 27 Aug 2025 11:41:34 +0000 (UTC) (envelope-from ross@bisd.ro) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=bisd.ro; spf=pass (mx1.freebsd.org: domain of ross@bisd.ro designates 38.45.72.165 as permitted sender) smtp.mailfrom=ross@bisd.ro Received: from [192.168.1.225] (syn-072-182-130-191.res.spectrum.com [72.182.130.191]) by ada.kiz.li (OpenSMTPD) with ESMTPSA id 6292833b (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 27 Aug 2025 07:41:32 -0400 (EDT) Message-ID: Date: Wed, 27 Aug 2025 06:41:31 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: hastd not working, getgroups failure, COMPAT_FREEBSD14 enabled SUCCESS From: "S. Ross Gohlke" To: Kyle Evans , freebsd-current@FreeBSD.org References: <27174be9-3057-4e86-b21e-00fb133b77f9@bisd.ro> <943978ca-4825-43bf-94c2-9e539c56deab@FreeBSD.org> <6f584939-6639-436d-881d-f324b78511ed@bisd.ro> Content-Language: en-US In-Reply-To: <6f584939-6639-436d-881d-f324b78511ed@bisd.ro> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.61 / 15.00]; NEURAL_HAM_LONG(-0.98)[-0.982]; NEURAL_HAM_SHORT(-0.98)[-0.977]; DMARC_POLICY_ALLOW(-0.50)[bisd.ro,reject]; R_SPF_ALLOW(-0.20)[+mx]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-0.06)[-0.055]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:174, ipnet:38.45.72.0/24, country:US]; TO_DN_SOME(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4cBjKp2DFkz3ZWJ On 8/26/25 17:18, S. Ross Gohlke wrote: > > On 8/26/25 15:32, Kyle Evans wrote: >> On 8/26/25 15:05, S. Ross Gohlke wrote: >>> I tried running the latest PRERELEASE snapshot obtained from >>> , >>> published on Aug. 22. >>> >>> The hastd rc service starts but "hastctl status" fails with the >>> following error message: >>> [CRIT] Assertion failed: (getgroups(0, NULL) == 1), function >>> drop_privs, file /usr/src/sbin/hastd/subr.c, line 287. >>> >>> I have followed the "UPDATING stuff" thread on this list about 14 >>> compatibility, and my understanding is that getgroups syscalls >>> should work as long as the kernel has "options COMPAT_FREEBSD14" >>> enabled. >>> >>> I am running a custom kernel, but it is based on MINIMAL, so >>> "options COMPAT_FREEBSD14" is enabled. >>> >>> % sysctl kern.conftxt | grep COMPAT_FREEBSD14 >>> options    COMPAT_FREEBSD14 >>> >>> Am I doing something wrong? Might this be fixed in the next snapshot >>> (due Thursday)? >>> >> >> Bah; I had adjusted the assertions, but overlooked one that doesn't >> make sense.  The last >> two could probably be coalesced, but it's probably worth being sure >> that we don't still >> return one gid if room was created for whatever reason.  Try this: >> >> diff --git a/sbin/hastd/subr.c b/sbin/hastd/subr.c >> index 284fb0d07647..add1280e960b 100644 >> --- a/sbin/hastd/subr.c >> +++ b/sbin/hastd/subr.c >> @@ -284,7 +284,7 @@ drop_privs(const struct hast_resource *res) >>         PJDLOG_VERIFY(rgid == pw->pw_gid); >>         PJDLOG_VERIFY(egid == pw->pw_gid); >>         PJDLOG_VERIFY(sgid == pw->pw_gid); >> -       PJDLOG_VERIFY(getgroups(0, NULL) == 1); >> +       PJDLOG_VERIFY(getgroups(0, NULL) == 0); >>         PJDLOG_VERIFY(getgroups(1, gidset) == 0); >> >>         pjdlog_debug(1, >> > I patched /usr/src/sbin/hastd/subr.c (just edited the file) and > rebuilt hastctl and now it works. I did not have to rebuild hastd. > > # nano /usr/src/sbin/hastd/subr.c > > > > # cd /usr/src/sbin/hastctl > > # make -j8 > > # ./hastctl status > > Gives proper output and no error. > > > Thanks for the help and prompt response, > > Ross > Correction: I did have to rebuild hastd as well. While, "hastctl status" worked without it, "hastctl role primary all" did not until I rebuilt hastd. # cd /usr/src/sbin/hastd # make -j8 # cp -p ./hastd /sbin From nobody Wed Aug 27 13:16:02 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBlRC5PqYz66HC0 for ; Wed, 27 Aug 2025 13:16:23 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBlRB5Qv5z3sSv; Wed, 27 Aug 2025 13:16:22 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-6188b5ad681so9322064a12.0; Wed, 27 Aug 2025 06:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756300576; x=1756905376; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=iewKlvedgyomt9b7XwostDxxQdxTkvL2z9S97jOd5BA=; b=mWuDPL8bRxDJnuM/2owzrx/5vImnQXaUSDcEuRRFa8tRRv+ltOwBVt27RqxkTcp6uG ftU7iKz3YrYgp7IFm9wovA6lVuBd5TFuAM50LvslNSiAKdgDUhP0Fls+jg28jdrNhYU3 QwZ3WF9cchSg+IBygogL+mTefGWGnR+I63THsQ4WmKPjOm2mgJy/GfnbRmRce7oQUJSS DgCPZBwHvAyBSvZj99KOYA8Ce+2dZlrfQlqJ7IYisswYhk9YX954utD259+ZCZOlRHgg lqfQxyfLrEY3Kw1dUQTSJ9E0AXNcN6rFE+aRJJrvw87exdwSNNjMkjJtIBdroKzwCsUe gYUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756300576; x=1756905376; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iewKlvedgyomt9b7XwostDxxQdxTkvL2z9S97jOd5BA=; b=XpuySgS7Xc2Sc0wumHVN6j5kbtG0KqjQredaVj0nEyBdwBihKOdBG7Yqvn10YH47aN u8j2dvQ5FXcTdeMN1sySPaTeETEj9cZ9DOniJVxUFQ7iG6s+5jBUiNQCvD0Luywzlonz u+4sZJar/w4ICm2VauNcynWwLnXUSW/K3GzMRz55SjqG2E51UPmXs4Pqb+x+YAlaqwzn 2ifrsJDd5+KhsrsyvkYlWJ85eZFgBVf2G8+4uB8g8dNcLw2kKfv90KdH1PZ9vyGTG930 VgWbk6lrZGKRiEqCqnJDowutmZCYq/vamGYu35NwAP5sHydPpTUR7dW8XyWjz7kTBUIA i1pg== X-Forwarded-Encrypted: i=1; AJvYcCU1rEVggL3rR8FS9M2/sekKd9Q0whlOmzEoY5DXkHnYz6aGTawX5IHgtedMfL6w1KC3cK+HJ/E/iFhk+1PW+fE=@freebsd.org X-Gm-Message-State: AOJu0Yz3cKNjlYPJUbbU5uW5cPVHKgAKue9Bq7C7l2Uh/RScguSjjwd8 Nq2vh7JFbcl9qUJnDky0jBQp9AwXE9BqSJP0Ho8zLEpjjoZh9Lw8CeCysbRDeA6I5R4BPNfDHxt DcSyRkisnDD0RnA1rHsMm0uN/SJfhmE1z X-Gm-Gg: ASbGncsbhVta2r5PPQQQSla/EVKbpyQOCnvAgjqGl52RKQbxrwoMXjldWfRPm5B/5Ak bJa6pJJfHHUel4pWMA7JyWEkhAJllixqTob41r4mv0bAr/XHB40Dy8pVJKOu2jZe9aK6YHhDHkT 0PEOxYZHFE4i20WGC8GcHcI2YzIGi5t4TkK8PVtSL46nEZ/lFj07lD+RRP5flfp+hjF5vIsfwO7 trTBYB4UwR146yCHLjGvD1urSIv/a/L/2rBQFI= X-Google-Smtp-Source: AGHT+IEvz6ZjoLYPVE+uZNnuPJXgZvjlGfeYqSMRmD0QK2XYOiNgOUeNNPs2s5zUIMS3FeoY3QHSWsojGzNiOUyAZjU= X-Received: by 2002:a05:6402:510e:b0:61c:a1a6:52a2 with SMTP id 4fb4d7f45d1cf-61ca1a65d0amr3666189a12.28.1756300575929; Wed, 27 Aug 2025 06:16:15 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Wed, 27 Aug 2025 06:16:02 -0700 X-Gm-Features: Ac12FXzcfzU9J3uoFViA0gDl-m_DFUrH5AyMn4XEx-GTfKlU6-BSsJbxnc2Gd3A Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Alexander Leidinger Cc: Gleb Smirnoff , Cy Schubert , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cBlRB5Qv5z3sSv On Wed, Aug 27, 2025 at 1:18=E2=80=AFAM Alexander Leidinger wrote: > > Am 2025-08-26 19:21, schrieb Rick Macklem: > > On Tue, Aug 26, 2025 at 9:35=E2=80=AFAM Gleb Smirnoff > > wrote: > >> > >> On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff wrote: > >> T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem wrote: > >> T> R> Ok. If you install FreeBSD-13.5 and then "pkg install heimdal", > >> you get a > >> T> R> working Heimdal-7.8 in ports. > >> T> R> > >> T> R> Now, I have another challenge. Fixing the master passwords. > >> T> R> I'll work on it later to-day. > >> T> > >> T> I have applied two commits from Heimdal from 2012 that add 'kadmin > >> dump -f MIT' > >> T> feature to our base heimdal and polished them to compile. So far > >> it doesn't > >> T> work yet, either create an empty dump or create a core dump, > >> instead of > >> T> database dump :) I'll see how difficult it is going to further > >> resolve that to > >> T> a working condition. If I succeed, then having 'dump -f MIT' in > >> base without > >> T> any ports would be the best solution. Can also be merged to > >> FreeBSD 14.4. > >> > >> Good news. In the above paragraph I was testing my change incorrectly > >> - threw > >> the new binary on a system running unpatched libraries. When run > >> correctly, > >> it successfully produced something that looks like a correct dump in > >> MIT format. > >> I haven't yet tried to load it into MIT kdc yet, though. > > You might have better luck than me, but if I just loaded it, > > "kadmin.local" wouldn't > > work. > > To get it loaded, I had to: > > - edit the mit.dump and remove the entries for > > K/M, kadmin/admin, kadmin/changepw and krbtgt/REALM. > > Then I... > > # kdb5_util create -s > > and > > # kdb5_util load -update mit.dump > > -after that, kadmin.local would find the prinicipals, but > > a "kinit" wouldn't work until I did a "change_password" on it. > > Have you tried "kadmin -l dump --decrypt --format=3DMIT"? Yes. It has not helped. (I've tried --decrypt at both the first dump of Heimdal-1.5 and at the second one in Heimdal-7.8.) I'll note that the MIT "kinit" fails before it prompts for a password, which suggests something is fundamentally broken in the TGT. I will be investigating this further to-day. rick > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From nobody Wed Aug 27 13:18:32 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBlTv17sdz66H6s for ; Wed, 27 Aug 2025 13:18:43 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (prime256v1) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E6" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBlTs6Hf8z3tbS for ; Wed, 27 Aug 2025 13:18:41 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zabbadoz.net header.s=20240622 header.b=mzLWkYCs; dmarc=pass (policy=none) header.from=zabbadoz.net; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2003:a:140a:2200:6:594:fffe:19 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id A4037A64806 for ; Wed, 27 Aug 2025 13:18:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zabbadoz.net; s=20240622; t=1756300706; bh=yHp89I+F/CFJzJrDjLUhxClu2mSKq5HldRM4nRqHXuA=; h=Date:From:To:Subject; b=mzLWkYCsAoIRXMr0rGe2fmGbW2zaybYkv5vrgI8QmEuwyzDBj0PVI0ZqQaA4DHgYM a5gypq7sOgfQdwggo3YUowywouKkE7XWwEG6u2RzOVCQEsQ0jHIPxVlIUCxQY+oR5N IMY7uaWhG+xifcr4QiC4b25aO+ltt891O5AWzV9Ul3fBiti1vqKaXtoRfDrF5HKvEN zy9SV1rb4kviTuvzaWmIPva7fhHJPYZZulU8LZ/avtIjq6mqszpANKgYD3M2uTlsnK dRUOXxcZweUcxheTFvwc9Xp4K57oHekVRGsR5Zmz7/sAvyK4z3aKEWHD0LIBxI2SGn IN7z/wdQiq9qo+BMDI1/PzEjkZQdjV1+0az4j6eXhAxhKHTd+UPUmE6CinP99es57n yiJuLFt4kFUwWbBgYEhCzL6yd4Z7rGC9WLZIGcZaTINpqaZKQNad2doU0mIOuQze+5 eLqd/APDGhJi24gJ3IvyDA/B04nKV+yW33p1pET48PvgcpEYREJSFDbL53NuzEikmQ JhclVtRWkO6/vByIsZgcVDy33hNBkDdzxpV2FyIDzqfrCutUVaJxYPRvlZ0lhKLGKG itZFNWFkZZNybUWGbrTyeXL9wSS9tvbXIu+tY+EeJCIx05bAhMjvJUcfNIabsmikv2 fQ/G/kJSApYiUksUNxFITFBs= Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A6D432D029E3 for ; Wed, 27 Aug 2025 13:18:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id 3Q-7Eb_8aiod for ; Wed, 27 Aug 2025 13:18:32 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:a66b:b6ff:fe40:39a9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 721192D029D8 for ; Wed, 27 Aug 2025 13:18:32 +0000 (UTC) Date: Wed, 27 Aug 2025 13:18:32 +0000 (UTC) From: "Bjoern A. Zeeb" To: current@freebsd.org Subject: nfs: panic: fsync: vnode is not exclusive locked but should be Message-ID: <38pos3n9-1605-7983-p50s-2ossos99sn21@yvfgf.mnoonqbm.arg> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.72 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.72)[-0.718]; DMARC_POLICY_ALLOW(-0.50)[zabbadoz.net,none]; R_DKIM_ALLOW(-0.20)[zabbadoz.net:s=20240622]; R_SPF_ALLOW(-0.20)[+ip6:2003:a:140a:2200:6:594:fffe:19]; MIME_GOOD(-0.10)[text/plain]; MISSING_XM_UA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3320, ipnet:2003::/19, country:DE]; RCVD_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[zabbadoz.net:+] X-Rspamd-Queue-Id: 4cBlTs6Hf8z3tbS Just netbooted a main (0d843cc2e2a373f01f) GENERIC to do some testing on a board I rarely use before pushing changes and got the below. Has this been fixed already? ... Last login: Sun May 25 19:37:45 on ttyu0 VNASSERT failed: locked not true at /usr/src/bz_wifi_precommit_testing/sys/kern/vfs_subr.c:5795 (assert_vop_elocked) 0xfffff8000761b000: type VREG state VSTATE_CONSTRUCTED op 0xffffffff81aad768 usecount 2, writecount 0, refcount 3 seqc users 0 hold count flags () flags (VV_VMSIZEVNLOCK|VMP_LAZYLIST) v_object 0xfffff80005d991f0 ref 0 pages 1 cleanbuf 0 dirtybuf 1 lock type nfs: SHARED (count 1) Aug 27 13:16:38 fapu2e4b login[19ileid 18620252 fsid 0x3a3a00ff01 panic: fsync: vnode is not exclusive locked but should be cpuid = 3 time = 1756300598 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0067d3a4c0 vpanic() at vpanic+0x136/frame 0xfffffe0067d3a5f0 panic() at panic+0x43/frame 0xfffffe0067d3a650 vop_fsync_debugprepost() at vop_fsync_debugprepost+0x124/frame 0xfffffe0067d3a690 VOP_FSYNC_APV() at VOP_FSYNC_APV+0x23/frame 0xfffffe0067d3a6b0 bufsync() at bufsync+0x3b/frame 0xfffffe0067d3a6e0 bufobj_invalbuf() at bufobj_invalbuf+0x24f/frame 0xfffffe0067d3a740 ncl_vinvalbuf() at ncl_vinvalbuf+0x100/frame 0xfffffe0067d3a7b0 nlm_advlock_internal() at nlm_advlock_internal+0xa7/frame 0xfffffe0067d3aaf0 nlm_advlock() at nlm_advlock+0x2d/frame 0xfffffe0067d3ab10 nfs_advlock() at nfs_advlock+0x1d0/frame 0xfffffe0067d3ac30 vop_sigdefer() at vop_sigdefer+0x30/frame 0xfffffe0067d3ac60 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0x51/frame 0xfffffe0067d3ac90 vn_closefile() at vn_closefile+0x9a/frame 0xfffffe0067d3ad10 _fdrop() at _fdrop+0x1a/frame 0xfffffe0067d3ad30 closef() at closef+0x1e3/frame 0xfffffe0067d3adc0 closefp_impl() at closefp_impl+0x71/frame 0xfffffe0067d3ae00 amd64_syscall() at amd64_syscall+0x169/frame 0xfffffe0067d3af30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0067d3af30 --- syscall (6, FreeBSD ELF64, close), rip = 0x1ea0dba28cca, rsp = 0x1ea0d6def6b8, rbp = 0x1ea0d6def6e0 --- KDB: enter: panic [ thread pid 1955 tid 100182 ] Stopped at kdb_enter+0x33: movq $0,0x1222d22(%rip) db> show alllocks Process 1955 (login) thread 0xfffff80005dda000 (100182) exclusive lockmgr nfsupg (nfsupg) r = 0 (0xfffffe006b1557e0) locked @ /usr/src/bz_wifi_precommit_testing/sys/fs/nfsclient/nfs_clsubs.c:146 shared lockmgr nfs (nfs) r = 0 (0xfffff8000761b070) locked @ /usr/src/bz_wifi_precommit_testing/sys/fs/nfsclient/nfs_clvnops.c:3477 Process 1817 (syslogd) thread 0xfffff80005d85780 (100108) exclusive lockmgr nfs (nfs) r = 0 (0xfffff800447a33e0) locked @ /usr/src/bz_wifi_precommit_testing/sys/kern/vfs_vnops.c:1243 -- Bjoern A. Zeeb r15:7 From nobody Wed Aug 27 13:20:15 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBlWy1LFYz66HJJ; Wed, 27 Aug 2025 13:20:30 +0000 (UTC) (envelope-from obiwac@gmail.com) Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBlWx2twKz3vfS; Wed, 27 Aug 2025 13:20:29 +0000 (UTC) (envelope-from obiwac@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of obiwac@gmail.com designates 209.85.218.52 as permitted sender) smtp.mailfrom=obiwac@gmail.com Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-afec5651966so121977166b.2; Wed, 27 Aug 2025 06:20:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756300828; x=1756905628; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=GqxXqoXJZ6aFCq0VUVALhr6AEcjgaKjHUd5Ce2+hwxQ=; b=glpBNHw3lDRaM9v95mkizIfaJvUZdGcE/ShJbZJXfmpHgLsvp1s+glhIECuYxHCGNc SsK0fZ8HVvp83qgcetymDlczxmg7WF6UjamfkaqBRYTiN8tUz8xXqBbiyKF66FtrlrrE WVcB4NEsoHEaXC9xQmhWjARQLRcPN5tFbH5JxWgsD0YE6Ws63VsuJx/EF4ekbw6XQZ0p dBHfFnt9+CgF+baVPgNq3BFq1lqs+O8aCQpaeYKizRwVB7ONujOvhnriTihqnQG/3y0E y4fbSWZcBW651OMYrgcZsOfdvNE59dyEDBSuyoJaPnjQEtlVpSspHn2shvgf3GVeOg80 z3uA== X-Forwarded-Encrypted: i=1; AJvYcCWon5GZD3jdlGHWvxbJXOf8FRFY0JwDkt6j2A4zzE2s7fnEqtUCBNzc6CzIxpMOBRlPW1Y7Z4k1UDVza0/hv6w=@freebsd.org X-Gm-Message-State: AOJu0YyDTe7UdxJCQ988Y7K5iAqojIXRYU6HpRvunN5OXA0a5B7O6N2r AFANi00nhtm7rmXdjs/r0D+PawjZv95wBUwgqENmK5puTjOmT/h4rSQyWZttZm7a X-Gm-Gg: ASbGncuLXtwmXMY9cDLDuX/Jj7i41TzwIuLd+OfX1Y9CC5RTj3QC7pHbtl5toKNEzOC KnSAgmEwUf82kmQogAVAuoVedCjbQsu5rs4Zw7b3jsa09lORw0RozNUx57Z6WdPCJ9XnvmZVxow mWIbVV5gbtENOPJUkqQ3v2fXyv7WTA2v1b9Bezj6cSG5MVTPz2wraAVardP4+YqGSefNAnNC02F zRGhdtRB6aqjbGfTgz4J9nnVR6tqAeaLh99TTihQWtgkwhaF+OYJK8UNvy2j22v0NdrKLVSBCC0 smYfLy7BkZEp2lZ47vidm6JeY3H7M+fAf98R4G571DeyBt20tcfXJ8X6CBBUBWVsVqHT4f7Qj0R DD8GnBCQTJGzxqF2MV5v0EPU2A2WiVVP56Lc0luAUkP33KDoh6HrW2XjiGQ== X-Google-Smtp-Source: AGHT+IFMEb9QcEjwGnGqFybwvz0FvjD7UUPjK54cpNodh88+2/44FyPyo+4jMfKz+jdalJI1U1cLcQ== X-Received: by 2002:a17:907:7f0e:b0:ade:198c:4b6f with SMTP id a640c23a62f3a-afe28f767b2mr1607798666b.1.1756300827356; Wed, 27 Aug 2025 06:20:27 -0700 (PDT) Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com. [209.85.218.51]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-afe6cdbd545sm796670366b.54.2025.08.27.06.20.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Aug 2025 06:20:27 -0700 (PDT) Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-afcb7ace3baso1215527366b.3; Wed, 27 Aug 2025 06:20:27 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVcpTEvsEpnkWceJ1EurU3K6GjkOSKfVDkYTW4rBPMlCOMPl/+7VXe4+FqSgyxEVSbbFBWT0cPUqbZ8kQvTVK8=@freebsd.org X-Received: by 2002:a17:906:4786:b0:ae0:ad5c:4185 with SMTP id a640c23a62f3a-afe295c1d7cmr1865785766b.57.1756300826167; Wed, 27 Aug 2025 06:20:26 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 From: obiwac Date: Wed, 27 Aug 2025 15:20:15 +0200 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXwEDCtaGmjp4cjeLhdP3m0mupRtbDO0Rj6mSBGOWPEud4plWyji0hZjSb0 Message-ID: Subject: S4 hibernate support for FreeBSD To: freebsd-arch@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: - X-Spamd-Result: default: False [-1.24 / 15.00]; NEURAL_HAM_LONG(-0.99)[-0.993]; NEURAL_HAM_SHORT(-0.67)[-0.675]; NEURAL_SPAM_MEDIUM(0.42)[0.423]; FORGED_SENDER(0.30)[obiwac@freebsd.org,obiwac@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RWL_MAILSPIKE_GOOD(-0.10)[209.85.218.52:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[obiwac]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[obiwac@freebsd.org,obiwac@gmail.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.218.52:from,209.85.218.51:received]; TO_DN_NONE(0.00)[] X-Rspamd-Queue-Id: 4cBlWx2twKz3vfS Hi all! The FreeBSD Foundation is beginning work on adding S4 (hibernate) support to FreeBSD. Currently we have S4BIOS support, but no hibernate support on modern platforms. We have started exploring what would be required to bring S4 to FreeBSD and kib@ has written up some initial findings, along with some open design questions. We'd like to share this early document with the community to gather feedback or identify any pitfalls, and generally open the discussion around hibernate. You can find the document here (which anyone with the link can add comments to): https://docs.google.com/document/d/1L6b-gEUQcbRMfSuKIytMPlsZfa_q6HCZmmYtN4ysg1M At this stage, we're mostly setting our focus to something similar to the approach taken by OpenBSD's hibernate implementation. We're also thinking of giving a lot of the responsibility to reloading the hibernated kernel to loader(8), as opposed to e.g. Linux, which first boots a preliminary kernel which then goes on to load the hibernated kernel. But nothing is set in stone. We're mostly hoping to hear from people with prior experience in this area, so feedback/comments are welcome! Feedback received before the end of September will be easiest to incorporate. Please add comments directly into the document shared above, or respond to this email. Thanks, Aymeric on behalf of the FreeBSD Foundation From nobody Wed Aug 27 13:50:33 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBmC50FRPz66JMp for ; Wed, 27 Aug 2025 13:50:57 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBmC40YsPz41Tf for ; Wed, 27 Aug 2025 13:50:55 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=idAkPGM5; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1756302635; bh=dBX8MMhNP3QrMiVaagkfWHmqtrh93DK6IKvkFq+75UQ=; h=Date:From:To:Subject:In-Reply-To:References; b=idAkPGM50/VZt5G3/37cgWoREY72UUTBOJZMEMgrZejDjE7NeSjgpJUQ8C038xU2Q zF0n4X0dhzD+YAGQtXPGll0IOFJv2aYMPpj4kycNAuBWhMJdSjJE7dn5wQFNb9mr61 QmCYJDo1raM0Af7BLOqyUyvmwABkZdRAYIjTc5y01h9oA1BwOuqHUAHbUGlAkwSwR/ qQk0Kp7JsRTi8kUsE2slOr9iEO4ba7TWy/4Y35RIuf+EVx1TIJtZhyvXXWgOZSk1l0 qMkXPMpjRnv4oZsQNFjBP/XT9SaO0f/RLhhxIKH3RYZNkXq4/4FO3I1O0UzeHF2j8I NpOjqYLGI/N6z57MDxMXuCf4IamVsJ+70rEnIZc6S44FO2kucXU7cIRTWOTOocsl80 LaOGA8qgMAnyX/CIu9LAxn+zeUTPbWiFUJBtzXSuHTdd9sOVz5j49Pgwdk3vHp+kt/ WVEeMHfDwdeQLutolRn6cUmXlQpJQA1ilSpK2ZmWBiEJONlYurqBWUpw2GaAFU9rom HCD9Le/ppT3jpm0xuH8TpL1a6C5K+W1UuK5LVmBlvU5cakOZW5ywS17w2lhOucQR9A NVC604jYszXRMNYlQHbEGbhJLYCV/DMs0YuH2UHr7CVGUSJUrdMVPtVwbMJWPaidRL p/prRAWHgpw36O/UZVxCwVf0= Received: from [IPv6:::1] (0115-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::115]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id CDA805ABDD2 for ; Wed, 27 Aug 2025 16:50:34 +0300 (EEST) Date: Wed, 27 Aug 2025 16:50:33 +0300 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: S4 hibernate support for FreeBSD User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: <22B468F8-E8F2-4635-B840-8AA314386CFE@ketas.si.pri.ee> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: / X-Spamd-Result: default: False [-0.76 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; NEURAL_HAM_SHORT(-0.98)[-0.976]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; SINGLE_SHORT_PART(0.00)[]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4cBmC40YsPz41Tf oh this is like bucket of water in dry sahara desert=2E=2E=2E From nobody Wed Aug 27 16:02:04 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBq6c6L0Yz66ShH for ; Wed, 27 Aug 2025 16:02:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBq6c0p20z3VDx for ; Wed, 27 Aug 2025 16:02:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-32326e2f0b3so10864a91.2 for ; Wed, 27 Aug 2025 09:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1756310530; x=1756915330; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bUulMfwLjaJWn21kvCW0/y/exVMDqSLBshzhNYu4ti4=; b=c6zyFzTwZnuWF44rhaFXvfJzZbcnRxKCPWJ9TwB47US18kjJisF1BZdw+eaEk64g3M ETTz4L18i1Ra+f2LZ5lkfQxRECwzhUv4sRawSUy6wXBLmnuaAaf34GOU/AuCHi3ET/Fr EP12ljSA6LRCjm9PC9TVRX6dy6MUIHDbMaNooWC7r9n6TAqge6kLYiDD5fIISYquBXWa tbAnZHfh3+pveb//EzROKQOaunNj3ECp2fhrXwa23DbfTEwwcHIOJ6CwRS9w8o2AtCas vwlFtIhaWe2PL4Ufiopo4xFPhTr6q6xY28Hgdz7eRV4LCf0C2p2sMQtVq8na5J1dT0JN QRrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756310530; x=1756915330; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bUulMfwLjaJWn21kvCW0/y/exVMDqSLBshzhNYu4ti4=; b=ZJTK6bQ5bRvOqwopFUhcqqUrlRKQB1wx/7z3tf+f31z+x9HCmghRyoPLp54GbTzOfQ xgqWelHjSRDBv4DAbbz1tliJJlIV/j1yIlcyUhTTt+C38K/cEcXAtJm8+1xa6BIaYfxi P1qVohubavvtmrPXa5H0yXSS7moMTi7I/FmlZaXbAnxFvz+L48rk1Rek6aDVNdWZU6hJ E5t92RgtTFhyJGB6SdKd+WLbZtJztSPZBNUhDYbBWKkZegwfgHQh+TIfC1/IeNrZUpVx OEOH5rvSHoAVtTpR8pjFuQK1Pssn+VQJJKoazoULMVYWwSngB/O/JeHShEZtDT+9aNV1 gjFQ== X-Forwarded-Encrypted: i=1; AJvYcCWjn+SK1rlij+zHR3VlLaObMRGk/XIu/5hjiMPOg8oOZMAERPuDOKoOLMdBsUj0qZnWUmZjsbVPJavSMs+nAYs=@freebsd.org X-Gm-Message-State: AOJu0YzSEEtm5rIhdvo5CHyuKWvsaxth2ptMVgzh/9U5UL4eqXsBQGC9 IetPUewjsqgLswkEeXIqrRXyLPeT0vpLLi5VGjVaGdHeCkUtuhOuX2SxysxVd9W2kI+EYuCHgED L2UeJQhdH+/YcsixxFugURXKARztdYJWwDFa5A2G+6g== X-Gm-Gg: ASbGncupR3w25pGZpJ+knXUc4CW857msVISuPh5KgIY9O2Y6Xrsx/VTukeSV2wcgSkO zhHHf6RQBs42Zm4BSJmhQXLVWt8WxrA2Ms1njebYcTai/8YUzU/wtGVzJLRYJw4Lki65wwAMUej yxM3JsZTUJBIMmo7okiT8Tk8mwQdKJLC/k4+HS8iUgjwGOLXSP0U8e+Bgv5cFf0O2YUwFhhg98K UB/7dyAfWDssQNuhePSEOK053e94YgyLPK57D8= X-Google-Smtp-Source: AGHT+IGfm3ZdOB5BPUYaPnRaQTQxhQrV7uB0AaY2by33GtmrOyMZCAzt+m/igLuc0lhWpvkLg2BVhPLNntYw92PNaEA= X-Received: by 2002:a17:90b:3c8d:b0:325:42f8:d733 with SMTP id 98e67ed59e1d1-32542f8d8e4mr22185576a91.26.1756310529285; Wed, 27 Aug 2025 09:02:09 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 27 Aug 2025 10:02:04 -0600 X-Gm-Features: Ac12FXzSeTpPEAWO0ESGtvqMHdMJl_LN1ceAvCx5U3iiH2KXY241TpjAlF2KDaY Message-ID: Subject: Re: S4 hibernate support for FreeBSD To: obiwac Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="00000000000036b386063d5ae9da" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cBq6c0p20z3VDx --00000000000036b386063d5ae9da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 27, 2025 at 7:20=E2=80=AFAM obiwac wrote: > Hi all! > > The FreeBSD Foundation is beginning work on adding S4 (hibernate) support > to > FreeBSD. Currently we have S4BIOS support, but no hibernate support on > modern > platforms. > > We have started exploring what would be required to bring S4 to FreeBSD a= nd > kib@ has written up some initial findings, along with some open design > questions. We'd like to share this early document with the community to > gather > feedback or identify any pitfalls, and generally open the discussion arou= nd > hibernate. > > You can find the document here (which anyone with the link can add commen= ts > to): > > > https://docs.google.com/document/d/1L6b-gEUQcbRMfSuKIytMPlsZfa_q6HCZmmYtN= 4ysg1M > > At this stage, we're mostly setting our focus to something similar to the > approach taken by OpenBSD's hibernate implementation. We're also thinking > of > giving a lot of the responsibility to reloading the hibernated kernel to > loader(8), as opposed to e.g. Linux, which first boots a preliminary kern= el > which then goes on to load the hibernated kernel. > > But nothing is set in stone. We're mostly hoping to hear from people with > prior > experience in this area, so feedback/comments are welcome! > > Feedback received before the end of September will be easiest to > incorporate. > Please add comments directly into the document shared above, or respond t= o > this > email. I added specific comments to the document. LinuxBoot has had to solve a small subset of this problem, at least the trampoline into the kernel. We setup things to look just like the start entry point, and then change the memory map to be what the kernel wants. For resume, you'd need to do something similar. loader(8) will just run on boot, but there's some information that we'll need to have in the headers because the loader is going to have to re-load things... It will need to do a pass over the saved memory (so a summary map early in the dump would make the incompatible determination faster). So the image will need to be accessible to EFI (don't bother with BIOS boot support, the loader is full there). This will requrie a pass over the disk partitions to read the headers for the partition(s) we might look at. So if we dump this in 'core dump' format that we use for panics, we'll need to tag it so that the loader doesn't try to resume a core dump from a panic. The loader will need to pass the EFI memory map through the trampoline. LinuxBoot does this as another metadata thing (just like ACPI), which suggests that we'd want to build a metadata bundle from the driver that allows us to pass many different types of data bundles to the kernel. We moved away from bootinfo a long time ago via metadata, and I think we'll need to do something akin to it for resuming the kernel, and the resume code in the kernel will need to look at that (I didn't put these details in the doc). I'd very strongly suggest you don't reinvent resume newbus methods. They are your friend, though they might need an augment to hint how we're resuming (though many already assume that they have to redo everything). The PCI bus already saves / restores the BARs because those disappear in D3 state. PCI likely will have to restore bus numbers, and/or finish jhb's work to grow/shrink them, the bridge windows, etc. Hotplug PCIe may change between suspend and resume, and this can affect bus numbering from the Firmware. The pci resume code may need to grow support for this. You may need to manage links, etc here, but that's usually fairly automatic. A lot would depend on what the Firmware does with them. The the extent you can do it, even to the extent of heroics, you don't want to destroy and recreate geom_disks. The upper layers just can't cope. There be a huge lift to make them cope, if you'd even be able to do it. The information just isn't there enough to support departure / arrival. There's a geom layer thing that does this, but you gotta interpose this before the mount for it to be effective. You can defer destroying the soft state (goem_disk, etc) for a time to allow transient failures today (umass does this IIRC), but once destroyed, the upper layers are orphaned and there's no way to recreate them. Network drivers are generally in good shape, and there's good mechanisms to reconstruct the state on a resume, though it's by no means perfect. You'll run into the well known problems, like I suspended on network ROMEO and resumed with only network MUST_DIE available. It's no different than suspend to memory, though. Audio is the same, etc. USB even is the same: it would do the same things that it does now, but it does some things via hardware state, iirc, so that might change. The loader would need some changes here to reload the state, do the trampolines, etc. I made a lot of comments on that on the doc. LinuxBoot has done this sort of thing for a while (the loader gives the memory to the linux kernel, and a trampoline. Linux reboots by tearing the CPU state down to 'boot ready' and then jumps to the trampoline). You'd likely have some lua work to add menu items for this, you'd need to expose this state to lua, and likely give the user a chance to abort a reload, a chance to poke around, and maybe even a chance to interact with the loader and then choose to resume even. You'll need to pass a bundle of data from the boot loader to the kernel. I'd suggest that we do this via the current metadata mechanism (or something similar) because bootinfo was a bad idea in the 90s and I'd hate to remake that mistake. There's some decisions that the kernel can make, and some that the loader will have to make. It's not clear to me what the kernel should do if it decides that it can't resume. It's unlikely to be able to write anything to the resume image early enough to keep the loader from looping. So we need to have a return from this trampoline ability? Or does the boot loader need to make a note with the firmware env variable that 'we tried to resume' so it doesn't loop if the kernel decides too late to return to just reboot. Or does the kernel then read the tea-leaves, note it can't resume, and then acts like the boot loader to harvest the metadata the resume path sent to it, maybe augment it, and jump back to its start routine or an alternative start vector. Given that we write to BSS, I'm guessing this path would be a non-starter: resume the current kernel or reboot with an indication that we have a corrupt image (I've not looked at ACPI to see if supports that directly). And so let's say we are resuming. And we have a watchdog enabled and the watchdog fires, what do we do? The loader would need to grow support for detecting that. Right now, we just disable the watchdog, so maybe this isn't a worry. We don't set it again before jumping to the kernel. Don't bother with boot1.efi support. I plan on removing it soon. I'd also make it a non-goal to support resume in a chain-booted environment= . I'd also augment / include a system UUID in the resume dump. I'd refuse to, by default, use files that have a mismatch. This allows us to suspend to disk, then remove that disk (say the laptop is really dead) and attach it to another machine and not have that other machine get confused if it reboots while it's attached (which can be days if we're mining a subset of it to preserve). The reader code likely won't care, so it could read even from files in a filesystem (though creating them might be tricky for the kernel, it might be helpful for testing). Finally, I'd suggest that 'if it doesn't work now' for suspend to memory, deferring those issues until all the other stuff that does work now is working with suspend to disk. I'd avoid hard-coding the decisions in the loader. I'd suggest we'd want flexibility for a variety of scenarios that you cannot today anticipate (not least, kernel resume bugs that cause a crash w/o writing some reboot cause reason). I'm not sure if you'd need to squelch core dumps in the early stages of this process, or not. During early boot we solve this problem by dumpdev being ignored until devices are back. Since the core dump process goes through the drivers, we may need to avoid it while suspended. Even though we poll in this path, we assume that the device has been initialized and don't check each write. The linux approach of having a resume kernel is interesting, and maybe shouldn't be discounted given the kexec work that's lurking in Phabricator. Here, the resume kernel knows what memory it can use, runs its thing, and then 'kexecs' back to the old kernel (this is from memory of a very old conference presentation, I've not verified this: it might actually be like the crash dump kernel). We also have a 'crush dump' kernel waiting in the wings to write crash dumps in the wings, and that might help us freeze the system, boot into a full kernel, write out the system memory and reboot. This would avoid having to do it in a polling mode and might open up features... Finally, there will be issues you don't anticipate that will cause trouble. This is typical, but I suspect even more so here. Warner --00000000000036b386063d5ae9da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 27,= 2025 at 7:20=E2=80=AFAM obiwac <o= biwac@freebsd.org> wrote:
Hi all!

The FreeBSD Foundation is beginning work on adding S4 (hibernate) support t= o
FreeBSD. Currently we have S4BIOS support, but no hibernate support on mode= rn
platforms.

We have started exploring what would be required to bring S4 to FreeBSD and=
kib@ has written up some initial findings, along with some open design
questions. We'd like to share this early document with the community to= gather
feedback or identify any pitfalls, and generally open the discussion around=
hibernate.

You can find the document here (which anyone with the link can add comments=
to):

https://docs.google.c= om/document/d/1L6b-gEUQcbRMfSuKIytMPlsZfa_q6HCZmmYtN4ysg1M

At this stage, we're mostly setting our focus to something similar to t= he
approach taken by OpenBSD's hibernate implementation. We're also th= inking of
giving a lot of the responsibility to reloading the hibernated kernel to loader(8), as opposed to e.g. Linux, which first boots a preliminary kernel=
which then goes on to load the hibernated kernel.

But nothing is set in stone. We're mostly hoping to hear from people wi= th prior
experience in this area, so feedback/comments are welcome!

Feedback received before the end of September will be easiest to incorporat= e.
Please add comments directly into the document shared above, or respond to = this
email.

I added specific comments to the doc= ument.

LinuxBoot has had to solve a small subset o= f this problem, at least the trampoline into the kernel. We setup=C2=A0thin= gs to look just like the start entry point, and then change the memory map = to be what the kernel wants. For resume, you'd need to do something sim= ilar. loader(8) will just run on boot, but there's some information tha= t we'll need to have in the headers because the loader is going to have= to re-load things... It will need to do a pass over the saved memory (so a= summary map early in the dump would make the incompatible=C2=A0determinati= on faster). So the image will need to be accessible to EFI (don't bothe= r with BIOS boot support, the loader is full there). This will requrie=C2= =A0a pass over the disk partitions to read the headers for the partition(s)= we might look at. So if we dump this in 'core dump' format that we= use for panics, we'll need to tag it so that the loader doesn't tr= y to resume a core dump from a panic. The loader will need to pass the EFI = memory map through the trampoline. LinuxBoot does this as another metadata = thing (just like ACPI), which suggests that we'd want to build a metada= ta bundle from the driver that allows us to pass many different types of da= ta bundles to the kernel. We moved away from bootinfo a long time ago via m= etadata, and I think we'll need to do something akin to it for resuming= the kernel, and the resume code in the kernel will need to look at that (I= didn't put these details in the doc).

I'd= very strongly suggest you don't reinvent resume newbus methods. They a= re your friend, though they might need an augment to hint how we're res= uming (though many already assume that they have to redo everything). The P= CI bus already saves / restores the BARs because those disappear in D3 stat= e. PCI likely will have to restore bus numbers, and/or finish jhb's wor= k to grow/shrink them, the bridge windows, etc. Hotplug PCIe may change bet= ween suspend and resume, and this can affect bus numbering from the Firmwar= e. The pci resume code may need to grow support for this. You may need to m= anage links, etc here, but that's usually fairly automatic. A lot would= depend on what the Firmware does with them.

The t= he extent you can do it, even to the extent of heroics, you don't want = to destroy and recreate geom_disks. The upper layers just can't cope. T= here be a huge lift to make them cope, if you'd even be able to do it. = The information just isn't there enough to support departure / arrival.= There's a geom layer thing that does this, but you gotta interpose thi= s before the mount for it to be effective. You can defer destroying the sof= t state (goem_disk, etc) for a time to allow transient failures today (umas= s does this IIRC), but once destroyed, the upper layers are orphaned and th= ere's no way to recreate them.

Network drivers= are generally in good shape, and there's good mechanisms to reconstruc= t the state on a resume, though it's by no means perfect. You'll ru= n into the well known problems, like I suspended on network ROMEO and resum= ed with only network MUST_DIE available. It's no different than suspend= to memory, though.

Audio is the same, etc. USB ev= en is the same: it would do the same things that it does now, but it does s= ome things via hardware state, iirc, so that might change.

The loader would need some changes here to reload the state, do th= e trampolines, etc. I made a lot of comments on that on the doc. LinuxBoot = has done this sort of thing for a while (the loader gives the memory to the= linux kernel, and a trampoline. Linux reboots by tearing the CPU state dow= n to 'boot ready' and then jumps to the trampoline). You'd like= ly have some lua work to add menu items for this, you'd need to expose = this state to lua, and likely give the user a chance to abort a reload, a c= hance to poke around, and maybe even a chance to interact with the loader a= nd then choose to resume even. You'll need to pass a bundle of data fro= m the boot loader to the kernel. I'd suggest that we do this via the cu= rrent metadata mechanism (or something similar) because bootinfo was a bad = idea in the 90s and I'd hate to remake that mistake. There's some d= ecisions that the kernel can make, and some that the loader will have to ma= ke. It's not clear to me what the kernel should do if it decides that i= t can't resume. It's unlikely to be able to write anything to the r= esume image early enough to keep the loader from looping. So we need to hav= e a return from this trampoline ability? Or does the boot loader need to ma= ke a note with the firmware env variable that 'we tried to resume' = so it doesn't loop if the kernel decides too late to return to just reb= oot. Or does the kernel then read the tea-leaves, note it can't resume,= and then acts like the boot loader to harvest the metadata the resume path= sent to it, maybe augment it, and jump back to its start routine or an alt= ernative start vector. Given that we write to BSS, I'm guessing this pa= th would be a non-starter: resume the current kernel or reboot with an indi= cation that we have a corrupt image (I've not looked at ACPI to see if = supports that directly).

And so let's say we a= re resuming. And we have a watchdog enabled and the watchdog fires, what do= we do? The loader would need to grow support for detecting that. Right now= , we just disable the watchdog, so maybe this isn't a worry. We don'= ;t set it again before jumping to the kernel.

Don&= #39;t bother with boot1.efi support. I plan on removing it soon.
=
I'd also make it a non-goal to support resume in a chain= -booted environment.

I'd also augment / include a s= ystem UUID in the resume dump. I'd refuse to, by default, use files tha= t have a mismatch. This allows us to suspend to disk, then remove that disk= (say the laptop is really dead) and attach it to another machine and not h= ave that other machine get confused if it reboots while it's attached (= which can be days if we're mining a subset of it to preserve). The read= er code likely won't care, so it could read even from files in a filesy= stem (though creating them might be tricky for the kernel, it might be help= ful for testing).
Finally, I'd su= ggest that 'if it doesn't work now' for suspend to memory, defe= rring those issues until all the other stuff that does work now is working = with suspend to disk.

I'd avoid h= ard-coding the decisions in the loader. I'd suggest we'd want flexi= bility for a variety of scenarios that you cannot today anticipate (not lea= st, kernel resume bugs that cause a crash w/o writing some reboot cause rea= son). I'm not sure if you'd need to squelch core dumps in the early= stages of this process, or not. During early boot we solve this problem by= dumpdev being ignored until devices are back. Since the core dump process = goes through the drivers, we may need to avoid it while suspended. Even tho= ugh we poll in this path, we assume that the device has been initialized an= d don't check each write.

The lin= ux approach of having a resume kernel is interesting, and maybe shouldn'= ;t be discounted given the kexec work that's lurking in Phabricator. He= re, the resume kernel knows what memory it can use, runs its thing, and the= n 'kexecs' back to the old kernel (this is from memory of a very ol= d conference presentation, I've not verified this: it might actually be= like the crash dump kernel). We also have a 'crush dump' kernel wa= iting in the wings to write crash dumps in the wings, and that might help u= s freeze the system, boot into a full kernel, write out the system memory a= nd reboot. This would avoid having to do it in a polling mode and might ope= n up features...

=
Finally, there will = be issues you don't anticipate that will cause trouble. This is typical= , but I suspect even more so here.

Warner
--00000000000036b386063d5ae9da-- From nobody Wed Aug 27 16:59:14 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBrNc1l9Kz65Jxv for ; Wed, 27 Aug 2025 16:59:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBrNb5C0Dz3fFG for ; Wed, 27 Aug 2025 16:59:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 57RGxEpS072004; Wed, 27 Aug 2025 19:59:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 57RGxEpS072004 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 57RGxE9g072003; Wed, 27 Aug 2025 19:59:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Aug 2025 19:59:14 +0300 From: Konstantin Belousov To: "Bjoern A. Zeeb" Cc: current@freebsd.org Subject: Re: nfs: panic: fsync: vnode is not exclusive locked but should be Message-ID: References: <38pos3n9-1605-7983-p50s-2ossos99sn21@yvfgf.mnoonqbm.arg> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38pos3n9-1605-7983-p50s-2ossos99sn21@yvfgf.mnoonqbm.arg> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cBrNb5C0Dz3fFG On Wed, Aug 27, 2025 at 01:18:32PM +0000, Bjoern A. Zeeb wrote: > Just netbooted a main (0d843cc2e2a373f01f) GENERIC to do some testing on > a board I rarely use before pushing changes and got the below. > Has this been fixed already? > > ... > Last login: Sun May 25 19:37:45 on ttyu0 > VNASSERT failed: locked not true at /usr/src/bz_wifi_precommit_testing/sys/kern/vfs_subr.c:5795 (assert_vop_elocked) > 0xfffff8000761b000: type VREG state VSTATE_CONSTRUCTED op 0xffffffff81aad768 > usecount 2, writecount 0, refcount 3 seqc users 0 > hold count flags () > flags (VV_VMSIZEVNLOCK|VMP_LAZYLIST) > v_object 0xfffff80005d991f0 ref 0 pages 1 cleanbuf 0 dirtybuf 1 > lock type nfs: SHARED (count 1) > Aug 27 13:16:38 fapu2e4b login[19ileid 18620252 fsid 0x3a3a00ff01 > panic: fsync: vnode is not exclusive locked but should be > cpuid = 3 > time = 1756300598 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0067d3a4c0 > vpanic() at vpanic+0x136/frame 0xfffffe0067d3a5f0 > panic() at panic+0x43/frame 0xfffffe0067d3a650 > vop_fsync_debugprepost() at vop_fsync_debugprepost+0x124/frame 0xfffffe0067d3a690 > VOP_FSYNC_APV() at VOP_FSYNC_APV+0x23/frame 0xfffffe0067d3a6b0 > bufsync() at bufsync+0x3b/frame 0xfffffe0067d3a6e0 > bufobj_invalbuf() at bufobj_invalbuf+0x24f/frame 0xfffffe0067d3a740 > ncl_vinvalbuf() at ncl_vinvalbuf+0x100/frame 0xfffffe0067d3a7b0 > nlm_advlock_internal() at nlm_advlock_internal+0xa7/frame 0xfffffe0067d3aaf0 > nlm_advlock() at nlm_advlock+0x2d/frame 0xfffffe0067d3ab10 > nfs_advlock() at nfs_advlock+0x1d0/frame 0xfffffe0067d3ac30 > vop_sigdefer() at vop_sigdefer+0x30/frame 0xfffffe0067d3ac60 > VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0x51/frame 0xfffffe0067d3ac90 > vn_closefile() at vn_closefile+0x9a/frame 0xfffffe0067d3ad10 > _fdrop() at _fdrop+0x1a/frame 0xfffffe0067d3ad30 > closef() at closef+0x1e3/frame 0xfffffe0067d3adc0 > closefp_impl() at closefp_impl+0x71/frame 0xfffffe0067d3ae00 > amd64_syscall() at amd64_syscall+0x169/frame 0xfffffe0067d3af30 > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0067d3af30 > --- syscall (6, FreeBSD ELF64, close), rip = 0x1ea0dba28cca, rsp = 0x1ea0d6def6b8, rbp = 0x1ea0d6def6e0 --- > KDB: enter: panic > [ thread pid 1955 tid 100182 ] > Stopped at kdb_enter+0x33: movq $0,0x1222d22(%rip) > db> show alllocks > Process 1955 (login) thread 0xfffff80005dda000 (100182) > exclusive lockmgr nfsupg (nfsupg) r = 0 (0xfffffe006b1557e0) locked @ /usr/src/bz_wifi_precommit_testing/sys/fs/nfsclient/nfs_clsubs.c:146 > shared lockmgr nfs (nfs) r = 0 (0xfffff8000761b070) locked @ /usr/src/bz_wifi_precommit_testing/sys/fs/nfsclient/nfs_clvnops.c:3477 > Process 1817 (syslogd) thread 0xfffff80005d85780 (100108) > exclusive lockmgr nfs (nfs) r = 0 (0xfffff800447a33e0) locked @ /usr/src/bz_wifi_precommit_testing/sys/kern/vfs_vnops.c:1243 > You are using nfslockd, right? Try this. commit 881d724a671caa628407373faf0b87a70bfb3218 Author: Konstantin Belousov Date: Wed Aug 27 19:57:06 2025 +0300 nfs client: switch nfs_advlock() to use exclusive vnode lock It eliminates the need to upgrade the lock in the function. More importantly, the calls to nfs_advlock_p()/nlm_advlock() sometimes flush buffers, which requires exclusive locking. Reported by: bz diff --git a/sys/fs/nfsclient/nfs_clvnops.c b/sys/fs/nfsclient/nfs_clvnops.c index a8b06fdb261b..eee571a04821 100644 --- a/sys/fs/nfsclient/nfs_clvnops.c +++ b/sys/fs/nfsclient/nfs_clvnops.c @@ -3474,7 +3474,7 @@ nfs_advlock(struct vop_advlock_args *ap) u_quad_t size; struct nfsmount *nmp; - error = NFSVOPLOCK(vp, LK_SHARED); + error = NFSVOPLOCK(vp, LK_EXCLUSIVE); if (error != 0) return (EBADF); nmp = VFSTONFS(vp->v_mount); @@ -3511,11 +3511,6 @@ nfs_advlock(struct vop_advlock_args *ap) cred = p->p_ucred; else cred = td->td_ucred; - NFSVOPLOCK(vp, LK_UPGRADE | LK_RETRY); - if (VN_IS_DOOMED(vp)) { - error = EBADF; - goto out; - } /* * If this is unlocking a write locked region, flush and From nobody Wed Aug 27 17:26:50 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBs0Q2fZ8z65LMH for ; Wed, 27 Aug 2025 17:27:02 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBs0Q1fsZz3kFN; Wed, 27 Aug 2025 17:27:02 +0000 (UTC) (envelope-from olivier@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756315622; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=sJSrGrTSuzWrGn29VNwhkWpJIgangN3vPagnvf9KZ0U=; b=NwE9fYuJ1mBAf4qECpzMgjYz+lK4FEID4sPeMqDCCA37Tg4XFvKF40DBvEbxj12kAzyeA6 qGtEPQzeoNqdGYKOfgrZne6tXAxXy5/AWLQBn3twyclM4q0iXgV4w3MiF7oxfthBIIvw7W 7e8hQ+psgnQX6Quq/KUltiLRscu12dO8Oi+38RxNUcJUDkU/o0ADi1in80E+N/V+GVEVnP J3T1ASVIEfn5THIb1qaBRnzWJU0GeVSd3/OWjmBuMfVBVtSpCBI0MA2g2E6GhhBpxOiE2y OPayDs5IgpgwixvngNc8+P6f2knS2eN7SMH8TaA2oHP//kPermFKU9T6zW9tow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756315622; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=sJSrGrTSuzWrGn29VNwhkWpJIgangN3vPagnvf9KZ0U=; b=gUAfY2czsvpKFoOcIQ0xlNMcQQt5qBRXscjhnJb8Q8qQI2tZppXhcPbvEOqsYLeN1p22nc fBAFbvOHg4ETOxAQ+rVQcmXaUu5MWSv9a6pRcR+NGb1DgTcryamtxtfQrs59uTe4TFOV5o +NGujnxOJ3+8BxDFU3mYIOfOFXm6H7oZrTJjvfe7Eo/kUnv9nEqHjZg15G1TEJf2c33zal GB0q5VFaqnI8gzDkTWKcuoHEa7djTdOKeozhiDF2YZOji7I9S8akwFmypKl/0/Dk8AGbO2 1XQx7czNy4T18BzbU5J3kQHk2JV8FTGypQGZtKYo8cOODAlJIhJYR1o4dDf2Sg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756315622; a=rsa-sha256; cv=none; b=WOAzRLBxQj1vKAl404BAMAlrmH8uT52xhSfYRFt0A848k5aSWuLGQBbEAZO4QUmbpmkz9T TcG6XMT65G8MYlZ0jqxynX1cABty9DcWIIManvcylsYLndFGxB1xpIRNZN085ZvI+vC+7H 5yhoGlZfg/o828Q+yy2NN3XgMW6byf72nmNCNSgISEZ34uJBjPfD81rDalPbAJpFRkJ1tq 6SfUgXs912fPJmZNq1Z+qL9iAeP8NKTjLIlPx4frIe+UT1So1vb0OgaWvb6gcMAdbUSlZc O/Cvrb8Af3KpZOXkt4KM4EkR8ygrw/GUz7aYnGQgVZsBJRv5Nr/4qBmmXTlwUw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) (Authenticated sender: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cBs0Q0lcGzBCH; Wed, 27 Aug 2025 17:27:02 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-qv1-f53.google.com with SMTP id 6a1803df08f44-70ddab8117cso1644186d6.0; Wed, 27 Aug 2025 10:27:02 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWyhjCL5qHBTOPBBliXp8kguBTMX1JaldMR6iEBVKHOwoWhMeOsFG7orhrDD3Te/+8CmFzQLzQFXXvLEb8TrA==@freebsd.org X-Gm-Message-State: AOJu0YwJom0suReKd1diRBK9If1TRNLWDsPiw5xoXOYu437zEPXAbTlx k+wpgoLY8GoKD/LMtaHCicAt7HAhfncd4L4DiW+wBMv1Mdzkz1QLQXCBFXdQj+pkv/SjI02jVHV 6k2wewXDFDP5ohVr5w0eqgeC/BjolGVc= X-Google-Smtp-Source: AGHT+IHBkXep44DMKxQAQ8p1mxYvhWJNbvOFDee7ojfpKEfAYJ2MgWvTCvh6UGrBdB9Mr7qrFX7+fXvdORcExaRjoPc= X-Received: by 2002:ad4:5967:0:b0:70d:ee9b:9ce7 with SMTP id 6a1803df08f44-70dee9ba665mr2165716d6.15.1756315621562; Wed, 27 Aug 2025 10:27:01 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Wed, 27 Aug 2025 19:26:50 +0200 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXwF4Tgyyxzcfub3FH30foHkFMEQy7abj9fD8DcLOdX9Hz6fdFKkar2Y4h8 Message-ID: Subject: Re: August 2025 stabilization week To: freebsd-current@freebsd.org, src-committers@freebsd.org Cc: Gleb Smirnoff Content-Type: multipart/alternative; boundary="000000000000bca2e2063d5c1899" --000000000000bca2e2063d5c1899 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 26, 2025 at 7:32=E2=80=AFPM Gleb Smirnoff = wrote: > > The performance & stability A/B testing at Netflix just started and we > expect to have results tomorrow. > > I will be AFK for the rest of the week, and thus passing responsibility > for the stabweek on Olivier Cochard olivier@. He will update on the > A/B test results, collect any success/failure reports and close the > week. > > -- > Gleb Smirnoff > Wednesday update: - We noticed a 100% reproducible kernel panic while running the ZFS regression tests (cd /usr/tests; kyua test sys/cddl/zfs/tests/). This issue was reported here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D2891= 31 - Our daily A/B test (22-hour run on 32 CDN servers total) at Netflix didn't show any regression or stability issues (stabweek July vs August). I was expecting more visible differences due to the OpenSSL upgrade, but I will have to wait for our long AB/BA performance results to get valuable data about this. - I've noticed that some of our ARM EC2 instances attach their ephemeral disk with a delay and display this error message in dmesg: cam_periph_alloc: attempt to re-allocate valid device nda0 rejected flags 0x100 refcount 4 ndaasync: Unable to attach to new device due to status 0x6 I'm still waiting for our contributions about this stabweek before closing the week. Regards, Olivier --000000000000bca2e2063d5c1899 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On = Tue, Aug 26, 2025 at 7:32=E2=80=AFPM Gleb Smirnoff <glebius@freebsd.org> wrote:

The performance & stability A/B testing at Netflix just started and we<= br> expect to have results tomorrow.

I will be AFK for the rest of the week, and thus passing responsibility
for the stabweek on Olivier Cochard olivier@.=C2=A0 He will update on the A/B test results, collect any success/failure reports and close the
week.

--
Gleb Smirnoff

Wednesday update:

- We noticed a 100% reproducible kernel = panic while running the ZFS regression tests (cd /usr/tests; kyua test sys/= cddl/zfs/tests/). This issue was reported here: https://bugs.freebsd.org/bugzil= la/show_bug.cgi?id=3D289131

- Our daily A/B test (22-hour run on= 32 CDN servers total) at Netflix didn't show any regression or stabili= ty issues (stabweek July vs August). I was expecting more visible differenc= es due to the OpenSSL upgrade, but I will have to wait for our long AB/BA p= erformance results to get valuable data about this.

- I've notic= ed that some of our ARM EC2 instances attach their ephemeral disk with a de= lay and display this error message in dmesg:
cam_periph_alloc: attempt t= o re-allocate valid device nda0 rejected flags 0x100 refcount 4
ndaasync= : Unable to attach to new device due to status 0x6

I'm still wai= ting for our contributions about this stabweek before closing the week.
=
Regards,
Olivier
<= /div>
--000000000000bca2e2063d5c1899-- From nobody Wed Aug 27 18:52:06 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBtty4m1sz65TBD for ; Wed, 27 Aug 2025 18:52:26 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBtty1nPsz40mQ; Wed, 27 Aug 2025 18:52:26 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-61c4f73cf20so271801a12.0; Wed, 27 Aug 2025 11:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756320740; x=1756925540; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=YAGYI64roA+9S72Cog6B3bzCVXD1cbJzeCspuaYoJ3E=; b=OGmtL5hhUlM+XQq9utvMKLWi6ZCNUsdxnYREfaJRE85V49ag76ZJEq217/5bruLjEW fGFZEjW/HTBoYuCKq27dq8JK/v1bRbjBVSF8BPWtyqxA4+MNKdLtFkyQI3mR1Yg1xBfu pdbp0lNFdJ1Ff/NtxgoLWRBqxRonhLoIavkASVIJF/T98yxXFrCfpxhDaIcQr60s6fkD 1RX0Ybsz8Bo/vzd908+BniXlRqB+1hC9n7nncUUe7b4IdCSbqSGK1Y4oyZffqFUIjIwR DKIMvAXcbqHfOaAXl4neSJ5qmTfIr/W8ZwEQ5gzxjoEKWVMRWEP5OoPcFy9v8l0pzuCp Hb3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756320740; x=1756925540; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YAGYI64roA+9S72Cog6B3bzCVXD1cbJzeCspuaYoJ3E=; b=tsNaTZzkaOYaVC+ih1r85yfZMevWHfCQoGsX1rMsofLKJtvL4d9O69atzeXmohxVm5 vabK6T/A9Tqn0ucaJcUN9MCqCm42RFh2EvMGgBLZ75uqu/ZF+dZnttgyNJBgUfGH/446 PRimnEawC1LYUXniPFNpXjr6N3/q8K6Fw2KO3PwXATp8RxxW4L8RoY4dyrjvFdbF8v7e BJGMtrK/HcHH/bz/IkNZa6xDF6uuxYnwSSI99qgtA/+lAeLPmrhA1qGmjKWlOX1xdT9z 8R+IAjibZUoAnK4XZkRe7bGFcKmalZbu4LGPsePq14Zidl2ox2Y9MF5Zui9kjQeAi6Kk mvlg== X-Forwarded-Encrypted: i=1; AJvYcCWtbGZPERuE4DhonWVS/8lJwYEN3G5RJcH4v6J6MVh4PtnAymRp30KPHZjWj+rJoft13rPqdBpyRtw/SHpTXLs=@freebsd.org X-Gm-Message-State: AOJu0YwhocJFmWESc3dMcrSeCVT4sgv/0/XjTbN1ikldurFXztTc/EZB hiBS/K8LdaNxCxOgg30dYdqH6oDKMyj34k//tKWCu1ccOMB2X1xBeA0RDi8MiYtuG476sTKKqZe IMPOmVYA5F1g45DadIcWsX1A+tt1Qdg== X-Gm-Gg: ASbGncvPm9TCYYMjBQelkJZvrtY6NPsuaunaea9K9/uMh/EzDniaudnXmXesCKLr73S cMkkdnDuODQCZUraMdTF3OAVobn4ZmD6Tdi8laK9+P9n/oUHgI+Ak3PRtDl+56Riaek9uSEQDke Ahv4BYf2W7t5UsMwfkKct/F4Er/3X0QLe08kGlrWt0onqiOIsQYwSDjobD1K1GeAUE7p8h7zfg7 JtwmS0ubPXOZ8GqSlAyPDp0viDtuSEOFuvw5kWbKSfaRz3LMQ== X-Google-Smtp-Source: AGHT+IGk00PdGoiB1LyGYLW2LGoXAFY5YNRfbc6tcW/NkgHbqjoeT1NUKmRi7AoQPtqzxZ7GHocyXOqC3ZJs7BCbKwU= X-Received: by 2002:a05:6402:13c9:b0:61c:8d3e:b0b1 with SMTP id 4fb4d7f45d1cf-61c8d3eb3a2mr6704181a12.3.1756320739461; Wed, 27 Aug 2025 11:52:19 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Wed, 27 Aug 2025 11:52:06 -0700 X-Gm-Features: Ac12FXzNuAqr2vfFqWyGQ8Wf0ey8MWvNPUvG8TKh6cfTN4BWYLvDd2-d2q0_IGY Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Alexander Leidinger Cc: Gleb Smirnoff , Cy Schubert , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cBtty1nPsz40mQ On Wed, Aug 27, 2025 at 1:18=E2=80=AFAM Alexander Leidinger wrote: > > Am 2025-08-26 19:21, schrieb Rick Macklem: > > On Tue, Aug 26, 2025 at 9:35=E2=80=AFAM Gleb Smirnoff > > wrote: > >> > >> On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff wrote: > >> T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem wrote: > >> T> R> Ok. If you install FreeBSD-13.5 and then "pkg install heimdal", > >> you get a > >> T> R> working Heimdal-7.8 in ports. > >> T> R> > >> T> R> Now, I have another challenge. Fixing the master passwords. > >> T> R> I'll work on it later to-day. > >> T> > >> T> I have applied two commits from Heimdal from 2012 that add 'kadmin > >> dump -f MIT' > >> T> feature to our base heimdal and polished them to compile. So far > >> it doesn't > >> T> work yet, either create an empty dump or create a core dump, > >> instead of > >> T> database dump :) I'll see how difficult it is going to further > >> resolve that to > >> T> a working condition. If I succeed, then having 'dump -f MIT' in > >> base without > >> T> any ports would be the best solution. Can also be merged to > >> FreeBSD 14.4. > >> > >> Good news. In the above paragraph I was testing my change incorrectly > >> - threw > >> the new binary on a system running unpatched libraries. When run > >> correctly, > >> it successfully produced something that looks like a correct dump in > >> MIT format. > >> I haven't yet tried to load it into MIT kdc yet, though. > > You might have better luck than me, but if I just loaded it, > > "kadmin.local" wouldn't > > work. > > To get it loaded, I had to: > > - edit the mit.dump and remove the entries for > > K/M, kadmin/admin, kadmin/changepw and krbtgt/REALM. > > Then I... > > # kdb5_util create -s > > and > > # kdb5_util load -update mit.dump > > -after that, kadmin.local would find the prinicipals, but > > a "kinit" wouldn't work until I did a "change_password" on it. > > Have you tried "kadmin -l dump --decrypt --format=3DMIT"? As I noted in the last post, this does not work. I think the problem is that the current MIT KDC requires keys to be encrypted in the master key. If the old Heimdal-1.5.2 KDC was configured with a master key of type aes256-cts-hmac-sha1-96, then it might be possible to put that master key on the MIT KDC and make things work. --> Since the Heimdal default for the master key is des3-cbc-sha1, almost all Heimdal-1.5.2 KDCs will have used that. If you "kadmin -l dump --decrypt old.dump" on the Heimdal-1.5.2 KDC, that file will load and work in the Heimdal-7.8 KDC. However, the next stage of "kadmin -l dump --decrypt -f MIT mit.dump" results in a file that, after loading into the MIT KDC via "kdb5_util load mit.dump" is reported as corrupt/incomplete by kadmin.local, etc. I think what would be needed is a command that both writes out a dump in MIT format and converts the encrypted keys to the new master key (kdb5_util can do this, but the database has to be loaded first) instead of just --decrypt'ng them. The only thing I have not yet tried is getting the MIT KDC to use the old des3-cbc-sha1 master key from the Heimdal-1.5.2 KDC, but I doubt it will allow it? rick > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From nobody Wed Aug 27 19:38:33 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBvwM1mh4z65XFS; Wed, 27 Aug 2025 19:38:43 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBvwL6B8qz46Vl; Wed, 27 Aug 2025 19:38:42 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id DBD62C3F3D; Wed, 27 Aug 2025 19:38:34 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 57RJcX0n009344; Wed, 27 Aug 2025 19:38:33 GMT (envelope-from phk) Message-Id: <202508271938.57RJcX0n009344@critter.freebsd.dk> To: Warner Losh cc: obiwac , freebsd-arch@freebsd.org, freebsd-current@freebsd.org Subject: Re: S4 hibernate support for FreeBSD In-reply-to: From: "Poul-Henning Kamp" References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <9342.1756323513.1@critter.freebsd.dk> Content-Transfer-Encoding: 8bit Date: Wed, 27 Aug 2025 19:38:33 +0000 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cBvwL6B8qz46Vl -------- Warner Losh writes: > The the extent you can do it, even to the extent of heroics, you don't want > to destroy and recreate geom_disks. > […] > but once destroyed, the upper layers are orphaned and there's > no way to recreate them. In terms of "getting to S4" I agree 100%, but I dont think the road should end there. It was a design decision that geom treat all arriving disk as "a new disk", because apart from a few tour-de-force academic exercises, all current filesystems assume the existence of a "mount-session" during which they are in supreme control of the content of their underlying block-store, and there no useful way to determine if the block-store was modified while not under our control. We reasonably expect that nobody mess with our disks while in S3, even though much modern hardware would allow it, and again, that can help us "get to S4". However, in "real S4" filesystems need to learn to suspend, and to resume when geom-tasting offers up a provider which contains their data - even if all other aspects of that provider is different. But... If it were up to me, S4 suspend would operate at the kernel/user-land boundary and not the of kernel/hardware boundary. Ideally we own one side of the kernel/hardware boundary and the other side is well documented. In practice: Not so much. In comparison we own 100% of both sides of the kernel/user-land boundary - nothing can prevent us from making it work. Suspend: * Send all processes SIGSUSPEND which defaults to calling a new "zzz(2)" syscall. Smart procs catch and do something sensible first. * Pause any processes that did not take the hint. * EAGAIN all userland threads in the kernel up to the syscall level. * Save all processes to storage along with their kernel state. * Save global kernel state to storage. * Tell the firmware to go ahead. Resume: * Boot a kernel on some hardware. Usually the same kernel on the same hardware, but it doesn't have to be (!) * Instead of /sbin/init execute /sbin/resume, which: * replays global kernel state * reloads the saved processes * replays their individual kernel state (open files etc.) * Mark their zzz(2) as done and hand them to the scheduler. Smart processes do smart thing when zzz(2) returns. * Send the EAGAIN user threads in syscall level back down. The kernel state to be saved amounts to something like: Per process: * open filedescriptors, including filesystem state * mapped files * POSIX IPC and SHMEM * AF_UNIX sockets (& pipes) * Per process device driver state. Global: * mounts * sysctls * jails * network interface and route config * device driver state, as required. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Wed Aug 27 19:49:13 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBw8W2xF6z65YBc for ; Wed, 27 Aug 2025 19:49:15 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBw8V4V3Sz49C1; Wed, 27 Aug 2025 19:49:14 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 31D03C43AD; Wed, 27 Aug 2025 19:49:13 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 57RJnD7G009480; Wed, 27 Aug 2025 19:49:13 GMT (envelope-from phk) Message-Id: <202508271949.57RJnD7G009480@critter.freebsd.dk> To: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= cc: freebsd-current@freebsd.org, src-committers@freebsd.org, Gleb Smirnoff Subject: Re: August 2025 stabilization week In-reply-to: From: "Poul-Henning Kamp" References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9478.1756324153.1@critter.freebsd.dk> Date: Wed, 27 Aug 2025 19:49:13 +0000 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cBw8V4V3Sz49C1 The only thing I have noticed on my laptop was one time where the USB ports did not work after resume, but I have not had time to experiment further. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Wed Aug 27 20:33:12 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cBx7S0DJTz65chh for ; Wed, 27 Aug 2025 20:33:24 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (prime256v1) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E6" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cBx7R2p2fz4GFM for ; Wed, 27 Aug 2025 20:33:23 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; none Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id 5D027A64805; Wed, 27 Aug 2025 20:33:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zabbadoz.net; s=20240622; t=1756326787; bh=kY7vLUyoI0zS+ZBGaK2Z5DBP1Wp4xsWQTxaFA+mXXQI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SH8K7svqsbMAAu8eC5vBPWepnZJ0ku1BHsu6TA3qmJI/f/VHHthxAbDks1iVmBxtL Fa+C+/d9gAvKdWby8akCii7NOMvTAwrbsBUxluPPxRM+ws0hXb/EvSrPrXuBd3s5rm rnsMs5D6LdlsyIsVVeSaIgRwd32/toyj6saIp+PHwPT9qRqg8ePAJt225MpmGpX89H E7VF8PEBiU/qlSRpB8bzyb7j35UUcck/8vabIc1+QX8o2VqR4321YmXk+1K8XNqRfQ XcXOQzA//hYU3kCgpMBAqjd06tuo6D3Gy8BwlWNy6aOHesquXCsovQuiuQeYKjLvEZ nPQF5FfgPRmYw24KypO7dE2ak9I/C8+O3TonzeLzHJwRGzNhCqTxmSdAeqKJ29i/A+ hsHMbqVhhhi1IHiw3S8Tf7M6TcMjZ+H1waXQ46fRFMNeLnJTeRdJbdGS6ljaB+Ci00 4+6AQR5k1eU5iR4PJ7dubWsKWeG8rpvsEHD1jPzokUVCvVVefKyF9I0I0/scw08ChU 7nixhShisUa4hlzTLK9BLvnsXvCKRjYkmK9Yhsuz6gpDIczXlNwGBsBgHlI5D29chQ QQMogMzHcl1XGMuIQu7pWkJes9GPpVZOwtkAwYklPYrN3hAdY3GVm0fExDoSgpmtAU oLNKlYEIZUSCpzgycBEFgqGA= Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 2FD822D029E3; Wed, 27 Aug 2025 20:33:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id 5XOJGGad1b-X; Wed, 27 Aug 2025 20:33:13 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:a66b:b6ff:fe40:39a9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 998472D029D8; Wed, 27 Aug 2025 20:33:12 +0000 (UTC) Date: Wed, 27 Aug 2025 20:33:12 +0000 (UTC) From: "Bjoern A. Zeeb" To: Konstantin Belousov cc: current@freebsd.org Subject: Re: nfs: panic: fsync: vnode is not exclusive locked but should be In-Reply-To: Message-ID: <8n54sp24-n885-0749-n12s-44811pr0290s@yvfgf.mnoonqbm.arg> References: <38pos3n9-1605-7983-p50s-2ossos99sn21@yvfgf.mnoonqbm.arg> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3320, ipnet:2003::/19, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cBx7R2p2fz4GFM On Wed, 27 Aug 2025, Konstantin Belousov wrote: > On Wed, Aug 27, 2025 at 01:18:32PM +0000, Bjoern A. Zeeb wrote: >> Just netbooted a main (0d843cc2e2a373f01f) GENERIC to do some testing on >> a board I rarely use before pushing changes and got the below. >> Has this been fixed already? >> >> ... >> Last login: Sun May 25 19:37:45 on ttyu0 >> VNASSERT failed: locked not true at /usr/src/bz_wifi_precommit_testing/sys/kern/vfs_subr.c:5795 (assert_vop_elocked) >> 0xfffff8000761b000: type VREG state VSTATE_CONSTRUCTED op 0xffffffff81aad768 >> usecount 2, writecount 0, refcount 3 seqc users 0 >> hold count flags () >> flags (VV_VMSIZEVNLOCK|VMP_LAZYLIST) >> v_object 0xfffff80005d991f0 ref 0 pages 1 cleanbuf 0 dirtybuf 1 >> lock type nfs: SHARED (count 1) >> Aug 27 13:16:38 fapu2e4b login[19ileid 18620252 fsid 0x3a3a00ff01 >> panic: fsync: vnode is not exclusive locked but should be >> cpuid = 3 >> time = 1756300598 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0067d3a4c0 >> vpanic() at vpanic+0x136/frame 0xfffffe0067d3a5f0 >> panic() at panic+0x43/frame 0xfffffe0067d3a650 >> vop_fsync_debugprepost() at vop_fsync_debugprepost+0x124/frame 0xfffffe0067d3a690 >> VOP_FSYNC_APV() at VOP_FSYNC_APV+0x23/frame 0xfffffe0067d3a6b0 >> bufsync() at bufsync+0x3b/frame 0xfffffe0067d3a6e0 >> bufobj_invalbuf() at bufobj_invalbuf+0x24f/frame 0xfffffe0067d3a740 >> ncl_vinvalbuf() at ncl_vinvalbuf+0x100/frame 0xfffffe0067d3a7b0 >> nlm_advlock_internal() at nlm_advlock_internal+0xa7/frame 0xfffffe0067d3aaf0 >> nlm_advlock() at nlm_advlock+0x2d/frame 0xfffffe0067d3ab10 >> nfs_advlock() at nfs_advlock+0x1d0/frame 0xfffffe0067d3ac30 >> vop_sigdefer() at vop_sigdefer+0x30/frame 0xfffffe0067d3ac60 >> VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0x51/frame 0xfffffe0067d3ac90 >> vn_closefile() at vn_closefile+0x9a/frame 0xfffffe0067d3ad10 >> _fdrop() at _fdrop+0x1a/frame 0xfffffe0067d3ad30 >> closef() at closef+0x1e3/frame 0xfffffe0067d3adc0 >> closefp_impl() at closefp_impl+0x71/frame 0xfffffe0067d3ae00 >> amd64_syscall() at amd64_syscall+0x169/frame 0xfffffe0067d3af30 >> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0067d3af30 >> --- syscall (6, FreeBSD ELF64, close), rip = 0x1ea0dba28cca, rsp = 0x1ea0d6def6b8, rbp = 0x1ea0d6def6e0 --- >> KDB: enter: panic >> [ thread pid 1955 tid 100182 ] >> Stopped at kdb_enter+0x33: movq $0,0x1222d22(%rip) >> db> show alllocks >> Process 1955 (login) thread 0xfffff80005dda000 (100182) >> exclusive lockmgr nfsupg (nfsupg) r = 0 (0xfffffe006b1557e0) locked @ /usr/src/bz_wifi_precommit_testing/sys/fs/nfsclient/nfs_clsubs.c:146 >> shared lockmgr nfs (nfs) r = 0 (0xfffff8000761b070) locked @ /usr/src/bz_wifi_precommit_testing/sys/fs/nfsclient/nfs_clvnops.c:3477 >> Process 1817 (syslogd) thread 0xfffff80005d85780 (100108) >> exclusive lockmgr nfs (nfs) r = 0 (0xfffff800447a33e0) locked @ /usr/src/bz_wifi_precommit_testing/sys/kern/vfs_vnops.c:1243 >> > > You are using nfslockd, right? > Try this. > > commit 881d724a671caa628407373faf0b87a70bfb3218 > Author: Konstantin Belousov > Date: Wed Aug 27 19:57:06 2025 +0300 > > nfs client: switch nfs_advlock() to use exclusive vnode lock > > It eliminates the need to upgrade the lock in the function. > More importantly, the calls to nfs_advlock_p()/nlm_advlock() sometimes > flush buffers, which requires exclusive locking. > > Reported by: bz > > diff --git a/sys/fs/nfsclient/nfs_clvnops.c b/sys/fs/nfsclient/nfs_clvnops.c > index a8b06fdb261b..eee571a04821 100644 > --- a/sys/fs/nfsclient/nfs_clvnops.c > +++ b/sys/fs/nfsclient/nfs_clvnops.c > @@ -3474,7 +3474,7 @@ nfs_advlock(struct vop_advlock_args *ap) > u_quad_t size; > struct nfsmount *nmp; > > - error = NFSVOPLOCK(vp, LK_SHARED); > + error = NFSVOPLOCK(vp, LK_EXCLUSIVE); > if (error != 0) > return (EBADF); > nmp = VFSTONFS(vp->v_mount); > @@ -3511,11 +3511,6 @@ nfs_advlock(struct vop_advlock_args *ap) > cred = p->p_ucred; > else > cred = td->td_ucred; > - NFSVOPLOCK(vp, LK_UPGRADE | LK_RETRY); > - if (VN_IS_DOOMED(vp)) { > - error = EBADF; > - goto out; > - } > > /* > * If this is unlocking a write locked region, flush and > This booted and I could log in at least once now. Thank you! -- Bjoern A. Zeeb r15:7 From nobody Wed Aug 27 21:33:49 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cByTR1LSVz65hbJ; Wed, 27 Aug 2025 21:34:03 +0000 (UTC) (envelope-from obiwac@gmail.com) Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cByTQ6FL4z4NCl; Wed, 27 Aug 2025 21:34:02 +0000 (UTC) (envelope-from obiwac@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-afeceee8bb1so35456866b.3; Wed, 27 Aug 2025 14:34:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756330441; x=1756935241; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WnPh3cocatJh0IrX7wbDNrhIMFawQNwNWDktIKPr4Mc=; b=PsacawJyXI6r8k3q31vMQ8Z8bbKH5HcG4YKsWws8SvZVNM6KEIs70kNK1QZwk072l5 PZ+Mak4MuvtFF0D3souww0Gb7rdeHjK0HhxaWI3eVqaRmjPHx45ijnT0DaQqELkP+RXX SiVcQT9fsJErH/U6ugZVBcOmABDuOtt0UciLLXSRjdV7YgPFl7oUdDA8FybvoXO25sys w6HcKbBBwEPfWfCRfTQFYmHUmACi4XlBsRb8GYETVCxxd0BNXWkn4iAOcaivuW0alOzj NJBJhFmFk8+VURfkHukhK3XFLurPS+pgH1n0dKaRkiQ4MTzVQ99aUJqYKiLOwAnb12X6 s91A== X-Forwarded-Encrypted: i=1; AJvYcCVtR1I+YMS+IxCOavg3Ttxt/S59CQT4q206NNauZHaXlEf88Y65uglpuAIhFoLEneGGv2vQQjeBQ7G8yfA=@freebsd.org, AJvYcCWKK7pRlWcbRV18sDlJQ7IszOJj2/c3bK6n0yNhCC6d0GEd4QxfNApqYnMMN6oP30nrCv+zGmMsjEkpdIdCawXB@freebsd.org X-Gm-Message-State: AOJu0YxH3J2sobMU01FGZ39WaweOwci0b7DyeAa7z9a+FA2NoDKUBrvw zNGJYY+hiXn1IBs2+zxyWw2EPEoxhG51TMCtA3uMXEq+rTzLu+U/2pW6PL/jJFdk X-Gm-Gg: ASbGncvSkwBF0KAIlaubZUrxwbkgcWMjXIbcM2kgdp4+t/JGmQnJkJmI+DJFJaf0aaT 3XA10xxUO02Bxg/SljAbqTU77/ZI0ZVYHJvMHZkjqpDTyFecRI+WMceYXWcWbxtV0VOOmubygVx UzY8v9PtcTe/aEQpCImGWIAuDtzdlGYPes06J2rvul4AWwWIMjGgKPpX7Oy8GlPsiOrtv0/WSEm aP/8O+KNOm9bHGCfgEOz3i7CdX2rxrq0AywWIomW44DZ/VQuMXSbjOZaSXx2p1qvbL6cSmxjE6n vne/YN0Zgq/SVpDf4quM7ZI4CrHsA6jm4tzRpfe9r4cQ5PUQQG1yTPcIo3ZUUziPo2H5ZLdg9nu v+DBriEFFXHrAS8lbHnyCtnIqwu4Fb8UtDf45//+1EhoHlUv2kBjjbP+kwQ== X-Google-Smtp-Source: AGHT+IEaRyy90QnJaih4XsBc7K75l5aWDDEb2b6cuNlV85MP5paTK93qwy+EttIwC37Ge/iLF0uOEg== X-Received: by 2002:a17:907:ea8:b0:afd:e687:d280 with SMTP id a640c23a62f3a-afe295d7033mr1757765966b.44.1756330441183; Wed, 27 Aug 2025 14:34:01 -0700 (PDT) Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com. [209.85.218.53]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-afeb049133dsm404410666b.75.2025.08.27.14.34.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Aug 2025 14:34:00 -0700 (PDT) Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-afcb7a16441so35979966b.2; Wed, 27 Aug 2025 14:34:00 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUMIc/HdTRHSampDJF01KnboEQJsMi+sKysVy3Ux6SIaBBGu2cUQazPVsomQG3BxauvfA92uPorgAAEEZM=@freebsd.org, AJvYcCXFgHrsW8p5CwHHIphlFKPMmqpemIJZxXFLTwW5flJCVPUWc7fYwJmbHpPhfDy6wBxA+PpRSeD/J8px1IVlLGsy@freebsd.org X-Received: by 2002:a17:907:1ca9:b0:ae6:efe1:5baf with SMTP id a640c23a62f3a-afe28fbf519mr2068570966b.19.1756330440081; Wed, 27 Aug 2025 14:34:00 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <202508271938.57RJcX0n009344@critter.freebsd.dk> In-Reply-To: <202508271938.57RJcX0n009344@critter.freebsd.dk> From: obiwac Date: Wed, 27 Aug 2025 23:33:49 +0200 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXwMr9gX_Sq_urIQgIgfzTvF1JJjp2vMLs6Bl7HA2mK0Iv_FXoGMB2bkHfs Message-ID: Subject: Re: S4 hibernate support for FreeBSD To: Poul-Henning Kamp Cc: Warner Losh , freebsd-arch@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cByTQ6FL4z4NCl Thanks for your in-depth responses! > It's not clear to me what the kernel should do if it decides that it can'= t resume. We could pass the burden on the user to select a different option at the loader. E.g. the kernel could show a persistent error message if failing to resume from hibernate, waiting for user input to reboot. I don't think the least-surprising option would be to have the loader just boot normally if the previous S4 resume failed at least. > The linux approach of having a resume kernel is interesting, and maybe sh= ouldn't be discounted given the kexec work that's lurking in Phabricator. Open to trying this out, and it might be quicker to get something working with kexec than working in the loader. Actually, doing it this way would open the doors to having the initial kernel load a small graphical environment to prompt for a password for decrypting the drive/swap file, rather than having to shove this in loader. This is what systemd-ask-password-plymouth does, though I don't know if any Linux distros support this on resuming from hibernate. Maybe a little heavy though vs putting in loader. phk@, I like the idea of operating at the kernel/userland boundary, but this would make resuming from S4 have pretty high latency right? How would passing driver state from the previous kernel to the new one work in practice without first initializing the driver? We couldn't just suspend/resume in this case I guess. On Wed, 27 Aug 2025 at 21:38, Poul-Henning Kamp wrote: > > -------- > Warner Losh writes: > > > The the extent you can do it, even to the extent of heroics, you don't = want > > to destroy and recreate geom_disks. > > [=E2=80=A6] > > but once destroyed, the upper layers are orphaned and there's > > no way to recreate them. > > In terms of "getting to S4" I agree 100%, but I dont think > the road should end there. > > It was a design decision that geom treat all arriving disk as "a > new disk", because apart from a few tour-de-force academic exercises, > all current filesystems assume the existence of a "mount-session" > during which they are in supreme control of the content of their > underlying block-store, and there no useful way to determine if the > block-store was modified while not under our control. > > We reasonably expect that nobody mess with our disks while in S3, > even though much modern hardware would allow it, and again, that > can help us "get to S4". > > > However, in "real S4" filesystems need to learn to suspend, and to > resume when geom-tasting offers up a provider which contains their > data - even if all other aspects of that provider is different. > > But... > > If it were up to me, S4 suspend would operate at the kernel/user-land > boundary and not the of kernel/hardware boundary. > > Ideally we own one side of the kernel/hardware boundary and the > other side is well documented. > > In practice: Not so much. > > In comparison we own 100% of both sides of the kernel/user-land > boundary - nothing can prevent us from making it work. > > > Suspend: > > * Send all processes SIGSUSPEND which defaults to calling a new > "zzz(2)" syscall. Smart procs catch and do something sensible first. > > * Pause any processes that did not take the hint. > > * EAGAIN all userland threads in the kernel up to the syscall level. > > * Save all processes to storage along with their kernel state. > > * Save global kernel state to storage. > > * Tell the firmware to go ahead. > > > Resume: > > * Boot a kernel on some hardware. > Usually the same kernel on the same hardware, but > it doesn't have to be (!) > > * Instead of /sbin/init execute /sbin/resume, which: > > * replays global kernel state > > * reloads the saved processes > > * replays their individual kernel state (open files etc.) > > * Mark their zzz(2) as done and hand them to the scheduler. > Smart processes do smart thing when zzz(2) returns. > > * Send the EAGAIN user threads in syscall level back down. > > > The kernel state to be saved amounts to something like: > > Per process: > > * open filedescriptors, including filesystem state > * mapped files > * POSIX IPC and SHMEM > * AF_UNIX sockets (& pipes) > * Per process device driver state. > > Global: > > * mounts > * sysctls > * jails > * network interface and route config > * device driver state, as required. > > Poul-Henning > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetenc= e. From nobody Thu Aug 28 00:59:21 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cC32R6yCkz65xwC for ; Thu, 28 Aug 2025 00:59:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cC32R4xgjz3VTG for ; Thu, 28 Aug 2025 00:59:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-24633f57e0bso2772665ad.0 for ; Wed, 27 Aug 2025 17:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1756342765; x=1756947565; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=k2LNQW4vRALEK9PhwCjMADbZ8tm+9DoX895syshiB18=; b=crIf+kKDPPdTlh/vWOmWrA6w1pYEMZiep70iA0UtMvABpPH/kL/gXREc02NX/MicKa q19afodtyFS/IJxrMstOvRD6nnYb5XNFbsiDElIO4kk8AFD3d2CHO3Sau5VqxJF9HUz0 Kpx5GkHzFBP6OLyQE8fFJf+ZHdYKOdkBv1FOtA8NHXzgJTvu+F6Hw0jwKeaww60J0V9A gc2m0tL5bYIPmehIEEt1xafA+cJ9AKcMX/hE33ob30QFOIv4PpnW42cur9CP+MF5RCDt ym9249aNju8q0NCnMFEYP+5brrsV4syutSRyOURQpSdPG7ZEZvI7/fS+0LXRGSWI6sNT 0ABw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756342765; x=1756947565; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=k2LNQW4vRALEK9PhwCjMADbZ8tm+9DoX895syshiB18=; b=lXMTdY1fPXRpqHCWQzaIqKf0PFakh+50VwNpaNSMrL3kFbDy4ZJzxzY7q6qqpTJjki O+jh9J96vBT6mW+2pv5lvwOBtAJjBdA2qUH3xydyylKitH7b3lPK8/kIInC3atMhKW0y renQ0zsee2bNHROzV7dwaUX5YPU8971pP7NpYJ8i1rv9T4Nj5Aogn5a7cbcY4CZhcimY YRbWwu8TumA5VmvW2prEx0urYuj2+livpDb9hRvzRZB5L90RdqPQ7CP2/YWzH3B3v46R pvBBDvfSZ0bqaWPa+b3ysCdIIMxpcQMUzoVq1Z16V8x2m8uYB/nP5BG1xvE+hkJkOWJv ITVg== X-Forwarded-Encrypted: i=1; AJvYcCUyBPZrLIxcb0/ZYYurqWSy55Ds8WNmzyioxFxer3U+7VpOA3Mu2T3PoPY5LToTRfdx3l3hFIsYG/E9+Y4pjzQ=@freebsd.org X-Gm-Message-State: AOJu0YzzG4XcNVDioL5vEc71Y/5V+CK3iAzzQsPOSm1nY7Y7bdGmtjxc TnEw1j7mZ4+WuQEh8JjHS/MBMNlfMfd3U+PJAd7XP8YMFE7TUXISdD1EcA8EJWT9/K142UnI2CG knhgtlD9CqZjRK90yEm8JSKNeNlbNYUO1puNCs7usZg== X-Gm-Gg: ASbGncuYFivuKX1awtiKxQDh+CftEQV8AiXrmVfThMTdDRXNXGHjRuYPl9b1ZhHDFEJ dVYiWzQ8yFiodH5so7aV1X6Lq9mtGzvKhxoLg1Fj2gY3UZlvzUb7ArXB0x9pSCOfcqFmqB5LPbq p3y4OEgk/yXB9WzCJBgh8cHrylsB8MGjB12C1mmMiDzRq/klgo1bT73yJbXmPWZHKhpOv1U+DbN 0/Iuj1iWkZnN9mDqmzC6JUGEuUDhf7Icka60uc2MhNCvKTP5g== X-Google-Smtp-Source: AGHT+IGqvKA34zzqbUV+nygFXA35oyiaEzMjRjIpf6IepBkeO7SxR9zyA8yeXSKPKqA3l9PlmucP9tXKJUMWMKGjHuo= X-Received: by 2002:a17:903:38d0:b0:246:2e9:daaa with SMTP id d9443c01a7336-2462edd744bmr319157775ad.2.1756342765541; Wed, 27 Aug 2025 17:59:25 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <202508271938.57RJcX0n009344@critter.freebsd.dk> In-Reply-To: From: Warner Losh Date: Wed, 27 Aug 2025 18:59:21 -0600 X-Gm-Features: Ac12FXwntYI1cTgWokmqjxHD_Rs9I3k1ITsO9lZQe-VDV8ShFlsfjFUVflzegZ0 Message-ID: Subject: Re: S4 hibernate support for FreeBSD To: obiwac Cc: Poul-Henning Kamp , freebsd-arch@freebsd.org, freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000a4ea84063d626a4f" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cC32R4xgjz3VTG --000000000000a4ea84063d626a4f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 27, 2025 at 3:34=E2=80=AFPM obiwac wrote: > Thanks for your in-depth responses! > > > It's not clear to me what the kernel should do if it decides that it > can't resume. > > We could pass the burden on the user to select a different option at > the loader. E.g. the kernel could show a persistent error message if > failing to resume from hibernate, waiting for user input to reboot. I > don't think the least-surprising option would be to have the loader > just boot normally if the previous S4 resume failed at least. > The trouble here is that the ability to persist data in the loader is limited. Waiting for the user to reboot would be good, maybe, assuming that the video device is good. And on a lot of laptops, you might not have enough of the kernel going to survive the handoff from the loader to the kernel. All other systems only try to do the resume once, at least that I've used. > > The linux approach of having a resume kernel is interesting, and maybe > shouldn't be discounted given the kexec work that's lurking in Phabricato= r. > > Open to trying this out, and it might be quicker to get something > working with kexec than working in the loader. Actually, doing it this > way would open the doors to having the initial kernel load a small > graphical environment to prompt for a password for decrypting the > drive/swap file, rather than having to shove this in loader. This is > what systemd-ask-password-plymouth does, though I don't know if any > Linux distros support this on resuming from hibernate. Maybe a little > heavy though vs putting in loader. > Yea. There's some measure of functionality that would still need to be in the mini-kernel, since the loader would have to know where it could or couldn't put things. It also occurs to me that unlike a kernel crash dump, you could easily invalidate all the data that's on a stable backing store, and it will fault in on first touch. You'd still have to save all the kernel, all its state but by and large, you don't need to save the user space of the running programs at all, since it will all either be in stable files (libc, etc) or in swap space (which might pose problems of allocation if you are writing the kernel resume dump to there as well... Another challenge that occurred to me is 'how do I know I can resume' while the resume functions are mostly synchronous, you have the same timing problem as 'mount root' for all the mount points, it seems. Though it may be enough to just stall until the device reconfigures all I/O requests (or some longish timeout happens). phk@, I like the idea of operating at the kernel/userland boundary, > but this would make resuming from S4 have pretty high latency right? > How would passing driver state from the previous kernel to the new one > work in practice without first initializing the driver? We couldn't > just suspend/resume in this case I guess. > It's an interesting notion, but I think it would need to be a carefully thought out refinement, rather than the first stop. But I'm sure I'm missing a lot. Warner > On Wed, 27 Aug 2025 at 21:38, Poul-Henning Kamp > phk@phk.freebsd.dk> wrote: > > > > -------- > > Warner Losh writes: > > > > > The the extent you can do it, even to the extent of heroics, you don'= t > want > > > to destroy and recreate geom_disks. > > > [=E2=80=A6] > > > but once destroyed, the upper layers are orphaned and there's > > > no way to recreate them. > > > > In terms of "getting to S4" I agree 100%, but I dont think > > the road should end there. > > > > It was a design decision that geom treat all arriving disk as "a > > new disk", because apart from a few tour-de-force academic exercises, > > all current filesystems assume the existence of a "mount-session" > > during which they are in supreme control of the content of their > > underlying block-store, and there no useful way to determine if the > > block-store was modified while not under our control. > > > > We reasonably expect that nobody mess with our disks while in S3, > > even though much modern hardware would allow it, and again, that > > can help us "get to S4". > > > > > > However, in "real S4" filesystems need to learn to suspend, and to > > resume when geom-tasting offers up a provider which contains their > > data - even if all other aspects of that provider is different. > > > > But... > > > > If it were up to me, S4 suspend would operate at the kernel/user-land > > boundary and not the of kernel/hardware boundary. > > > > Ideally we own one side of the kernel/hardware boundary and the > > other side is well documented. > > > > In practice: Not so much. > > > > In comparison we own 100% of both sides of the kernel/user-land > > boundary - nothing can prevent us from making it work. > > > > > > Suspend: > > > > * Send all processes SIGSUSPEND which defaults to calling a new > > "zzz(2)" syscall. Smart procs catch and do something sensible first. > > > > * Pause any processes that did not take the hint. > > > > * EAGAIN all userland threads in the kernel up to the syscall level. > > > > * Save all processes to storage along with their kernel state. > > > > * Save global kernel state to storage. > > > > * Tell the firmware to go ahead. > > > > > > Resume: > > > > * Boot a kernel on some hardware. > > Usually the same kernel on the same hardware, but > > it doesn't have to be (!) > > > > * Instead of /sbin/init execute /sbin/resume, which: > > > > * replays global kernel state > > > > * reloads the saved processes > > > > * replays their individual kernel state (open files etc.) > > > > * Mark their zzz(2) as done and hand them to the scheduler. > > Smart processes do smart thing when zzz(2) returns. > > > > * Send the EAGAIN user threads in syscall level back down. > > > > > > The kernel state to be saved amounts to something like: > > > > Per process: > > > > * open filedescriptors, including filesystem state > > * mapped files > > * POSIX IPC and SHMEM > > * AF_UNIX sockets (& pipes) > > * Per process device driver state. > > > > Global: > > > > * mounts > > * sysctls > > * jails > > * network interface and route config > > * device driver state, as required. > > > > Poul-Henning > > > > -- > > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > phk@FreeBSD.ORG | TCP/IP since RFC 956 > > FreeBSD committer | BSD since 4.3-tahoe > > Never attribute to malice what can adequately be explained by > incompetence. > --000000000000a4ea84063d626a4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 27,= 2025 at 3:34=E2=80=AFPM obiwac <o= biwac@freebsd.org> wrote:
Thanks for your in-depth responses!

> It's not clear to me what the kernel should do if it decides that = it can't resume.

We could pass the burden on the user to select a different option at
the loader. E.g. the kernel could show a persistent error message if
failing to resume from hibernate, waiting for user input to reboot. I
don't think the least-surprising option would be to have the loader
just boot normally if the previous S4 resume failed at least.

The trouble here is that the ability to persist data= in the loader is limited. Waiting for the user to reboot would be good, ma= ybe, assuming that the video device is good. And on a lot of laptops, you m= ight not have enough of the kernel going to survive the handoff from the lo= ader to the kernel. All other systems only try to do the resume once, at le= ast that I've used.
=C2=A0
> The linux approach of having a resume kernel is interesting, and maybe= shouldn't be discounted given the kexec work that's lurking in Pha= bricator.

Open to trying this out, and it might be quicker to get something
working with kexec than working in the loader. Actually, doing it this
way would open the doors to having the initial kernel load a small
graphical environment to prompt for a password for decrypting the
drive/swap file, rather than having to shove this in loader. This is
what systemd-ask-password-plymouth does, though I don't know if any
Linux distros support this on resuming from hibernate. Maybe a little
heavy though vs putting in loader.

Yea.= There's some measure of functionality that would still need to be in t= he mini-kernel, since the loader would have to know where it could or could= n't put things.

It also occurs to me that unli= ke a kernel crash dump, you could easily invalidate all the data that's= on a stable backing store, and it will fault in on first touch. You'd = still have to save all the kernel, all its state but by and large, you don&= #39;t need to save the user space of the running programs at all, since it = will all either be in stable files (libc, etc) or in swap space (which migh= t pose problems of allocation if you are writing the kernel resume dump to = there as well...

Another challenge that occurred t= o me is 'how do I know I can resume' while the resume functions are= mostly synchronous, you have the same timing problem as 'mount root= 9; for all the mount points, it seems. Though it may be enough to just stal= l until the device reconfigures all I/O requests (or some longish timeout h= appens).


phk@, I like the idea of operating at the kernel/userland boundary,
but this would make resuming from S4 have pretty high latency right?
How would passing driver state from the previous kernel to the new one
work in practice without first initializing the driver? We couldn't
just suspend/resume in this case I guess.

It's an interesting notion, but I think it would need to be a carefu= lly thought out refinement, rather than the first stop. But I'm sure I&= #39;m missing a lot.

Warner
=C2=A0
=
On Wed, 27 Aug 2025 at 21:38, Poul-Henning Kamp


=C2=A0
phk@phk.fre= ebsd.dk> wrote:
>
> --------
> Warner Losh writes:
>
> > The the extent you can do it, even to the extent of heroics, you = don't want
> > to destroy and recreate geom_disks.
> > [=E2=80=A6]
> > but once destroyed, the upper layers are orphaned and there's=
> > no way to recreate them.
>
> In terms of "getting to S4" I agree 100%, but I dont think > the road should end there.
>
> It was a design decision that geom treat all arriving disk as "a<= br> > new disk", because apart from a few tour-de-force academic exerci= ses,
> all current filesystems assume the existence of a "mount-session&= quot;
> during which they are in supreme control of the content of their
> underlying block-store, and there no useful way to determine if the > block-store was modified while not under our control.
>
> We reasonably expect that nobody mess with our disks while in S3,
> even though much modern hardware would allow it, and again, that
> can help us "get to S4".
>
>
> However, in "real S4" filesystems need to learn to suspend, = and to
> resume when geom-tasting offers up a provider which contains their
> data - even if all other aspects of that provider is different.
>
> But...
>
> If it were up to me, S4 suspend would operate at the kernel/user-land<= br> > boundary and not the of kernel/hardware boundary.
>
> Ideally we own one side of the kernel/hardware boundary and the
> other side is well documented.
>
> In practice:=C2=A0 Not so much.
>
> In comparison we own 100% of both sides of the kernel/user-land
> boundary - nothing can prevent us from making it work.
>
>
> Suspend:
>
> * Send all processes SIGSUSPEND which defaults to calling a new
>=C2=A0 =C2=A0"zzz(2)" syscall.=C2=A0 Smart procs catch and do= something sensible first.
>
> * Pause any processes that did not take the hint.
>
> * EAGAIN all userland threads in the kernel up to the syscall level. >
> * Save all processes to storage along with their kernel state.
>
> * Save global kernel state to storage.
>
> * Tell the firmware to go ahead.
>
>
> Resume:
>
> * Boot a kernel on some hardware.
>=C2=A0 =C2=A0Usually the same kernel on the same hardware, but
>=C2=A0 =C2=A0it doesn't have to be (!)
>
> * Instead of /sbin/init execute /sbin/resume, which:
>
> * replays global kernel state
>
> * reloads the saved processes
>
> * replays their individual kernel state (open files etc.)
>
> * Mark their zzz(2) as done and hand them to the scheduler.
>=C2=A0 =C2=A0Smart processes do smart thing when zzz(2) returns.
>
> * Send the EAGAIN user threads in syscall level back down.
>
>
> The kernel state to be saved amounts to something like:
>
> Per process:
>
> * open filedescriptors, including filesystem state
> * mapped files
> * POSIX IPC and SHMEM
> * AF_UNIX sockets (& pipes)
> * Per process device driver state.
>
> Global:
>
> * mounts
> * sysctls
> * jails
> * network interface and route config
> * device driver state, as required.
>
> Poul-Henning
>
> --
> Poul-Henning Kamp=C2=A0 =C2=A0 =C2=A0 =C2=A0| UNIX since Zilog Zeus 3.= 20
> phk@FreeBSD.ORG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| TCP/IP since RFC 95= 6
> FreeBSD committer=C2=A0 =C2=A0 =C2=A0 =C2=A0| BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompet= ence.
--000000000000a4ea84063d626a4f-- From nobody Thu Aug 28 02:43:57 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cC5MM5Tlhz666P0 for ; Thu, 28 Aug 2025 02:44:15 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cC5ML5DZxz3hyF; Thu, 28 Aug 2025 02:44:14 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=bVMMV2TJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-61caa266828so885337a12.1; Wed, 27 Aug 2025 19:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756349048; x=1756953848; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UnAMV2QsTLeYqpCH8Ifd8mJTXM8F3BWUlNQU3LHuJSU=; b=bVMMV2TJZwJ4oPk4dGVoMyZh0ZLAcwNp+TpNp8IQHTN+7aiDdGiw57CSuXTW+MaDS5 WYnCaAKejj93FBuZh34HbyhOAwMgjHEssWlC8y3RmbnR4vStmHxDDJjAxHVcBPmeY2PE X5seNRWvFyzZ3AqVb2TWXVTjz3mzQKMfB3s9GHUEkLw3xIz9uRrJfuIzvO9HrbqISYvk hbSQoBzAzr2Vo3fQbnav+eTnwY1JUTzuJiBtj9RBUPbKIZg+WjEDFUxdzIqkSDT6CgAn liQp4yXZiGtGcQPl0afLvLywlvlCV4eFEqc3iFPxVDZZGP+Z+bOu3Prnw7AwfoAyM4mI b5nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756349048; x=1756953848; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UnAMV2QsTLeYqpCH8Ifd8mJTXM8F3BWUlNQU3LHuJSU=; b=DgUoGwwiApXjVDsDHKEvq5HPdULepKnM4O7S+U/X1KpKboiMo+qdLa+oakhtrlG34U bJYS9ODxinJJEqc6b9P8obhRwNtYrfLWsVGt+tPrHAFK7LxhT9n0+2UAM6eogqTqQ7cN t4NeXTtxJOGQ05ixKezaRtjZJueKbZafM4OOuWE+pXQ4nVusnRqc5U4qcO2vd7kkl2Py 6+ROZm71oX+KG81yBjWKOxbW8Ferne1MveZxgYnsROIRHPf8FNASrP7fxVIvBmEUtyNo B8JSg7YiD9DQKbc7lGIuAPZhPXKu13mkKb/0RBn8CqtcoT7O1OzoI4E+3Vjk2nA8CQ9s CwEA== X-Forwarded-Encrypted: i=1; AJvYcCUHnFQggK+SqA3U3Q5Upf9ziY9VLagP/QG4F6OMfEKKQPLvCv9YQ41zANRfGDPS5f4Yw8zchOC88oxWpcMqoQg=@freebsd.org X-Gm-Message-State: AOJu0Yx7fqdtIRVs/AYZk18Bz3goCKWTdZ/PVFdruC2j2ZkhbGSPHhlf BLI5+NVjoMwO4r49966kW4tY9Y1+z+NsfmlzAno1lKTBIYEdUbXEcYFhGcm97YtsZW3hBrSu486 OiE7ykPmGY7X/bAywb1gMKr5r4y9/ItWh X-Gm-Gg: ASbGncuOmUPR3DyammkmLzLIWuJT/Hty/C7nlP/y/EgZLVax+kQa0qsxwNEou1ghCTE KEczY+/GOPm2Vqwo8l1yY8jaJuO/WRyXKsPfZs90Bhduj6j7OYtVIEldKpryxLoB8hGb50Ed8zH D84E+jJDmcD6+XD3Wgm+ZuhPtXgIf7PxNuGQNOO6jJ1uG878x35QNhSuiCQvu3bEZr0NKcwpkZZ ndZehP1gI1EB2WQiFVAu53plUJpjj4DdeZrVok= X-Google-Smtp-Source: AGHT+IF4IeEAGdhjAOMig3ENaqE+gTLNbMgFdRw71Nrw/nsryvDTqoMZAnPoMLp9EtxbayY5B6pH2VG3IZOKtW8XwA8= X-Received: by 2002:a05:6402:50c7:b0:61c:db49:aeb6 with SMTP id 4fb4d7f45d1cf-61cdb49b0edmr333628a12.28.1756349048033; Wed, 27 Aug 2025 19:44:08 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Wed, 27 Aug 2025 19:43:57 -0700 X-Gm-Features: Ac12FXz0Er1MXymNy4k7UxhUAW9VOaDP9JJrWpiQyb4RIt4cDCxOgbS2mbAaBFI Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Gleb Smirnoff Cc: Cy Schubert , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.966]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4cC5ML5DZxz3hyF On Tue, Aug 26, 2025 at 9:35=E2=80=AFAM Gleb Smirnoff = wrote: > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff wrote: > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem wrote: > T> R> Ok. If you install FreeBSD-13.5 and then "pkg install heimdal", you= get a > T> R> working Heimdal-7.8 in ports. > T> R> > T> R> Now, I have another challenge. Fixing the master passwords. > T> R> I'll work on it later to-day. > T> > T> I have applied two commits from Heimdal from 2012 that add 'kadmin dum= p -f MIT' > T> feature to our base heimdal and polished them to compile. So far it d= oesn't > T> work yet, either create an empty dump or create a core dump, instead o= f > T> database dump :) I'll see how difficult it is going to further resolve= that to > T> a working condition. If I succeed, then having 'dump -f MIT' in base w= ithout > T> any ports would be the best solution. Can also be merged to FreeBSD 1= 4.4. > > Good news. In the above paragraph I was testing my change incorrectly - = threw > the new binary on a system running unpatched libraries. When run correct= ly, > it successfully produced something that looks like a correct dump in MIT = format. > I haven't yet tried to load it into MIT kdc yet, though. > > I will finalize the branch promptly and share it. The above experience a= lso > indicated that I need to do a library version bump. I don't know if you are enthusiastic about pursuing this, but hopefully thi= s works and gets the principals in (although I doubt the passwords will work without changing them). To get the passwords to work, I think the following *might* do it: - If you look in the Heimdal sources, when "--decrypt" is specified, I think it finds its way down into a function called hdb_unseal_key_mkey(= ) which decrypts the key using the master key by calling _hdb_mkey_decrypt(= ). To get the passwords to work, I think the call to _hdb_mkey_decrypt() wou= ld need to be followed by a call to _hdb_mkey_encrypt() with the "key" argument being the master key for the MIT database. (It it a keytab entry called /var/db/krb5kdc/.k5.YOUR.REALM created when you do a "kdb5_util create -s" on the system that will be the MIT KDC.) - Just to make it even more fun, there is a flag called HDB_KU_MKEY which is set to the Heimdal way and not for the MIT way (whatever that really means?). - There is also some stuff about padding in hdb_unseal_key_mkey(), but hopefully that won't be a problem? I think hdb_read_master_key() can be used to read in the MIT master key from the file you provide as an argument to it. This all is just a hunch, based on what I've seen so far. I'll admit since the hardware I have takes forever to "make buildworld" and I don't know a quick way to build/test these changes, I'm not inspired to try it. rick > > -- > Gleb Smirnoff From nobody Thu Aug 28 03:39:53 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cC6bv3SM3z66BB1 for ; Thu, 28 Aug 2025 03:40:11 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cC6bt5VsZz3qDL; Thu, 28 Aug 2025 03:40:10 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=NnyT67G4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::52c as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-6188b6f501cso591945a12.2; Wed, 27 Aug 2025 20:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756352404; x=1756957204; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=WU1nPgjPFlBaWPBvaLa4FTn2pmRtmGH8RxCwI/wXXNA=; b=NnyT67G4sYquwGtC1y/7uail9Rk36D89y47N22GePTDxj2sQBWdkJ3DTcmEyAmH3QA q0O2/cQ9RUeZ/QBYhEd+ALy1jggoNijRx53CTeTiRgCkllFQFMdo3eTU7ZmMuCFQtV7f wnVWT0iUnirmaWJK0KqpC3X4oy1edZIr/OcXSm/bTjRdjnJ6oAcxXVYp2ZU5TCLpWkkh 2oG9E7SoUwC8SjNVcthxMnhX/vBZ0g5E5Mf8Ua75+tXJ9Pt+jB77Cu+Cp1wDsd4NtoPQ qnZEVM10fobI3xFplEEGtR4jV+m0Df1GAn2VC5ZRVNx+sP7LX1ejgZKSg0u1E1SRVshN 3WZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756352404; x=1756957204; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WU1nPgjPFlBaWPBvaLa4FTn2pmRtmGH8RxCwI/wXXNA=; b=Muk+8Zn1Oxp442TiOjVzmXegIxvK/4SfoOSHLI7xnXbuOdHdEFZI2kC9T6+ql7r0CC ugXmMEw5W9m0GtSPIrO7db+frT2L6iGwUpAZ3K706dZZWaIZoGq7SLu7aKnjkjnoWT9x V46HkrwPdVf29tL1L7b4KMGvmAuqDq/ZaVTrAp/3Q+TRmWZAKRYuXpOurd9wSfKHe9C+ yVQ5GzMU121Qc9iuHigome1XFq9rDGn+mp8J4dbMEPcCoFyRM2veQfOo99c1beXQdXTA iW8s4PgP0CJHYzHIsA+8VUCFKbCYEAoGF2vG5mIScBhMvq8B+yg1Rc2OMXwp5iHBzwtY HAQA== X-Forwarded-Encrypted: i=1; AJvYcCXAWViHvVe4b8deWQCo3WYGR1JmCFmZgiRBOwmZZlP6bStJ3hZjKH8PICcWA0yYm490d8ZjgOT/KeyncJaAzEM=@freebsd.org X-Gm-Message-State: AOJu0YzbZCF+9Ttro+XYHK5WQO6fTiCI9PQ+HmDkNR8QfPoIP0RjlxRi WX3l3BE6dgq+nlW0C/vK7xTejr1k4eDJpVWHYEx0YuC2xLJ7xnUNouEmBSpKjSk3SqUFHoR31J3 oi2hNBV0Bz5ljuNNunBr1egO4uFTWX3XA X-Gm-Gg: ASbGncv3bJbIAgEOJfo3n7hAtSLnN0I//kguVsMA5K9uNxJX3NKFDpE8sUjE32H8RSY 1vFZawXztks4eISGd9WJyccvRgm57/TYGpdBsLPh/MIMbUIB8ttOH2YE354HFL2IJNGKCobcWkf BVjlacu1yQqTLVyq2s9jrdeS1uExlKJgsAPqPGHnCHuQIEqC5ikJFLbRfnJdZMpgPMzkVU6zmdb 8KsegEa2Zjqf91hBP0gnAU/2mezjiv7Vsj1VLM= X-Google-Smtp-Source: AGHT+IHDoT692H+2yaddJYoQi3LgeaL+P6WL6Mo/Lk4Hf1mpXGx268Q/0OQ8Iz4dQ2hDYPsBfsxHuO5z7WInPRdz3RI= X-Received: by 2002:a05:6402:2189:b0:615:77cf:782e with SMTP id 4fb4d7f45d1cf-61c1b6f247bmr16177712a12.25.1756352404443; Wed, 27 Aug 2025 20:40:04 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Wed, 27 Aug 2025 20:39:53 -0700 X-Gm-Features: Ac12FXzvzLBlCLinI89-cbf95wLNeR0gBwwefMIl1RvAcYlq1Tixy2a2iSd7N-U Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Gleb Smirnoff Cc: Cy Schubert , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52c:from]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4cC6bt5VsZz3qDL On Wed, Aug 27, 2025 at 7:43=E2=80=AFPM Rick Macklem wrote: > > On Tue, Aug 26, 2025 at 9:35=E2=80=AFAM Gleb Smirnoff wrote: > > > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff wrote: > > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem wrote: > > T> R> Ok. If you install FreeBSD-13.5 and then "pkg install heimdal", y= ou get a > > T> R> working Heimdal-7.8 in ports. > > T> R> > > T> R> Now, I have another challenge. Fixing the master passwords. > > T> R> I'll work on it later to-day. > > T> > > T> I have applied two commits from Heimdal from 2012 that add 'kadmin d= ump -f MIT' > > T> feature to our base heimdal and polished them to compile. So far it= doesn't > > T> work yet, either create an empty dump or create a core dump, instead= of > > T> database dump :) I'll see how difficult it is going to further resol= ve that to > > T> a working condition. If I succeed, then having 'dump -f MIT' in base= without > > T> any ports would be the best solution. Can also be merged to FreeBSD= 14.4. > > > > Good news. In the above paragraph I was testing my change incorrectly = - threw > > the new binary on a system running unpatched libraries. When run corre= ctly, > > it successfully produced something that looks like a correct dump in MI= T format. > > I haven't yet tried to load it into MIT kdc yet, though. Oh, and one more thing... - If there are keys for old encryption types like des.. or arcfour.. in the MIT dump, those will screw up the load. (You can check and delete them in the Heimdal-1.5.2 kdc system via.. # kadmin -l get - if old keys are listed in Keytypes: del_enctype exit Ideally the conversion code would skip over these and not put them in the = dump. rick ps: If you don't do this, when you "get_principal" in kadmin.local on the MIT KDC system, it will give you a "Database record is incomplete or corrupte= d..". > > > > I will finalize the branch promptly and share it. The above experience= also > > indicated that I need to do a library version bump. > I don't know if you are enthusiastic about pursuing this, but hopefully t= his > works and gets the principals in (although I doubt the passwords will > work without changing them). > > To get the passwords to work, I think the following *might* do it: > - If you look in the Heimdal sources, when "--decrypt" is specified, > I think it finds its way down into a function called hdb_unseal_key_mke= y() > which decrypts the key using the master key by calling _hdb_mkey_decryp= t(). > To get the passwords to work, I think the call to _hdb_mkey_decrypt() w= ould > need to be followed by a call to _hdb_mkey_encrypt() with the "key" > argument being the master key for the MIT database. (It it a keytab > entry called /var/db/krb5kdc/.k5.YOUR.REALM created when you do a > "kdb5_util create -s" on the system that will be the MIT KDC.) > - Just to make it even more fun, there is a flag called HDB_KU_MKEY > which is set to the Heimdal way and not for the MIT way (whatever > that really means?). > - There is also some stuff about padding in hdb_unseal_key_mkey(), > but hopefully that won't be a problem? > > I think hdb_read_master_key() can be used to read in the MIT master > key from the file you provide as an argument to it. > > This all is just a hunch, based on what I've seen so far. > > I'll admit since the hardware I have takes forever to "make buildworld" > and I don't know a quick way to build/test these changes, I'm not > inspired to try it. > > rick > > > > > -- > > Gleb Smirnoff From nobody Thu Aug 28 15:01:08 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cCPkd5Ntdz668Nn for ; Thu, 28 Aug 2025 15:02:01 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cCPkR4YKLz44VV for ; Thu, 28 Aug 2025 15:01:51 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=H1xfTDpf; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 2001:1640:5::8:31 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id C26EE240EE1 for ; Thu, 28 Aug 2025 17:01:42 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 303772400FE for ; Thu, 28 Aug 2025 17:01:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1756393301; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=ngyveuQng58HQZMUGVg8KauYAvcH4hm1/s38u+TGn1U=; b=H1xfTDpfHEg9mjwyoUZBvB/vLvqS/2S0zZ2qKBJNQ1AKiPU8OEQMYlWKEExpzTUPgaizdi kXX2myQ1260BgWiW1CvnXYltGycPkE9gZzgbFlbpH9HPNKADITMSo6cGUOApM4K8oyjNPd W16dUBVNBoE1sGJTuTYiVUZ08gTDswXcX2eHTFL0ejj7V1XPsfwJ9SndGbSDIzB6f9FmCq oZ6r+/p/wE4Pb/HyossZCmiz4JkSmTCxjZXu+QdVMLfiyRNrIBnVO5en6GB0LyzbvIxMoo 7ZXZxVKuITUva75d9bD5R5gl1525QGDLkg1GWp9hEUhg3ymCW7b4JUxWkCfVCg== Received: from thor.sb211.local (dynamic-2a02-3100-18cc-2b02-c740-8221-446e-f214.310.pool.telefonica.de [IPv6:2a02:3100:18cc:2b02:c740:8221:446e:f214]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 1617824025B for ; Thu, 28 Aug 2025 17:01:35 +0200 (CEST) Date: Thu, 28 Aug 2025 17:01:08 +0200 From: A FreeBSD User To: FreeBSD CURRENT Subject: CURRENT: bad performance in LibreWolf, Firefox, mplayer Message-ID: <20250828165246.5fed81aa@thor.sb211.local> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/=7_mcpodINe2dlwGz7oCf6c"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-UID: 9f504e X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.60 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2001:1640:5::8:0/112]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN_FAIL(0.00)[1.3.0.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.0.0.0.0.4.6.1.1.0.0.2.asn6.rspamd.com:server fail]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RSPAMD_URIBL_FAIL(0.00)[walstatt-de.de:query timed out]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt-de.de]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4cCPkR4YKLz44VV --Sig_/=7_mcpodINe2dlwGz7oCf6c Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, running CURRENT (FreeBSD 15.0-PRERELEASE #3 master-n279925-393356f25fb8: Th= u Aug 28 06:53:41 CEST 2025 amd64) on a moderat modern hardware (AMD based), I whitness some = very strange and nasty performance issues with the usage of certain "day-to -day" applicatio= ns, like Firefox, LibreWolf, mplayer. CPU is a current AMD Ryzen (no 3D cache!), 96 GB RAM, GPU is a nVida RX 506= 0 - with recent nvidia-driver-580.76.05.1500063 driver version due to issues with the 570 s= eries in ports tree. X11 window manager is x11-wm/windowmaker. All ports are custom compil= ed and has been recently recompiled - these details just for the record. The phenomenon is when starting Firefox and/or Librewolf, these programs ar= e almost unusable. Clicking on menus produce drop down artefacts in the shape of the drop-dow= n-menu when moving the window. Content of the interior does not change and is frozen and/or do= esn't get refreshed. After several long minutes this misbehaviour seems to mitigate a= nd the program seems mor responsive. When it comes to video streams, like youtube, the mes= s is back: streams are slowed down a way its like a torture watching them. Same with videos in= mplayer: playing a video we made a couple of years ago with Blender (.mkv, .avi) are in slow m= otion. From time to time I try my best with warzone2100 - the game also indicates sometimes whi= le in game a sudden jumpy behaviour or at the beginning. It seems erratic when and how such "ju= mpiness" occurs.=20 While those applications show up harsh and serious performance problems, th= e OS itself and even the X11 windowmaker window system do not indicate any flaw in performa= nce penalties, which surprises me. So, I susepct something wrong with either the video subsystem (as mentioned= initially, the in-ports-tree driver nvidia 570 shows some similar problems which could be = mitigated by using the most recent one provided by nvidia, version 580.76.05). I tried to recompile every single port from scratch due to suspect some ABI= issues somewhere since some critical changes in FreeBSD's core, but this approach didn't hel= p much. Does anybody else have such problems on the recent CURRENT system and is th= is well-known (and so the hope for a solution does not die early) or is this problem sticky wi= th me alone? Thanks for the patience, oh --=20 A FreeBSD user --Sig_/=7_mcpodINe2dlwGz7oCf6c Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCaLBvTwAKCRCxzvs8Oqok r+g6AQCVLOpZJua7Rz8dMZzNPSoueCRsfuaqgf6tSBXKWA9lGwEAlCkNGo3RfvNP yrahCvhKq8LnZh8t+Umz1oT7ndn5Pgo= =7L5Z -----END PGP SIGNATURE----- --Sig_/=7_mcpodINe2dlwGz7oCf6c-- From nobody Thu Aug 28 15:16:09 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cCQ3Z5XkZz669lN; Thu, 28 Aug 2025 15:16:42 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cCQ3Y4GrYz46L4; Thu, 28 Aug 2025 15:16:41 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=osqSbNcY; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 85.220.129.60 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 85B66240870; Thu, 28 Aug 2025 17:16:39 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id E9979240866; Thu, 28 Aug 2025 17:16:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1756394198; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=49VF3331/uFcEoNdjxBmUY40tO1h5Q+97QLe+zOPsYA=; b=osqSbNcY5RYmFK4YwaSOA+gK+KhrNyP9qODXj49hMtZgy+PzZoITk4Ywd4Qrf6AfEYqVzK afecJIBoyD5K3jiGG+NnQngJB7SpxdYPApJ/05k5Kl2sQjmtj0uIDyJ3HE20p5PK8Sl5aI /jgzlXZvsf79Kg2NCZZNtgrmhA3nJ/DNOJV/wwkYXZJsqRZ3z9v59svAJio6CRDVRS0OIa iNxe/QLDTE2rIGrUtqxqzxqj3q+nJ8u/ZNuMz+/wN0A33+XMAe6MNryEL/BkppoYwvo/Nh JotuIogqmIqipTpseTkktlRFPw3f0CmKCcuO083gISQLvSRO90M0NxXZAlmdjw== Received: from thor.sb211.local (dynamic-2a02-3100-18cc-2b02-c740-8221-446e-f214.310.pool.telefonica.de [IPv6:2a02:3100:18cc:2b02:c740:8221:446e:f214]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id A43C324084C; Thu, 28 Aug 2025 17:16:37 +0200 (CEST) Date: Thu, 28 Aug 2025 17:16:09 +0200 From: A FreeBSD User To: FreeBSD CURRENT , FreeBSD Ports Subject: mail/claws-mail: IPv6 issues: SSL handshake error Message-ID: <20250828171636.04a61a93@thor.sb211.local> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/7+24N6HJsOEuO+JlhOJgsUW"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-UID: 6c6e39 X-Rspamd-UID: 91890d X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.70 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.995]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:85.220.129.0/25]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.60:from]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-ports@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4cCQ3Y4GrYz46L4 --Sig_/7+24N6HJsOEuO+JlhOJgsUW Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, I'm using mail/claws-mail for my daily work with FreeBSD (CURRENT, 14-STABL= E at this time). After switching to a working IPv6 environment I face serious connection pro= blems with one of my providers, to which claws-mail prefereably connects via IPv6. Sending an= d receiving is done via "Use TLS" on sending an receiving (the provider, goneo.de has a dedica= ted introduction configuring claws-mail I followed step by step). On the firewall I observe that the provider in question is connected via IP= v6, while other providers, University and others, are not, they are still with IPv4 and do = not show any issues. claws-mail provides a log screen, but I can not make much out of it, the SM= TP and/or IMAP server is connected at the correct port and the initial handshake seems all= right, but in 8 out of 10 times the connection fails and does not get initialized due to a = "TLS handshake error". Sending emails takes sometimes 10 attempts, but then of a sudden it= works flawlessly! After running claws-mail for a couple of minutes a day, this problem seems = to go away in a mysterious way, receiving/sending works like a charm as nothing has ever be= en broken before ... I;m floating here like a dead man in the water. The firewall / router is Fr= eeBSD / ipfw, I suspected this instance, but why should mail being blocked/corrupted while = other connections via IPv6 work? Maybe someone has some ideas what to check and where to look ... Thanks in advance, oh=20 --=20 A FreeBSD user --Sig_/7+24N6HJsOEuO+JlhOJgsUW Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCaLBy1AAKCRCxzvs8Oqok r76zAQDMseQZmJqwrmmugEIkbsI2ZDifUiHoBAHxMlk0vpHTeQD/caw/LSIHUcOw 9j9Qz1Y1daex67BuyFpV6dVOsSsIXg4= =/cvX -----END PGP SIGNATURE----- --Sig_/7+24N6HJsOEuO+JlhOJgsUW-- From nobody Thu Aug 28 16:49:41 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cCS716Krvz66JTX; Thu, 28 Aug 2025 16:49:49 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cCS715mGHz3KKc; Thu, 28 Aug 2025 16:49:49 +0000 (UTC) (envelope-from ronald@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756399789; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=557hkX2e3S/jlGrpe5kJe4Hrk+pcedYhUi8yl2zU6S8=; b=Oi2WihGjJSJwqm7wDnwmNbh6492Dg7TEQAyF/7OPN8G3jTSp/0lHNdzhGH5DIwkV/7w0Hv ohfMEhZon5maiz2rzZTMsoc9ylxgV5qTLxn3lMDixwK2vBUkPbRmz5zQ3jiwkT+xCcAcRC vHhSbHTorksV2ycHq2lgcjn3Gc8vr/CF/Sqzg1UyQip7RfFZIvICLrejPmWz19B/mBio4u mGEwjyqZFNPqb+F0twiHF/YGaqh9e02K0mlv3OSV//59BGObyWTb4ALYiDdePAjHqAdkHM 6Y4EE4/kDpcv57Wxeb0FH36KvBtEsklLzIKTMaWHtUc6sbE/FMhyCBy00Vn7ZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756399789; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=557hkX2e3S/jlGrpe5kJe4Hrk+pcedYhUi8yl2zU6S8=; b=XwPTmLUM7d8uwSthABNmuAyDaPP7D+6Rd/hC06JQ9lmQr3aygTwLdO927bbS7fVhO2cE+x DG1qSeqWdnR/l4rGpLS0pCyS1wtBntp/dPjBowus/XPicPtBwNHwIbiyTpfIOFSYMZz3ev 5HjnIlk8haRx0K9ZYGP8El5ugYPE7zCDtLchbsQEU4ZjT6XDGMlWwNPOxhF9PAuobXEig2 k5G1KhNDAzDd0fl3X0pOh2y8uQVeSb3GYWznfMZcfMWOes7azCA2ukWMsiUOiuIyNM5GHG RRwwq9dGC3u+PGNEXpFFXzWCEDvrR6iToVlEscuxBO8de4QTZo2YTJjYYOfbcw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756399789; a=rsa-sha256; cv=none; b=Gp2VlvL2f/Qcq4LIRER5JfRrxwiEDK3mprRd7Xr2nbj/ziLS3nIEjqunvKIcnFpKaSHnJX Lx7wQfxBWp5uKqjrE8xqF69RRq37lm4rRMVfFsHLo/GJz4m79C/3RFPxic4l1SI+utmyti baczp4qW5hyyeamtEqU5BmUSq7q2vmiItV9yFC8Q54fSBsd60QMq3KwSqjg0yWLJHfUEU/ YMUWn9Qz6dvA3zYY35nwn/9nfTNGovQCFckUDZhu1yxXEXO6aYxUZdCtHTBCq2hGuXgWXZ M7NT2qlKOx4DhNENE6pD+0up5rRRsTllzuYPYv5MlPk+nuznPHdPgIVua9rl4Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2001:1c00:270f:14b0:52f:733b:674f:b081] (2001-1c00-270f-14b0-052f-733b-674f-b081.cable.dynamic.v6.ziggo.nl [IPv6:2001:1c00:270f:14b0:52f:733b:674f:b081]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: ronald/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cCS711z97zw64; Thu, 28 Aug 2025 16:49:49 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Message-ID: <91944f04-24b4-4374-b147-474a59e85568@FreeBSD.org> Date: Thu, 28 Aug 2025 18:49:41 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: mail/claws-mail: IPv6 issues: SSL handshake error To: A FreeBSD User , FreeBSD CURRENT , FreeBSD Ports References: <20250828171636.04a61a93@thor.sb211.local> Content-Language: en-US From: Ronald Klop In-Reply-To: <20250828171636.04a61a93@thor.sb211.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Op 28-08-2025 om 17:16 schreef A FreeBSD User: > Hello, > > I'm using mail/claws-mail for my daily work with FreeBSD (CURRENT, 14-STABLE at this time). > After switching to a working IPv6 environment I face serious connection problems with one of > my providers, to which claws-mail prefereably connects via IPv6. Sending and receiving is done > via "Use TLS" on sending an receiving (the provider, goneo.de has a dedicated introduction > configuring claws-mail I followed step by step). > > On the firewall I observe that the provider in question is connected via IPv6, while other > providers, University and others, are not, they are still with IPv4 and do not show any issues. > > claws-mail provides a log screen, but I can not make much out of it, the SMTP and/or IMAP > server is connected at the correct port and the initial handshake seems all right, but in 8 > out of 10 times the connection fails and does not get initialized due to a "TLS handshake > error". Sending emails takes sometimes 10 attempts, but then of a sudden it works flawlessly! > After running claws-mail for a couple of minutes a day, this problem seems to go away in a > mysterious way, receiving/sending works like a charm as nothing has ever been broken before > ... > > I;m floating here like a dead man in the water. The firewall / router is FreeBSD / ipfw, I > suspected this instance, but why should mail being blocked/corrupted while other connections > via IPv6 work? > > Maybe someone has some ideas what to check and where to look ... > > Thanks in advance, > oh > > Hi, Does it work with this provider if you force claws-mail to use ipv4? Can you reproduce the issue easily? Is it possible to reproduce it with openssl? Something like this. There are also options to choose specific TLS versions. openssl s_client -starttls imap -connect :143 -6 openssl s_client -starttls smtp -connect :25 -6 Can you tcpdump the traffic to a file and see in wireshark what is going on? Regards, Ronald. From nobody Thu Aug 28 18:53:32 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cCVt05G85z66SHt for ; Thu, 28 Aug 2025 18:53:44 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cCVt00gL8z3cWT for ; Thu, 28 Aug 2025 18:53:43 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 57SIrXQD018718; Fri, 29 Aug 2025 03:53:34 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1756407214; bh=z8EddBZ0GCNSNF9sIBZHH7fCXt0uU2Ob3ptbDZVxE4k=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=NQCX33CkV20CN0asiiGidhORzmnxYGcxgO5xy+1x4EL3VJNoSVWN9haE8sZ7oZ0LM Yf3E7mXdK3zof7m/Pr7W36nnap670QM1D0umtLdhekd+vTnuMO9l0bUY9uYFDDSp+W Iv1szGonYsl4zzc7UOSANFAL5JFoC285RBtPMwo4= Date: Fri, 29 Aug 2025 03:53:32 +0900 From: Tomoaki AOKI To: A FreeBSD User Cc: FreeBSD CURRENT Subject: Re: CURRENT: bad performance in LibreWolf, Firefox, mplayer Message-Id: <20250829035332.e6f6d224c206882ea8ffd9ba@dec.sakura.ne.jp> In-Reply-To: <20250828165246.5fed81aa@thor.sb211.local> References: <20250828165246.5fed81aa@thor.sb211.local> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.3) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cCVt00gL8z3cWT On Thu, 28 Aug 2025 17:01:08 +0200 A FreeBSD User wrote: > Hello, > > running CURRENT (FreeBSD 15.0-PRERELEASE #3 master-n279925-393356f25fb8: Thu Aug 28 06:53:41 > CEST 2025 amd64) on a moderat modern hardware (AMD based), I whitness some very strange and > nasty performance issues with the usage of certain "day-to -day" applications, like Firefox, > LibreWolf, mplayer. > > CPU is a current AMD Ryzen (no 3D cache!), 96 GB RAM, GPU is a nVida RX 5060 - with recent > nvidia-driver-580.76.05.1500063 driver version due to issues with the 570 series in ports > tree. X11 window manager is x11-wm/windowmaker. All ports are custom compiled and has been > recently recompiled - these details just for the record. > > The phenomenon is when starting Firefox and/or Librewolf, these programs are almost unusable. > Clicking on menus produce drop down artefacts in the shape of the drop-down-menu when moving > the window. Content of the interior does not change and is frozen and/or doesn't get > refreshed. After several long minutes this misbehaviour seems to mitigate and the program > seems mor responsive. When it comes to video streams, like youtube, the mess is back: streams > are slowed down a way its like a torture watching them. Same with videos in mplayer: playing a > video we made a couple of years ago with Blender (.mkv, .avi) are in slow motion. From time to > time I try my best with warzone2100 - the game also indicates sometimes while in game a sudden > jumpy behaviour or at the beginning. It seems erratic when and how such "jumpiness" occurs. > > While those applications show up harsh and serious performance problems, the OS itself and > even the X11 windowmaker window system do not indicate any flaw in performance penalties, > which surprises me. > > So, I susepct something wrong with either the video subsystem (as mentioned initially, the > in-ports-tree driver nvidia 570 shows some similar problems which could be mitigated by using > the most recent one provided by nvidia, version 580.76.05). Hi. Replying partially. The in-tree version of the nvidia driver sets are already at 580.76.05 https://cgit.freebsd.org/ports/commit/?id=9dbf8452e1fbb8e075b0f8d978fe9be9d0df9355 on main (aka latest) branch of ports tree 10 days ago. But it would NOT be merged into 2025Q3 as it does not contain security fixes nor build fixes (so we don't requested approval of portmgr to do so). > I tried to recompile every single port from scratch due to suspect some ABI issues somewhere > since some critical changes in FreeBSD's core, but this approach didn't help much. > > Does anybody else have such problems on the recent CURRENT system and is this well-known (and > so the hope for a solution does not die early) or is this problem sticky with me alone? Not sure if it's case for you unless the problem is happening from much earlier days, but if you see cores of your WM after the slowness dissappeared, try disabling tab thumbnailing of firefox (and its derivatives). For firefox, in aout:config window, setting browser.tabs.hoverPreview.enabled browser.tabs.hoverPreview.showThumbnails to false. For me, after firefox started showing thumbnails of tabs, it caused compiz to crash (unusable until generation of core is finished, but after that, compiz stop working but underlying [for my config] Mate is still working). I've found above as I didn't experience this problem unless I mouse-over the any of tabs. HTH. > Thanks for the patience, > > oh > > -- > > A FreeBSD user -- Tomoaki AOKI From nobody Thu Aug 28 22:21:48 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cCbVK1tzBz65WQg for ; Thu, 28 Aug 2025 22:22:01 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cCbVK11ybz43ng; Thu, 28 Aug 2025 22:22:01 +0000 (UTC) (envelope-from olivier@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756419721; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TMGlkr1Ryoia99wgbFJixi6MxOrKdQwWXXjnGM0AxLE=; b=q+CKeal2ES0Ei+7Ib8VQn8gvsDr9TFJvadREL0wqbdVohCRdc3MTSCv8qbOGVnvcApxtKn obbo4muigQrPqXj5YigCtgYTJTvlQt5KWFt3cFAPT6eqPtbnGV6Uq4nDQjbpe7qRbwqagD CiT+jlwZUR2/E19Zk1EM/QqJQzBDkVFtVmpEQ5fGHG9i/MdARavrNGh3uFy2mKK804T64P 0Au6vbtWtPMOY+L22HKlZMs6OxMvteZOhlchYGHR7qcmqeiy8PmQqRY0wGJVM0v6g0R5B+ 9MnKZsue4H10a/MfSK0Ykm7Zl3x64WNXKcigpxCYKLILQaxPhJG0NcqOh/gX6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756419721; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TMGlkr1Ryoia99wgbFJixi6MxOrKdQwWXXjnGM0AxLE=; b=rd8UaVgBZIQFmWKsSsmiZfeJ+jdf0J6ZgvalA9F0UcaUHG+pufl0udZ90VZ3nVE0g1mNBj JPgR4hzpmq3xAs2pWwLGkBu34fyiT39bm1ZI40/7XOp1M8oyvFb1iZXX4UUIb1Q22UCEl3 r9ru4oUqR7OmWQqnmP2ZQJW/Usy5N8FHLIJNzWqi5lMhg5LTtJl9tAfiji+9udtRrd8P2q XdXMO8JW3sif3i2Cg0zgEPVO1kDFsCEFdr5vr6w5HuQ/fgCRRTtdtbvXgf2pXcS9y0pqYt dQvaGvus7hZgJUPm7fknl+U4CfA8qkM4K8tWPOsEiPo3Ng66WMIEg80dx72jYw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756419721; a=rsa-sha256; cv=none; b=HHT++z6L2ONqgsjN2IM+wB7jlfPxpKPnushuLrESThNrVSyxsLLkCWJR51VWNcCUjmTyTV wMkM1E/9W37Cp9H5QVZA5bKoFLsUXOHl4ne/fE02C4DUuF0KoKPgcg0i4IcE+6kbW6i/De hdGNHOHao1eQe0sdJbfS8a+avn+8L9YghxyJUgCliOY1Cs8SQD5nbtowicRO2JbefFk4vb 8M1piVPGy4HiT13p8QQtK5rmTptMK9soTc573Bbyt8MshymGHJ1Q7nBrVTXHly3VrPuqBi gMs08bmCxajaXPpM9ZKnSK+n1rcn5gtkmMcXu4tM+CxemNfHkK5hu4zM78og9Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) (Authenticated sender: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cCbVK0MpTz14Pf; Thu, 28 Aug 2025 22:22:01 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-qv1-f51.google.com with SMTP id 6a1803df08f44-70ddadde292so13781866d6.0; Thu, 28 Aug 2025 15:22:01 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVa8rxCuMfqbNnF7StsL2glTYCGgyvKj05T0yKiNfpnqKICwV+hTWxKQhPv0vjbbGIgRfsQnYXqsEMMRWpiHA==@freebsd.org X-Gm-Message-State: AOJu0YzoaoFjVQluevTIbXL1w2iffNRiPyM6NbASBTZlLYlLoWVMKTZJ enIIPajm6pDTx228tRD8PQju6sWRLTYjphJU4oFoj2PI3l/xl9ZpNmWN3UhFx2o7QUgAi7h86vH O0dzZu+7FUhGsvjS2EkZpaXUselSU4ms= X-Google-Smtp-Source: AGHT+IHDVINZPVd2ZG9VVdPO5LX8Jiu6YLl61v58KFtKOI8+mBi7tqRAViSdHbYWgRZaybhIiRWuvM6rTnYZa7fshYM= X-Received: by 2002:a05:6214:20af:b0:70d:ed1f:38ab with SMTP id 6a1803df08f44-70ded1f3d53mr63358806d6.15.1756419720455; Thu, 28 Aug 2025 15:22:00 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Fri, 29 Aug 2025 00:21:48 +0200 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXyY7OYxumsLrqU29OZ0cZR3ADPzyCXtfuWN1EPZ1rgQqLjsVqvFKrke-tE Message-ID: Subject: Re: August 2025 stabilization week To: freebsd-current@freebsd.org, src-committers@freebsd.org Cc: Gleb Smirnoff Content-Type: multipart/alternative; boundary="00000000000083acf8063d745545" --00000000000083acf8063d745545 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 27, 2025 at 7:26=E2=80=AFPM Olivier Cochard-Labb=C3=A9 wrote: > > > I'm still waiting for our contributions about this stabweek before closin= g > the week. > > > The "August 2025 stabilization week" is now over. This stabweek has been more challenging than usual, so please be aware of the following known issues: 1. OpenSSL 3.5.1: The legacy provider is broken, causing some ports to fail. A temporary fix is to use `env CRYPTOGRAPHY_OPENSSL_NO_LEGACY=3D1`. C= f an example of regression in PR/273656 2. MIT Kerberos: The default Kerberos is now MIT. Clients should migrate smoothly, but some scripts may need adjusting. Machines running kdc must continue to use Heimdal by setting WITHOUT_MITKRB5=3D"yes" in /etc/src.conf= . 3. Still empty Pkg repo today: The official package repository is currently almost empty. Don't run `make delete-old-libs` unless you're prepared to build packages from source.=E2=80=AFA bug in the current versio= n of pkg means that running `pkg upgrade` might result in the removal of many packages due to this empty repository state. 4. ABI Breakage: A recent ABI change in `setgroups(2)` and `getgroups(2)` syscalls will cause some packages to crash. These packages must be rebuilt. 5. ZFS Kernel Panic: We've identified a 100% reproducible kernel panic when running ZFS regression tests. The bug has been reported on PR/289131. The FreeBSD CI ZFS tests have not been running for about a month, with the latest run also resulting in a panic too [1]. Thanks for your reports, Olivier [1] https://ci.freebsd.org/job/FreeBSD-main-amd64-test_zfs/14237/console --00000000000083acf8063d745545 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, = Aug 27, 2025 at 7:26=E2=80=AFPM Olivier Cochard-Labb=C3=A9 <olivier@freebsd.org> wr= ote:


I'm still waiti= ng for our contributions about this stabweek before closing the week.



The "August 2025 stabilization week" is now over.

This st= abweek has been more challenging than usual, so please be aware of the foll= owing known issues:

1.=C2=A0 OpenSSL 3.5.1: The legacy provider is b= roken, causing some ports to fail. A temporary fix is to use `env CRYPTOGRA= PHY_OPENSSL_NO_LEGACY=3D1`. Cf an example of regression in PR/273656
2.=C2=A0 MIT Kerberos: The default Kerberos is now MIT. Clients should mig= rate smoothly, but some scripts may need adjusting. Machines running kdc mu= st continue to use Heimdal by setting WITHOUT_MITKRB5=3D"yes" in = /etc/src.conf.

3.=C2=A0 Still empty Pkg repo today: The official pac= kage repository is currently almost empty. Don't run `make delete-old-l= ibs` unless you're prepared to build packages from source.=E2=80=AFA bu= g in the current=C2=A0version of pkg means that running `pkg upgrade` might= result in the removal of many packages due to this empty=C2=A0repository s= tate.

4.=C2=A0 ABI Breakage: A recent ABI change in `setgroups(2)` a= nd `getgroups(2)` syscalls will cause some packages to crash. These package= s must be rebuilt.

5.=C2=A0 ZFS Kernel Panic: We've identified a= 100% reproducible kernel panic when running ZFS regression tests. The bug = has been reported on PR/289131. The FreeBSD CI ZFS tests have not been=C2= =A0running for about a month, with the latest run also resulting in a panic= too [1].

Thanks for your reports,


[1]=C2=A0https://ci.free= bsd.org/job/FreeBSD-main-amd64-test_zfs/14237/console
--00000000000083acf8063d745545-- From nobody Thu Aug 28 22:29:36 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cCbgC6bWnz65XCW for ; Thu, 28 Aug 2025 22:29:43 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com [IPv6:2607:f8b0:4864:20::112e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cCbgC4V29z45Fb; Thu, 28 Aug 2025 22:29:43 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-71d6051afbfso11432947b3.2; Thu, 28 Aug 2025 15:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756420177; x=1757024977; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7cwRevGhFsxTalUL0nMqFzhRARJpOdqwuTbJIoj45po=; b=DSAS+sLw7ql3mfXBNLyfAxT1zLw1sZW+5hqp7TbAxmS8Qc8PcAsts5YZiOO+bBFUeh 8TyW09Z41rGvej3BB8Nqk+BSkgVtRB8lkZ0BVar9QLRdKdrKF/Ocy+Q5eUx2qBBlwXW9 tZOMBUH0HiAuVuPP0odJAIsVuzD5HPHiG3v2B+Sc8LJhx1mIOLvpHlpC+d24qQvX8PX8 JYAX1r4826f6Omeb2a0TqqdOrZdkZWnuQ1DifBogr9f3k1nG7y208kuDCMVf5Mtte5HI Xyv78kZcMcjqiPwQZvW/r9X01AD3hWwIYS2sQyCfu4X0N0Whn2/DqAfLTCRvefi3OhmG L1jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756420177; x=1757024977; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7cwRevGhFsxTalUL0nMqFzhRARJpOdqwuTbJIoj45po=; b=dDxcSDR9zmOGKxZaAteBSCYt0j00hZnWHnKTc/HAlAWoqOeQJv6Mw395uRP42Ia6J1 gU9SjRVuIIznZb5sudhDGqw5QmzQxV1pvFeP6k4cE0SwDmJ8xof9qSx9b98JPBhVjL3f cW9ud2z9HtFwQkelZyE0/UUiClP0O9rQ4JSwm0GC0U+mA/sczyVMRe5VCO3yyqo7CjED bG6/aQP9I2vFB/FdU5mvm7YVm1Scv2JSU2gnNa/BNZ39vG9RaYq4J/AsXiKcRxoBge8b 5yyYmCyxjPPsoQpF9atO0YQ/oeSzQgHxQ7yKDjXuaxlOpZtx1zBQeuIRrX6Jd6Dr0VqW EnUA== X-Forwarded-Encrypted: i=1; AJvYcCVSyI4HWHkPqoCRuNzYZCqd5mfpDQYLbBfbz75tu3VoP49p+RUNYSnRcuS+foXXPP2slUdU1DC8Na2DqsJB6XE=@freebsd.org, AJvYcCWeyt5TilwFG1qUismJSwV3UTBTmEBqcbt/Z4htqvg3Za3m0/5l0H04y3El82oIdNrdlGYXVbgVQydmoADqczI=@freebsd.org X-Gm-Message-State: AOJu0YzxZ4/jct2c/y0DvZc6Lk/oLaXSq34nFzZA3vQYHjuYjoDDbq2x Yj2Yf9DwsBOysjHWYjXARS3clkUiPtJ42y8O76VH4xOSVMTlDWafpaTzpXJwjYWZ X-Gm-Gg: ASbGnctfUcnmjXorqcoSUger48UCttcd5gvgx/5FWPGTpAJ9I9cEMDagG48ou2stOC3 O3YfxrpQrr0HeLQQ6OUxQa4cIULYYUm1ooqNIiNV0YW+QeFEidnA75TTv+LzOe9VM9ljtW4Bor3 8nUxhSBjRLQvZa90zhsyZM11PBITWlWvsvNPqx4GwPUwLorqtT9/yxhP48eZ7RS98M21wt7jSkb lkcd0eOi2cjG2FAYqSWsVoOfUgRQM33vhH6C3OchPDL9B4W3FqlXpZg96k8wCRSxi8mIOMIGrxm hTDkdOoAYyK8LvGEtPBFu/SE1vZC0c0tt+xQua0NMA787+mwDKtk2nTVBeMezUlPYDMGGM/fKhd SgJa8Qg+P8nY/BgMDEeLnPH5aflcEBTWJ7tMfZYwAj3+1ZJPjeL7D1aN/mSwPjfOuGcJjVffWST 7G9YNBROlW4RE= X-Google-Smtp-Source: AGHT+IEp0BdqC6tlhNa6G1ISLmlRqqcXR35dSdBHstvRPF2iG909NuJgrbVBinMdDH6jQ5oXskPZLg== X-Received: by 2002:a05:690c:892:b0:71f:b944:1035 with SMTP id 00721157ae682-71fdc5313b3mr275783727b3.50.1756420177220; Thu, 28 Aug 2025 15:29:37 -0700 (PDT) Received: from ?IPV6:2600:1700:18f0:6812:129a:8666:ef01:3293? ([2600:1700:18f0:6812:129a:8666:ef01:3293]) by smtp.gmail.com with ESMTPSA id 00721157ae682-721ce5f102esm2621647b3.67.2025.08.28.15.29.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Aug 2025 15:29:36 -0700 (PDT) Message-ID: Date: Thu, 28 Aug 2025 18:29:36 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Thunderbird Daily Subject: Re: August 2025 stabilization week To: =?UTF-8?Q?Olivier_Cochard-Labb=C3=A9?= , freebsd-current@freebsd.org, src-committers@freebsd.org Cc: Gleb Smirnoff References: Content-Language: en-US From: Ian FREISLICH In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cCbgC4V29z45Fb On 2025-08-28 18:21, Olivier Cochard-Labbé wrote: > The "August 2025 stabilization week" is now over. > > This stabweek has been more challenging than usual, so please be aware > of the following known issues: > > 1.  OpenSSL 3.5.1: The legacy provider is broken, causing some ports to > fail. A temporary fix is to use `env CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1`. > Cf an example of regression in PR/273656 I had provided a patch to the list that fixes the legacy provider, at least for me. It can be found here thanks to Pierre Pronchery https://reviews.freebsd.org/D51897 Ian From nobody Thu Aug 28 23:06:54 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cCcV832y7z65ZkM for ; Thu, 28 Aug 2025 23:06:56 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cCcV82K6dz47ks; Thu, 28 Aug 2025 23:06:56 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756422416; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tiu1Ic4VqWMR+w+KHlUcqByXCAcJmqyBcvfFmW2m/pk=; b=k00QI6NdUWTJX/h8PIiQXm0x4SWq/XSGTuav64vTuLdvqLnHxhCngn4q8aAsS6rAaTSJ0M 4zBVHYdkMRW3CfkwiqFhfxwAM7kGa85ANpRKQjCwQyG6Q4deJboAuPn4NjJKDEJoWTBVk8 7k4A86TvjLKPp+sXxnEza+Y7ual0jWesmSLG85JUn5pZcl7EA9iIbSvi3S+sQHHgQOkqOk taHinibWaJjX2uKPLiUOTqgNhfpO4abZl1UYftsrrMAJ36Rl2oRw1FCYVaZT5DITtjcW9C nzCxP4Yz9DFziomywNzceMqegIzt6n2ByxRCX3SVspoF7oD+2tNi+XirJOQpBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756422416; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tiu1Ic4VqWMR+w+KHlUcqByXCAcJmqyBcvfFmW2m/pk=; b=sbz3K+0b0q7FZJkrGEhsewNGZIT6n0+K7hAq+QXWNHddfWoUGfDOdUjYy731oxXYfoW6Qp OgBpVgPunncaCq+5JclMwXfb7zM3Qy0KUaVlA9zF7saxOsNDOGrBbkT2mznrzd0JOAxrtI i1SCGaUSdMLpBD5WtpHSL+FwxqOUFtP2MSS2LMGT1glyeFjFB9sn3Mk3Fiqp6SbQmUmf0x DsCNHy7uDsGvQ1xhdQt5+poRrXQ/0v3vxYLX9+L7qgZ2nX8QtpHQQkV13OvKsGJmhZHY/J prTX0F8yNgS3fpmQAedfb5Rr72Qi3dvddIYGGVNs2K97lmWjFke1ho+3+nexyg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756422416; a=rsa-sha256; cv=none; b=NkwvtH3Iwyr20FTEm+dOioqHBA/C8pcvqod8D6/E1yrku8LqxI94H6pBijIe2npzHdExWr Ipkzp+oLZQNdtwKXGXHIoMMZleOstl5hpV+Q1TL8vfWvOTszUBcP2Q4RHfgX1yRwZRg2WT A/gSCFscNGpY4Sh8egW08nJeNMp2vZtQKLYtknAPnIpkzlU93JJV93Na4StAAoxgwpGGow KlH3NJ3+f/uaH6MrwHnm4n+daySwxQxiy+9t0eorYpDnFOkDHrWlgliVsiwhnLQwUcTabX Fw5v7ZgeWQSxYpLo3g2vHHWHGc/Rd/Cs99UK992NqyF/z+fK306GHZuFHL30wA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cCcV76LF6z15XF; Thu, 28 Aug 2025 23:06:55 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: Date: Thu, 28 Aug 2025 18:06:54 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: August 2025 stabilization week To: =?UTF-8?Q?Olivier_Cochard-Labb=C3=A9?= , freebsd-current@freebsd.org, src-committers@freebsd.org Cc: Gleb Smirnoff References: Content-Language: en-US From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/28/25 17:21, Olivier Cochard-Labbé wrote: > > On Wed, Aug 27, 2025 at 7:26 PM Olivier Cochard-Labbé > wrote: > > > > I'm still waiting for our contributions about this stabweek before closing the week. > > > > > The "August 2025 stabilization week" is now over. > > This stabweek has been more challenging than usual, so please be aware of the following known issues: > > 1.  OpenSSL 3.5.1: The legacy provider is broken, causing some ports to fail. A temporary fix is to use `env CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1`. Cf an example of regression in PR/273656 > > 2.  MIT Kerberos: The default Kerberos is now MIT. Clients should migrate smoothly, but some scripts may need adjusting. Machines running kdc must continue to use Heimdal by setting WITHOUT_MITKRB5="yes" in /etc/src.conf. > > 3.  Still empty Pkg repo today: The official package repository is currently almost empty. Don't run `make delete-old-libs` unless you're prepared to build packages from source. A bug in the current version of pkg means that running `pkg upgrade` might result in the removal of many packages due to this empty repository state. > > 4.  ABI Breakage: A recent ABI change in `setgroups(2)` and `getgroups(2)` syscalls will cause some packages to crash. These packages must be rebuilt. > At the risk of being both repetitive and pedantic, I note once more that it's important to emphasize that they must be rebuilt *if you are not running a kernel with COMPAT_FREEBSD14*. The distinction is quite important because if you're not running GENERIC or MINIMAL and you need to rebuild, ok, cool, that's the usual process. If you're running GENERIC or MINIMAL and you need to rebuild, I really want to hear about it because that means I broke something that wasn't supposed to break. > 5.  ZFS Kernel Panic: We've identified a 100% reproducible kernel panic when running ZFS regression tests. The bug has been reported on PR/289131. The FreeBSD CI ZFS tests have not been running for about a month, with the latest run also resulting in a panic too [1]. > > Thanks for your reports, > > Olivier > > [1] https://ci.freebsd.org/job/FreeBSD-main-amd64-test_zfs/14237/console From nobody Fri Aug 29 03:07:58 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cCjrX6YVYz65vc0 for ; Fri, 29 Aug 2025 03:08:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cCjrX3P7Nz3Wdv; Fri, 29 Aug 2025 03:08:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 57T37wrU046472; Fri, 29 Aug 2025 06:08:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 57T37wrU046472 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 57T37wTn046471; Fri, 29 Aug 2025 06:07:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 29 Aug 2025 06:07:58 +0300 From: Konstantin Belousov To: Kyle Evans Cc: Olivier =?utf-8?Q?Cochard-Labb=C3=A9?= , freebsd-current@freebsd.org, src-committers@freebsd.org, Gleb Smirnoff Subject: Re: August 2025 stabilization week Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cCjrX3P7Nz3Wdv On Thu, Aug 28, 2025 at 06:06:54PM -0500, Kyle Evans wrote: > On 8/28/25 17:21, Olivier Cochard-Labbé wrote: > > > > On Wed, Aug 27, 2025 at 7:26 PM Olivier Cochard-Labbé > wrote: > > > > > > > > I'm still waiting for our contributions about this stabweek before closing the week. > > > > > > > > > > The "August 2025 stabilization week" is now over. > > > > This stabweek has been more challenging than usual, so please be aware of the following known issues: > > > > 1.  OpenSSL 3.5.1: The legacy provider is broken, causing some ports to fail. A temporary fix is to use `env CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1`. Cf an example of regression in PR/273656 > > > > 2.  MIT Kerberos: The default Kerberos is now MIT. Clients should migrate smoothly, but some scripts may need adjusting. Machines running kdc must continue to use Heimdal by setting WITHOUT_MITKRB5="yes" in /etc/src.conf. > > > > 3.  Still empty Pkg repo today: The official package repository is currently almost empty. Don't run `make delete-old-libs` unless you're prepared to build packages from source. A bug in the current version of pkg means that running `pkg upgrade` might result in the removal of many packages due to this empty repository state. > > > > 4.  ABI Breakage: A recent ABI change in `setgroups(2)` and `getgroups(2)` syscalls will cause some packages to crash. These packages must be rebuilt. > > > > At the risk of being both repetitive and pedantic, I note once more that it's important to emphasize that they must be rebuilt > *if you are not running a kernel with COMPAT_FREEBSD14*. The distinction is quite important because if you're not running > GENERIC or MINIMAL and you need to rebuild, ok, cool, that's the usual process. If you're running GENERIC or MINIMAL and > you need to rebuild, I really want to hear about it because that means I broke something that wasn't supposed to break. > To be correct, this is not an ABI breakage. Old binaries which are linked against setgroups@FBSD_1.0/SYS_freebsd14_setgroups#80, get the old behavior. The new behavior of setgroups@FBSD_1.8/SYS_setgroups#596 is what hits the old unaware code _after recompilation and linking_. I.e. while being perfectly ABI compatible there, we get some nuanced new behavior that is impossible to detect at the compile time. I was assured that the advantages of this change overcome the inconvinience. not assuming egid presence is provided > > 5.  ZFS Kernel Panic: We've identified a 100% reproducible kernel panic when running ZFS regression tests. The bug has been reported on PR/289131. The FreeBSD CI ZFS tests have not been running for about a month, with the latest run also resulting in a panic too [1]. > > > > Thanks for your reports, > > > > Olivier > > > > [1] https://ci.freebsd.org/job/FreeBSD-main-amd64-test_zfs/14237/console > From nobody Fri Aug 29 03:21:43 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cCk891fG7z65wqg for ; Fri, 29 Aug 2025 03:21:45 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cCk890w35z3ZBB; Fri, 29 Aug 2025 03:21:45 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756437705; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VGp3qhpLwraBhbOqopbCCAP7aFUlVouDpWW+yp+/24U=; b=XC3i+ZhlqPkHNxyUcFTVV/W5dm+BpLijs8PVTNrH1RU3/bLKQPtLXq99Kgm+1fZAbfME0f 1xwcC5vfKetPk3xZ7zgR6BZE4OIDblux3UNZr5RhKHIXw4LMEHgexMRXHL/s2zRRf5T9eN KSIaRKin0NKIkvea5/2ZJnC3Mzfe7EbNyerySQJDc36LELe8WA1/7xtB5Iybuf/zGSayov 6nv71qAgQK40CQLS85bsELnzKvPIx/quZ5mCZpCSY4Y0lGwwBZF7cwCoWUBjydo1pbcRjU iBNfvOJFqxIYqY+UTwfle6VSSfjVD+bnP9HGlD7nE/+Iu4eKVZ2huA8AkVc51Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756437705; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VGp3qhpLwraBhbOqopbCCAP7aFUlVouDpWW+yp+/24U=; b=v2otr4q0JKqDY1CnkICx+By6e5ftFOVnOeSZtWUohRPyhF/9IoS6JommefEwyyayW8mR20 JvDBVcriRSN3ORbXv93IpHD72c7FKP9s6iRLgjeR4EiBrntcQb+6gXe7WF8kUKUjLXZUju WmcmqC5CEGIpzGhD6si36eVd3iEpFAwQfhMiUnGwlSJM+t/8SAe3UvNmxbVUGFWEpFdDPm 3WqJSlyqqelZfE2zk3enSV6wi2cvumlQ9jBX84DvHcfJjk6QSE4VgXHSa4kYWGwfgsLUjG YYOA1u4nC+D0iyu2L7YoBHS3RDWjrEifQYdZoWqnRpC1xy2vTToPB/AJskXELQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756437705; a=rsa-sha256; cv=none; b=Qmco1mCu3A8nTe5bmtIoQPkvAkW7n7RjPaRCudXLLxw0eSSTw2dAmOzchNzGvJPwWhGQaV CzicaKk6C775gkM/1653ddD+v2hic1GZI4B1d4BT8D+pdnXSwZ+MOiOfyedG4hzdZtx7j8 3g2UKOY79AsYNC/poHf+Y9ywT8RiNhVaho8vO6/lAZMr0Pg9g5X4vnkY+1nocM5cD9Lo0z ANkhUGdNXwiE+QJfot9TUASd3vcHZ/iqow9M+AJDE/fE5evh3jp7hgus9j2IWvY0qiNC7L WW6hshDwlprsFM1xZHSUm5cy6uL50aQELldeJCCjiURXxCmcM5BPKhkUrTEPsw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cCk884FM4z1BRy; Fri, 29 Aug 2025 03:21:44 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <6b399776-d1d6-480e-809b-2b5d8b7fe91a@FreeBSD.org> Date: Thu, 28 Aug 2025 22:21:43 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: August 2025 stabilization week To: Konstantin Belousov Cc: =?UTF-8?Q?Olivier_Cochard-Labb=C3=A9?= , freebsd-current@freebsd.org, src-committers@freebsd.org, Gleb Smirnoff References: Content-Language: en-US From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/28/25 22:07, Konstantin Belousov wrote: > On Thu, Aug 28, 2025 at 06:06:54PM -0500, Kyle Evans wrote: >> On 8/28/25 17:21, Olivier Cochard-Labbé wrote: >>> >>> On Wed, Aug 27, 2025 at 7:26 PM Olivier Cochard-Labbé > wrote: >>> >>> >>> >>> I'm still waiting for our contributions about this stabweek before closing the week. >>> >>> >>> >>> >>> The "August 2025 stabilization week" is now over. >>> >>> This stabweek has been more challenging than usual, so please be aware of the following known issues: >>> >>> 1.  OpenSSL 3.5.1: The legacy provider is broken, causing some ports to fail. A temporary fix is to use `env CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1`. Cf an example of regression in PR/273656 >>> >>> 2.  MIT Kerberos: The default Kerberos is now MIT. Clients should migrate smoothly, but some scripts may need adjusting. Machines running kdc must continue to use Heimdal by setting WITHOUT_MITKRB5="yes" in /etc/src.conf. >>> >>> 3.  Still empty Pkg repo today: The official package repository is currently almost empty. Don't run `make delete-old-libs` unless you're prepared to build packages from source. A bug in the current version of pkg means that running `pkg upgrade` might result in the removal of many packages due to this empty repository state. >>> >>> 4.  ABI Breakage: A recent ABI change in `setgroups(2)` and `getgroups(2)` syscalls will cause some packages to crash. These packages must be rebuilt. >>> >> >> At the risk of being both repetitive and pedantic, I note once more that it's important to emphasize that they must be rebuilt >> *if you are not running a kernel with COMPAT_FREEBSD14*. The distinction is quite important because if you're not running >> GENERIC or MINIMAL and you need to rebuild, ok, cool, that's the usual process. If you're running GENERIC or MINIMAL and >> you need to rebuild, I really want to hear about it because that means I broke something that wasn't supposed to break. >> > > To be correct, this is not an ABI breakage. Old binaries which are linked > against setgroups@FBSD_1.0/SYS_freebsd14_setgroups#80, get the old behavior. > The new behavior of setgroups@FBSD_1.8/SYS_setgroups#596 is what hits the > old unaware code _after recompilation and linking_. > I haven't yet seen any reports of problems after recompilation and linking, but I'm interested in those as well, of course. The reports we've seen to-date that I am aware of have been from getting smacked with a SIGSYS or SIGABRT, and I suspect the latter may have been something that fork()ed a child that got hit with a SIGSYS, which effectively asserted in the parent when the child did not exit as expected. We weren't able to collect any debug information from the SIGABRT case to confirm, though. > I.e. while being perfectly ABI compatible there, we get some nuanced new > behavior that is impossible to detect at the compile time. I was assured > that the advantages of this change overcome the inconvinience. > > not assuming egid presence is provided >>> 5.  ZFS Kernel Panic: We've identified a 100% reproducible kernel panic when running ZFS regression tests. The bug has been reported on PR/289131. The FreeBSD CI ZFS tests have not been running for about a month, with the latest run also resulting in a panic too [1]. >>> >>> Thanks for your reports, >>> >>> Olivier >>> >>> [1] https://ci.freebsd.org/job/FreeBSD-main-amd64-test_zfs/14237/console >> > From nobody Fri Aug 29 03:37:18 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cCkVM6LLrz65xG5 for ; Fri, 29 Aug 2025 03:37:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cCkVM4Z69z3cX6; Fri, 29 Aug 2025 03:37:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 57T3bJ3u048293; Fri, 29 Aug 2025 06:37:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 57T3bJ3u048293 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 57T3bIP3048292; Fri, 29 Aug 2025 06:37:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 29 Aug 2025 06:37:18 +0300 From: Konstantin Belousov To: Kyle Evans Cc: Olivier =?utf-8?Q?Cochard-Labb=C3=A9?= , freebsd-current@freebsd.org, src-committers@freebsd.org, Gleb Smirnoff Subject: Re: August 2025 stabilization week Message-ID: References: <6b399776-d1d6-480e-809b-2b5d8b7fe91a@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6b399776-d1d6-480e-809b-2b5d8b7fe91a@FreeBSD.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cCkVM4Z69z3cX6 On Thu, Aug 28, 2025 at 10:21:43PM -0500, Kyle Evans wrote: > On 8/28/25 22:07, Konstantin Belousov wrote: > > On Thu, Aug 28, 2025 at 06:06:54PM -0500, Kyle Evans wrote: > > > On 8/28/25 17:21, Olivier Cochard-Labbé wrote: > > > > > > > > On Wed, Aug 27, 2025 at 7:26 PM Olivier Cochard-Labbé > wrote: > > > > > > > > > > > > > > > > I'm still waiting for our contributions about this stabweek before closing the week. > > > > > > > > > > > > > > > > > > > > The "August 2025 stabilization week" is now over. > > > > > > > > This stabweek has been more challenging than usual, so please be aware of the following known issues: > > > > > > > > 1.  OpenSSL 3.5.1: The legacy provider is broken, causing some ports to fail. A temporary fix is to use `env CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1`. Cf an example of regression in PR/273656 > > > > > > > > 2.  MIT Kerberos: The default Kerberos is now MIT. Clients should migrate smoothly, but some scripts may need adjusting. Machines running kdc must continue to use Heimdal by setting WITHOUT_MITKRB5="yes" in /etc/src.conf. > > > > > > > > 3.  Still empty Pkg repo today: The official package repository is currently almost empty. Don't run `make delete-old-libs` unless you're prepared to build packages from source. A bug in the current version of pkg means that running `pkg upgrade` might result in the removal of many packages due to this empty repository state. > > > > > > > > 4.  ABI Breakage: A recent ABI change in `setgroups(2)` and `getgroups(2)` syscalls will cause some packages to crash. These packages must be rebuilt. > > > > > > > > > > At the risk of being both repetitive and pedantic, I note once more that it's important to emphasize that they must be rebuilt > > > *if you are not running a kernel with COMPAT_FREEBSD14*. The distinction is quite important because if you're not running > > > GENERIC or MINIMAL and you need to rebuild, ok, cool, that's the usual process. If you're running GENERIC or MINIMAL and > > > you need to rebuild, I really want to hear about it because that means I broke something that wasn't supposed to break. > > > > > > > To be correct, this is not an ABI breakage. Old binaries which are linked > > against setgroups@FBSD_1.0/SYS_freebsd14_setgroups#80, get the old behavior. > > The new behavior of setgroups@FBSD_1.8/SYS_setgroups#596 is what hits the > > old unaware code _after recompilation and linking_. > > > > I haven't yet seen any reports of problems after recompilation and linking, but I'm > interested in those as well, of course. The reports we've seen to-date that I am > aware of have been from getting smacked with a SIGSYS or SIGABRT, and I suspect the > latter may have been something that fork()ed a child that got hit with a SIGSYS, which > effectively asserted in the parent when the child did not exit as expected. We weren't > able to collect any debug information from the SIGABRT case to confirm, though. > What we might do, which is not too late still, is something like this, of course not tested. Then only the code that explicitly opts in, would get the new behavior after the recompilation. I am more worried about ports and third-party compilation envs that we do not control, than about src/. diff --git a/include/unistd.h b/include/unistd.h index 21e3a7740607..7de52d036654 100644 --- a/include/unistd.h +++ b/include/unistd.h @@ -571,7 +571,11 @@ int ruserok(const char *, int, const char *, const char *); int select(int, fd_set *, fd_set *, fd_set *, struct timeval *); #endif int setdomainname(const char *, int); +#ifndef _WANT_SEGROUPS_NO_EGID int setgroups(int, const gid_t *); +#else +int setgroups(int, const gid_t *) __attribute__((__alias__("setgroups@FBSD_1.0"))); +#endif void sethostid(long); int sethostname(const char *, int); int setlogin(const char *); > > I.e. while being perfectly ABI compatible there, we get some nuanced new > > behavior that is impossible to detect at the compile time. I was assured > > that the advantages of this change overcome the inconvinience. > > > > not assuming egid presence is provided > > > > 5.  ZFS Kernel Panic: We've identified a 100% reproducible kernel panic when running ZFS regression tests. The bug has been reported on PR/289131. The FreeBSD CI ZFS tests have not been running for about a month, with the latest run also resulting in a panic too [1]. > > > > > > > > Thanks for your reports, > > > > > > > > Olivier > > > > > > > > [1] https://ci.freebsd.org/job/FreeBSD-main-amd64-test_zfs/14237/console > > > > > From nobody Fri Aug 29 03:42:10 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cCkc62s1Tz65y0S for ; Fri, 29 Aug 2025 03:42:30 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cCkc60q68z3f3H; Fri, 29 Aug 2025 03:42:30 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-61cd1046d42so2146318a12.3; Thu, 28 Aug 2025 20:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756438942; x=1757043742; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=1UZmpycPrBSo6CGO3zDeSw6rndsZV7pjwiBQfYZlsr4=; b=OjnuqVwZbJ303Cs5Cby6TXLb/hBBEbvUBYBXf6PYTDd1cbvBym5rL+0ezqB77kXWtx NYotWpebOGJ8pnmj09/RQVBZfIPx30qBz3SYeRLZ1n6xeG3b7TetAyt8zwtyKjNb1SHR MYZ0Hhhq+RHJazFNRmoIWzowuYdX9ScfgBhPwjG4JbNkWyoTCEasU67sgYxchT23IPxR L5F+7pk5wDFqiWI5aQUjRS5QFdzEm9KkeOK49djG+cC3yw5J8otpxmuXuSg5Vp2iHvkP Y18jpZ/TFGxEgw47/Uw8XNLF6poyDkG53FUGTYk4exKts1uqkqHdj7icT7q+JlEmF5ge WBxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756438942; x=1757043742; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1UZmpycPrBSo6CGO3zDeSw6rndsZV7pjwiBQfYZlsr4=; b=FywrDI5VUD5dotzG19hRCQzzsSJIuvdVIpMSfrpxGZKF0icZKZ4v4wJR6+RJFiCur9 Zaqb1J9am80L3/TCmrtcYNwA6c/AcADR/EWckAejRrcEs7omnGz3PKv4dL5JaggbAguj iYTGLij+1QxvC3P5vASClbHRtsRFek2avHDZORbbDCKilkrUzDTO6lCFBOHQjAmYzRx2 GJYgCNkcPqGXz8/vk55E/fvBUBb5Tiws2cZGubjsbV9AjZC/hJdquruPgB3MmylZrNdE D7Oe6zbebfTDtd+Ijuk8Nt5Zf/6Xqj5WmoDZ8q0RT6owAkk/CQFkCDOYrl+1HjGmVYf5 /FGA== X-Forwarded-Encrypted: i=1; AJvYcCUHC1hubDleOh0maoaQdaa8DfqdF6JikUT5TUSVQPjnvCennSLrYMrDe7G6dXKZxWAlJtzq50tf@freebsd.org, AJvYcCURxsIcSHVEYBj3uDQrjnN4uCcCWLU9B+kbvQsrRVNSHRM7sEj8w5rBcMYNc0oz3ThrIkrzM6xvNtGY+4vB/tg=@freebsd.org X-Gm-Message-State: AOJu0Yz3qEt6oMkYbehBLT4ezNboIWGcPVdQHAtXaTHemYFtvaY5Cn/C qiHgblVjNkn+HfdMGmhZ8Ql44Nlew6VX35OmLiyXhI9KvIU5pNRP9JmbNhUM/2h3hjd76lCPR+b mSt2Yl793HPk9E70x44hZ4usyYN3D4xI4 X-Gm-Gg: ASbGnctJHFzIKFIM1Whzt3uSncmnJ1rYHG0ulyiE9MotcCp+suELHVNRbXJqyxlckZD 3Mum07z6axVKdC6cPAmLSyLMakBJ5f0ztgnt9SRNtj0elZa2koknmMFVPp1FDjEEWcvFTS5rTGn wCPTak5HhsfFV3FoHl8zR5/Dcmkqaq02Zfz7zCzF7D3bvkbeWDcfa9wiwEKccpYZYLP3QLECqqm dOYfFZEP04KsGD9A90Mh6OZFMIt4cYbS1PLGR4= X-Google-Smtp-Source: AGHT+IF5XQP8GzZMpZlxDcB7rI+vRfnJoYKpkBSpgEzkntRvuJNn8h1c2ok0SS8ZYpB18n5spi44L8TC6YAPySx6aHY= X-Received: by 2002:a05:6402:52c4:b0:607:28c9:c3c9 with SMTP id 4fb4d7f45d1cf-61c1b453182mr23286747a12.6.1756438942237; Thu, 28 Aug 2025 20:42:22 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Thu, 28 Aug 2025 20:42:10 -0700 X-Gm-Features: Ac12FXxRB_Nh5f-4yHQyqLR5qhQkWFdK1WY2vSLoxxcDIkyhMh5t5jyZYvJK_BI Message-ID: Subject: Re: August 2025 stabilization week To: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Cc: freebsd-current@freebsd.org, src-committers@freebsd.org, Gleb Smirnoff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cCkc60q68z3f3H On Thu, Aug 28, 2025 at 3:22=E2=80=AFPM Olivier Cochard-Labb=C3=A9 wrote: > > CAUTION: This email originated from outside of the University of Guelph. = Do not click links or open attachments unless you recognize the sender and = know the content is safe. If in doubt, forward suspicious emails to IThelp@= uoguelph.ca. > > > On Wed, Aug 27, 2025 at 7:26=E2=80=AFPM Olivier Cochard-Labb=C3=A9 wrote: >> >> >> >> I'm still waiting for our contributions about this stabweek before closi= ng the week. >> >> > > > The "August 2025 stabilization week" is now over. > > This stabweek has been more challenging than usual, so please be aware of= the following known issues: > > 1. OpenSSL 3.5.1: The legacy provider is broken, causing some ports to f= ail. A temporary fix is to use `env CRYPTOGRAPHY_OPENSSL_NO_LEGACY=3D1`. Cf= an example of regression in PR/273656 > > 2. MIT Kerberos: The default Kerberos is now MIT. Clients should migrate= smoothly, but some scripts may need adjusting. Machines running kdc must c= ontinue to use Heimdal by setting WITHOUT_MITKRB5=3D"yes" in /etc/src.conf. This didn't work for me to-day. I got a... crypto/openssh/kexgexs.c:50 gssapi/gssapi.h not found when included from crypto/openssh/ssh-gss.h Anyone know where the Heimdal gssapi.h ends up now during "make buildworld"= ? rick > > 3. Still empty Pkg repo today: The official package repository is curren= tly almost empty. Don't run `make delete-old-libs` unless you're prepared t= o build packages from source.=E2=80=AFA bug in the current version of pkg m= eans that running `pkg upgrade` might result in the removal of many package= s due to this empty repository state. > > 4. ABI Breakage: A recent ABI change in `setgroups(2)` and `getgroups(2)= ` syscalls will cause some packages to crash. These packages must be rebuil= t. > > 5. ZFS Kernel Panic: We've identified a 100% reproducible kernel panic w= hen running ZFS regression tests. The bug has been reported on PR/289131. T= he FreeBSD CI ZFS tests have not been running for about a month, with the l= atest run also resulting in a panic too [1]. > > Thanks for your reports, > > Olivier > > [1] https://ci.freebsd.org/job/FreeBSD-main-amd64-test_zfs/14237/console From nobody Fri Aug 29 03:48:20 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cCkkt1Sm8z65yfD for ; Fri, 29 Aug 2025 03:48:22 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cCkkt0xWvz3flw; Fri, 29 Aug 2025 03:48:22 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756439302; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mmSiDOjeVVYCfx2hEbAP74Njwipfm6JPRFjWYPHBrlE=; b=pM1I6ny1dgGd8rbdzapm4LSwGhgmLnmwcxuhr/NNraqX1pfNfA8fDV9x5PGXtEUbQ0UZ3N B7ECzRQlfr+eXDOrFYWwUcvs5tjOBto3baxWwGud3lLuoKTnHy1nCF6wLEmbXUtODmh7CK vqVa/aigFLvK3tIV37AeDLKiV9AmNm+G1UOPj8Y/eLPfMTctPNPECmtMHkTcpCvYxmwjw6 Qv3Ml59G6JEuOqclN5iPtjUUXlxcmrL7crSshC6WKKK3OS7xvPo7ysogdwZv2+l5Hw/doZ wwDlPLyeSjgeVcbwv3smRJMcYhZiS7qUxXgfHVWVVPO2ccUlUfj7OOFeA+U2bA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756439302; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mmSiDOjeVVYCfx2hEbAP74Njwipfm6JPRFjWYPHBrlE=; b=Bg/8h/ccs9u7VtfRLnXkicIrQCeqyEX76Mz6V0m8OAIXAcsk8TwB1fg9Gq7Ozoke7OrTJp dc0TqIJcSnqk3TVlY3kmT+H/zz4Q17TmWRBuYLG0rEAalKAABk6T7ObAXp7FJx0j6pUtNw bppRIPKw4xCvGBrbRkksUrCF/7gg+632xe3DsF6knAnVMubh6ai/ExcBUwrk0Wk8Toj4CH J7MEFhgleyfiGd789yT77ynd17nqLGEsCKLKpHXyJEDvGTVxmQHATuWs/OCklBaECTzi68 vTZAGzWUB6WpRLUkO1Vkm2mcSgxhfQGiRCLP9whJAo+h/IL9Sm4U5q7SZtkbuQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756439302; a=rsa-sha256; cv=none; b=gvZXWkiYI77IzQli7Q5M2tai0e+Uj8bhiVC70D2EzUoIRz6UxhJcIoX7sHc+NMZ16DgutR sgs/vBPINZt/94cVVRGvPOkFR4OdK/gtOQl4N7ZZ606WkkbWFzUXNL9d+FPCUxO7wQDqtc hDjEsN6YZKjD190ZroFq/Ms8Nkp7hDKlJkdj78Uy7GMHnhwuYzdV5/E899hMjchxADm2jv J9wM1qlCOsRPvxBjKLeWypGKhqL+0/Bax82O+xdxmQRJUfCfg2Sf77XebsqX7NMhxWwPYL /LZKTZl/TFfpaO+P9SBn0moww6iicG/Jpzi2d6JsWENosg/JAw8/ULe0rWTrRQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cCkks38FTz19mW; Fri, 29 Aug 2025 03:48:21 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <44ec5de3-9f61-4043-be74-edbb6272901a@FreeBSD.org> Date: Thu, 28 Aug 2025 22:48:20 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: August 2025 stabilization week To: Konstantin Belousov Cc: =?UTF-8?Q?Olivier_Cochard-Labb=C3=A9?= , freebsd-current@freebsd.org, src-committers@freebsd.org, Gleb Smirnoff References: <6b399776-d1d6-480e-809b-2b5d8b7fe91a@FreeBSD.org> Content-Language: en-US From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/28/25 22:37, Konstantin Belousov wrote: > On Thu, Aug 28, 2025 at 10:21:43PM -0500, Kyle Evans wrote: >> On 8/28/25 22:07, Konstantin Belousov wrote: >>> On Thu, Aug 28, 2025 at 06:06:54PM -0500, Kyle Evans wrote: >>>> On 8/28/25 17:21, Olivier Cochard-Labbé wrote: >>>>> >>>>> On Wed, Aug 27, 2025 at 7:26 PM Olivier Cochard-Labbé > wrote: >>>>> >>>>> >>>>> >>>>> I'm still waiting for our contributions about this stabweek before closing the week. >>>>> >>>>> >>>>> >>>>> >>>>> The "August 2025 stabilization week" is now over. >>>>> >>>>> This stabweek has been more challenging than usual, so please be aware of the following known issues: >>>>> >>>>> 1.  OpenSSL 3.5.1: The legacy provider is broken, causing some ports to fail. A temporary fix is to use `env CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1`. Cf an example of regression in PR/273656 >>>>> >>>>> 2.  MIT Kerberos: The default Kerberos is now MIT. Clients should migrate smoothly, but some scripts may need adjusting. Machines running kdc must continue to use Heimdal by setting WITHOUT_MITKRB5="yes" in /etc/src.conf. >>>>> >>>>> 3.  Still empty Pkg repo today: The official package repository is currently almost empty. Don't run `make delete-old-libs` unless you're prepared to build packages from source. A bug in the current version of pkg means that running `pkg upgrade` might result in the removal of many packages due to this empty repository state. >>>>> >>>>> 4.  ABI Breakage: A recent ABI change in `setgroups(2)` and `getgroups(2)` syscalls will cause some packages to crash. These packages must be rebuilt. >>>>> >>>> >>>> At the risk of being both repetitive and pedantic, I note once more that it's important to emphasize that they must be rebuilt >>>> *if you are not running a kernel with COMPAT_FREEBSD14*. The distinction is quite important because if you're not running >>>> GENERIC or MINIMAL and you need to rebuild, ok, cool, that's the usual process. If you're running GENERIC or MINIMAL and >>>> you need to rebuild, I really want to hear about it because that means I broke something that wasn't supposed to break. >>>> >>> >>> To be correct, this is not an ABI breakage. Old binaries which are linked >>> against setgroups@FBSD_1.0/SYS_freebsd14_setgroups#80, get the old behavior. >>> The new behavior of setgroups@FBSD_1.8/SYS_setgroups#596 is what hits the >>> old unaware code _after recompilation and linking_. >>> >> >> I haven't yet seen any reports of problems after recompilation and linking, but I'm >> interested in those as well, of course. The reports we've seen to-date that I am >> aware of have been from getting smacked with a SIGSYS or SIGABRT, and I suspect the >> latter may have been something that fork()ed a child that got hit with a SIGSYS, which >> effectively asserted in the parent when the child did not exit as expected. We weren't >> able to collect any debug information from the SIGABRT case to confirm, though. >> > > What we might do, which is not too late still, is something like this, > of course not tested. Then only the code that explicitly opts in, would > get the new behavior after the recompilation. > > I am more worried about ports and third-party compilation envs that we > do not control, than about src/. > Ports software almost universally comes from platforms that don't exhibit the same behavior that we used to. We could do something like this, but I'm hesitant to do anything here until we understand if there's even a problem. We haven't even had an actual package set since the change happened on any platform, and we're not going to have any idea what kind of problems lay in wait if nobody's ever actually run the new behavior. > diff --git a/include/unistd.h b/include/unistd.h > index 21e3a7740607..7de52d036654 100644 > --- a/include/unistd.h > +++ b/include/unistd.h > @@ -571,7 +571,11 @@ int ruserok(const char *, int, const char *, const char *); > int select(int, fd_set *, fd_set *, fd_set *, struct timeval *); > #endif > int setdomainname(const char *, int); > +#ifndef _WANT_SEGROUPS_NO_EGID > int setgroups(int, const gid_t *); > +#else > +int setgroups(int, const gid_t *) __attribute__((__alias__("setgroups@FBSD_1.0"))); > +#endif > void sethostid(long); > int sethostname(const char *, int); > int setlogin(const char *); > >>> I.e. while being perfectly ABI compatible there, we get some nuanced new >>> behavior that is impossible to detect at the compile time. I was assured >>> that the advantages of this change overcome the inconvinience. >>> >>> not assuming egid presence is provided >>>>> 5.  ZFS Kernel Panic: We've identified a 100% reproducible kernel panic when running ZFS regression tests. The bug has been reported on PR/289131. The FreeBSD CI ZFS tests have not been running for about a month, with the latest run also resulting in a panic too [1]. >>>>> >>>>> Thanks for your reports, >>>>> >>>>> Olivier >>>>> >>>>> [1] https://ci.freebsd.org/job/FreeBSD-main-amd64-test_zfs/14237/console >>>> >>> From nobody Fri Aug 29 05:46:48 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cCnMk4WyBz667Lt for ; Fri, 29 Aug 2025 05:46:58 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cCnMh5bxhz3pXG; Fri, 29 Aug 2025 05:46:56 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 79DC4C3F3D; Fri, 29 Aug 2025 05:46:48 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 57T5kmm4004504; Fri, 29 Aug 2025 05:46:48 GMT (envelope-from phk) Message-Id: <202508290546.57T5kmm4004504@critter.freebsd.dk> To: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= , freebsd-current@freebsd.org, src-committers@freebsd.org, Gleb Smirnoff Subject: Re: August 2025 stabilization week From: "Poul-Henning Kamp" List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4502.1756446408.1@critter.freebsd.dk> Date: Fri, 29 Aug 2025 05:46:48 +0000 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.79 / 15.00]; FAKE_REPLY(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; NEURAL_SPAM_LONG(0.21)[0.211]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; FREEFALL_USER(0.00)[phk]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; MISSING_XM_UA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DMARC_NA(0.00)[freebsd.dk]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_THREE(0.00)[4] X-Rspamd-Queue-Id: 4cCnMh5bxhz3pXG -------- Poul-Henning Kamp writes: > The only thing I have noticed on my laptop was one time where the USB > ports did not work after resume, but I have not had time to experiment > further. I had a bit of time yesterday, and I can confirm that the USB-A port on the right side of my T14s does not work after suspend/resume. The USB-C and USB-A ports on the left side of the computer does work. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Fri Aug 29 07:28:25 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cCqd24nSfz66GKm for ; Fri, 29 Aug 2025 07:28:38 +0000 (UTC) (envelope-from wulf@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cCqd23hmgz3xm3; Fri, 29 Aug 2025 07:28:38 +0000 (UTC) (envelope-from wulf@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756452518; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=083ftkt2phayAsDzLpzhC14ORtaDHc7SAM3uaeUwmzA=; b=Qw67hhxyGKA9HIYTWIZXV4DE1QPpBWz1kMCHRXw1rnF5UafRK+Nq9dwp7uexLKADUCEen2 qRewU2S7AD7mA8VppP0+WrosDxWwVfPi2VeZO8FddlOQ8eIq9pr7EnAgDeIYVf0GVl6lo8 4BfqNSLeeEZ8Pco4B/TbH9/m2XJ/efXEg2ERj4Ffb/AdxzOugbfy4A50bONgZcYMJVIfsV NIRaCqDL5xJPzNHOysVqaqJxXArETCgC5vZTpAZisFPTz2jpO8pkOf12RfWzZZH/CLQOMk e6nA+qrxGThQoAaGUTN1GVaPn4LSJdD2zj1WLMctHPPr5eURA4T5j241m5pQIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756452518; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=083ftkt2phayAsDzLpzhC14ORtaDHc7SAM3uaeUwmzA=; b=Ge08Vn05Tzm9l+oksu4bqtuRAoEVZPyWSqOYWuYwG8j0JbmVYxPfZ5nNM2f93pKXtUEJN+ oOpBUTyQkiOC40bgKX3AbLMeUKJn7Qda1Cu4fuK+cO8m6ooqhNbTO/K4+rovHouBh4H8Ey bIu3HLrO0KnJ79uxtWk1SFV88ZSrslOyZalxJMUl8qBdFRlkjrtOZcvi6yzRVR+YDgOjwS jkQyuxjBRZvzgZ/a+hui+GdSgTdgAgOA6+apckwoOztgFFXLOzxvz+G4O7MmOzlzzcQEdL 2n2vYi7pePEPH4KXrJwA+ULnSCSy/XWrkbPHO6lx2etKCahIQE6VuAGpMk3YAg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756452518; a=rsa-sha256; cv=none; b=Py0CErZ5gFpMeuIclhWJXVypxtpoFXjQm90/33SP7LD2eiHlHpYVNo92GYgLRC34jDZf1Y eHekDsx/GgVzhFO+Gr/iRXdk6eLFQdOl+5fbQpvt7A97iFg1vQZ1iaUk64gticYfwUKTU0 B0W4cM8ljeYyGOgbNKP0Gj1Ze5+Dp5us9r39kDGfCEU2Th+7n2y56g6pEpZYX7EKRibpw2 +0fRq1Szp9I4A5VyYr9HWrygV3itCuODRseKfzmFPEm8emUoPLZ/NJIz64p54nxnus8Xbt EY0DHKe7X2WeQ6StKRh0ides+XYtDHKtXXsgfBSmfdgSdraJm+Ogdzyqs05OgA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.0.30] (unknown [94.45.197.131]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: wulf) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cCqd20J5dz3N9; Fri, 29 Aug 2025 07:28:37 +0000 (UTC) (envelope-from wulf@FreeBSD.org) Message-ID: <77e7c725-c6f2-494d-b8d5-0a3168ae017e@FreeBSD.org> Date: Fri, 29 Aug 2025 10:28:25 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: CFT: evdev-awared moused To: Nuno Teixeira Cc: freebsd-current@freebsd.org References: <9a192238-a56e-4944-ba1a-c330da2ef32c@kondratyev.su> <3a183117-05ad-4b48-8786-f8afd0dc6de3@FreeBSD.org> <1c78a688-c4b5-44e4-ab57-803526a3a45d@FreeBSD.org> Content-Language: en-US From: Vladimir Kondratyev In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/2/25 15:16, Nuno Teixeira wrote: > Hello Vladimir, > > On recent main, UPDATING says "set the loader tunable hw.usb.usbhid_enable=0" in > case of trouble and this is what I expect to happen on my Lenovo laptop on next > upgrade. > While I can live without mouse on console I don't feel the need to build your > custom moused driver at this point but interested in if there's a PR/review with > your changes that I might missed on this thread? See https://reviews.freebsd.org/D52164 -- WBR Vladimir Kondratyev From nobody Fri Aug 29 13:03:35 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cCz3h5DVgz65Tn0 for ; Fri, 29 Aug 2025 13:03:44 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R10" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cCz3g2WYMz3RYp for ; Fri, 29 Aug 2025 13:03:43 +0000 (UTC) (envelope-from imb@protected-networks.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b="C VDlM/I"; dmarc=pass (policy=reject) header.from=protected-networks.net; spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 2001:470:8d59:1::8 as permitted sender) smtp.mailfrom=imb@protected-networks.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:subject:subject:from:from:content-language :user-agent:mime-version:date:date:message-id; s=201508; t= 1756472615; bh=kidmv2Ai+AJ3sUAoUfP+y6avAv7JjnQy9QoXNWtI1GA=; b=C VDlM/IMWUhqlnw0JwapAILf1KlfnprseQI2gr6fMJs2Y1W2hBHDQpcOUi/LzQv9X vLzJXcw+tf0hI/TzkzJboWuQnzC1EEsuQ9YXX4+7rI0+P4Gm3zvuTz4vzamw9zY6 uZSj5ov9yMhR0AExuayB1gizW1lG0nFjxyvamPiL58= Received: from [192.168.1.9] (d5540.auburn.protected-networks.net [192.168.1.9]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id E66206F07F for ; Fri, 29 Aug 2025 09:03:35 -0400 (EDT) Message-ID: <62eb92d8-f71f-4b8f-bf12-e423ffb0f8fa@protected-networks.net> Date: Fri, 29 Aug 2025 09:03:35 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-NZ To: freebsd-current From: Michael Butler Subject: TZ changes affect screen Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[protected-networks.net:+] X-Rspamd-Queue-Id: 4cCz3g2WYMz3RYp It seems the recent tweaks to timezone handling (libc?) affect sysutils/screen on a dual-boot machine (Windows and FBSD) with /etc/wall_cmos_clock present. When run as a regular user, it shows UTC. As 'root', it shows local time, Michael From nobody Fri Aug 29 13:35:52 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cCzmq0HHkz65Xgk for ; Fri, 29 Aug 2025 13:35:55 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cCzmp6XwRz3crJ; Fri, 29 Aug 2025 13:35:54 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756474554; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=y/dnC+/wIR3aNgDMzXT0U7SqjkPiZNDLzC0kQnjckD0=; b=QMsbH+fBLCCs0cBzo87B6+zvpqwD06iMlCjZfi9qC9q0VAyTX2JmqbS28yGqMk5kMA0ip0 oqGR30IyzF/HAZ5tOgV2Y6JzEekNrtyxPnEV3HN5IteQ82kxQfUafJ6t7BQg9TVU/2y4Vv HCKBNhdECTxpqdkjcrqNO6/vT5tt/RY+JRSKmwf8yaLEbaLjxmk6KvKXiWFMYSG+TxjZ3j VOto79csK2+80XjkIXHssOn6IvgqBVqU1AhuGT1VEB9AUD6M7PWG7CL/X+cjswLxf62a1l F58pDDOMbRaJc6RRlgH0GYoKyH4+q4tHSUQ+UqwvZTEmI7HvlbtCPLwH7Rr+8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756474554; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=y/dnC+/wIR3aNgDMzXT0U7SqjkPiZNDLzC0kQnjckD0=; b=duTNlOQm8biGQh0uB1/Rk3cIjvjM/d2xDRaHXJvZOxthV8VXm0MJa8nmMZ4HO0zS+rx3tJ yZ1dTNw+owZdzfw85gg1yt1yK5CMbYVaTihHcjLwadbLdo8wa52y5h6YhDFdcbSUVw3mpV i3y16CFP+0P63Ls+BgWAb820KKy4ECeRXshjqnzseD2lcGuYWMeSrJkLRXiq0NXWLh92qx svd3OSohAZ9FeJNtGyON3VoxwdvhzlM3xXwEJ80+5OydAAck+x21wJMlycQi3UQ9VShIC0 Yh3kiNOyVt2yXmOOTB+skmhfUnXEl2fjQfgK6xltOXwejXeNycuNLLfSSQ36wA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756474554; a=rsa-sha256; cv=none; b=R7Nr1FlMY2rbf0cmsgd+2GkElot9CBMkYSUTOMAzU3WnYx3JZHPHpvhvwxojPdC3AEln1V 43g+4/SEglv2vn5il6U/1L3K372ytTsTD7HERIfc6zw+AXa23udUvfo2kEQ1iltEA97e39 9UJBfroIdHr4pbuQnCoJAnbOUIYEaYNEfyWcdAJZ8Zs+xjSOEskJzjE0i4V8DWUMJyT4Ci O0HSvoJFVa2EwdRjHsZw2O45qm2yWkSVQ3kINkzW0Kgc6+HnFngtSombjMk3z4CbQkdqsV 9Jrrhytevbp8KIIasg7tArrj7Fruzn7hTYQw0zZpnISwVpdNQ5ydN8c4OHLL4w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (88-177-82-251.subs.proxad.net [88.177.82.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cCzmp51Lhz9Hw; Fri, 29 Aug 2025 13:35:54 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 3B32B3BFFB; Fri, 29 Aug 2025 15:35:52 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Michael Butler Cc: freebsd-current Subject: Re: TZ changes affect screen In-Reply-To: <62eb92d8-f71f-4b8f-bf12-e423ffb0f8fa@protected-networks.net> (Michael Butler's message of "Fri, 29 Aug 2025 09:03:35 -0400") References: <62eb92d8-f71f-4b8f-bf12-e423ffb0f8fa@protected-networks.net> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Fri, 29 Aug 2025 15:35:52 +0200 Message-ID: <865xe6tflz.fsf@ltc.des.dev> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Butler writes: > It seems the recent tweaks to timezone handling (libc?) affect > sysutils/screen on a dual-boot machine (Windows and FBSD) with > /etc/wall_cmos_clock present. The timezone code does not read this file, so that's not relevant. Is /etc/localtime a symlink or a file? If a symlink, where does it point? Is the TZ variable set in your environment? If yes, what is it set to? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Fri Aug 29 14:19:00 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cD0kf4ZpZz65byk for ; Fri, 29 Aug 2025 14:19:06 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R10" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cD0kf2R01z3l46; Fri, 29 Aug 2025 14:19:06 +0000 (UTC) (envelope-from imb@protected-networks.net) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:content-language:references :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1756477140; bh=YyiD48gOh/wOwqUxWT+Xu6lTyJqkF/Khs6ef PoCmKPk=; b=ML76pVSw2ZBh3DhMXZwSv0hm2uNnf46Me0kpUu1iQX0rTi8yw4p1 NbrYkuabFQNi2z1J9WcwdKSMOIRugCYZsMPPpxEY7huHxE+lib/aueErrBZr5OVF YXZoT4MQeR9C6a5G8yNqccLKJC1C5wF/Z3OFy4n4VUilwSvT7pn41M8= Received: from [192.168.1.9] (d5540.auburn.protected-networks.net [192.168.1.9]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 6CE5578628; Fri, 29 Aug 2025 10:19:00 -0400 (EDT) Message-ID: Date: Fri, 29 Aug 2025 10:19:00 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: TZ changes affect screen To: =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Cc: freebsd-current References: <62eb92d8-f71f-4b8f-bf12-e423ffb0f8fa@protected-networks.net> <865xe6tflz.fsf@ltc.des.dev> Content-Language: en-NZ From: Michael Butler In-Reply-To: <865xe6tflz.fsf@ltc.des.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cD0kf2R01z3l46 On 8/29/25 09:35, Dag-Erling Smørgrav wrote: > Michael Butler writes: >> It seems the recent tweaks to timezone handling (libc?) affect >> sysutils/screen on a dual-boot machine (Windows and FBSD) with >> /etc/wall_cmos_clock present. > > The timezone code does not read this file, so that's not relevant. > > Is /etc/localtime a symlink or a file? If a symlink, where does it > point? imb@d5540:/home/imb> ll /etc/localtime lrwxr-xr-x 1 root wheel 36 Aug 29 09:24 /etc/localtime@ -> /usr/share/zoneinfo/America/New_York imb@d5540:/home/imb> ll /usr/share/zoneinfo/America/New_York -r--r--r-- 1 root wheel 3552 Aug 29 09:24 /usr/share/zoneinfo/America/New_York imb@d5540:/home/imb> ll /etc/wall_cmos_clock -r--r--r-- 1 root wheel 0 Feb 19 2024 /etc/wall_cmos_clock > Is the TZ variable set in your environment? If yes, what is it set to? TZ is not set in either privileged or unprivileged environments. Michael From nobody Fri Aug 29 14:43:22 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cD1H23TlWz65dhK for ; Fri, 29 Aug 2025 14:43:42 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cD1H151JBz3r1r; Fri, 29 Aug 2025 14:43:41 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=aiq2KAeL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::52d as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-61caa266828so4543673a12.1; Fri, 29 Aug 2025 07:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756478615; x=1757083415; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=TOIUkzcZz0nDljeoS5LnR2oWkp8f7AXPNcTiPqp15dA=; b=aiq2KAeLvwBBRiirBoGVbzaVmmQkJN/shB4gQFg2WpXYyYkqFzfgHKHcGZ7ovgdyeV FJz4CotrMycFlG7eVw4MVF3hQY50QDUpGyw6b7cSWlw0vjZ8vHx1F2UZfvpQUW62lzgL 8mLaEG3xA5B25OEMWXS51VIsQzaS/LxqJGYVdedQppCzth0hxur2IF2IDIs4pFQ/+du/ ju94F0u/8LQYvnut9UEZVTuspzM9ZzkGEyIxnITK+Ep142nsbz7DTgcKx4FGUU5phhdD v8zQs9m4zAHjvVH3K5bsRs7+rD/4vxjrTeNuYOWJeYKZ112tpzbyjytSAZEqMbuKOjjP M1YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756478615; x=1757083415; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TOIUkzcZz0nDljeoS5LnR2oWkp8f7AXPNcTiPqp15dA=; b=Wz2nQY9UmxyAwloLlfQ6QATHHQiUR3oiVipOZIt5wAxXzXXsI4PcZGMDkTr24Dj6F7 r4UIWG0kxCXzulxSV4qb3ramOTPkW9oE5obyH494BlEa0MybkiGLqNUfLmiOzc2LAzBH n1dKQOzV0upPXCz7GBSKy9fYYx2KDVXAfd/JhhD9JZXesbn7/ARc7reKYLpDBYEPMcrv PsSigudQr9HpmCqeccKNNwmvZmYfyXH58D8tVryGVx6v+blUdHr9cKKk8WMmfa1dEi9A sctpg9G8CB4/Oowb3rOWhPcEUY9RPKOEsPVxAnLAqxH1qAzraVDNv/byF0UiLc72iUAy 4AgA== X-Forwarded-Encrypted: i=1; AJvYcCW+Nsrg8MyCwxM5N7C5Ya+OXFYMAIMDDsnDEG2rt/jtaGXOlOzCbu1EARn43xE/8sXIv0ZWH7Af1+vkqKDIA7I=@freebsd.org X-Gm-Message-State: AOJu0Yy7XyQRzchd2GYtoqjDh6br0qZPZ3Hj5RiW6BqigJZkOy5n9WKq li57vqdDUjcP+H4tBWTy8Nh1mMjt3Z2p5nN3bHqHcYF4H0I7ozjaOUoXYrz/l48yYr/xR6J4dY9 r0vM3OjJUEO3WWjkdCV8g8pvDj64o+GNQ X-Gm-Gg: ASbGncvaxrEmE3/O29mwfbdmVrUQRv9dt4EcJZNTosIien5rG2y1T9TiebUDsAsNHZc HDLTXU996DeYVqwUFqU+Ybawa260/DK7/RdQiCZvgw81gQRYCYsJdj8HgMjN0gNzHuVhidX7lyW 90lwHr7+Cg+tPt4jT29T0kTjbQtMjqfRZb2UAivR7CDQVXhOSNJZOYlWucz5nEKyI9sV8tcUTv6 1+JyIk75/8aXpKUM/5cULGM40SA/9nfFOf1p2rUsvS0FiF/ X-Google-Smtp-Source: AGHT+IEW9ILhujwGHC15vwALw3OB6FyFNVayB2qwAHYz5DHLHvXxrmvkgXlk0bI+DUWihWzCMf8ZiibgK8il2UQ/MHw= X-Received: by 2002:a05:6402:274f:b0:61c:d740:2471 with SMTP id 4fb4d7f45d1cf-61cd740275cmr6324934a12.3.1756478614645; Fri, 29 Aug 2025 07:43:34 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Fri, 29 Aug 2025 07:43:22 -0700 X-Gm-Features: Ac12FXwU5rSKU7pJBEy82uBf-iyJPrMmYowpWj3WZjmKJwmYex5fosej_7u2HrY Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Gleb Smirnoff Cc: Cy Schubert , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52d:from]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4cD1H151JBz3r1r On Wed, Aug 27, 2025 at 8:39=E2=80=AFPM Rick Macklem wrote: > > On Wed, Aug 27, 2025 at 7:43=E2=80=AFPM Rick Macklem wrote: > > > > On Tue, Aug 26, 2025 at 9:35=E2=80=AFAM Gleb Smirnoff wrote: > > > > > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff wrote: > > > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem wrote: > > > T> R> Ok. If you install FreeBSD-13.5 and then "pkg install heimdal",= you get a > > > T> R> working Heimdal-7.8 in ports. > > > T> R> > > > T> R> Now, I have another challenge. Fixing the master passwords. > > > T> R> I'll work on it later to-day. > > > T> > > > T> I have applied two commits from Heimdal from 2012 that add 'kadmin= dump -f MIT' > > > T> feature to our base heimdal and polished them to compile. So far = it doesn't > > > T> work yet, either create an empty dump or create a core dump, inste= ad of > > > T> database dump :) I'll see how difficult it is going to further res= olve that to > > > T> a working condition. If I succeed, then having 'dump -f MIT' in ba= se without > > > T> any ports would be the best solution. Can also be merged to FreeB= SD 14.4. > > > > > > Good news. In the above paragraph I was testing my change incorrectl= y - threw > > > the new binary on a system running unpatched libraries. When run cor= rectly, > > > it successfully produced something that looks like a correct dump in = MIT format. > > > I haven't yet tried to load it into MIT kdc yet, though. > Oh, and one more thing... > - If there are keys for old encryption types like des.. or arcfour.. > in the MIT dump, > those will screw up the load. (You can check and delete them in the > Heimdal-1.5.2 > kdc system via.. > # kadmin -l > get > - if old keys are listed in Keytypes: > del_enctype > exit > > Ideally the conversion code would skip over these and not put them in th= e dump. > > rick > ps: If you don't do this, when you "get_principal" in kadmin.local on > the MIT KDC > system, it will give you a "Database record is incomplete or corrup= ted..". > > > > > > > I will finalize the branch promptly and share it. The above experien= ce also > > > indicated that I need to do a library version bump. > > I don't know if you are enthusiastic about pursuing this, but hopefully= this > > works and gets the principals in (although I doubt the passwords will > > work without changing them). > > > > To get the passwords to work, I think the following *might* do it: > > - If you look in the Heimdal sources, when "--decrypt" is specified, > > I think it finds its way down into a function called hdb_unseal_key_m= key() > > which decrypts the key using the master key by calling _hdb_mkey_decr= ypt(). > > To get the passwords to work, I think the call to _hdb_mkey_decrypt()= would > > need to be followed by a call to _hdb_mkey_encrypt() with the "key" > > argument being the master key for the MIT database. (It it a keytab > > entry called /var/db/krb5kdc/.k5.YOUR.REALM created when you do a > > "kdb5_util create -s" on the system that will be the MIT KDC.) > > - Just to make it even more fun, there is a flag called HDB_KU_MKEY > > which is set to the Heimdal way and not for the MIT way (whatever > > that really means?). > > - There is also some stuff about padding in hdb_unseal_key_mkey(), > > but hopefully that won't be a problem? > > > > I think hdb_read_master_key() can be used to read in the MIT master > > key from the file you provide as an argument to it. > > > > This all is just a hunch, based on what I've seen so far. > > > > I'll admit since the hardware I have takes forever to "make buildworld" > > and I don't know a quick way to build/test these changes, I'm not > > inspired to try it. Although not inspired, I have taken a stab at it. I am still trying to figure out how to build/test it, but I have forked glebius@'s github and added some code to... - Not dump the weak encryption keys (they just cause MIT's kadmin.local to complain that the principal's database entry is corrupted. - If the argument to "kadmin -l dump" is "-f " instead of "-f MIT" it re-encrypts the keys in MIT's master key. (I hope that wil= l make the passwords work. (Basically, someone will "kdb5_util create -s" on the MIT KDC system and then copy the /var/db/krbkdc/.k5.YOUR.REALM file over to the Heimdal KDC system and do "kadmin -l dump -f <.k5-filename> mit.dump" then copy "mit.dump" over to the MIT KDC system and "kdb5_util load -update mit.dump". Then, hopefully, the principals will work??) Anyhow, it is currently sitting here: github.com/rmacklem/FreeBSD in the kadmin-dump-MIT branch. (I'm as unconversant with git and github as anyone, so if you have trouble finding it, just let me know.) I'll keep updating this github fork as I get to test it, but if others know how to build it, feel free to test, rick > > > > rick > > > > > > > > -- > > > Gleb Smirnoff From nobody Fri Aug 29 15:29:20 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cD2Hk4nZ1z65js0 for ; Fri, 29 Aug 2025 15:29:22 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cD2Hk3l2Rz40lF; Fri, 29 Aug 2025 15:29:22 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756481362; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MgnUYdTF7UAykKr/+Y2da0um2BoSqYOAd0TVNtF+J0U=; b=WHTzK2/gdKuFlqfbKtYGB3tmjHxtledncfu2sdkiU0HByBM/bOUk8GJ62hjIWSbawP17zI r5yXYVtvj96dbCTGt00/MDS+0v7dK+ep75X3j3BmF0eOGyuaqyBgA4ps1zJxNMdFynEwtl 2XA6tIjf5aOyOnrxmerNYIp0i1u+1F93WNcllhTIt3LIT3bUXXKonTOmBhQzIbOxe1uG+Y 5NzKAMg+KGE7IIQu0uNfH0IPtTDAn6NhmdeWjLyeJfJT44Q1wXhciaus1c62QdWkt9qq4E EESnZxgxujASxAyITnfutyFZ4KJBEX1x3GM3gppucXDMPMKfuuUQxxb5Z/DaIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756481362; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MgnUYdTF7UAykKr/+Y2da0um2BoSqYOAd0TVNtF+J0U=; b=xXyBfX4f5OekmXMTm4CjuZif5Kei/TU1wcy/uM9Pp0zdwot/ODlEZFmjiN2OV+RuBlM6Ng 2KN4AiIyaMD9eheWk4zpvRKOzINoTVhbG5Zpg+b9jvJGYfkRHPR5Um0RpPMUJx9mTsda1Z 76sDClGLkckD1SV0YIFqsrLvmRmYZBPmdGHwAQBU2TPsaTZx1DRM6jIe+BCbn3mt6e09YZ IRNQkQGzXYps34dwt1nVZt0TdRK/SyFBcgZPJyH1VK884e2bDj4g3IwsvVf+FmefrXNut/ xu1XhU/Pn3pC0DixjteBhcJuiM8gcrBDZq0a1IeavM5PKoui3pNk3YSzbHYVEA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756481362; a=rsa-sha256; cv=none; b=VbcjsJQUx/nnWrTUBYy1px9RJn4n1X0NykpapiG/B4YKYeh+9OAorW5ZDE2B8iYXvIHdYY BFJfKaxkvjo2dRfkBgG+49bgD5R+tJN1iVnbGFCGcmLBSqpVXlXh2VkrPa61iGqVMGZ5Y9 ZTRi9FqMmCug54KMRmG/x/PazJxUKox1C3kC/dyBgDe/rBpo8JB3gvwLvo31eCqx7/x+Xr C65HlxW1AIHkXhK26POhwrpOpbBoAiN4DxOVW//aP8E0gYcpQPg0NTrAv3u9W9azjvkSUx ymp3vMQBqLd94jhHdkpcpoVn0qNl8IzoCvblTmep+UR7HbLIPaRvYen4THqFVw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (88-177-82-251.subs.proxad.net [88.177.82.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cD2Hk2GRTzCt6; Fri, 29 Aug 2025 15:29:22 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id C8DDA3BFF6; Fri, 29 Aug 2025 17:29:20 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Michael Butler Cc: freebsd-current Subject: Re: TZ changes affect screen In-Reply-To: (Michael Butler's message of "Fri, 29 Aug 2025 10:19:00 -0400") References: <62eb92d8-f71f-4b8f-bf12-e423ffb0f8fa@protected-networks.net> <865xe6tflz.fsf@ltc.des.dev> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Fri, 29 Aug 2025 17:29:20 +0200 Message-ID: <861poutacv.fsf@ltc.des.dev> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Butler writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Is /etc/localtime a symlink or a file? If a symlink, where does it > > point? > imb@d5540:/home/imb> ll /etc/localtime > lrwxr-xr-x 1 root wheel 36 Aug 29 09:24 /etc/localtime@ -> > /usr/share/zoneinfo/America/New_York > > Is the TZ variable set in your environment? If yes, what is it set to? > TZ is not set in either privileged or unprivileged environments. OK, the upstream code is setting TZLOAD_FROMENV unconditionally even when not using the environment variable. That is causing us to consider /etc/localtime as untrusted, and then reject it because it is not relative to /usr/share/zoneinfo. Unfortunately this fell between the cracks of my test cases (it's a combination of the thin_jail and setugid cases). I'll submit a patch upstream and fix it locally. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Fri Aug 29 18:57:42 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cD6wr2dwXz6626B; Fri, 29 Aug 2025 18:58:20 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cD6wq2kcWz3TB6; Fri, 29 Aug 2025 18:58:19 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=qxNbxAfw; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 2001:1640:5::8:30 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 0AC1B240454; Fri, 29 Aug 2025 20:58:12 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 6A9762400D4; Fri, 29 Aug 2025 20:58:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1756493890; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zFFE/VJS5Y2nW7H/9XnPnwHObStIVdHCyJSwMLNeR8g=; b=qxNbxAfwW1CXNoan35jZ0osIawpz94XdLYyy3quZHKsV4MK1cNIf1DKKWfcilqYvDfAlk6 fx7T9ChimKQw68KYvvpSfNDlww7m7RqxTQuI6ob7UIQ+LnqC0dsbYqQ63WndqfbD+iXhQd 9JxJBT+SmYWrccobbWAzc/6orriyDakSOXihoUcxGZL0lbMYo5FyUCwA2xwuCS4F86KSTe n8NDaDw6HCizLAnbF95FVFvDK14yiKXuqdlTs9y0o5gETbanrIhMdVotqQFNDu4UjPOQzR 3XYKn8rNMUypVBtopJ1vaQRQYz9vO7rTqSKT8fYaeRAmKXpUb6qmnNONt6s6aQ== Received: from thor.sb211.local (dynamic-2a02-3100-1a97-b302-14c5-b920-98da-1944.310.pool.telefonica.de [IPv6:2a02:3100:1a97:b302:14c5:b920:98da:1944]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 27EA0240263; Fri, 29 Aug 2025 20:58:10 +0200 (CEST) Date: Fri, 29 Aug 2025 20:57:42 +0200 From: A FreeBSD User To: Ronald Klop Cc: FreeBSD CURRENT , FreeBSD Ports Subject: Re: mail/claws-mail: IPv6 issues: SSL handshake error Message-ID: <20250829203734.202d8f07@thor.sb211.local> In-Reply-To: <91944f04-24b4-4374-b147-474a59e85568@FreeBSD.org> References: <20250828171636.04a61a93@thor.sb211.local> <91944f04-24b4-4374-b147-474a59e85568@FreeBSD.org> X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/bz_1Neq1c4IEuvJbYOO7SfX"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-UID: 0b0389 X-Rspamd-UID: 2d3a4b X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.70 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip6:2001:1640:5::8:0/112]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; RCVD_IN_DNSWL_LOW(-0.10)[2001:1640:5::8:30:from]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-ports@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4cD6wq2kcWz3TB6 --Sig_/bz_1Neq1c4IEuvJbYOO7SfX Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tage des Herren Thu, 28 Aug 2025 18:49:41 +0200 Ronald Klop schrieb: > Op 28-08-2025 om 17:16 schreef A FreeBSD User: > > Hello, > >=20 > > I'm using mail/claws-mail for my daily work with FreeBSD (CURRENT, 14-S= TABLE at this time). > > After switching to a working IPv6 environment I face serious connection= problems with one > > of my providers, to which claws-mail prefereably connects via IPv6. Sen= ding and receiving > > is done via "Use TLS" on sending an receiving (the provider, goneo.de = has a dedicated > > introduction configuring claws-mail I followed step by step). > >=20 > > On the firewall I observe that the provider in question is connected vi= a IPv6, while other > > providers, University and others, are not, they are still with IPv4 and= do not show any > > issues. > >=20 > > claws-mail provides a log screen, but I can not make much out of it, th= e SMTP and/or IMAP > > server is connected at the correct port and the initial handshake seems= all right, but in 8 > > out of 10 times the connection fails and does not get initialized due t= o a "TLS handshake > > error". Sending emails takes sometimes 10 attempts, but then of a sudde= n it works > > flawlessly! After running claws-mail for a couple of minutes a day, thi= s problem seems to > > go away in a mysterious way, receiving/sending works like a charm as no= thing has ever been > > broken before ... > >=20 > > I;m floating here like a dead man in the water. The firewall / router i= s FreeBSD / ipfw, I > > suspected this instance, but why should mail being blocked/corrupted wh= ile other > > connections via IPv6 work? > >=20 > > Maybe someone has some ideas what to check and where to look ... > >=20 > > Thanks in advance, > > oh > >=20 > > =20 >=20 >=20 > Hi, >=20 > Does it work with this provider if you force claws-mail to use ipv4? >=20 > Can you reproduce the issue easily? Is it possible to reproduce it with o= penssl? The problem itself as described can be reproduced with claws-mail utilizing= IPv6 - for me at least - on CURRENT. But there is a certain speciality: my home office box u= ses IPv6 via prefix delegation in a subnet, at work we use OPNsense with NPTv6 - which doesn't= introduce any problems, although claws-mail prefers IPv6 (other provider there than thos = of mine at home). Just a "descriptive" statement. Did not try openssl so far, but thank you for the hint! > Something like this. There are also options to choose specific TLS versio= ns. I do not see such in claws-mail config, options are NO TLS, TLS, STARTTLS w= hich refers to the proper port when autoconfigured. Manually override can be applied. > openssl s_client -starttls imap -connect :143 -6 > openssl s_client -starttls smtp -connect :25 -6 >=20 > Can you tcpdump the traffic to a file and see in wireshark what is going = on? Haven't done the wireshark analysis so far, but did a lot of tcpdumps both = sides of the end of the communication between host and router, but it seemed all clear to me an= d faults at the provider's side ... But, I have to admit that in terms of networking, I'm a= kind of an enduser ... When forcing claws mail to use IPv4 only, everything is all right. There is= also not problem when using NPTv6 on my FreeBSD routing/ipfw instance.=20 In the faulty case, the puzzling thing is that after a couple of time runni= ng claws-mail, say, 20 - 30 minutes doing some mail fetches and sending (even with the nasty re= plying on faults) everything runs smooth - until next restart of the application. And this lo= oks to me like some serious misconfiguration or serious issue on the providers side.=20 >=20 > Regards, > Ronald. >=20 >=20 --=20 A FreeBSD user --Sig_/bz_1Neq1c4IEuvJbYOO7SfX Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCaLH4QQAKCRCxzvs8Oqok r3PmAQCGlhALYC982nhWr3+27MtgRn49/Jp4+njN2bNaRwiPngD+KR1/DZZeh9vg eAFGc47XC0/749P9mThpcpjZQeF0dA0= =NBL0 -----END PGP SIGNATURE----- --Sig_/bz_1Neq1c4IEuvJbYOO7SfX-- From nobody Fri Aug 29 20:05:20 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cD8QY63kBz666md for ; Fri, 29 Aug 2025 20:05:41 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cD8QX4wpsz3dd1; Fri, 29 Aug 2025 20:05:40 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=CXUDDpMu; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::535 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-61cfabc02b8so2408291a12.2; Fri, 29 Aug 2025 13:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756497933; x=1757102733; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=yzyTOPLdSb4r/Mt0gRt8zgio6lN92Rwxgb084kt3wls=; b=CXUDDpMuO+vVkOWItRyN0vvrlClGRIDYMscS/bYkehKVrxE+bWiUrv7nsP1AfsqH0J OgdyqAAbEoCg/fPlpHdJA1XJt6PFjTQptRuIRxeV/sC9SI+bAD0T4Mvh5qP7sLQGRc2e PTELff2xCj/wuN4w32zljpQ/ZgOB/8VpwUGlU8spHC4ny5e51NQ/WrzKjtgyIDfXCba6 mw8d8a3Hz3ZxVeCKWQRSlD1zH6cAPrCTycXlvJHJvTywWC10fIkiOtJdXSqYgkpGIZBY kLTS1h7RLdu6DMbTS0502TibYsThjJGvbLe9US9eojp5ZuAK/cuN6c4N6DEUTyoVV95I TNJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756497933; x=1757102733; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yzyTOPLdSb4r/Mt0gRt8zgio6lN92Rwxgb084kt3wls=; b=FTuxivNADiofZVftOaW/vNn1TJWInGuoI1xTqMY57RgjX1/96IxNKq0ZBBdxyNLDur zA6qfCHC/aw8olJnCWYvwQD7WORMeqY23p4aYVKce3LjpPXSz5EE/L8Ufrzb0j1mQ0m5 BlTw4gRu4M4hYZNe5waBN4dZ/ClH2EL71PpUhaWKQk8YoWhF0K9ZWmf5IkmbmAbfMizC oaa7nFcXbMQTsL+NToReAyGMBO6dvMohyDEdy3QWdk3Fmm6TPSMspKsY+xPSpZP+cY8b WBHSauYqYfA5TZ2e8kda+UItM/2G50NGrd8NiQRR0ovhC8Qiow/8vj/SqR0iwGs3+/l4 5MGA== X-Forwarded-Encrypted: i=1; AJvYcCXEzaM9s0fpGwN5UZVdjfhM1n+PNCNLKm8Gmxi/29fUtsh6MccZnxb+vT6lTdJZ/ra/2qiNicf41q2tRhinV2A=@freebsd.org X-Gm-Message-State: AOJu0Yysh2Y/byDYXpr4zE8CErVUmALErirgaIJ48tbHHvTQDmCozQkA 3B4yVA3b/MhMMBKrTWwC7x3HeKf0eu/SQR4RMEu32Pg6JimxW/vnAAIGRswP08nR8OoJ48e4QoV KvkPQMhR4bsE1IEWZ/32cjA/A6Bk2XxyL X-Gm-Gg: ASbGnctABOpc7q9lr0I4FhbImno1aY1LHDDzVplm+jayTXbG/UVSLm9jo2Y8Xr0XZ8J eBHTXdqwYCUhUiXRpp5Yhx5VtDenzCQfC8fPqU9HbQXq+4sHMYuSDRiZaxa61gz3FIRUlvYwNQE WsZLz5AgQPby9yC3U93doy2wQqJ8YPDrTuwZVWsCXQowPU+Inr0Xxv0103d81wcEyT9BZDXMq0u pviC+S/EDdszZFrmwhd67eKNnTqs1zockK9Bg== X-Google-Smtp-Source: AGHT+IG8xPll8Gheka/AmRxZ2NgArVNPG4buvm+ENk+5AuRdlTkv3QiNvySsq65C1U7JB1o4T7XzKGkoK8EJhtcaxvY= X-Received: by 2002:a05:6402:2110:b0:61d:2096:1e92 with SMTP id 4fb4d7f45d1cf-61d20962222mr653626a12.15.1756497933218; Fri, 29 Aug 2025 13:05:33 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Fri, 29 Aug 2025 13:05:20 -0700 X-Gm-Features: Ac12FXy5WWMiDD-okAO7MW5Zb4OJTGrR08twxf5ljfrHlv4yz2uWXhZrE0Uiyag Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Gleb Smirnoff Cc: Cy Schubert , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::535:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4cD8QX4wpsz3dd1 On Fri, Aug 29, 2025 at 7:43=E2=80=AFAM Rick Macklem wrote: > > On Wed, Aug 27, 2025 at 8:39=E2=80=AFPM Rick Macklem wrote: > > > > On Wed, Aug 27, 2025 at 7:43=E2=80=AFPM Rick Macklem wrote: > > > > > > On Tue, Aug 26, 2025 at 9:35=E2=80=AFAM Gleb Smirnoff wrote: > > > > > > > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff wrote: > > > > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem wrote: > > > > T> R> Ok. If you install FreeBSD-13.5 and then "pkg install heimdal= ", you get a > > > > T> R> working Heimdal-7.8 in ports. > > > > T> R> > > > > T> R> Now, I have another challenge. Fixing the master passwords. > > > > T> R> I'll work on it later to-day. > > > > T> > > > > T> I have applied two commits from Heimdal from 2012 that add 'kadm= in dump -f MIT' > > > > T> feature to our base heimdal and polished them to compile. So fa= r it doesn't > > > > T> work yet, either create an empty dump or create a core dump, ins= tead of > > > > T> database dump :) I'll see how difficult it is going to further r= esolve that to > > > > T> a working condition. If I succeed, then having 'dump -f MIT' in = base without > > > > T> any ports would be the best solution. Can also be merged to Fre= eBSD 14.4. > > > > > > > > Good news. In the above paragraph I was testing my change incorrec= tly - threw > > > > the new binary on a system running unpatched libraries. When run c= orrectly, > > > > it successfully produced something that looks like a correct dump i= n MIT format. > > > > I haven't yet tried to load it into MIT kdc yet, though. > > Oh, and one more thing... > > - If there are keys for old encryption types like des.. or arcfour.. > > in the MIT dump, > > those will screw up the load. (You can check and delete them in the > > Heimdal-1.5.2 > > kdc system via.. > > # kadmin -l > > get > > - if old keys are listed in Keytypes: > > del_enctype > > exit > > > > Ideally the conversion code would skip over these and not put them in = the dump. > > > > rick > > ps: If you don't do this, when you "get_principal" in kadmin.local on > > the MIT KDC > > system, it will give you a "Database record is incomplete or corr= upted..". > > > > > > > > > > I will finalize the branch promptly and share it. The above experi= ence also > > > > indicated that I need to do a library version bump. > > > I don't know if you are enthusiastic about pursuing this, but hopeful= ly this > > > works and gets the principals in (although I doubt the passwords will > > > work without changing them). > > > > > > To get the passwords to work, I think the following *might* do it: > > > - If you look in the Heimdal sources, when "--decrypt" is specified, > > > I think it finds its way down into a function called hdb_unseal_key= _mkey() > > > which decrypts the key using the master key by calling _hdb_mkey_de= crypt(). > > > To get the passwords to work, I think the call to _hdb_mkey_decrypt= () would > > > need to be followed by a call to _hdb_mkey_encrypt() with the "key" > > > argument being the master key for the MIT database. (It it a keytab > > > entry called /var/db/krb5kdc/.k5.YOUR.REALM created when you do a > > > "kdb5_util create -s" on the system that will be the MIT KDC.) > > > - Just to make it even more fun, there is a flag called HDB_KU_MKEY > > > which is set to the Heimdal way and not for the MIT way (whatever > > > that really means?). > > > - There is also some stuff about padding in hdb_unseal_key_mkey(), > > > but hopefully that won't be a problem? > > > > > > I think hdb_read_master_key() can be used to read in the MIT master > > > key from the file you provide as an argument to it. > > > > > > This all is just a hunch, based on what I've seen so far. > > > > > > I'll admit since the hardware I have takes forever to "make buildworl= d" > > > and I don't know a quick way to build/test these changes, I'm not > > > inspired to try it. > Although not inspired, I have taken a stab at it. > I am still trying to figure out how to build/test it, but I have forked > glebius@'s github and added some code to... > - Not dump the weak encryption keys (they just cause MIT's kadmin.local > to complain that the principal's database entry is corrupted. > - If the argument to "kadmin -l dump" is "-f " inste= ad > of "-f MIT" it re-encrypts the keys in MIT's master key. (I hope that w= ill > make the passwords work. > (Basically, someone will "kdb5_util create -s" on the MIT KDC system > and then copy the /var/db/krbkdc/.k5.YOUR.REALM file over to the > Heimdal KDC system and do "kadmin -l dump -f <.k5-filename> mit.dump" > then copy "mit.dump" over to the MIT KDC system and > "kdb5_util load -update mit.dump". Then, hopefully, the principals wil= l > work??) > > Anyhow, it is currently sitting here: > github.com/rmacklem/FreeBSD in the kadmin-dump-MIT branch. > (I'm as unconversant with git and github as anyone, so if you have > trouble finding it, just let me know.) Actually, it hasn't made it there yet. For some reason (I think it is glebius@s large # of branches) it takes a very long time to "git push" a patch involving 4 files. It failed after over an hour with an unexpected TCP disconnect. I am running it again. I will stick the patch here, in case the push fails again. (It needs to be applied on top of glebius@'s kadmin-dump-MIT branch. https://people.freebsd.org/~rmacklem/kadmin.patch Meanwhile I've given up trying to build it on a universe system and an now trying the "make buildworld" locally. This will take days, so I guess I'll go do something else.;-) rick > > I'll keep updating this github fork as I get to test it, but if others > know how to build it, feel free to test, rick > > > > > > > rick > > > > > > > > > > > -- > > > > Gleb Smirnoff From nobody Sat Aug 30 04:05:41 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cDM4j57ZBz65qrt for ; Sat, 30 Aug 2025 04:05:57 +0000 (UTC) (envelope-from chris.torek@gmail.com) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cDM4h6ncCz3Xfq for ; Sat, 30 Aug 2025 04:05:56 +0000 (UTC) (envelope-from chris.torek@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=OgcM5ZnH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of chris.torek@gmail.com designates 2a00:1450:4864:20::134 as permitted sender) smtp.mailfrom=chris.torek@gmail.com Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-55f4bc9bc93so2247716e87.3 for ; Fri, 29 Aug 2025 21:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756526754; x=1757131554; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Z3roSz1UC/W1CqMDL/+YaPtXqVwIV8kKixxM2j/jjg4=; b=OgcM5ZnHVfNlOyH38xzOf1dHpKJ6+KkaodPRnDZbHqGATV6rJWI7YczbNvWJEQMAvr MCSmgjL33RXNhb+mXCkCZRTMIYpuPdJcJsndMrDGj0FNGAHbTD5ngjESTUEiM/6G9SuZ 22pi0SF/tvvg8/BuPRPZc58ffpEfA6rv4Q2GTx56bhrGcMaeUQs7OewqJdyMynH0PB9G rQADKsm6Z2FzrTqmRpawXWX68O+Q9ara3A6EFNeg+4vblWn213Ooum9tAEhW82pcOtck FPTt1r3eTjlhUi6nwV/k9Bz4S4mfa685OsZ/IL+ETqyr6x4mXuU3T9tMl9y7nBTwT+92 Tf+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756526754; x=1757131554; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Z3roSz1UC/W1CqMDL/+YaPtXqVwIV8kKixxM2j/jjg4=; b=QtQo51gwJd19bXDiEBumN+omckjLLuDMzX7/C6vZ4LTZHI0AM8UMlpMhj4CF4vUC7J wlbe8gT+rwoSf3bxj23kSyRLfVCKDO2oVPoMHFE0NHafrJTf18HuSGjbLEBiqwgHO9Yh QqIwC5QbqtukhG7MtNGpTMD4UygG/vqxKyOSvvyxmj8o79UJf5nf89Gu/Lj3fZmhZ7hf NMq9o+XgjWOQQj8WC3csX96cSD1kX8/6gCWSv+/gfZHRZqgn3C0Ir5RO1j+9zp8ruLbL FWZzkCEG9EHJLq/8cbwbykr4yPwFilGtl4Y0LB8z0p8psb3qXTW1G3ougb/VTL7kACmV 24jg== X-Gm-Message-State: AOJu0Yyh1TxpGgha1Jrdx4vD71G29CuMlidEPNsREfqQHOl1Qa+KOar5 NkxtRjbyynymXBrlz0c62henUQbdtenUqiamfbe/ufm+CN51nIK3ksGya3b0bUpjG/qnBJY4zmj 7IrEs/OEqaQXF3A7uzxe6giETih16xgMzokbG X-Gm-Gg: ASbGnctUXQosECE70DJ5t0FKJ3+5BbH2LiDp+AQNLfk5gSHknqw6wOM/Zc+y57W39je u+W4BCxX1jOrLGAUfBS4I2vZDA1/pbdwAC/exytl43mkMdjaxewxpIu/CpWSDXNKTPrwqiLWGb8 mHTjhoF1Il/owS9SaB49tF1E81M/yAgwwG4OZ5/dti1opswsiHW3v7gYnWtQYmJwduCM8pOxAao KhrpxSgYfhySsw54rk= X-Google-Smtp-Source: AGHT+IFhuSNwEmULwfnmMef3S+f3whL2Fxu9A167G5xRmOjMW6Btu1vSFOxwG4XXbI3lLlHEeYyBS2883vo51y/hgSI= X-Received: by 2002:a05:6512:6812:b0:55c:c9f3:6ed9 with SMTP id 2adb3069b0e04-55f708ece9amr152500e87.35.1756526753304; Fri, 29 Aug 2025 21:05:53 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 From: Chris Torek Date: Fri, 29 Aug 2025 21:05:41 -0700 X-Gm-Features: Ac12FXxMVLkD7pwa0eIg_K6eGS7SADr2XvCdRSfjHXYhwIVB8IfSHv1Wx7Yz6pk Message-ID: Subject: a few observations with 15-prerelease as of early this week To: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::134:from] X-Rspamd-Queue-Id: 4cDM4h6ncCz3Xfq The mysterious "build failed when process died from signal during memory pressure" problem seems to be gone. I suspect one of the VM system fixes that squeezed in between all the memq work, specifically the copy on write stuff. Specifically: c9836764199 vm_fault: Defer marking COW pages valid 43c1eb894a5 vm_object: Fix handling of wired map ... seem like candidates. I ran into the libcurl issue and had a heck of a time rebuilding it with the krb5 changes and "git fetch" failing, but a quick temporary update of the curl port to disable gssapi entirely got past it. :-) I am now *sometimes* able to "kldload amdgpu" without having the console blow up and the system reboot. This is on a 7950-based system with the iGPU as the console. One problem seems to be that the amdgpu_device_init() sequence winds up calling dml2_init() without first invoking DC_FP_START() somewhere in the path. This means that the kernel uses FPU instructions without having done the prep work. All of this is specific to the drm-66-kmod AMD GPU port, though it might appear in earlier drm-*-kmod versions as well. Even once it's loaded, however, actually firing up X on the console eventually leads to another crash (perhaps another misuse of the FPU, but I don't get a crash dump and the screen has nothing readable before the BIOS resets everything -- I need a better way to debug this...). What is the status of https://github.com/freebsd/drm-kmod anyway? It is very different code-wise, on its master branch, from what you get in the port tarball. If I work on the FPU enable stuff, should I hack on the github repo, or code patches for the tarball? Despite the report of the reproducible zfs crash, overall everything looks remarkably solid so far. From nobody Sat Aug 30 10:52:10 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cDX5Q74nwz66Np3; Sat, 30 Aug 2025 10:52:10 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cDX5Q6jhhz49bX; Sat, 30 Aug 2025 10:52:10 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756551130; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=1JlMnvIMGSgp0ae6nzMMAkRM9AsGrIAWBEFokMvPhdA=; b=gMpu3mf/KWYeBpncdIIly1NFjbQGb8vLSZ3kGv/dPtpwWqyoxLqX4F6R3zodCgD37x9jw8 GvyFS5JwUTdl5L5mm61tlwzKdgUpxF9puNl9AnG79WqHvTozCmhybIUyOu9q6OQO5bubPL j4ar0dLqPbVhbbLjGLaHk1gyO1Q1iSj+zxrrktPUSOjip5PDRTLthhNCSX4YQCdaah42IN HmVpvSBqiHkDfd0fMmCjNHC9QMh4uIHbYILfsASGLe5JxvE/Pe1fbQt5FMIPvPiwxyT5Lk iEEfRqHpWE+fZ9OSC+e6rZxIKjW7JY2FZiJ41piTOz8+vpDRthR5zQ2LodYJpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756551130; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=1JlMnvIMGSgp0ae6nzMMAkRM9AsGrIAWBEFokMvPhdA=; b=VvMYPeWLIcGaaibWHqx2bUO3bFFTXlu346ewF9hAMSX8Ed4eHyHH7RP5m7a0AF6FuvPhw4 p6fUgs/D9QX5agUXfRLuRd6V1Wa4SmTegNCUoc3tbtqyAhBw/PIr8jNgUVGkGz05H20sSj 4ooaRK6xZj1AxwxoaFOgCZJ6SDdZJwFGJIPcIQo7pIe3wwg10fI8aDCJjhl6gE/j8/s9ms EmeIdM9Ni6ojtRDbWDsCkKRIncL8ZWbdRWojx9qbd9y60rWacgIbxYjhMRnFFifx/EzGm5 AMNQzMd6yLJFB4eavtm94k0t6ciNt5SG+899wqNxZlBZt9d3saDQQgu0CQQEbQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756551130; a=rsa-sha256; cv=none; b=adpSW5ryLSxETjVZK7zKmq0c/d/GRct7YBZg3lWIEI/PAgMroE3uKpEx9914+pzcgroPB2 02C7v2HxfY9tn7ZwqrgerNzIE+HMrMZxwf6npEHJsuzEjlo/7IdB+1Cc3zDe8BIxxq5z9A 4YE/7s8hdBhZe6+2rYckAQOyMOxqzsYcuQjDE5VKDHGqr/7awS57ZU7v1HtiBoZAeXQ9HZ 7Y4IzV5OWm6zOD2PWxiPp+d1uuDZWtnIz3w661qrPFfWOx7Lh9ASyADe/ZFS7o8n4hxWTk 3AdsP9LmQx7sI/sltmqQb58RMHod5hYVV3FhSpbfXBZG0PM1kcE6jnMhqbwZmg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: by freefall.freebsd.org (Postfix, from userid 1472) id CBB5611AF; Sat, 30 Aug 2025 10:52:10 +0000 (UTC) Date: Sat, 30 Aug 2025 10:52:10 +0000 From: Lorenzo Salvadore To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Status Report - Second Quarter 2025 Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit FreeBSD Status Report Second Quarter 2025 Here is the second 2025 status report, with 32 entries. As for the preceding quarters, this report is published just a few days before calls for 2025Q3 report submissions are sent. Indeed, although according to our timeline we should have published this report in July (general rule is publication should happen within the month just after the calls for reports are sent), we kept receiving important reports until the end of August. This is both a positive and a negative thing. On one hand, it means that our FreeBSD community is busy fixing existing issues and implementing new features, making the OS we love better and better every day; it means that the community works so intensely that very little time remains for reporting. On the other hand, it means that news in these reports is always two months old when published. Two months is not bad, especially if we consider that FreeBSD communication happens on many other channels too, but it would be nice if we could improve it. If you are a late submitter, please take some time to evaluate if there is anything you can do to improve your report submission punctuality. The Status Team is always glad to ease the submission process: if there is something we can do for you, just ask. If you are a contributor or just a FreeBSD user, please consider contributing more, if you can. Even working on a single small simple task is useful, it can help to lower the pressure on other developers, for whom it might thus become easier to find the time to document their work. Have a nice reading! Lorenzo Salvadore, on behalf of the Status Team. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A rendered version of this report is available here: https://www.freebsd.org/status/report-2025-04-2025-06/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents • FreeBSD Team Reports □ FreeBSD Core Team □ FreeBSD Foundation □ FreeBSD Release Engineering Team □ Ports Collection □ Bugmeister Team □ Source Management Team • Projects □ Infrastructure Modernization □ Support for pkgbase in the FreeBSD installer □ BSD-USER 4 LINUX □ Sylve — A Unified System Management Platform for FreeBSD □ Hackathon 202506 Kitchener-Waterloo, Canada • Userland □ ucred / group changes in FreeBSD 15.0 □ MIT Kerberos Import into FreeBSD □ SysctlTui □ Geomman Development • Kernel □ Audio Stack Improvements □ DRM drivers □ Suspend/Resume Improvement □ Named attribute support (Solaris style extended attributes) □ Packrat — NFS client caching on non-volatile storage □ LinuxKPI 802.11 and Native Wireless Update □ USB Kernel Debugging □ Porting HFS+ to FreeBSD • Architectures □ Pinephone Pro Support • Cloud □ FreeBSD on EC2 • Documentation □ Documentation Engineering Team □ FreeBSD Wiki □ Vision Accessibility • Ports □ Security Hardening Compiler Options for the Ports Collection □ Improve OpenJDK on FreeBSD □ GCC on FreeBSD • Third Party Projects □ Chinese FreeBSD Community (CFC) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. Project roadmap Core is collecting ideas and comments to draft Project’s roadmap. It is an item core.13 thinks is worth to continue from core.12. The roadmap is not about restricting or limiting what developers and contributors can do, but about the compiled goals and expectations of the Project and things the community can collaborate on. It will also let the FreeBSD Foundation help the Project more effectively, so, this is an important discussion item for the meetings between core and the FreeBSD Foundation. Policy on generative AI created code and documentation Core is investigating setting up a policy for LLM/AI usage (including but not limited to generating code). The result will be added to the Contributors Guide in the doc repository. AI can be useful for translations (which seems faster than doing the work manually), explaining long/obscure documents, tracking down bugs, or helping to understand large code bases. We currently tend to not use it to generate code because of license concerns. The discussion continues at the core session at BSDCan 2025 developer summit, and core is still collecting feedback and working on the policy. Work in Progress Core is currently working on the following items: • Core and the FreeBSD Foundation are working on the 2025 edition of the Community survey • Privacy-friendly web analytics, proposed by the Foundation. An idea is to compare traffic flows between freebsd.org and freebsdfoundation.org ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Foundation Links: FreeBSD Foundation URL: https://freebsdfoundation.org/ Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadmap/ Donate URL: https://freebsdfoundation.org/donate/ Foundation Partnership Program URL: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/ FreeBSD Journal URL: https://freebsdfoundation.org/journal/ Foundation Events URL: https://freebsdfoundation.org/our-work/events/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit dedicated to advancing FreeBSD through both technical and non-technical support. Funded entirely by donations, the Foundation supports software development, infrastructure, security, and collaboration efforts; organizes events and developer summits; provides educational resources; and represents the FreeBSD Project in legal matters. Here are some of the ways we supported FreeBSD in the second quarter of 2025. Advocacy Advocacy work in the 2nd quarter of 2025 included hosting events, launching a new series of video guides and bringing on a new Marketing Coordinator. Florine Kamdem brings social media, branding, and IT skills. She uses storytelling to craft digital campaigns that spark interest and build connection within the community. Read more about Florine, and check out just a few of the ways the Foundation helped advocate for FreeBSD in Q2 of 2025: • Held the June 2025 FreeBSD Developer Summit June 11-12, 2025, co-located with BSDCan 2025. Videos of the all day stream are available on the Project’s YouTube Channel, and videos of the individual talks will be available in the coming weeks. • Finalized our Silver Sponsorship of EuroBSDcon 2025, held in Zagreb, Croatia; September 25-28, 2025. Travel Grants are now available. The application deadline is Aug 5, 2025. • Provided updates and announcements about our Software Development work including: □ The Road to Better Wi-Fi on FreeBSD □ April 2025 Laptop Support and Usability Project Update □ FreeBSD Ports and Packages Security Project □ Software Bill of Materials (SBOM) for FreeBSD Project • Published the following blogs and videos to help inform and educate the community: □ The Hidden Costs of Stagnation: Why Running EOL Software is a Ticking Time Bomb □ How to Unlock High Speed Wi-Fi on FreeBSD 14 □ The Report of My Death Was an Exaggeration □ ZFS automatic snapshots with Sanoid on FreeBSD □ Three Ways to Try FreeBSD in Under Five Minutes • Published the March/April 2025 and May 2025 FreeBSD Foundation Newsletters. • Released the January/February/March 2025 issue of the FreeBSD Journal with HTML versions of the articles. OS Improvements The Foundation continued to support two major initiatives: the Laptop Support and Usability project (in collaboration with Quantum Leap Research) and an infrastructure modernization project commissioned by the Sovereign Tech Agency. For background on both efforts, see the 2025Q1 quarterly status report. Throughout the quarter, there were 536 src, 64 ports, and 41 doc commits that identified the FreeBSD Foundation as a sponsor. Here is a sampling of that work and other sponsored efforts: • Various improvements to libvirt’s support for bhyve, including: □ An initial port of the libvirt integration testing project, libvirt-tck, enabling test execution against libvirt’s bhyve driver on FreeBSD. □ Enhancements to the bhyve driver to improve compatibility and testability. □ Support for virtio-rnd devices, NVRAM configuration, and extended domain usage statistics (under review). □ Initial support for pf(4)-based NAT networking (under review). • Improved handling of tlsbase (thread-local storage) on amd64, making it more reliable across context switches and benefiting applications that manually manage TLS, such as Wine. • Runtime linker improvements, including support for the -z initfirst flag. This addresses longstanding issues with RTLD_DEEPBIND and provides better control over symbol resolution and initialization order in dynamically linked applications. • Enhanced ptrace usability by enabling transient PT_ATTACH behavior. This reduces friction for debugging tools and eliminates spurious EINTR errors that could interrupt or break tracing workflows. • kqueue introspection support by extending procstat(1) to report kqueue state, improving observability into how processes use kernel event notification mechanisms • Design and implementation of EXTERROR, a mechanism that reports extended error information to userspace, augmenting the usual errno value. This enables applications to retrieve more detailed diagnostics beyond standard error codes. Other sponsored efforts are covered in separate report entries: • Vision Accessibility • Suspend/Resume Improvements • LinuxKPI 802.11 and Native Wireless Update • Audio Stack Improvements • Improve OpenJDK on FreeBSD • Sylve — A Unified System Management Platform for FreeBSD • Support for pkgbase in the FreeBSD Installer • DRM drivers • MIT Kerberos Import into FreeBSD • USB Kernel Debugging • Bugmeister Team The Foundation is managing FreeBSD’s participation in the Google Summer of Code (GSoC) program. Twelve projects were accepted this year. Continuous Integration and Workflow Improvement As part of our continued support of the FreeBSD Project, the Foundation supports a full-time staff member dedicated to improving the Project’s continuous integration system and test infrastructure. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to https://freebsdfoundation.org to find more about how we support FreeBSD and how we can help you! ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Release Engineering Team Links: FreeBSD 14.3-RELEASE announcement URL: https://www.freebsd.org/releases/14.3R/announce/ FreeBSD 15.0-RELEASE schedule URL: https://www.freebsd.org/releases/15.0R/schedule/ FreeBSD releases URL: https://download.freebsd.org/releases/ISO-IMAGES/ FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team, The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. The Team managed 14.3-RELEASE, leading to the official RELEASE build and announcement in June. Planning has started for the upcoming 15.0-RELEASE, which is due to arrive in December. The OCI Container Images built by the Release Engineering Team are now being uploaded to Docker and GitHub repositories in addition to being available on the FreeBSD download site. The Team gained a new member, Jake Freeland, and three members have departed: Konstantin Belousov, John Hixson, Doug Rabson. We thank them for their contributions. The Release Engineering Team continued providing weekly development snapshot builds for the main, stable/14, and stable/13 branches. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Collection Links: About FreeBSD Ports URL:https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/#ports-contributing Ports Management Team URL: https://www.freebsd.org/portmgr/ Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/ Contact: Tobias C. Berner Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. During the last quarter, we welcomed Älven (alven@) and Jesús Daniel Colmenares Oviedo (dtxdf@) as new ports committers, and said goodbye to one committer. According to INDEX, there are currently 36,605 (up from 36,450) ports in the Ports Collection. There are currently about 3,330 (down from 3,333) open ports PRs, of which 832 are unassigned. The last quarter saw 10,294 (down from 10,733) commits by 157 (down from 158) committers on the main branch and 770 (up from 707) commits by 56 (up from 54) committers on the 2025Q2 branch. The most active committers to main were: • 3541 sunpoet@FreeBSD.org • 503 yuri@FreeBSD.org • 439 vvd@FreeBSD.org • 345 bofh@FreeBSD.org • 315 rene@FreeBSD.org • 301 arrowd@FreeBSD.org • 240 tagattie@FreeBSD.org • 240 jbeich@FreeBSD.org • 183 diizzy@FreeBSD.org • 178 bapt@FreeBSD.org A lot has happened in the ports tree in the last three months, an excerpt of the major software upgrades are: • pkg 2.2.1 • Default version of Go switched to 1.24 • Default version of Lazarus (non-aarch64) switched to 4.0 • Default version of Linux (non-i386) switched to Rocky Linux 9 (rl9) • Default version of Perl switched to 5.40 • Default version of PostgreSQL switched to 17 • Default version of Ruby switched to 3.3 • Chromium 137.0.7151.119 • Electron 35.* and 36.* • Firefox 140.0.2 • Firefox-esr 128.12.0 • Gnome 47 • KDE Plasma 6.4.1 • KDE Framework 6.15.0 • Qt6 6.9.1 • Ruby 3.2.8, 3.3.8, 3.4.4 (new), and 3.5.0-preview1 (new) • Rust 1.87.0 • SDL 2.32.8 and 3.2.16 • Sway 1.11 • wlroots 0.19.0 (new) • Xorg server 21.1.18 During the last quarter, pkgmgr@ ran 22 exp-runs to test infrastructure changes and various ports upgrades. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Bugmeister Team Links: FreeBSD Bugzilla URL: https://wiki.freebsd.org/Bugzilla Contact: Bugmeister In this quarter we stayed steady-state on the PR count. Mark Linimon has held some voice chats on the FreeBSD Discord for "Bugmeister Office Hours". The plan is to hold them more regularly and announce them in advance. At the moment the schedule is Mondays at 3pm CDT (1800 UTC). We still are doing better at triaging PRs than we are generating committer attention to the ones we have triaged. Suggestions welcome. We have added new search queries about Maintainer Approval (applies to Attachments) and Maintainer Feedback (applies to an entire individual Problem Report). These queries were not easily composable from the various web forms. This work was funded by the FreeBSD Foundation. Please see the new documentation. We used these queries to close various PRs, and also to investigate inactive maintainers. As of yet, we have not taken action on the latter. A problem with the setup of the upgrade to Bugzilla 5.2 has been fixed. Light testing shows no regressions. Switching to this codebase is scheduled for next quarter. patchQA.py still remains in beta. The patch application code is not up to its task and must be replaced. The other problem known with patchQA.py is that it does not know the origins of files that are installed into /etc by installworld. We have created dozens of new Bugzilla accounts by user request. See also: https://wiki.freebsd.org/Bugzilla/SearchQueries Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Source Management Team Contact: srcmgr The srcmgr@ team aims to make src developers more productive, and works to manage the large number of bug reports, pull requests and code reviews that we receive. Meeting minutes are available on GitHub. We held a bug-busting session on 2025-05-23 with about 10 attendees. Members of srcmgr@ gave a presentation at the 2025 FreeBSD developer summit in Ottawa. Per the discussion at the developer summit, the i386 and 32-bit powerpc targets have been disconnected from the build. To help ensure continuity of the team, we introduced a "lurkers" program which lets src committers participate in bi-weekly srcmgr meetings, giving developers an opportunity to decide whether they are interested in officially joining srcmgr@ without taking on any specific obligations. After soliciting interested developers, we have five lurkers who have been joining calls over the past couple of months: • Jake Freeland • Olivier Certner • Dag-Erling Smørgrav • Bojan Novković • Kyle Evans Aside from participating in discussions, they have been working on src development tasks — especially in preparation for FreeBSD 15.0 — and topics such as monitoring stale Phabricator reviews, performance regression tracking, and using git notes to track certain types of commit metadata. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Infrastructure Modernization Contact: Ed Maste Contact: Alice Sowerby The project started in Q3 of 2024 and was commissioned by the Sovereign Tech Agency with a budget of $745,000, to be spent over about one year. The main goals are to improve security tools for the base system, ports, and packages, update the project’s infrastructure to speed up development, enhance build security, and make it easier for new developers to get started. Q2 update All five work packages are now in progress and will run until the end of December 2025, at which time the project will close. Work Package A: Technical Debt reduction The majority of the work in this work package is complete, with a small number of hours allocated each month to help support FreeBSD Project’s Source Management team to embed their new processes to make bug management easier and more sustainable. The bug backlog dashboard https://grimoire.freebsd.org remains available to help make the backlog easier to understand. We have also been upgrading Bugzilla by applying patches from 2023 onward and improving the upgrade process to ensure smoother future updates. A panel discussion at Open Source Summit Europe in August will share this work with a wider audience. Two members of the Foundation project staff will be present, along with two representatives from Bitergia who delivered the GrimoireLab implementation for this project. (Members of the FreeBSD Project Source Management team were not available to attend.) Progress is being made to reduce technical debt by creating an automated method for evaluating patches (code improvements) attached to existing pull requests for source and ports trees to see whether they are still relevant, and applying them if they are. This tool is in beta. Work Package B: Zero Trust Builds This work package intends to improve tooling and processes to support Zero Trust Builds of FreeBSD by extending the current components to enable the project to build release artifacts (package sets, ISO images, etc.) without requiring any special privilege. The detailed scope was co-created with core@, srcmgr@, secteam@. Work items are as follows: • Must □ No-root for all source release build cases/artifacts (in progress) □ Src artifacts to build reproducibly (in progress) □ Formalize and document make world and release.sh (in progress) • Should □ Remove privilege from orchestration tooling (not started) □ Move build scripts into the public repository (not started) • Could □ Environment Standardization (not started) □ Ports to build reproducibly (not started) □ CI to verify reproducibility (in progress) □ Documentation to allow 3rd parties to confirm reproducibility (not started) Work Package C: CI/CD Automation This work package intends to improve CI/CD automation to streamline software delivery and operations for new and existing software by modernizing and securitizing the existing CI/CD system and extending it to cover the third party packages in the FreeBSD Ports Collection. The detailed scope was co-created with core@, srcmgr@, portmgr@, doceng@. • Must □ Improve quality of incoming commits (completed) □ Pre-merge CI (completed) □ Environment Metadata (not started) □ Extend CI to the Ports tree (in progress) □ CI Threat Model (not started) □ CI Management Process (in progress) □ Documentation (not started) • Should □ 3rd-party Interoperability (in progress) □ Automated analysis in tests (in progress) □ Test Case Management (not started) • Could □ Granular Debugging (not started) Work Package D: Ports and Packages security improvements This work package intends to modernize and extend security controls in the FreeBSD Ports and Package Collection by: • migrating from our VuXML Vulnerability Database to OSV or similar contemporary format • developing a package audit backend and server to reliably fetch vulnerability data from global agency databases in any format (JSON - NIST) and produce insight • improving CI tooling for FreeBSD Ports. The detailed scope was co-created with core@, portmgr@, pkgmgr@, secteam@. • Must □ New Database Format (in progress) □ Set up 2+ Database Instances (not started) □ Migrate Data from old to new database (in progress) □ Add support for new format in pkg(8) (in progress) □ Upstream engagement (not started) □ SBOM on demand (not started) □ Document how to set up build and test targets (not started) □ Integrate 3rd party test targets (not started) □ Continuous Testing (not started) • Could □ Make CI artifacts available (not started) Work Package E: SBOM improvements This work package intends to improve existing, and implement new, tooling and processes for FreeBSD Software Bill of Materials (SBOM) by implementing: tooling to roll up the individual provenance data/markers from across the tree into a higher-level view; developing tooling to parse/review/inspect the FreeBSD source tree and produce a comprehensive/holistic report to act as a SBOM for the full software stack and; extending pkg to enable this capability for software installed from ports/packages. The detailed scope was co-created with core@, portmgr@, pkgmgr@, secteam@, releng@ • Must □ Evaluate projects/solutions available in the wider ecosystem (in progress) □ Propose the target solution for SBOM (not started) □ Produce an SBOM in CI (e.g. weekly builds) (in progress) □ Produce an SBOM as an artifact as part of the release process (in progress) □ SBOM artifact on demand (in progress) □ Roll up existing data (not started) □ Record and explain decisions made (not started) • Could □ Engage with other similar projects (not started) Commissioning body: Sovereign Tech Agency ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Support for pkgbase in the FreeBSD installer Contact: Isaac Freund The FreeBSD installer now supports installing a pkgbase system. Recent FreeBSD 15.0 snapshots have a new dialog in the installer that allows the user to fetch and install packages from pkg.freebsd.org instead of using the legacy distribution sets. There is also support in the build system to build FreeBSD installation media with offline pkgbase packages included, enabling fully offline installation of a pkgbase system. These offline pkgbase packages are not yet included in 15.0 snapshot release installation however, as including both the offline legacy distribution sets and pkgbase packages would significantly increase the size of the installation media. There is however a -DPKGBASE build-time switch ready to be flipped by the FreeBSD Release Engineering team, hopefully in the near future. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BSD-USER 4 LINUX Contact: Maksym Sobolyev Links: Project Page URL: https://github.com/sobomax/qemu-bsd-user-l4b Tooling URL: https://github.com/sobomax/qemu_l4b The bsd-user-4-linux project ports BSD user-mode emulation for QEMU to Linux. The primary goal is to enable unmodified FreeBSD binaries to run on modern Linux systems. Additionally, the project aims to provide multi-platform container images with a functional FreeBSD environment and ready-to-use GitHub Actions templates. News: • Two new pull requests have been received since the initial project announcement: □ Diagnostic output cleanup; □ kqueue() support using libkqueue library on Linux. • The latest set of changes has been pulled from the Warner’s qemu-bsd-user project bringing Qemu version to 9.2.0 along with some fixes and improvements. Current Status: • The initial port successfully runs make -jN buildworld. • Most command-line tools are working as expected (sh(1), bash(1), find(1), grep(1), git(1), clang(1), etc). • A GitHub Actions pipeline builds x86_64 emulation images for: □ linux/386 □ linux/amd64 □ linux/arm/v5 □ linux/arm64/v8 • A pre-built Docker container with FreeBSD 14.1 binary world is created and pushed to the GitHub Container Registry. □ FreeBSD Image @ GHCR • Special pre-built "admin" container with Linux user-mode qemu binary for the FreeBSD/amd64 emulation is also published at the GHCR. □ FreeBSD binfmt Image @ GHCR Next Steps: * Bump FreeBSD version to 14.3; * Rebase onto Qemu 10.0.x. How You Can Help: • Test with your preferred toolchain, report issues, or contribute fixes. • Identify and implement missing system calls. • Support us on Patreon. Sponsor: Sippy Software, Inc. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Sylve — A Unified System Management Platform for FreeBSD Links: GitHub URL: https://github.com/AlchemillaHQ/Sylve CI URL: https://sylve-ci.alchemilla.io Discord URL: https://discord.gg/bJB826JvXK Contact: Hayzam Sherif Sylve is a modern, unified system management platform for FreeBSD, inspired by Proxmox. We aim to provide an integrated web interface for managing virtual machines (via Bhyve), Jails, ZFS storage, networking, and firewalling. The backend is implemented in Go, while the frontend uses SvelteKit with Tailwind CSS and ShadCN UI components. The project emphasizes a minimal system footprint, currently requiring only sysutils/smartmontools, sysutils/tmux, and libvirt as runtime dependencies. Sylve continues to address a key gap in the FreeBSD ecosystem by delivering a cohesive, user-friendly interface for system administration tasks. Q2 Progress Highlights Dashboard Added dynamic charts to the main summary page, including real-time visualization of CPU usage, RAM usage, and network throughput. Networking Interfaces can now be viewed in detail through the UI, with all relevant metadata presented in a structured format. Users can also create "switches" — simple layer 2 switches built on top of FreeBSD bridge interfaces. Storage ZFS integration is nearing completion. Users can now: • Create and destroy pools, filesystems, volumes, and snapshots. • Delete multiple datasets at once. • Schedule automatic (timed) snapshots. Initial dashboard work for ZFS monitoring has started, with further enhancements planned in Q3. Utilities A built-in downloader was introduced that supports both HTTP and magnet links. This is especially useful for fetching ISO images or VM templates directly through the interface. Virtual Machines VM creation and deletion with Bhyve is now supported. Key features include: • CPU pinning. • Web-based VNC console access. • PCI passthrough for devices. • Basic CPU and RAM usage charts for each VM. A new runtime dependency on libvirtd has been added to support VM lifecycle operations. Planned for Q3 • Polish and stabilize current functionality. • Ability to edit VMs. • Expand charting and add a basic notification system to detect hardware or service failures. • Implement UI and API support for managing Jails. • Extend networking features: □ More switch/bridge types. □ Firewall rule configuration. □ DHCP support via dns/dnsmasq or similar (for VMs). □ WireGuard VPN integration. Contributions, testing, and feedback are very welcome. If you are interested in contributing, consider helping with: • UI testing and accessibility feedback. • Bug reports and feature requests via GitHub. Sponsor: FreeBSD Foundation and Alchemilla (development and infrastructure support) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Hackathon 202506 Kitchener-Waterloo, Canada Links: Hackathon/202506 Wiki Page URL: https://wiki.freebsd.org/Hackathon/202506 FreeBSD Hackathon Wiki Page URL: https://wiki.freebsd.org/Hackathon In the week following BSDCan 2025, a hackathon took place in the Kitchener-Waterloo area. Thanks to Ed Maste for hosting this event at the Communitech Hub in Kitchener. Pictures of the hackathon Pictures of the hackathon are collected here. National FreeBSD day landed sometime during the hackathon, so Charlie Li treated us to a great DJ set to celebrate, mixing entirely on FreeBSD at an arcade bar in Waterloo :) The work done during the hackathon WiFi Testbed (Li-Wen Hsu) • The hardware of a proof-of-concept wireless has been set up in Foundation’s Kitchener office. • The current setup is simple: • One baremetal machine has multiple wireless interface and, • One access point is also connected to the machine via a serial console and a private testing network • Currently we have following hardware to be passthru to bhyve VM provisioned with the image from Artifact server of FreeBSD CI • Intel AX210 • Realtek RTL8812AU • The work continues on connecting it to FreeBSD CI cluster as a downstream job after standard tests finishes. Installer (Joseph Mingrone, Ed Maste, Aymeric Wibo) • Go through installer step-by-step and create the Improving the Installer wiki page with the notes we collected. • lualoader: Add distinct brand for installer (Make it obvious to users that the system is booting into the installer.) Patch: https://reviews.freebsd.org/D51001 pkgbase (Ed Maste) • bsdinstall(8): Default to pkgbase if media contains base packages Patch: https://reviews.freebsd.org/D50467 • release(7): Add set -e to abort upon failure Patch: https://reviews.freebsd.org/D50383 Landing scheduler run queue patches (Olivier Certner) • Land all scheduler runqueue patches. □ D45387 □ D45388 □ D45389 □ D45390 □ D45391 □ D45392 □ D46566 □ D46567 □ D50880 Capsicum (Ed Maste) • Improvements to the capsicum(4) manpage. Patches: https://reviews.freebsd.org/D50855, ce65ff203a4f • Capsicumize beep(1) to serve as an easy example of Capsicum. Patches: https://reviews.freebsd.org/D50709 s2idle/S0ix/USB4 (Aymeric Wibo, Sheng-Yi Hung) • Fix some more USB4 driver panics. • Discuss how s2idle should work w.r.t. the scheduler with Olivier & Mark, and temporarily implement "idle" state for the scheduler (where it just always chooses the idle thread). • Extend amdgpio driver to service all GPIO interrupts (requirement for S0i3 on AMD). We were also looking into how we can consume GPIO interrupts in device drivers on x86 for stuff like reducing the latency of the Framework trackpad with Sheng-Yi. • Implement some more S0i3 debugging features for AMD to help us debug why we would not be entering S0i3. Ports (Joseph Mingrone) • Mk/Scripts/qa.sh: Fix false positives in LIB_DEPENDS warnings Patch: https://reviews.freebsd.org/D50860 • editors/emacs-devel: Update to 2025-06-17 snapshot Patch: 4170f6575380 Miscellaneous (Ed Maste, Olivier Certner, Sheng-Yi Hung, Li-Wen Hsu) • Enable sccache support as an alternative to ccache when building (through WITH_CCACHE_BUILD environment variable). Commit: 10cb3979a9bd • Discussion on the CPPC implementation (Sheng-Yi, Olivier), see in particular D49587. • Other various fixes. Patches: D50876, 956100d60fa8, fc77abfd1e62, D50938, 6d8cfd29d477, 4f33d073003c Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Userland Changes affecting the base system and programs in it. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ucred / group changes in FreeBSD 15.0 Links: freebsd-arch@ discussion URL: https://lists.freebsd.org/archives/freebsd-hackers/2025-August/004825.html Primary kernel change URL: https://cgit.freebsd.org/src/commit/sys/sys/ucred.h?id=be1f7435ef218b1df35aebf3b90dd65ffd8bbe51 Primary userspace change URL: https://cgit.freebsd.org/src/commit/sys/kern/kern_prot.c?id=9da2fe96ff2ea227e4d5f03ef92b55aabeabb7fc Contact: Kyle Evans Contact: Olivier Certner FreeBSD 15.0 will change how supplementary groups are handled in both userspace and the kernel in FreeBSD 15.0 in a way that warrants additional attention and feedback. For some background: FreeBSD has historically tracked the effective group-ID of a process in the ucred(9) cr_groups array as the first element, with the rest of the array describing its supplementary groups. The natural consequence of this decision is that the arrays used in setgroups(2) and getgroups(2) follow the same format, and setgroups(2) has the documented side effect of setting the effective group-ID. The vast majority of other platforms do not exhibit this behavior anymore, including NetBSD and OpenBSD. macOS appears to be the only exception found in testing. The problem is that the vast majority of software in the FreeBSD Ports Collection comes from other platforms, where setgroups(2) and setgroups(2) operate purely on the supplementary groups. This kind of a behavior difference is very subtle and would need to be audited more carefully to be sure that we have not introduced a potential security issue in ported software. In FreeBSD 15.0, the primary user-facing change is that setgroups(2), getgroups (2), and initgroups(3) behavior will change to match other platforms, and users are requested to be extra vigilant in areas that may be affected as we proceed through the release cycle. In general, the expectation is that this change may: • Fix some small number of bugs where we would have lost either our expected effective group membership or one of the supplementary groups we should have been in • (Less likely) Introduce some even smaller number of bugs where something expected setgroups(2) to change our effective group membership but now it is just a supplementary group and our effective group-ID is unchanged Software included in the base system is largely unaffected or improved by this change, with OpenSSH being a notable example of a strange bug caused by the historical implementation. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ MIT Kerberos Import into FreeBSD Contact: Cy Schubert The FreeBSD Foundation was approached to import MIT KRB5 into FreeBSD with the intent to replace our aging Heimdal. The Enterprise Working Group made a request to the Foundation to replace Heimdal with MIT KRB5. This is the first report for this project. Tasks completed: • MIT KRB5 has been imported into FreeBSD 15-CURRENT. • The WITH_MITKRB5 option is disabled until a successful ports exp-run is complete. Additional remaining tasks: • Fix port build errors identified by a ports exp-run. • Produce a writeup of the new Kerberos. • Determine if migration of the Heimdal database to an MIT database is possible. (At the moment this appears unlikely due to the age of our ancient Heimdal and the lack of support for old crypto in newer Heimdal MIT). • Produce Heimdal Kerberos database to MIT database migration documentation (if possible). • (Optional) Develop and discuss the import and migration options at the next BSDCan. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SysctlTui Link: Project Repository URL: https://gitlab.com/alfix/sysctltui Contact: Alfonso Sabato Siciliano SysctlTUI is an interactive text user interface (TUI) utility for exploring and managing sysctl(3) parameters. It presents the sysctl Management Information Base (MIB) as a hierarchical and navigable tree, enabling users to: • Browse metadata for each kernel parameter. • Retrieve and display current values. • Modify parameters interactively from within the interface. The UI consists of three panels: a tree view of the MIB hierarchy, a detail panel showing metadata, and a value editor. Pressing the F1 key opens a help dialog explaining: • When the MIB is built. • When values are retrieved or updated. • A link to an online guide for getting started with sysctl, including guidance on interpreting and using the displayed data. Although still in early development (currently at version 0.0.2), SysctlTUI already offers functionality comparable to tools like sysutils/nsysctl and deskutils/sysctlview. A manual page is included, with suggestions to make the output similar to sysctl(8) or nsysctl(8). The ToDo list outlining plans for enhancements like configuration file integration and subtree sorting by names. SysctlTUI is open source and available via the FreeBSD Ports Collection: sysutils/sysctltui. Note: TUIs are a known accessibility issue, as they are not usable with most screen readers. Users who access FreeBSD using a screen reader can use the sysutils/nsysctl package instead. It is a command line utility that provides the same information as SysctlTUI, since both tools use the same underlying kernel interface. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Geomman Development Links: Geomman GSoC wiki URL: https://wiki.freebsd.org/SummerOfCode2025Projects/FullDiskAdministrationToolForFreeBSD geomman Gitlab repository URL: https://gitlab.com/brauliorivas/geomman bsddialog repository URL: https://gitlab.com/alfix/bsddialog sade URL: https://man.freebsd.org/cgi/man.cgi?query=sade&manpath=FreeBSD+14.3-RELEASE+and+Ports Contact: Braulio Rivas Geomman is a new partition tool based on sade(8) that brings more functionality such as moving, copying, and pasting partitions. Geomman is part of Google Summer of Code 2025. Currently, it is available in a Gitlab repository. But at some future time, it is expected to become a tool in the base system. Geomman is a TUI designed to allow to growing, shrinking, moving, copying, and pasting partitions with filesystems other than UFS. For example, users may be able to create an exFAT partition, as well as to resize an ext4 filesystem. This would make partition management easier, because there are tools for each individual task (mainly depending on the filesystem), but none that concentrates all cases in a single tool. For the moment, geomman only allows copying and pasting partitions. However, for the next report the tool should be almost finished. Currently, I am working on a mechanism to move partitions using dd(1). Other approaches may be possible, so any help is very welcome. The next steps for geomman are: • Develop a way of moving partitions. • Handle duplicate UUIDs between partitions when using dd. • Add options to create, grow, and shrink more filesystem types. Sponsor: Google Summer of Code ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Audio Stack Improvements Contact: Christos Margiolis I have been working on the audio stack since 2024Q1. Below is a list of the previous status reports: 2024Q1 URL: https://www.freebsd.org/status/report-2024-01-2024-03/#_audio_stack_improvements 2024Q2 URL: https://www.freebsd.org/status/report-2024-04-2024-06/#_audio_stack_improvements 2024Q3 URL: https://www.freebsd.org/status/report-2024-07-2024-09/#_audio_stack_improvements 2024Q4 URL: https://www.freebsd.org/status/report-2024-10-2024-12/#_audio_stack_improvements 2025Q1 URL: https://www.freebsd.org/status/report-2025-01-2025-03/#_audio_stack_improvements Important work since last report: • More sound(4) cleanups, fixes and improvements. • Committed sndctl(8) (previously mentioned as audio(8)). • Committed AFMT_FLOAT support. • More out-of-the-box laptop support. • Gave up on the /dev/dsp as a router device patch in favor of D50070 (includes relevant discussions). • Submitting series of patches to clean up the MIDI subsystem, and working on refactoring it into a generic layer, similar to PCM. • Gave BSDCan 2025 talk (slides). Future work includes: • Port virtual_oss to base. • More bug fixes, support, optimizations and general improvements, in all areas of the sound stack. You can also follow the development process in freebsd-multimedia@, where I post regular reports. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ DRM drivers Links: Update to Linux 6.9 DRM drivers URL: https://github.com/freebsd/drm-kmod/pull/361 Contact: Jean-Sébastien Pédron DRM drivers are kernel drivers for integrated and discrete GPUs. They are maintained in the Linux kernel and we port them to FreeBSD. As of this report, we take the AMD and Intel DRM drivers only (NVIDIA FreeBSD drivers are proprietary and provided by NVIDIA themselves). We port them one Linux version at a time. This allows us to ship updates more often and it eases porting and debugging because we have a smaller delta compared to a bigger jump skipping several versions. This quarter, we finally merged the drivers from Linux 6.7 and 6.8 that were done during the first quarter into drm-kmod. The porting for DRM drivers from Linux 6.9 was finished and is now ready for review and testing; see the pull request for instructions if you want to try them. The pull request also lists all the patches needed to linuxkpi, the Linux drivers compatibility layer in the FreeBSD kernel. Several patches were already reviewed but there is still work. These updates target the FreeBSD 15-CURRENT development branch for now. Once kernel patches are accepted and the DRM drivers updates merged, we will evaluate if/how we can backport the kernel patches to earlier release branches (namely 14-STABLE). While waiting for review, we also started to work on two features which were unsupported on FreeBSD: • DMA_BUF_IOCTL_EXPORT_SYNC_FILE and DMA_BUF_IOCTL_IMPORT_SYNC_FILE ioctls • DRM_IOCTL_SYNCOBJ_EVENTFD ioctl They are apparently required to allow the use of wlroots-based Wayland compositors with the Vulkan API (see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286311). wlroots will need a patch as well because it only expects these features on Linux for now. Both pull requests as well as the patches to linuxkpi they rely on are ready for review and testing. The linuxkpi patches are linked in the pull requests. This work is kindly sponsored by the FreeBSD Foundation as part of the Laptop and Desktop Project. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Suspend/Resume Improvement Links: Blog URL: https://obiw.ac/s0ix/ FOSDEM talk on s2idle/S0ix URL: https://youtu.be/mBxj_EkAzV0 Working Repo URL: https://github.com/obiwac/freebsd-s0ix/tree/everything Tip of the s2idle/S0ix + AMD SMU stack URL: https://reviews.freebsd.org/D48721 USB4 suspend stack URL: https://reviews.freebsd.org/D49453 Contact: obiwac Suspend-to-idle and support for S0ix sleep is in the process of being added to FreeBSD. This will allow modern Intel and AMD laptops (e.g. AMD and newer Intel Framework laptops), some of which do not support ACPI S3 sleep, to enter low power states to increase battery life. The USB4 driver (which was a dependency to S0i3 entry) has been updated to allow for the sleep routines, and all CPUs are now entering C3 during s2idle. Scheduler work is needed to ensure CPUs stay in C3 and do not get work scheduled to them, but a prototype solution exists and is working. This means that S0i3 can now be entered on the Framework 13 AMD Ryzen 7040 series laptops, albeit only on my working 14.1 branch. This does not work on -CURRENT yet. The amdgpio driver (for the AMD GPIO controller) has been extended to service all GPIO interrupts and suspend the controller, as that was potentially a blocker for the CPU to enter S0i3. Nothing is being done with these GPIO interrupts at the moment as FreeBSD does not have the infrastructure for device drivers to register these interrupts on x86 yet. The SMU idlemask is also now being exported as a sysctl now (dev.amdsmu.0.idlemask), the value of which is not documented and is mostly to help AMD debug issues with S0i3 entry on FreeBSD on their side. A pre-built image is being built to aid in easily testing S0i3 entry on machines. With respect to the links, the blog post entry is outdated. A talk was given about this at BSDCan 2025 too, but it has yet to be uploaded as a standalone video; it will be included in the next status report. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Named attribute support (Solaris style extended attributes) Contact: Rick Macklem Named attributes is the NFSv4 term for what is also known as Solaris style extended attributes. Since ZFS has its origins in Solaris, the wiring for these exists in OpenZFS. This little project consists of connecting that wiring up. This is not intended to replace the extended attribute support already in FreeBSD. It provides an alternate mechanism for manipulating extended attributes that will be supported for ZFS and NFSv4. There are a few reasons I think this could be useful (as indicated via email discussion). This mechanism allows for extended attributes as large as any regular file, which can be partially updated. Some NFSv4 clients, such as MacOS and Windows, can use these extended attributes but not the FreeBSD/Linux style ones. (I think MacOS calls these extended attributes fork files and Windows calls them alternate data streams.) There is software, such as bash, that know how to manipulate these extended attributes. The fundamental difference is that this mechanism provides a directory that is not in the file system’s namespace, but is associated with a file object. This named attribute directory can then be read via readdir(3) to get the list of extended attributes, which are really just regular files. These extended attributes are then read/written like any regular file. The top level system call interface is open(2)/openat(2) with the new O_NAMEDATTR flag (called O_XATTR on Solaris). Most of the work has been committed to FreeBSD’s main for FreeBSD 15. Once the ZFS patch makes it through review and gets pulled into OpenZFS, the ZFS and NFSv4 support should work. There are also a couple of manual pages currently under review in phabricator. The main thing left to do is update libarchive/tar so that large extended attributes can be archived/retrieved. (The current FreeBSD extended attribute mechanism is supported by libarchive, but will have size constraints.) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Packrat — NFS client caching on non-volatile storage Contact: Rick Macklem NFSv4.1/4.2 provides support for a feature called delegations. When a NFSv4.1/ 4.2 client holds a delegation, the client has certain rights to a file, including a guarantee that no other client will make changes to the file unless the delegation is recalled. As such, when a client holds a delegation for a file, it can aggressively cache the file’s data, knowing that it will not be modified by other clients until it returns the delegation. This project is intended to allow the NFSv4.1/4.2 client to aggressively cache file data on client local non-volatile storage, when the client holds a delegation for the file. I created a patch long ago to try and do this for NFSv4.0, but it was never at a stage where it was worth using. This project is a complete rewrite of the patch, done in part because NFSv4.1/4.2 plus other recent NFSv4 related changes makes doing this more feasible. The patch is getting stable now, but I am not sure if it will be ready for inclusion in FreeBSD 15 as an experimental feature enabled via a new mount option called "packrat". The main thing I still need to do is code a writeback kernel thread. Right now, dirty chunks stored on client local non-volatile storage get written back to the NFSv4.1/4.2 server upon umount. This can result in the umount taking a long time (as in many minutes). To alleviate this, I am planning on implementing a writeback kernel process that will walk the non-volatile storage and write the dirty chunks back. The trick is to make it aggressive enough that most dirty chunks have been written back when a umount is done, but not so aggressive that it impedes the performance of synchronous NFSv4.1/4.2 RPCs. This will be very much an experimental feature, but it is hoped it will allow NFS mounts to be used more effectively, particularly in WAN situations, such as a mobile laptop. There is still work to be done, particularly with respect to recovery of delegations after a NFSv4.1/4.2 client restart. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ LinuxKPI 802.11 and Native Wireless Update Links: 802.11ac support URL:https://github.com/FreeBSDFoundation/proj-laptop/issues/33 LinuxKPI TKIP and GCMP support URL:https://github.com/FreeBSDFoundation/proj-laptop/issues/64 LinuxKPI wireless suspend and resume URL:https://github.com/FreeBSDFoundation/proj-laptop/issues/58 MediaTek mt76 PCI driver support URL:https://github.com/FreeBSDFoundation/proj-laptop/issues/66 802.11ax support URL:https://github.com/FreeBSDFoundation/proj-laptop/issues/34 net80211 updates URL:https://github.com/FreeBSDFoundation/proj-laptop/issues/79 Tracked wireless PRs URL:https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=277512&hide_resolved=1 Contact: Bjoern A. Zeeb Contact: The FreeBSD wireless mailing list This report focuses on the efforts using permissively licensed Linux wireless drivers, mostly unmodified, on FreeBSD, as well as preparing the native net80211 stack for support of newer standards. As announced iwlwififw(4) was removed from the source tree in favor of a ports/ package based solution. Users are asked to use fwget(8) to automatically install the firmware along with any possible configuration. Support for wlan_tkip(4) was added to linuxkpi(4) but has to be manually enabled. wlan_gcmp(4) support for linuxkpi(4) followed later and is available from FreeBSD 15 onward. FreeBSD 14.3-RELEASE is the first release with VHT (802.11ac) support available. Modern iwlwifi(4) chipsets are supported. There was some fallout after the release and a few open problems, but also a lot of positive feedback. rtw88(4) saw a fix for a NULL pointer in the driver and is now starting to be usable. Thanks to everyone who helped track this down and test patches along the way. Work on suspend and resume for LinuxKPI-based wireless drivers was picked up again, and we are getting closer to a working solution (at least for suspend it now exists). Work is also ongoing for Mediatek mt76-based PCIe card support. HE (802.11ax) definitions were migrated from linuxkpi(4) to native net80211 code and corrected. ifconfig(8) was enhanced parsing more information elements to aid debugging. Work is in progress to fix a problem with reporting signal strength and dealing with RSSI. Further fixes to LinuxKPI and resolving the problems we worked around by improving native net80211 code are in the works. Lastly, various man pages were improved or written. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ USB Kernel Debugging Contact: Tom Jones XHCI USB controllers offer a mode which allows them to be used as a system debugging interface. XHCI debug uses a special USB 3 cable with VBUS, D+ and D- disconnected. The feature can be used to live debug the FreeBSD kernel, enabling investigation of issues which cause the system video console to lock up and there is not an alternative such as a serial console. This can happen when debugging issues with graphics drivers. Hiroki Sato developed support for the XHCI debug interface and made it available as some in progress git branches. This implementation enables FreeBSD to operate as both a Debug Host and a Debug Target, with support for debugging from the loader through to the kernel. I have been updating and testing this support along with Mitchell Horne and together we have a WIP branch which applies to FreeBSD main. We are currently tidying up interfaces and testing for stability with the goal of introducing XHCI debug once 16 is branched. In doing the XHCI debug work I rediscovered a second form of kernel debugging implemented by Hans Petter Selasky (hselasky@) in 2009. The FreeBSD USB stack supports using a USB serial device as a system console and includes support to continue polling the interface once the system has entered the debugger (such as during a panic). USB Serial debugging allows a developer with two commodity USB serial interfaces to connect to a FreeBSD target and debug the kernel. USB Serial debugging is available in all FreeBSD releases in FreeBSD 9, but changes in the kernel build process mean that it is not detected in modern kernels. In this quarter I have been working on documentation required to use this interface and changes to make it available in GENERIC kernels for newer FreeBSD releases. A core part of this work has been trying to document kernel debugging interfaces. If you use live debug interfaces other than serial or network debugging please get in touch so I can add these to the FreeBSD Developers Handbook. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Porting HFS+ to FreeBSD Links: Project Home URL: https://github.com/stupendoussuperpowers/freebsd_hfs Contact: Sanchit Sahay HFS+ (Hierarchical File System) is a legacy filesystem introduced by Apple for its BSD-based XNU operating systems. Although HFS+ has been deprecated in favor of APFS, it is still in use on many older Apple devices, such as iPods, which rely on HFS+ volumes for storage. While many modern operating systems include native support for HFS+, FreeBSD currently offers only limited functionality via FUSE. This project aims to address that limitation by porting the original, now open-sourced HFS+ implementation to the FreeBSD kernel as a native filesystem driver. The primary focus of this effort is to modernize the VFS layer to align with current FreeBSD interfaces and to adapt XNU-specific logic to their FreeBSD equivalents. Features implemented: • Mount support for HFS, HFS+ Volumes • Read, stat support for directories and files • Create support for directories and files • mount_hfs binary ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Architectures Updating platform-specific features and bringing in support for new hardware platforms. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Pinephone Pro Support Links: Repository on Codeberg URL: https://codeberg.org/Honeyguide/freebsd-pinephonepro Contact: Toby Kurien The project to port FreeBSD over to the Pinephone Pro is progressing. The aim of this project is to step by step support components of the Pinephone Pro in FreeBSD so that the device one day might be usable as a highly mobile FreeBSD device. In this quarter, a new development release has been made available for flashing and testing on a PinePhone Pro. It includes a newly added touch driver, and a minimal desktop environment with an on-screen keyboard. You can simply flash this build to an SD card and boot it up, provided you have the correct version of U-boot bootloader installed (details at the repository). The image also contains the kernel and drivers source code, along with editors/vim editor and build tools, allowing for development of drivers on-device. To facilitate testing and driver development, network access has been enabled via the headphone jack (using the headphone-to-USB-serial adapter). It works by using Point-to-Point Protocol (PPP) to access the network via your PC. Details of setting this up are in the repository README file. Work is now under way to develop USB and WiFi drivers. As always, contributions in the form of testing, feedback, upstreaming, driver development, or just words of encouragement are welcome. See the post on the FreeBSD Forum for more: https://forums.freebsd.org/threads/porting-freebsd-to-pinephone-pro-help-needed.95948/ Sponsor: Honeyguide Group ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cloud Updating cloud-specific features and bringing in support for new cloud platforms. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD on EC2 Contact: Colin Percival FreeBSD is available on both amd64 (Intel and AMD) and arm64 (Graviton) EC2 instances. In the past quarter, the final bits needed for "hot plug" (and unplug) landed, allowing this to be fully functional in FreeBSD 14.3-RELEASE. FreeBSD "AMI Builder AMIs" are now being produced as part of the FreeBSD release building process (including for 14.3-RELEASE). Sponsor: Amazon Sponsor: https://www.patreon.com/cperciva ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Documentation Noteworthy changes in the documentation tree, manual pages, or new external books/documents. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Documentation Engineering Team FreeBSD Documentation Project URL: https://www.freebsd.org/docproj/ FreeBSD Documentation Project Primer for New Contributors URL: https://docs.freebsd.org/en/books/fdp-primer/ Documentation Engineering Team URL: https://www.freebsd.org/administration/#t-doceng Contact: FreeBSD Doceng Team The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter. During the last quarter the following commit bits were taken for safekeeping: • ale • brueffer • danger • glewis • hrs • ygy Team changes: • doceng@ welcomes ebrandi@ as a new member (lurker). • carlavilla@ stepped down from doceng@. doceng@ thanks him for his service. • dbaio@ stepped down from doceng@. doceng@ thanks him for his service. • fernape@ stepped down from doceng@. doceng@ thanks him for his service. Document changes • Handbook □ The jails chapter has been updated □ The Wi-Fi information have been updated • Website □ Plausible Analytics have been added to the website • Porter’s Handbook: □ Document Uses=gnome:gnomedesktop4 Many typos have been fixed in all related documents. • Documentation repository: □ Added manpages for macOS 10.12.0, 10.15.0, and 11.1 □ Updated manpages for macOS to 15.5.0 □ Added OpenIndiana manpages for 2013.08, 2015.10, 2020.10, 2022.10, and 2024.10 □ Added manpages for NetBSD 9.4 □ Added manpages for OpenBSD 7.7 □ Updated Debian manpages to 12.11.0 FreeBSD Translations on Weblate Translate FreeBSD on Weblate URL: https://wiki.freebsd.org/Doc/Translation/Weblate FreeBSD Weblate Instance URL: https://translate-dev.freebsd.org/ Q2 2025 Status • 20 team languages • 252 registered users 6 new translators joined Weblate: • @mohamad (fa) • @v.popolitov (ru) • @SochiByte • @carlosdaniel26 • @tj (nl_NL) • @Natthachai043 (en) Languages • Chinese (Simplified) (zh_CN) (progress: 7%) • Chinese (Traditional) (zh_TW) (progress: 3%) • Dutch (nl_NL) (progress: 1%) • French (fr_FR) (progress: 1%) • German (de_DE) (progress: 1%) • Greek (progress: 1%) • Indonesian (progress: 1%) • Italian (it_IT) (progress: 4%) • Korean (progress: 30%) • Norwegian Bokmål (progress: 1%) • Persian (progress: 3%) • Polish (progress: 1%) • Portuguese (progress: 0%) • Portuguese (Brazil) (progress: 23%) • Russian (progress: 37%) • Spanish (progress: 35%) • Turkish (tr_TR) (progress: 1%) We want to thank everyone that contributed, translating or reviewing documents. And please, help promote this effort on your local user group, we always need more volunteers. Packages maintained by DocEng During this quarter the following work was done in packages maintained by doceng@: • www/gohugo: update to 0.147.8 Open issues There is 1 Open PRs in Bugzilla assigned to doceng@: • 267274 Please remove the zh-CN Handbook of the current FreeBSD website ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Wiki Links: FreeBSD wiki front page URL: https://wiki.freebsd.org/FrontPage Contact: Mark Linimon Contact: Wiki admin Since the last status report, several people have expressed an interest in bringing the wiki up to the level it ought to be. The ongoing discussions (mostly taking place on the FreeBSD Discord) are concerned with the topics of: • Defining what content we consider useful. • Ensuring that the useful content is kept current. • Figuring out a way to keep obsolete content away from search engines. • Add basic analytics to existing site to see what pages, if any,are actually being accessed. • Decide on whether MoinMoin can still be useful for purpose in the short-term while we consider the longer-term needs listed above. We do not yet have consensus on these issues. Please join us on the FreeBSD Discord #documentation under the #wiki subthread. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Vision Accessibility Link: Project Repository URL: https://gitlab.com/alfix/freebsd-accessibility Contact: FreeBSD Accessibility mailing list Contact: Alfonso Sabato Siciliano This quarter, the review for the FreeBSD Accessibility Handbook was submitted and is available at: https://reviews.freebsd.org/D50894. The review includes a link to an HTML preview. The handbook aims to document assistive technologies for vision accessibility available in FreeBSD, covering both the BASE system and the Ports Collection. It is divided into two parts and contains six chapters: 1. Help — Covers how to request assistance effectively through appropriate FreeBSD communication channels. 2. Virtual Terminal — Documents vision-related accessibility features of the FreeBSD console (vt(4)). 3. Colors — Explains how to configure color schemes, including high-contrast themes and adjusting screen colors for ambient lighting. 4. Low Vision — Outlines accessibility tools in graphical desktop environments for users with low vision, such as screen magnifiers, readable fonts, and scaling. 5. Blindness — Describes assistive technologies for blind users, focusing primarily on screen readers and compatible tools. 6. Development — Provides resources for developers to make their software accessible, test accessibility, and improve support for users with visual impairments. The handbook deliberately avoids images and minimizes non-plain-text elements to enhance compatibility with assistive technologies. Tips and new ideas are welcome. If possible, send reports to the FreeBSD Accessibility mailing list, to share and to track discussions in a public place. Sponsored by: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Security Hardening Compiler Options for the Ports Collection Links: Commit of the features URL: https://cgit.freebsd.org/ports/commit/Mk/Features/fortify.mk?id=7a489e95c51f47f5e25a5613e375ec000618e52a FreeBSD security hardening with compiler options URL: https://www.leidinger.net/blog/2025/05/24/freebsd-security-hardening-with-compiler-options/ Contact: Alexander Leidinger The Ports Collection gained the possibility to enable some security features of modern compilers for package builds. As not all ports are compatible with them, this is not enabled by default. The 3 new features which can be enabled for the Ports Collection in make.conf are: • WITH_FORTIFY=yes: This enables mitigations of common memory safety issues, such as buffer overflows, by adding checks to functions like memcpy, strcpy, sprintf, and others when the compiler can determine the size of the destination buffer at compile time. This requires support from the FreeBSD base system and may only be available in FreeBSD 15 onwards. • WITH_STACK_AUTOINIT=yes: This enables a compiler specific option to automatically initialize local (automatic) variables to prevent the use of uninitialized memory. • WITH_ZEROREGS=yes: Zero call-used registers at function return to increase program security by either mitigating Return-Oriented Programming (ROP) attacks or preventing information leakage through registers. This depends upon support from the compiler for a given architecture. This is disabled for python ports; currently there are issues. The blog post referenced in the links section explains how to use them, how to exclude certain ports if needed, and provides a more detailed explanation of those 3 new features along the already existing build-time security options of the Ports Collection and the basesystem build. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Improve OpenJDK on FreeBSD Links: Project description URL: https://freebsdfoundation.org/project/improving-openjdk-on-freebsd/ Project repository URL: https://github.com/freebsd/openjdk Contact: Harald Eilertsen FreeBSD Java mailing list The goal of this project is to improve OpenJDK support for FreeBSD/amd64 and FreeBSD/arm64. Java is an important runtime environment for many high performance, critical enterprise systems. Making sure Java based applications run correctly and efficiently on FreeBSD is important to ensure that FreeBSD will continue to be a viable and attractive platform for enterprises, as well as businesses and organizations of all sizes. In this quarter the following issues/milestones were reached: • The OpenJDK 24 port was updated to OpenJDK 24.0.1 at the beginning of the quarter, soon after it was released by upstream. • A recurring issue with the PPC ports was fixed (thanks to Piotr Kubaj). • A new way of bootstrapping OpenJDK ports was suggested and discussed – this is a prerequisite to get the FreeBSD port integrated into the OpenJDK CI environment. • A CI job for building and testing the jtreg test harness for FreeBSD was integrated using GitHub Actions - in part to get familiar with the CI framework used by OpenJDK projects, but also to make sure the test harness builds and works on FreeBSD. In addition, a lot of time was spent cleaning up and refactoring the BSD port for Aarch64, fixing various issues and working towards making the BSD port up to date with the OpenJDK mainline. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GCC on FreeBSD Links: GCC Project URL: https://gcc.gnu.org/ GCC 12 release series URL: https://gcc.gnu.org/gcc-12/ GCC 13 release series URL: https://gcc.gnu.org/gcc-13/ GCC 14 release series URL: https://gcc.gnu.org/gcc-14/ GCC 15 release series URL: https://gcc.gnu.org/gcc-15/ GCC 16 release series URL: https://gcc.gnu.org/gcc-16/ Contact: Lorenzo Salvadore The exp-run to update GCC default version from 13 to 14 is still suspended. As a reminder, it has been noticed that FreeBSD 13.4 lacks symbols that are used by GCC 14 for linking; please see https://bugs.freebsd.org/bugzilla/ show_bug.cgi?id=284499#c0 for a more detailed explanation. The symbols are however already present in higher FreeBSD versions. At the time this report is written, FreeBSD 13.4 is expected to go out of support soon (on June 30th), so it has been decided that it is preferable to suspend the exp-run until then. Thus it will get back on track on July 1st. Meanwhile, GCC 15 has been released. As usual, the new port package lang/gcc15 has been created, as well as lang/gcc16-devel that tracks the latest GCC development. More bugs have been addressed. Bug 285711 about issues with some CPUTYPE values has been fixed with a temporary workaround. The workaround will be needed until commit 22e564c74eb2 is included in all supported FreeBSD releases. A build failure has been found on aarch64 machines, see bug 282797. A fix has been found and is about to be submitted upstream. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Third Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Chinese FreeBSD Community (CFC) Chinese FreeBSD Community (CFC) URL: https://bsdcn.org/ The community currently comprises 316 members in the QQ group and 175 members in the WeChat group. Documentation Project Links: FreeBSD-Ask Documentation Project on GitHub URL: https://github.com/FreeBSD-Ask/ FreeBSD-Ask Documentation Project URL: https://book.bsdcn.org/ It is noteworthy that all prior FreeBSD documentation has been fully translated into Chinese, including but not limited to the following materials: • FreeBSD Release Notes (i386 or amd64) • FreeBSD Status Reports • FreeBSD Handbook • FreeBSD Porters Handbook • FreeBSD Articles • FreeBSD Architecture Handbook • Developers' Handbook In addition, two classic works have been translated. • A Quarter Century of Unix • The UNIX-HATERS Handbook, an humoristic book written in 1994 about issues that some users found in the UNIX operating system. It includes an anti-foreword from Dennis Ritchie, one of the authors of UNIX, which he wrote in a style similar to the one used in the handbook itself. FreeBSD-Ask Links: FreeBSD-Ask on GitHub URL: https://github.com/FreeBSD-Ask/FreeBSD-Ask FreeBSD-Ask on Website URL: https://book.bsdcn.org/ Contact: ykla Contact: Voosk The FreeBSD-Ask was initiated on 14 March 2021 by ykla from the Chinese FreeBSD Community (CFC). It is an open-source publication written in Simplified Chinese that aims to provide introductory knowledge about the FreeBSD operating system. Quarterly Updates • Documentation Additions: □ Overview of FreeBSD Desktop Distributions □ Installing databases/postgresql17-server with pgAdmin4 □ Migration Guide for Windows Users □ FreeBSD as a Host with VirtualBox • Rewritten Documentation: □ Games on FreeBSD (Renpy and Minecraft) □ Installing sysutils/podman-suite □ Installing x11/gnome(to 47) □ Installing net/rsync □ Installing net/samba420 □ Graphic card drivers □ Printing □ Wubi Input Method(Based on textproc/fcitx5 or textproc/ibus) □ Installing x11-wm/xfce4 • Miscellaneous: □ The tutorials pertaining to DragonFly BSD, OpenBSD and NetBSD have undergone comprehensive translation, updating and rewriting. □ Several GitHub Actions have been added to verify that images are referenced correctly. □ We now support exporting FreeBSD-Ask to the ePub format. □ A tutorial about the security/py-fail2ban port (utilizing ipfw(4), pf (4), and ipf(4)) has been submitted to the FreeBSD Journal for review. It is hoped that an increasing number of contributors will join the documentation efforts. The primary objective of this project is to undertake a comprehensive modernisation and rewrite of the FreeBSD Handbook with a view to promoting the development and adoption of FreeBSD. Ports QQ Port on GitHub URL: https://github.com/FreeBSD-Ask/QQ-Port/ Bug 287292 - [NEW PORT] net-im/qq: consider restoring QQ port due to resumed upstream development URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287292 In the current quarter, a port was created for QQ, one of the most popular instant messaging applications currently in use in mainland China. The bug report remains open and has not yet been assigned any reviewers. Sponsors: Chinese FreeBSD Community (CFC) From nobody Sat Aug 30 13:24:50 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cDbTs3Hjfz65QtG for ; Sat, 30 Aug 2025 13:25:05 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cDbTr5Pstz3KDF; Sat, 30 Aug 2025 13:25:04 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=KThnIeNB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::635 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-afcb731caaaso455493566b.0; Sat, 30 Aug 2025 06:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756560304; x=1757165104; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=dNyMAOocgwHbGG1np2Igf6i8Bd5qJyylTs1nFJwIOHA=; b=KThnIeNBNMD9rk7AmMtRd0EhoKzTgib8pYgRiInUvnszbjoLfVTk3NfrUEUIV8Gcas TBhFVp6p9G5/aC94xOTSXh9gT1mmcTSIDg6Ujot7J71o4sF8IGAGDJXQEuZK6TnDYXvb CKxCnYFAfYMiq6uy5expb0dG8luxI1/X5gmzF6xyTiqvIknLoZPnmkedaO6WvF2YKwRX qWTKGuAAu87iyEAsfUHfyRi0JC+5KQJOANem79aNd+IlQ0nHdZYQcGsvCarKofeFMaQS /PygE5G8/7NeXiWVjKHZFvE6aJUcRGll4k7HUA0xytd1ZtnwVzOa7JCdLmOUw7B0Ei/4 G2Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756560304; x=1757165104; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dNyMAOocgwHbGG1np2Igf6i8Bd5qJyylTs1nFJwIOHA=; b=I2Ok2JCcMrYgCoOaOdWGuQBhgzORDTSveyfKiwCVBbFv37UMcsemqEsoINamYloak4 7YlTtRJz3Ob+RFhp7G8hoWgcuDMeiiBo9zZ1rl7dLVWGMt4t1Q3Udcpl6itVdMrVjPYt L1twUgPxSZplg4c/zWG531DvO/K7+s1bzcIg2u++crXh9qJ+AZlCnMAcXiuPA+dVmCmh sQVq3N5D7lpMTNbAijcxRSUToh/C/61Ar5rMQ0UVW4UX0qVCJm9UDtDzvhl3JjBhP8q5 K0JQeayy/tLK/6eVHqEUs7vW+JISzz8rs5MiKKJrDVxaWPmzweS2i2+vvpi3n7ArJ8YG 0Nuw== X-Forwarded-Encrypted: i=1; AJvYcCWHSCAgPUNE66VARH02ctHNuB6TRRIEC2sPfPYdsQ3eYwk+YzTWAiqM7ko3Lle+xhSpxOTga51oJ5G+CbbjAkw=@freebsd.org, AJvYcCXM6zBjNvC/rrbToAmG7HwouRXb2pRdIH4yZoqAT59WArPoWDz61XqNNbsMskF7wyRg5pvp9Kxz@freebsd.org X-Gm-Message-State: AOJu0YzCkTzySbaKLgLNy2VhKgqAFgZi7g/s2XSlesmeclYOkIkcHyaD 2qPtUyetfggPcdAbq5WuB6kAP4kulUgE6pxHHbeW1B9p0ADyVgRoLTn7lw3iHQ9iUV2oDIaOBU2 YMgE+LBeqwqnlP6nMbHwqcsk4qA8j6MVW X-Gm-Gg: ASbGncsLJx0iaW8UtBioBZeyk9DijV5FY+OQhZwUIthKiULHXVNIsL5XLOgaFeyrvTq TCXSApbVm14iDs7iH2ZVi4MUMOxpzViHxftzJwdBakB7edRVvvSNkqB0PnOLEY/4sGl4ppa0zKp 9fUQkP63cu42Nc9TmI4kOfWYY3oJG9IJQAIqO+wxKLWlouzhd5+Of/Ba33aDnRO3a38jhjwZuWq ve46H6dVGhpS/Ifum5FiHjBtzSpgsoe07vU1w63NDExF6JhaQ== X-Google-Smtp-Source: AGHT+IHDFwGj3V2/wG3W4CAakFk8nkFE4kFztJEkvMP+24z97Uy3pPTFB97h+SBYqQrPjvoFUypbbkOAAlVgku7NFh8= X-Received: by 2002:a05:6402:3506:b0:61c:5272:a739 with SMTP id 4fb4d7f45d1cf-61d2686997dmr1813847a12.2.1756560303247; Sat, 30 Aug 2025 06:25:03 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Sat, 30 Aug 2025 06:24:50 -0700 X-Gm-Features: Ac12FXzqgGFGjnIiqPWjHgh_1kOiyyOiScnPWDwh8QcQS_x5KY2mxCqP3yYQNKM Message-ID: Subject: Re: August 2025 stabilization week To: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Cc: freebsd-current@freebsd.org, src-committers@freebsd.org, Gleb Smirnoff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.98)[-0.979]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::635:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4cDbTr5Pstz3KDF On Thu, Aug 28, 2025 at 8:42=E2=80=AFPM Rick Macklem wrote: > > On Thu, Aug 28, 2025 at 3:22=E2=80=AFPM Olivier Cochard-Labb=C3=A9 > wrote: > > > > CAUTION: This email originated from outside of the University of Guelph= . Do not click links or open attachments unless you recognize the sender an= d know the content is safe. If in doubt, forward suspicious emails to IThel= p@uoguelph.ca. > > > > > > On Wed, Aug 27, 2025 at 7:26=E2=80=AFPM Olivier Cochard-Labb=C3=A9 wrote: > >> > >> > >> > >> I'm still waiting for our contributions about this stabweek before clo= sing the week. > >> > >> > > > > > > The "August 2025 stabilization week" is now over. > > > > This stabweek has been more challenging than usual, so please be aware = of the following known issues: > > > > 1. OpenSSL 3.5.1: The legacy provider is broken, causing some ports to= fail. A temporary fix is to use `env CRYPTOGRAPHY_OPENSSL_NO_LEGACY=3D1`. = Cf an example of regression in PR/273656 > > > > 2. MIT Kerberos: The default Kerberos is now MIT. Clients should migra= te smoothly, but some scripts may need adjusting. Machines running kdc must= continue to use Heimdal by setting WITHOUT_MITKRB5=3D"yes" in /etc/src.con= f. > This didn't work for me to-day. I got a... > crypto/openssh/kexgexs.c:50 > gssapi/gssapi.h not found when included from crypto/openssh/ssh-gss.= h > > Anyone know where the Heimdal gssapi.h ends up now during "make buildworl= d"? This was something I did incorrectly on the universe system. The build worked on my own hardware. rick > > rick > > > > > 3. Still empty Pkg repo today: The official package repository is curr= ently almost empty. Don't run `make delete-old-libs` unless you're prepared= to build packages from source.=E2=80=AFA bug in the current version of pkg= means that running `pkg upgrade` might result in the removal of many packa= ges due to this empty repository state. > > > > 4. ABI Breakage: A recent ABI change in `setgroups(2)` and `getgroups(= 2)` syscalls will cause some packages to crash. These packages must be rebu= ilt. > > > > 5. ZFS Kernel Panic: We've identified a 100% reproducible kernel panic= when running ZFS regression tests. The bug has been reported on PR/289131.= The FreeBSD CI ZFS tests have not been running for about a month, with the= latest run also resulting in a panic too [1]. > > > > Thanks for your reports, > > > > Olivier > > > > [1] https://ci.freebsd.org/job/FreeBSD-main-amd64-test_zfs/14237/consol= e From nobody Sat Aug 30 15:56:21 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cDfrp4jLwz65hhv for ; Sat, 30 Aug 2025 15:56:42 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cDfrn6Y7Gz3dM7; Sat, 30 Aug 2025 15:56:41 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=XpwnmHin; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-6188b72b7caso3098407a12.2; Sat, 30 Aug 2025 08:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756569394; x=1757174194; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=bRhVvPDV32S0bvrblriQ2wAmOwey7y/+pjjxsZIylbg=; b=XpwnmHinliJkSgSg8XYhSB3YXvSjkkmee5vMfHEScOZMp6ppORjsNrLtSL3Q95CstM KH+ku7UlyBJASqClDIrMixiZrI0I82BTCKEeaJToIP5eTxb0kxP7VXrpXGQcs8A2jvvj XgJ6dlGfRrzCRKLL8CVvpw+yX9v0skMUQVspFW3qpGUtm1P19w4syyJMKpftbKSTMBx+ nlbeMVKqfaw4m6g7L+swuksp49S0VhuL2sQ+IMycCOsDHy7pZ/mZIfmjd6LIbiOg2ex1 CceKAXAFNM9T4+iN8wzsiKzVU2eg6Ltxbilp7ZFRyfKE5j/IVkL/bBzNZPIvSxn/vtwC Ae/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756569394; x=1757174194; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bRhVvPDV32S0bvrblriQ2wAmOwey7y/+pjjxsZIylbg=; b=YwPJaW8annDJnIs3lY21Q+kTNqqbMo3w6lZA4OuIjhzCqQKWTUngLGeZzLXRitWaZg oFPuzH2195KqtmR1fPMcU98c1L3QpO3PsfcSLqVfR6rD49989vhln1S7k8hBCLhNOWPR 5/pygT6YqDxZGn2+kzbqRMVhWzNyKJuD2afiGNQKMnjwvm9qxBiqxRmp6Tv0k7Y8tCh+ lG7Wg6Nz0/rjqgRP2iVJCnBjMtPVxJYfsYSf2kILDqu8ZJPA1x5rEvwSBdGUKenc7NHI NUV9ZSRuYb4QU8gIuaTqWKNi4m8suVLjJHqKApHb+4dKYLGXB/jwAXuuEKw7PQy95h9Y DHhA== X-Forwarded-Encrypted: i=1; AJvYcCUrwf48aKIlXZQHjKv4RpVGTk3TMAys+Isf7JQVaja+fvNWA1xjiOGKo75tVn0UerAkikmcDIV8ntZSedCHeeM=@freebsd.org X-Gm-Message-State: AOJu0Ywx27X2857Kl9ppd1sMpt9qrRZFycM5xlPIDo0CR3SwJJUrAvT4 +GWdUN+2GDkgK4ArugufFo9hsIcR/E9UFA8ffn3c0GIwPmhC+5mhfW1tpWiNE29tncHNvPyt+QX oWqSqO0Z/IYf5oXa15xl8hejhvDCvv4nJ X-Gm-Gg: ASbGncvUOsAf0lIjfKUEtsTK1EuAuPpr3iL/iJfWO0c8WhursJ+6DZY8ekiXWESeLlo ByNsvZ2IGmc0lhnk9Z/tqLuq97zJWmJ3FsaOQ79AEZQTTkffjGfHxNxnDsyfBmqoA1Ttem+R5MK 6MCtk6I/5PXZ4kJ6emWWQLwctrEtcx7JiZ7AfDDLlydgSRi73hvr8D1jXQ2W4EDM6sojmPa8A4j 5wkQEvUVRlOoRagIdxEj4BaRLK/WnyDDrZG1k0h8boQsqQfCQ== X-Google-Smtp-Source: AGHT+IGX2k5N2nBu0+9do8iZX4wfiF/NqE1pQAD64disoZBnTe7ri9U+blJ2xRjjseZGCts6BUQcrCtjSwQ3BE27xCU= X-Received: by 2002:a05:6402:52cb:b0:61d:1a83:8744 with SMTP id 4fb4d7f45d1cf-61d269a1259mr2042254a12.10.1756569393604; Sat, 30 Aug 2025 08:56:33 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Sat, 30 Aug 2025 08:56:21 -0700 X-Gm-Features: Ac12FXxqj-2rqXruukYi94Yjj_bzHJBL4oPJVDLlDamfGhV7pm31L3ee3b4cwKU Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Gleb Smirnoff Cc: Cy Schubert , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.62 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.62)[-0.621]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4cDfrn6Y7Gz3dM7 On Fri, Aug 29, 2025 at 1:05=E2=80=AFPM Rick Macklem wrote: > > On Fri, Aug 29, 2025 at 7:43=E2=80=AFAM Rick Macklem wrote: > > > > On Wed, Aug 27, 2025 at 8:39=E2=80=AFPM Rick Macklem wrote: > > > > > > On Wed, Aug 27, 2025 at 7:43=E2=80=AFPM Rick Macklem wrote: > > > > > > > > On Tue, Aug 26, 2025 at 9:35=E2=80=AFAM Gleb Smirnoff wrote: > > > > > > > > > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff wrote: > > > > > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem wrote: > > > > > T> R> Ok. If you install FreeBSD-13.5 and then "pkg install heimd= al", you get a > > > > > T> R> working Heimdal-7.8 in ports. > > > > > T> R> > > > > > T> R> Now, I have another challenge. Fixing the master passwords. > > > > > T> R> I'll work on it later to-day. > > > > > T> > > > > > T> I have applied two commits from Heimdal from 2012 that add 'ka= dmin dump -f MIT' > > > > > T> feature to our base heimdal and polished them to compile. So = far it doesn't > > > > > T> work yet, either create an empty dump or create a core dump, i= nstead of > > > > > T> database dump :) I'll see how difficult it is going to further= resolve that to > > > > > T> a working condition. If I succeed, then having 'dump -f MIT' i= n base without > > > > > T> any ports would be the best solution. Can also be merged to F= reeBSD 14.4. > > > > > > > > > > Good news. In the above paragraph I was testing my change incorr= ectly - threw > > > > > the new binary on a system running unpatched libraries. When run= correctly, > > > > > it successfully produced something that looks like a correct dump= in MIT format. > > > > > I haven't yet tried to load it into MIT kdc yet, though. > > > Oh, and one more thing... > > > - If there are keys for old encryption types like des.. or arcfour.. > > > in the MIT dump, > > > those will screw up the load. (You can check and delete them in the > > > Heimdal-1.5.2 > > > kdc system via.. > > > # kadmin -l > > > get > > > - if old keys are listed in Keytypes: > > > del_enctype > > > exit > > > > > > Ideally the conversion code would skip over these and not put them i= n the dump. > > > > > > rick > > > ps: If you don't do this, when you "get_principal" in kadmin.local on > > > the MIT KDC > > > system, it will give you a "Database record is incomplete or co= rrupted..". > > > > > > > > > > > > > I will finalize the branch promptly and share it. The above expe= rience also > > > > > indicated that I need to do a library version bump. > > > > I don't know if you are enthusiastic about pursuing this, but hopef= ully this > > > > works and gets the principals in (although I doubt the passwords wi= ll > > > > work without changing them). > > > > > > > > To get the passwords to work, I think the following *might* do it: > > > > - If you look in the Heimdal sources, when "--decrypt" is specified= , > > > > I think it finds its way down into a function called hdb_unseal_k= ey_mkey() > > > > which decrypts the key using the master key by calling _hdb_mkey_= decrypt(). > > > > To get the passwords to work, I think the call to _hdb_mkey_decry= pt() would > > > > need to be followed by a call to _hdb_mkey_encrypt() with the "ke= y" > > > > argument being the master key for the MIT database. (It it a keyt= ab > > > > entry called /var/db/krb5kdc/.k5.YOUR.REALM created when you do a > > > > "kdb5_util create -s" on the system that will be the MIT KDC.) > > > > - Just to make it even more fun, there is a flag called HDB_KU_MK= EY > > > > which is set to the Heimdal way and not for the MIT way (whatev= er > > > > that really means?). > > > > - There is also some stuff about padding in hdb_unseal_key_mkey()= , > > > > but hopefully that won't be a problem? > > > > > > > > I think hdb_read_master_key() can be used to read in the MIT master > > > > key from the file you provide as an argument to it. > > > > > > > > This all is just a hunch, based on what I've seen so far. > > > > > > > > I'll admit since the hardware I have takes forever to "make buildwo= rld" > > > > and I don't know a quick way to build/test these changes, I'm not > > > > inspired to try it. > > Although not inspired, I have taken a stab at it. > > I am still trying to figure out how to build/test it, but I have forked > > glebius@'s github and added some code to... > > - Not dump the weak encryption keys (they just cause MIT's kadmin.local > > to complain that the principal's database entry is corrupted. > > - If the argument to "kadmin -l dump" is "-f " ins= tead > > of "-f MIT" it re-encrypts the keys in MIT's master key. (I hope that= will > > make the passwords work. > > (Basically, someone will "kdb5_util create -s" on the MIT KDC system > > and then copy the /var/db/krbkdc/.k5.YOUR.REALM file over to the > > Heimdal KDC system and do "kadmin -l dump -f <.k5-filename> mit.dump= " > > then copy "mit.dump" over to the MIT KDC system and > > "kdb5_util load -update mit.dump". Then, hopefully, the principals w= ill > > work??) > > > > Anyhow, it is currently sitting here: > > github.com/rmacklem/FreeBSD in the kadmin-dump-MIT branch. > > (I'm as unconversant with git and github as anyone, so if you have > > trouble finding it, just let me know.) > Actually, it hasn't made it there yet. For some reason (I think it is > glebius@s large # of branches) it takes a very long time to "git push" > a patch involving 4 files. It failed after over an hour with an unexpecte= d > TCP disconnect. I am running it again. > > I will stick the patch here, in case the push fails again. > (It needs to be applied on top of glebius@'s kadmin-dump-MIT branch. The patch is here. (For some reason, I couldn't push so I deleted the github fork.) https://people.freebsd.org/~rmacklem/kadmin.patch I haven't yet been able to test it, but will be able to do so later to-day,= rick > > Meanwhile I've given up trying to build it on a universe system and > an now trying the "make buildworld" locally. This will take days, > so I guess I'll go do something else.;-) > > rick > > > > > I'll keep updating this github fork as I get to test it, but if others > > know how to build it, feel free to test, rick > > > > > > > > > > rick > > > > > > > > > > > > > > -- > > > > > Gleb Smirnoff From nobody Sat Aug 30 19:36:20 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cDlkW4fLtz664X4 for ; Sat, 30 Aug 2025 19:36:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cDlkV6swYz41NK; Sat, 30 Aug 2025 19:36:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=AR+UT7PZ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of adrian.chadd@gmail.com designates 2607:f8b0:4864:20::736 as permitted sender) smtp.mailfrom=adrian.chadd@gmail.com Received: by mail-qk1-x736.google.com with SMTP id af79cd13be357-7e86faa158fso331542285a.1; Sat, 30 Aug 2025 12:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756582592; x=1757187392; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=91pp2zzq4OSJnpNr4p6GggJYeZPzsg5qZZE39YDJ86s=; b=AR+UT7PZZ9IrecPBzppB0sKmllpnfr8rrqye0Vqe2m6BZsqMIeG5bAlc5MDKZ/E/Sl x4cOCu778GY349tocjYt0ywMpX4WpTDDnr8ut5tkMoCzPRIpx9Djl9tSSCdrJsdOcX6G GO9lZ/uH/8/6Dp15NKUcUxQY3TJ1NgTmUurv5z5Hlrvx8CeLgvcqE83gNpzDvy80h2ES JAIgogv6z9oyCUV26dG0sQQGPY+S0DBrcvuClFkN0tD+FKOxya21+pJYIVq5kWAVWybu gzQ3JJV32G3/tFqpoNN/KWz5gcDugL7Mqlo7x+zEFUubAMVnId6mACjOBxqcznusfhQ3 Wc9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756582592; x=1757187392; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=91pp2zzq4OSJnpNr4p6GggJYeZPzsg5qZZE39YDJ86s=; b=UVIwgfwIYX62kYve/1LEdlTsVowhkZmDZCa0WVRM31cTcUd6+8HYpR82Byk+h9hsL6 lA55khaiF6gJCuIYFsQspFLofiOR36GaAFomEDsWUaoUZ2dC63SpAS22r2XNu+P3QrTi cDN/Cz1SB+GsQKQAvIkBQTR2iRcKk2+KS0OVIBUubmp1HyHqXKEEifcZ+/A415Z68Hr1 iBDh16dOc/ZcK3Yx0+kq/MwNgC9bru9R7FF+dt6BugW/0MoW7577JG7VzHba3Z3hx+F5 SvIeWrllMfvXgz9g9dz++GqBcpJNbaepp+7nBYGYi6PK8n8RU3umfFLctAkz9S2C8LMl lz6A== X-Forwarded-Encrypted: i=1; AJvYcCUt5nvPjXg1su8tF8vIjr+njU3M/Ra8d0h9QLPtYiJCwB/QeAthbxLRNe+WEFwdkRI/JPpFnfVDxS4s45CD3Lo=@freebsd.org, AJvYcCVpoLDUyoIIYzaJjMa8NxoJxIZ+x+Gre3/rFynN04jIeK2RPrRJ6PpVrqje890yJkkda3VV16AHTg==@freebsd.org, AJvYcCVyGycfF2EcCbBgl+cKgIg6N1Q4D8LXikrHC2AjNsunKziN9hf3EqA0weT9LnTiAWHjQFaGJP8g/IjXcSoiBBw=@freebsd.org X-Gm-Message-State: AOJu0Yzh1FKxTJpSsgv1Orx6v+OaeUIAXPM/IpTbPrfKKmFz8MvRYD2R BHCdc98yueyYu/PtCgIayu4xC4+NnnoxKXAiC63J8tXHZ1GsEcrrDpfoKXQYUULpNe1WzMhLQ7s S/gRhiIvHpppT5zEyAqvAN6rqxbDHIk7LBg== X-Gm-Gg: ASbGncvD8QWABWOLqJ5fGCbt0GYgQSK8NqMl6iBoRuxqFF/2rXDSmIkuCqfBKQ6YqRn MrG454Z5/AphtDFqBRWtlToC9k/vQSqckonx/7WwmgJPsTnujFUk6TpT021rMCrFs0IkkQBiDEI zQOSnxoG9Ssg55LAgvykNbfPFzO+JBNHyPoI6BH4Rd4r1Xo/MBnX6cYy4REUKw3OeLUlsBKAs+W +ES0A== X-Google-Smtp-Source: AGHT+IH+sxBndbIQvrhIMZkzJtYzhknPVISwbbHg9jzYEEU12RAMYmmjwEDyUqlmpqc5okLr8CykzgpNC0yTWxx570o= X-Received: by 2002:a05:620a:7118:b0:7e6:9993:b34e with SMTP id af79cd13be357-7fed6bab62dmr338881385a.33.1756582592268; Sat, 30 Aug 2025 12:36:32 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <202508290546.57T5kmm4004504@critter.freebsd.dk> In-Reply-To: <202508290546.57T5kmm4004504@critter.freebsd.dk> From: Adrian Chadd Date: Sat, 30 Aug 2025 12:36:20 -0700 X-Gm-Features: Ac12FXxC97VZpFVPln8HwMHrj4UqP69aO0FqEOEapslgb7kDSw17X7q2hlOebdA Message-ID: Subject: Re: August 2025 stabilization week To: Poul-Henning Kamp Cc: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= , freebsd-current@freebsd.org, src-committers@freebsd.org, Gleb Smirnoff Content-Type: multipart/alternative; boundary="0000000000006e4f2e063d9a4172" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.988]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::736:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4cDlkV6swYz41NK --0000000000006e4f2e063d9a4172 Content-Type: text/plain; charset="UTF-8" do you have "works" and "doesn't work" commit hashes so we can compare? -a On Thu, 28 Aug 2025 at 22:47, Poul-Henning Kamp wrote: > -------- > Poul-Henning Kamp writes: > > > The only thing I have noticed on my laptop was one time where the USB > > ports did not work after resume, but I have not had time to experiment > > further. > > I had a bit of time yesterday, and I can confirm that the USB-A port on > the right side of my T14s does not work after suspend/resume. > > The USB-C and USB-A ports on the left side of the computer does work. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > --0000000000006e4f2e063d9a4172 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
do you have "works" and "doesn't w= ork" commit hashes so we can compare?


-a


On Thu, 28 Aug 2025 at= 22:47, Poul-Henning Kamp <phk@phk= .freebsd.dk> wrote:
--------
Poul-Henning Kamp writes:

> The only thing I have noticed on my laptop was one time where the USB<= br> > ports did not work after resume, but I have not had time to experiment=
> further.

I had a bit of time yesterday, and I can confirm that the USB-A port on
the right side of my T14s does not work after suspend/resume.

The USB-C and USB-A ports on the left side of the computer does work.

--
Poul-Henning Kamp=C2=A0 =C2=A0 =C2=A0 =C2=A0| UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| TCP/IP since RFC 956
FreeBSD committer=C2=A0 =C2=A0 =C2=A0 =C2=A0| BSD since 4.3-tahoe=C2=A0 =C2= =A0
Never attribute to malice what can adequately be explained by incompetence.=
--0000000000006e4f2e063d9a4172-- From nobody Sat Aug 30 19:41:26 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cDlrG6sY9z664rj for ; Sat, 30 Aug 2025 19:41:34 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cDlrF3hmBz42Sl; Sat, 30 Aug 2025 19:41:33 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 4D379C43AD; Sat, 30 Aug 2025 19:41:26 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 57UJfQBv003111; Sat, 30 Aug 2025 19:41:26 GMT (envelope-from phk) Message-Id: <202508301941.57UJfQBv003111@critter.freebsd.dk> To: Adrian Chadd cc: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= , freebsd-current@freebsd.org, src-committers@freebsd.org, Gleb Smirnoff Subject: Re: August 2025 stabilization week In-reply-to: From: "Poul-Henning Kamp" References: <202508290546.57T5kmm4004504@critter.freebsd.dk> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3109.1756582886.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sat, 30 Aug 2025 19:41:26 +0000 X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FREEFALL_USER(0.00)[phk]; MIME_TRACE(0.00)[0:+]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; MISSING_XM_UA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DMARC_NA(0.00)[freebsd.dk]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4cDlrF3hmBz42Sl -------- Adrian Chadd writes: > do you have "works" and "doesn't work" commit hashes so we can compare? My previous kernel, where I am almost 100% sure it worked: FreeBSD 15.0-PRERELEASE #2 main-n279689-c04fe26aa2f7: Mon Aug 18 20:14:08= UTC 2025 My current kernel where it fails is: FreeBSD 15.0-PRERELEASE #3 main-n279849-49ae0c259205: Tue Aug 26 05:41:2= 8 UTC 2025 -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Sat Aug 30 20:16:01 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cDnB864Jbz669T0 for ; Sat, 30 Aug 2025 20:42:08 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta004.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cDnB83hgBz47NW; Sat, 30 Aug 2025 20:42:08 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTPS id sLPbuTfp85MqysSOlupJuf; Sat, 30 Aug 2025 20:42:07 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id sSOjudthPJhBPsSOkuo7or; Sat, 30 Aug 2025 20:42:07 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=QY3Fvdbv c=1 sm=1 tr=0 ts=68b3621f a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=IkcTkHD0fZMA:10 a=2OwXVqhp2XgA:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=YxBL1-UpAAAA:8 a=4lFl-uwwPQ0RuP_v9YgA:9 a=QEXdDO2ut3YA:10 a=zZCYzV9kfG8A:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from [127.0.0.1] (unknown [209.52.88.212]) by spqr.komquats.com (Postfix) with ESMTPSA id 429D215A; Sat, 30 Aug 2025 13:42:05 -0700 (PDT) Date: Sat, 30 Aug 2025 13:16:01 -0700 From: Cy Schubert To: freebsd-current@freebsd.org, Poul-Henning Kamp , Adrian Chadd CC: =?ISO-8859-1?Q?Olivier_Cochard-Labb=E9?= , src-committers@freebsd.org, Gleb Smirnoff Subject: Re: August 2025 stabilization week In-Reply-To: <202508301941.57UJfQBv003111@critter.freebsd.dk> References: <202508290546.57T5kmm4004504@critter.freebsd.dk> <202508301941.57UJfQBv003111@critter.freebsd.dk> Message-ID: <5D8A52A1-4F88-4806-A7A1-988F1EF2C5AC@cschubert.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4xfLjMdN3I13ZiIiU/SJFBdOuumM62e6qtmEm+dwyTkqaE1OpO/RPrn0fFA7TIflnw6Z6hWe60tKH5J4IWTZrW1EwSuO0kfh7xZVTZeXvj5LDN4QNwJ4Ed DxzzJTDE073Gy+JLKvuWlPLqZHOMOP1hXtQWYQY6qjoYGZCAI3CIixoq6VVaR2y2s0mttBACg5pYQpgdcoUyk7gvtGocTB52hLpj20Yzu9dEv2pKn60qaGgc qoHIJukRXoP6Gi05K+4uBaC6IgSrtg+IPPHaPODPgTQdFVerMn89ax4gCwyHHPgQJvyxvOrc8QAzKAobCY2Y6DUGBfpt6pdi9k9t5zbuVVAogdIcm9Voveeo wZ4AvCx4SLxS9arlJJhb+NXlQ/UgOQ== X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cDnB83hgBz47NW I'm on my phone, I don't have access to the commit hash=2E The patch(1} com= mit broke make patch for some ports=2E You can verify this in devel/qt5-ass= istance=2E --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD=2Eorg NTP: Web: https://nwtime=2Eorg e^(i*pi)+1=3D0 Pardon the typos=2E Tiny keyboard in use=2E On August 30, 2025 12:41:26=E2=80=AFp=2Em=2E PDT, Poul-Henning Kamp wrote: >-------- >Adrian Chadd writes: > >> do you have "works" and "doesn't work" commit hashes so we can compare? > >My previous kernel, where I am almost 100% sure it worked: > > FreeBSD 15=2E0-PRERELEASE #2 main-n279689-c04fe26aa2f7: Mon Aug 18 20:14= :08 UTC 2025 > >My current kernel where it fails is: > > FreeBSD 15=2E0-PRERELEASE #3 main-n279849-49ae0c259205: Tue Aug 26 05:4= 1:28 UTC 2025 > From nobody Sat Aug 30 20:45:26 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cDnG255xSz669tM for ; Sat, 30 Aug 2025 20:45:30 +0000 (UTC) (envelope-from ivy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cDnG24P3Nz49Th; Sat, 30 Aug 2025 20:45:30 +0000 (UTC) (envelope-from ivy@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756586730; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wB/7KavYYRqCNuF6GA1OdJDseD6lQzyL+f15zl5s9eQ=; b=SGAAvgbQ18hItjKTuAtrD6K4TC5NAzfsRZLtRhNGfdkBv9J9xYj661ni+bz78Luvn+0p1M YdoDh5CV5gTy55ib9V30SP50eaFtTzZLfAGrSqGoT6h8h2xtjk8ZCxr5DqSOTILlitTxZt Id3rjnLA+xowAkKC0k3ibmuKJ3acXuCDmbNQ/HxhMNV20LQ1yjr+/oIcZH/OOw7lKJmAM4 ZNHmR5+q4b6wtDi/Sqdzgy6v9bzl4Q8wrXQa/7YB+5pbvwtQLQ//YO+IJhVGXKnsCRPskD KAIkZGqbhZtm5dX5mOaZKm/2gZXztj7wDVY/IOMuT973DYyLr83TFrOgadkHLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756586730; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wB/7KavYYRqCNuF6GA1OdJDseD6lQzyL+f15zl5s9eQ=; b=TMXN6BNh6VUdAqjI1FLap3zFUdVxg9uiAhqWbb6DjURsqWiT5LJpUDaudrvL/+6tsLDCtn uFgJeh7HxJ08u9fGSCFY0u3YJQilVrhA55PuT2Hh7fQEJ6ynPZfR2qAt3HzVCn2kooVbhN njxS7nEjiBTeJvED+UErqOMBFnNOqWqGqcEhajnOG3h7NN7J4Ktn7nTJOP+ofin5iuwTfC ZGAR2yetpcJ2RYmMvgi0nn3AfQyqCvHqbdUYOLdRAnGaVMTYvH6ee2QnL99TO3jqxhU1zl y2h0MYCpoVFC4laLs1ONfTzZr5G5ALc5IkDUCvR6zFVhkMi/YNQl0viKRBzReQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756586730; a=rsa-sha256; cv=none; b=SfN1ez6RPJus1yBjTlEqJQ4FvTqKc6wPd+xDtiAuIOpVNm9yJzcA2nCndKsmAUZKRBh6Lu i6f6rlj6qJ1G7tV9atPtxo1Pi8CD9WT5wKnOobeSWGTAG3ouZrZOvtOlybP9lLnzOsqUvh 2ysFA1bRz1lebYp8Yqa4pheXTc1+DY7l2glu0RJ3r3fcMiTG2iF+r7QK2Em1JM2GXDpXP6 5pxzRtCsLW5R83iLS+hu4a2zUeg65id1nTRSWtcxW9xR6YjJVcTr8EiLIe46GJHubuSfsS jx1r1GN6Dy8JLHhSdsc3giu7C9UJvV6/knRqYb5zyjwX7PuARIFwvfztpm1lMg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from amaryllis.le-fay.org (amaryllis.le-fay.org [IPv6:2a00:1098:6b:400::9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cDnG21Nqtz17hq; Sat, 30 Aug 2025 20:45:30 +0000 (UTC) (envelope-from ivy@freebsd.org) Date: Sat, 30 Aug 2025 21:45:26 +0100 From: Lexi Winter To: Chris Torek Cc: freebsd-current Subject: Re: a few observations with 15-prerelease as of early this week Message-ID: Mail-Followup-To: Chris Torek , freebsd-current References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="L3wf1tf/bQhmqupP" Content-Disposition: inline In-Reply-To: --L3wf1tf/bQhmqupP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Chris Torek: > I ran into the libcurl issue and had a heck of a time rebuilding > it with the krb5 changes and "git fetch" failing, but a quick > temporary update of the curl port to disable gssapi entirely got > past it. :-) assuming you have an up-to-date base system and ports tree, building curl with base (MIT) Kerberos should work fine. if you were unable to build it, please provide more details. --L3wf1tf/bQhmqupP Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaLNi4gAKCRD1nT63mIK/ YP1+AP9JPesVsEDDGbZwTdfm+/XizXfZErfc0RBco+IA0tNhuAEA//LsCdTMXzt3 V0g+j2JNVcdq20GzsE7lxI+XT7+gOwU= =SNr1 -----END PGP SIGNATURE----- --L3wf1tf/bQhmqupP-- From nobody Sat Aug 30 21:35:21 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cDpMx6JX0z66FyQ for ; Sat, 30 Aug 2025 21:35:41 +0000 (UTC) (envelope-from chris.torek@gmail.com) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cDpMx0P1Dz3G9b for ; Sat, 30 Aug 2025 21:35:41 +0000 (UTC) (envelope-from chris.torek@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=PXoN188n; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of chris.torek@gmail.com designates 2a00:1450:4864:20::12a as permitted sender) smtp.mailfrom=chris.torek@gmail.com Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-55f6f434c96so982793e87.2 for ; Sat, 30 Aug 2025 14:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756589733; x=1757194533; darn=freebsd.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=MDhSVmu55jxw0ee84n35zTQekv/n+UOBPfXdQ8MYNh4=; b=PXoN188nqVRgBvbNo/Hsz9b105C2KNXH1o3w6mRzt9N9BuOIjXT6sUYiyRE4DLT2pJ 6QCV19YFxOa/j2+WVEUgA5SDb39R0eZ6yGZSwA++lv4qPHsoedq1T9uEmkN9ti8DPF4I +a7rWh8iq7wldB7clPUTZr8XtH4CAmSzXXLJK296FMvNyNP4OPTUYCvScNDIEeIh9vTA I1NiSP6fbKp+34UZQ36LDsQZ5F0bWOUMkYs2hHYKLNJx7n7JrivWZr8A27+v0MOUFwDI 5+RONef2jsS78JRIv3gWVbkVbvr+XLqanbY/QnzU5dp4nvn/YfmOgC/ImZpNf/u8U0bb USOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756589733; x=1757194533; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MDhSVmu55jxw0ee84n35zTQekv/n+UOBPfXdQ8MYNh4=; b=oq+o7CcQ9taTrOMlZONd/c+XUThD5GcJ/T7z/zQZxmP/zr1yUMPrtJ3fNSvzeU84hT UqzkkOM6YRSSjptvIp0FmfslykocD3ipgjRca/0xlI/FZgcAYNl9xC0XtLuYbhjchi0T Hw63w1ykAvjLF2c3BzepoYm2g/5EcNV3w7JH/KGYyBzo/HKdx7e1PS9c9FSZJehGfIFi zr7uylDTZkWafxdwkjekeYmRQRl1TvSBH/ylHFfUCRUjRbXT2yC0UbakjJXM8rXYMrjb JjqrBbH1aRnO3yeL50OpT7Vx13FpgfiQfx3V8OeQxSYTmYUmYxR4KT0bEa0PAZpYgEO/ RFhQ== X-Gm-Message-State: AOJu0YyTJ7fM8vw6jKjBFlIgIWqj99/LnpJdTsbiqbMHn7IhhmMDe7IS iY03LYuJ/V1tSuH69rlzHrBXqznIWTyy+JMo2kNbq5040uSWp7jk72EuH9LBi3yIJur/AI+NfXv n1MMmeMw1mVSO/vg6kzI/B1bn+CeMfbXE9zfS X-Gm-Gg: ASbGncvv89039nFP7hSadhB4B2DYMCDZKZq6rOQ8VLmv5u052APJIyf37G25Tv8aKVq /D81UsaI8vfaS3p94/iLs7dScGxxVNwQLoizI5CFAsfsZ3SeOkz0JrGTHhGHAaCSM5wnTNP4X0a NiB68wQjLEoflAQ013/SHl/sZtSKIflltdQY140yFplwqSZbow+mDkLyiI6IFmR7G/X54C1wApx t9enLik7/52K7DYL9I= X-Google-Smtp-Source: AGHT+IG9u6t6TMMQxUAmrry+0rkNzZGIRORrX5m2HgU5QLM/h6ZtKADdJfvt460z9kAShY5WnULX+wqTpW3Rzh61SH4= X-Received: by 2002:a05:6512:2392:b0:55f:6d59:d068 with SMTP id 2adb3069b0e04-55f7089c57fmr798110e87.3.1756589733027; Sat, 30 Aug 2025 14:35:33 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Chris Torek Date: Sat, 30 Aug 2025 14:35:21 -0700 X-Gm-Features: Ac12FXzc8OlD18B9JVZKvBkoGD4w73u9WeDAjcI1OcJl_JSyUYV6BKwaVKuGUL0 Message-ID: Subject: Re: a few observations with 15-prerelease as of early this week To: freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12a:from] X-Rspamd-Queue-Id: 4cDpMx0P1Dz3G9b On Sat, Aug 30, 2025 at 1:45=E2=80=AFPM Lexi Winter wrote= : > assuming you have an up-to-date base system and ports tree, building > curl with base (MIT) Kerberos should work fine. if you were unable > to build it, please provide more details. Oh, it was already fixed in ports (your commit d30d5dfae), I just had an out of date ports tree at that time. To update it I needed to run "git fetch", which needed the new libcurl, which, etc. Rather than haul everything back to the previous zfs bootenv, I just hacked the curl build temporarily. I'm more interested in who to talk to about the amdgpu / drm module stuff, which I'd like to get working on this machine. My current choice is between 10 minute builds (the fast machine) or 10 hour builds (the old box). The new box stays up if I don't use the console for X11... Chris From nobody Sat Aug 30 22:03:53 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cDq0W6nhtz66Hxk for ; Sat, 30 Aug 2025 22:03:55 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cDq0W6Df1z3KJV; Sat, 30 Aug 2025 22:03:55 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756591435; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=b+W/YTbcVz2q3lUBTvvGkVJupSJjt0FZwJj7Hq7MuwU=; b=MP3WoJWZtiCL90TZTCFzBJ32EQNnsxVPvjv6P3qJqy+fxAYDoERt64q25+OXsd6iyH/kJ0 Rglwhhs9HMfvUrmF40254RLjPK9loWEO+QvU8TwL8bxTYePfyhBmgtaMClYTXco2ceETKB +Opvwqtk7b92K2qzFMMXP4ugpnkMMGq3o2N1r7CmHTov+vl8bp9e4JJJcJ11L4ePK9QxjJ HablioSK56SvcK02QjqNBB+pKowP1GJht+kTSR6OAC8JLfPHvEooRithEVKY5rkU8ulcV3 9okBMTJRrnSnEfTQZbbkNX2XLzThGtgxsYAxsAAr2OJv1l+RDyHQINkl3u+zrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756591435; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=b+W/YTbcVz2q3lUBTvvGkVJupSJjt0FZwJj7Hq7MuwU=; b=cwYSpwQQIcMnWmhxgoNI56KqUWNzNQ3pj+iwzxmZhr5IqCzm4qOrH5M3Uie4z4ddpaeAQg 6ODiJatDh4gbw2TZsNDAiRxyfak5j4HX+Zq1kqaSKQsqXMlHx4ViMHklTfwxHDBG6Vljaf jhlmlvgc28TKxk9Y+43vdE8dMEMq+UVgEt6QmOG1x92OOfQW3W7oQkCGFQpvF7bttZdVQN /NptlP/KmI+ytx1S7le9008HnQVUVWIrSKqqEEBWLG0tgEGnHY4PoMWu3Y7ozzVzZb6Oz6 8QE4EdQhD+qXHBsQSl1QAEf96um5rQwI/qmmTsSA/aQio7O+gOYr0ror5X7WMg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756591435; a=rsa-sha256; cv=none; b=NvjfCcyLCqJYy2L5vF8NEEqLvX1x+uong9Piu9fpEfE0/PyXh5tFHG3nmx0xZnem6bt4LH 9uRcZ09a5jn4EZjCj5ZEuJdMCren/n2lx+LyQbMKXdcMCIe7bQQA5NYhnKK9hVmZ+sQIAw fBQPS0Yc84+lLopmvV14Am424fcH1ZBtrb7+BCdtymV3h2/+07s04oF1EviIvyE7miz81Z BXsWG0g2P8yIVNtnMguE91tscz4b+mffbkzjqhe2Q1HHUqnVLf3IV2nvALr+LQ0b7CKDji W4ZuL0NWplZtAvQHqSTmf18kNgzX9AOVObHFRWIwjI0WReqbUzPGMQUVt+shvQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cDq0W0L2rz187Z; Sat, 30 Aug 2025 22:03:54 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: Date: Sat, 30 Aug 2025 17:03:53 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: August 2025 stabilization week To: Cy Schubert , freebsd-current@freebsd.org, Poul-Henning Kamp , Adrian Chadd Cc: =?UTF-8?Q?Olivier_Cochard-Labb=C3=A9?= , src-committers@freebsd.org, Gleb Smirnoff References: <202508290546.57T5kmm4004504@critter.freebsd.dk> <202508301941.57UJfQBv003111@critter.freebsd.dk> <5D8A52A1-4F88-4806-A7A1-988F1EF2C5AC@cschubert.com> Content-Language: en-US From: Kyle Evans In-Reply-To: <5D8A52A1-4F88-4806-A7A1-988F1EF2C5AC@cschubert.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/30/25 15:16, Cy Schubert wrote: > I'm on my phone, I don't have access to the commit hash. The patch(1} commit broke make patch for some ports. You can verify this in devel/qt5-assistance. > This seems like an odd sub-thread to drop this in, was it supposed to be in response to the general stabweek e-mail or is there some other context that might be helpful? Looking at devel/qt5-assistance, *sigh*. Our fuzz implementation is too naive and needs to learn that it can do different before/after fuzzing, I guess. Reverted in fb37e38fbe99039a, sorry about that. I'll request an exp-run when I revisit it later. Thanks, Kyle Evans From nobody Sat Aug 30 23:22:58 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cDrm76gQYz66PfD for ; Sat, 30 Aug 2025 23:23:19 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cDrm65sXwz3SBV; Sat, 30 Aug 2025 23:23:18 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=b76kkLf4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-61a8c134533so6043919a12.3; Sat, 30 Aug 2025 16:23:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756596192; x=1757200992; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ZTncibX4S4ycd2RnuFD+DonsW9Byr1m/HiU1C+avqHU=; b=b76kkLf4+7d5op5afBoufGMiiuNYjJoLqhDWu1TWfzhCUTtkLvCiF8nsav2PCe25qa /t5TniA5BXKv4OPppGPfNvWkPe8E7jrm1i78QDPDPsDwC/ggtg+K2XwYBI6J/T+3zwxw h6qeZSJvHdOk6nHRA/xwC1TWhrbLQcpRAu7QGwUD5h47ygSqfmAYBcIRcmtoNmurGaGh 0DtpcsZZL6bjA5RYMrXSms/J0f3kBXIIVmcJpjyJDQl92Hp4rGKSTW6up3l7dIPB/7dF xW15fLGmQtmaOXFUV6zU1PPY82qDJGIG3qpq79AHPuU4pVb9EG8s1MyidB1rpxfQhmOf wK5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756596192; x=1757200992; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZTncibX4S4ycd2RnuFD+DonsW9Byr1m/HiU1C+avqHU=; b=r5UPyGQV8ngyqkJPrHRbM/TOmxjBEkduWhzJHpM2KYkcBHaGGsehuqSn++1gJhHPkp u/DtiFy4W1nlEkFhLmxFsgsg0ReSy+z3EgUyPqfRJ5UUTdVlvH503W9J4U5wQjLvxbRo cJWmAFntFaIEenwWhIi/xV8WeiqeyqBxn9CGtz89CqThjY+6UGyt/JP1z0Pdi4Orom1X uO8nMOIvWiw7s4r4FwwFnm0u06apmKK6+u8P96hXsTXaEpcsCEtIP28ccA4ZmV1qQmCm OncYmhbWPmVD9sxMoEGVv0GyeJg3qQSqu0X7HFNPo/2Dtp51N4qumyPf4ZBBTR6cdxpq SU4Q== X-Forwarded-Encrypted: i=1; AJvYcCXGvJWeZqAy5lXqqUCW+LUK0r3/NH/93L8zTFda3WuZigzl9zsJtRMbpZMn0fxzYv5HT8KiY/WWSHAo3pIE2Xw=@freebsd.org X-Gm-Message-State: AOJu0YzfJ84pLLly6L0UiLu4tskc2ES/sTemuAjKBVHuuRKjIZCrnAsU L7QdOEApxBaohEoxhCE8VWol+5ZIJWWSwYT1CLSlqPueTYWZ8QyWV31H1Qsdnuf035CwfjrxRk/ KgeXziI/rVlCn8LHUwa3/036I4UyPECQlD3g= X-Gm-Gg: ASbGncvsIA4JqkND9VtIb6ybxNA//Uz0knP6/eS2QrpFKw4C4RF5JxC747hH9Z2assW o0bQaFFS1slQAyxugEUrLhUvRDNCIZgKShjYO8OpvjT0wKUW3mkvkNY7ED0fFT4NFBVZKsrv3XU qrxDMy37EBqUujXSuv917tv4mCZMzFOanP7PQNKsdkTS/7fYly2jDHcc3NC6WPH+Xh8/5ilTGVc z5QvVSIHCUk0DgwSkK8Wg2oZUOJ1aAWYrmMYzZCOJ+DkJt1Ww9G8bZTBFE= X-Google-Smtp-Source: AGHT+IHjFfmuCi6/LYzpb4aC5mGzN5mXjdHAtkoJLe7p62jPZM0WD7Cc8AY9+gh0sNHAfFXeC6i5dZlb0gPcVYEQRV8= X-Received: by 2002:a05:6402:3881:b0:61a:967f:55f9 with SMTP id 4fb4d7f45d1cf-61d26bfd42dmr2877968a12.10.1756596191297; Sat, 30 Aug 2025 16:23:11 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Sat, 30 Aug 2025 16:22:58 -0700 X-Gm-Features: Ac12FXwdG0K3vDdYKRm41YzYDVY6aFFiCovRSGzCAJ2giNfEPuDpGLb_Oi0ul6w Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Gleb Smirnoff Cc: Cy Schubert , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4cDrm65sXwz3SBV On Sat, Aug 30, 2025 at 8:56=E2=80=AFAM Rick Macklem wrote: > > On Fri, Aug 29, 2025 at 1:05=E2=80=AFPM Rick Macklem wrote: > > > > On Fri, Aug 29, 2025 at 7:43=E2=80=AFAM Rick Macklem wrote: > > > > > > On Wed, Aug 27, 2025 at 8:39=E2=80=AFPM Rick Macklem wrote: > > > > > > > > On Wed, Aug 27, 2025 at 7:43=E2=80=AFPM Rick Macklem wrote: > > > > > > > > > > On Tue, Aug 26, 2025 at 9:35=E2=80=AFAM Gleb Smirnoff wrote: > > > > > > > > > > > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff wrote: > > > > > > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem wrote= : > > > > > > T> R> Ok. If you install FreeBSD-13.5 and then "pkg install hei= mdal", you get a > > > > > > T> R> working Heimdal-7.8 in ports. > > > > > > T> R> > > > > > > T> R> Now, I have another challenge. Fixing the master password= s. > > > > > > T> R> I'll work on it later to-day. > > > > > > T> > > > > > > T> I have applied two commits from Heimdal from 2012 that add '= kadmin dump -f MIT' > > > > > > T> feature to our base heimdal and polished them to compile. S= o far it doesn't > > > > > > T> work yet, either create an empty dump or create a core dump,= instead of > > > > > > T> database dump :) I'll see how difficult it is going to furth= er resolve that to > > > > > > T> a working condition. If I succeed, then having 'dump -f MIT'= in base without > > > > > > T> any ports would be the best solution. Can also be merged to= FreeBSD 14.4. > > > > > > > > > > > > Good news. In the above paragraph I was testing my change inco= rrectly - threw > > > > > > the new binary on a system running unpatched libraries. When r= un correctly, > > > > > > it successfully produced something that looks like a correct du= mp in MIT format. > > > > > > I haven't yet tried to load it into MIT kdc yet, though. Well, would you like the not so bad news or the bad news??;-) Your patch works, in that it produces a dump that "kdb5_util load -update" can load. After loading, if the principal only has keys for the newer encryption type= s of aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 then you can look at the principal via kadmin.local, but the password must be changed before it works. --> This is the same behaviour as you get if you use Heimdal-7.8 to do the dump conversion. So far, so good... Now, the not so good news. Once you update the Heimdal libraries (libhdb.so and libkadm5srv.so) "kadmin -l" is broken on the system running the old KDC. "kadmin -l dump" works, but something like: # kadmin -l kadmin> get rmacklem kadmin: get rmacklem: Service key not available - I have not yet looked in your patched sources to see where this failure comes from? Now, more not so good news... My patch doesn't help. It does re-encrypt the key in the master key from the MIT KDC system, but that doesn't make the password work. When I compared the dump generated via kadmin with both your patch and mine, the key for aes256-cts-hmac-sha1-96 is 34bytes long. After doing the change_password so that it works, a dump generated by "kdb5_util dump -r13" (the same dump format) has a key that is 62bytes long. --> So, there is more to converting the key than just re-ecrypting it. (I'll try and find where the MIT code encrypts a key in a master key to see why it ends up at 62bytes and whether that can be done in the old code.) So, if we are going to continue with this... - We need to figure out why your patch breaks "kadmin" for other things and fix that. - I/we need to figure out how to convert the 34byte key to the MIT 62byte key (and then maybe the password won't need to be changed?). Or do we just say "When you convert the KDC database, all the passwords must be changed to get them to work?". rick > > > > Oh, and one more thing... > > > > - If there are keys for old encryption types like des.. or arcfour.= . > > > > in the MIT dump, > > > > those will screw up the load. (You can check and delete them in t= he > > > > Heimdal-1.5.2 > > > > kdc system via.. > > > > # kadmin -l > > > > get > > > > - if old keys are listed in Keytypes: > > > > del_enctype > > > > exit > > > > > > > > Ideally the conversion code would skip over these and not put them= in the dump. > > > > > > > > rick > > > > ps: If you don't do this, when you "get_principal" in kadmin.local = on > > > > the MIT KDC > > > > system, it will give you a "Database record is incomplete or = corrupted..". > > > > > > > > > > > > > > > > I will finalize the branch promptly and share it. The above ex= perience also > > > > > > indicated that I need to do a library version bump. > > > > > I don't know if you are enthusiastic about pursuing this, but hop= efully this > > > > > works and gets the principals in (although I doubt the passwords = will > > > > > work without changing them). > > > > > > > > > > To get the passwords to work, I think the following *might* do it= : > > > > > - If you look in the Heimdal sources, when "--decrypt" is specifi= ed, > > > > > I think it finds its way down into a function called hdb_unseal= _key_mkey() > > > > > which decrypts the key using the master key by calling _hdb_mke= y_decrypt(). > > > > > To get the passwords to work, I think the call to _hdb_mkey_dec= rypt() would > > > > > need to be followed by a call to _hdb_mkey_encrypt() with the "= key" > > > > > argument being the master key for the MIT database. (It it a ke= ytab > > > > > entry called /var/db/krb5kdc/.k5.YOUR.REALM created when you do= a > > > > > "kdb5_util create -s" on the system that will be the MIT KDC.) > > > > > - Just to make it even more fun, there is a flag called HDB_KU_= MKEY > > > > > which is set to the Heimdal way and not for the MIT way (what= ever > > > > > that really means?). > > > > > - There is also some stuff about padding in hdb_unseal_key_mkey= (), > > > > > but hopefully that won't be a problem? > > > > > > > > > > I think hdb_read_master_key() can be used to read in the MIT mast= er > > > > > key from the file you provide as an argument to it. > > > > > > > > > > This all is just a hunch, based on what I've seen so far. > > > > > > > > > > I'll admit since the hardware I have takes forever to "make build= world" > > > > > and I don't know a quick way to build/test these changes, I'm not > > > > > inspired to try it. > > > Although not inspired, I have taken a stab at it. > > > I am still trying to figure out how to build/test it, but I have fork= ed > > > glebius@'s github and added some code to... > > > - Not dump the weak encryption keys (they just cause MIT's kadmin.loc= al > > > to complain that the principal's database entry is corrupted. > > > - If the argument to "kadmin -l dump" is "-f " i= nstead > > > of "-f MIT" it re-encrypts the keys in MIT's master key. (I hope th= at will > > > make the passwords work. > > > (Basically, someone will "kdb5_util create -s" on the MIT KDC syste= m > > > and then copy the /var/db/krbkdc/.k5.YOUR.REALM file over to the > > > Heimdal KDC system and do "kadmin -l dump -f <.k5-filename> mit.du= mp" > > > then copy "mit.dump" over to the MIT KDC system and > > > "kdb5_util load -update mit.dump". Then, hopefully, the principals= will > > > work??) > > > > > > Anyhow, it is currently sitting here: > > > github.com/rmacklem/FreeBSD in the kadmin-dump-MIT branch. > > > (I'm as unconversant with git and github as anyone, so if you have > > > trouble finding it, just let me know.) > > Actually, it hasn't made it there yet. For some reason (I think it is > > glebius@s large # of branches) it takes a very long time to "git push" > > a patch involving 4 files. It failed after over an hour with an unexpec= ted > > TCP disconnect. I am running it again. > > > > I will stick the patch here, in case the push fails again. > > (It needs to be applied on top of glebius@'s kadmin-dump-MIT branch. > The patch is here. (For some reason, I couldn't push so I deleted the > github fork.) > https://people.freebsd.org/~rmacklem/kadmin.patch > > I haven't yet been able to test it, but will be able to do so later to-da= y, rick > > > > > Meanwhile I've given up trying to build it on a universe system and > > an now trying the "make buildworld" locally. This will take days, > > so I guess I'll go do something else.;-) > > > > rick > > > > > > > > I'll keep updating this github fork as I get to test it, but if other= s > > > know how to build it, feel free to test, rick > > > > > > > > > > > > > rick > > > > > > > > > > > > > > > > > -- > > > > > > Gleb Smirnoff From nobody Sun Aug 31 00:57:37 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cDts13jByz65KSx for ; Sun, 31 Aug 2025 00:57:41 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta003.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cDts11LL1z3f4w; Sun, 31 Aug 2025 00:57:41 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTPS id sJN3utTAU9JM2sWO4uUAlF; Sun, 31 Aug 2025 00:57:40 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id sWO2uWODJl5eGsWO3ucMac; Sun, 31 Aug 2025 00:57:40 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=EO6l0EZC c=1 sm=1 tr=0 ts=68b39e04 a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=IkcTkHD0fZMA:10 a=2OwXVqhp2XgA:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=YxBL1-UpAAAA:8 a=a4p5fJF5ua-8_LorYUoA:9 a=QEXdDO2ut3YA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from [127.0.0.1] (walden_pont_ng.cwsent.com [70.66.136.190]) by spqr.komquats.com (Postfix) with ESMTPSA id 267FB24B; Sat, 30 Aug 2025 17:57:38 -0700 (PDT) Date: Sat, 30 Aug 2025 17:57:37 -0700 From: Cy Schubert To: Kyle Evans , freebsd-current@freebsd.org, Poul-Henning Kamp , Adrian Chadd CC: =?ISO-8859-1?Q?Olivier_Cochard-Labb=E9?= , src-committers@freebsd.org, Gleb Smirnoff Subject: Re: August 2025 stabilization week In-Reply-To: References: <202508290546.57T5kmm4004504@critter.freebsd.dk> <202508301941.57UJfQBv003111@critter.freebsd.dk> <5D8A52A1-4F88-4806-A7A1-988F1EF2C5AC@cschubert.com> Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4xfEuoVUpGZ1buDikvweg5Rh0fpA2+EGdgUIO9lrmrxiyq4zered+lfXYalmGnLdK7PWGTPm+Jt3qb261TCWDaco6CuBVMgLEgDvVGJNFjjngXCxQPhwoK GSC+DZ/r+r3LCx5OQW5gReORc7lHChuYX90dJe49lh4ZKhf0EzM92sRO2hhNs2oasOlOBoPq94a3rw7O0M/FEMhPTyw34Mp+VcSYxM9Gm0zsLeLEQHNB3ZAQ X9uWmTeZwnUAyAXdpkAULDzrP+A2JMsZTzNIVOHtgZRvfx/vo5u2bnPEp/sJfJY/9L2i6HhS8enFAzNvWrOIVjkgDIpC+/vkbl1lgmuzU7KO0vpRizTIqIwj xCPWyp16YPHR8JZzT5brUpUo+zKqD1pxecG4lda7LaYZy5li0CI= X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cDts11LL1z3f4w I'm sorry=2E This was in response to stabilization week=2E I supposed I sho= uld have waited until I got access to a real keyboard again=2E My apologies=2E This won't happen again=2E --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD=2Eorg NTP: Web: https://nwtime=2Eorg e^(i*pi)+1=3D0 Pardon the typos=2E Tiny keyboard in use=2E On August 30, 2025 3:03:53=E2=80=AFp=2Em=2E PDT, Kyle Evans wrote: >On 8/30/25 15:16, Cy Schubert wrote: >> I'm on my phone, I don't have access to the commit hash=2E The patch(1}= commit broke make patch for some ports=2E You can verify this in devel/qt5= -assistance=2E >>=20 > >This seems like an odd sub-thread to drop this in, was it supposed to be = in >response to the general stabweek e-mail or is there some other context th= at >might be helpful? > >Looking at devel/qt5-assistance, *sigh*=2E Our fuzz implementation is to= o naive >and needs to learn that it can do different before/after fuzzing, I guess= =2E > >Reverted in fb37e38fbe99039a, sorry about that=2E I'll request an exp-ru= n when >I revisit it later=2E > >Thanks, > >Kyle Evans > From nobody Sun Aug 31 02:40:08 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cDx7G54Zyz661lw for ; Sun, 31 Aug 2025 02:40:10 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cDx7G4NDFz3xCv; Sun, 31 Aug 2025 02:40:10 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756608010; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pQ6uSjyghYNYfJ/637kUV1vTEaqn3oUnGkcUf6RY4kY=; b=B4/zOMCMqruOkoiUDMK+uxkaxZNTWuzeAvfdlAqzbwOdYGtxIJnCiVnevHZulQVyfPhdmS 0tGZkE2Memq0OwV+4Njq6hwzelJsjeO03t2Z/CP4D5Vzi7jfeR1BuNDJhzsPhkOv5oYhJs E4wfVOQI6R3qb1R3Za/vRFipanVViL1zEsigmmM17NlIGZRdt4Me+kRmRmDIGa/ds21OV2 q6BrvyOek4dSJWl0EiLY24jQD0arE73+7xYJyzzyQ9lXGRiRkqpRZWh5X4taqiznWBuC9C fBq04gXLdNcBsmVleG41wPCYhzY947qd0uLeziR3luIAJ2RqMfT4i53fSfYhBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756608010; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pQ6uSjyghYNYfJ/637kUV1vTEaqn3oUnGkcUf6RY4kY=; b=lG+PLS9KPFLRWZqAOqgm1bHLfarf5pmHAwcA78yNcodV7nJzDAEKOIja2KIZ681rxaEm1m E1r0HsHF1o01JBOE+6yetTFItvU0UEFO1pckcnv6eJS6l1b/+a/KfzwhIFcDzTWygUWiS1 w5qvlXEiFFdChnzsnPpGfGVvQ9j2pY/aOU72W4YbAGmqi6JnZ3QblgTt9/Av5D0WcgW5Rp D/ZSsDi8QufYxMU8nYEuVvKbCWi8sPcRR4pc/oEXOcrFt81kQNwvCjFanDteXyQgV/luft dNWyYPqHiFxV7GRHushL7U5fOLJhRD7u1/1mOW7Rhcx3M4AXUPnrQRMQhJC7ug== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756608010; a=rsa-sha256; cv=none; b=owoNCM/2A/6x2CHONmq1wMlhq5Bi/QgI+wIbq3F45pp0vHKfU5lZVDtoe2PO1M5XpBUoUY RBU/LGv1GnNoFVQWpzizGowqPPoxcl9g8MHzpaqS8lHX1mePkCvdYrYB2Fm6nuXrgxjcxr 7gT2aWb8zjM60jnk7+dkRmFq9UzQYPNJvqioIkhZtkKNRHXhQFdw/5b8y3F0wRiQO/Wadm kO7PPCQuPbo1765zrAXNOYfjQkR92Ed1LTA7woTM7pTQfkTCWuLuyacGlIJxucfwbIjlZP FMLA5M/+cUOSi0ftaLYTKuZXt0ICizb8x930Yw2d1AL8wwPiELL+1sG/o2htkQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cDx7F6xt7z291; Sun, 31 Aug 2025 02:40:09 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: Date: Sat, 30 Aug 2025 21:40:08 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: August 2025 stabilization week To: Cy Schubert , freebsd-current@freebsd.org, Poul-Henning Kamp , Adrian Chadd Cc: =?UTF-8?Q?Olivier_Cochard-Labb=C3=A9?= , src-committers@freebsd.org, Gleb Smirnoff References: <202508290546.57T5kmm4004504@critter.freebsd.dk> <202508301941.57UJfQBv003111@critter.freebsd.dk> <5D8A52A1-4F88-4806-A7A1-988F1EF2C5AC@cschubert.com> Content-Language: en-US From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/30/25 19:57, Cy Schubert wrote: > I'm sorry. This was in response to stabilization week. I supposed I should have waited until I got access to a real keyboard again. > > My apologies. This won't happen again. > > No worries, just wanted to make sure that I wasn't missing another report that I should have noticed. Thanks! Kyle Evans From nobody Sun Aug 31 04:47:06 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cDzy63mMTz66F4l for ; Sun, 31 Aug 2025 04:47:26 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cDzy557TMz3CHY; Sun, 31 Aug 2025 04:47:25 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="JL/Lxunl"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-61e425434bbso207715a12.2; Sat, 30 Aug 2025 21:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756615639; x=1757220439; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/rKte6ny+vsO+4EOLJJRhwDEwLOOUQYO4wBdrAqYqGc=; b=JL/LxunlcbsWPQb03PtqlL6uox3RXyTyqVKTMqoqMDi9np+Oezm2EE/GS1IworxYEZ BskwocsTz2iAMIpxF6sVDLqBVNEvzNNueUcKhGZAx5tJ5+13VSSq+XGjWZA7f4lGeXZ8 Q/iw5AQxdj8Y58x2BDXrVES9O61rHXFjMZ1ugHPgje93AUI7bO9t7gUuOLv8f3+IOvbd mEvIVo29TRB0oSncv3hD0Byrq/yhy0YC2jZpK7QuGk8sW2NNTSYSxPmA/JKH5mcEAZx6 nPsf7KxSr9a/vXFeyfM0/IfI05gYLCsoEF8wPGpicUrk3tImPsgGL0KTq1M7PAAamuOn D/Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756615639; x=1757220439; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/rKte6ny+vsO+4EOLJJRhwDEwLOOUQYO4wBdrAqYqGc=; b=nFx+aAAZeh4kLzaMzUilyBDseS2f1LcQOw53jPPH7ayDD1RsRymq3vXc4LDS+1TAKT asiCQrR/D7q8F6dMls1dmL4pAbxkj7P6rNpPcqXzYy/gWamVXZRLAY1saBoqKzQKh6ce 85o7EMxYDJVZ6frF+xf7NqqsHwBesNyDXBf4EbgBSMFhQsn1KMp0Q6hIVKh4QFkGbe90 ZCvf9AqEir71Ie+v1NPMORiMkYLjKj7jd12QKcHZCbfZB0gG8OQvKRJXoKSJzNKrc4jS ueG9Y/jdN0YsT4jeSjk1IY35yLqmWJucQKvMhFKK0BKm/FfFo/lGFmn/mDOlqEqKtrfz cOPA== X-Forwarded-Encrypted: i=1; AJvYcCWArxR4bB9kNv/bA9A4dcMjW4F5GGjjOOimAoD3aKbCecvKOakYFO45GwyPIGmp+oyjI5M1jxfuHE67JngcTYM=@freebsd.org X-Gm-Message-State: AOJu0YyAOu9TNKgv41hj0xgFtyTUWY5e5UpKetEHVHtss7oW0rwyLMUc 0++Z4/y/xw6pbYoseUPWzZEtlBXETD7QWXbeYpplSpxieirXhkV5NbDB57Enp75TEpiPiL2HSqF WlxLqI/Nx2uOVWVuJLOcnathJMobPlpGf X-Gm-Gg: ASbGncsqpdUP45ghmWjDLkJSr2YLOeG2YOuL4uzEwH9hk2ZFdv+Kp6LU7jkf89/ICRc Px3pWlYtqT67PfSb03QQZhR/YV0KkbNcm4ZDXG/s+FAz7pxsJrsQU89v9ygMECVTZaMIXAww/yI 9aZkueulUekXcW8wCZOBFcoRBlImyC3PgmntSUW2dQB4d/3raLSV0xa9jo0ZCmghzYdufLfrWsj yp3X4XqOww7yZ/pUmGd1QtNX1RNdNpGIIXIKbG92+CsQK9a X-Google-Smtp-Source: AGHT+IG92sTkkqhJXJpGd+rhYcrb1DUXZ3ff1POm/ZDoh7H93mpXI288YjD+5XOERWkOsFU1BWB2q7h1RUkO7sMDDHo= X-Received: by 2002:a05:6402:5108:b0:61a:843c:2dec with SMTP id 4fb4d7f45d1cf-61d26d79037mr3132128a12.30.1756615638396; Sat, 30 Aug 2025 21:47:18 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Sat, 30 Aug 2025 21:47:06 -0700 X-Gm-Features: Ac12FXz62Gs-ea9aFIM0zXZfw3H1d_7quUfqb-FXXfvtIuCrEBoEl0mQvwChKbk Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Gleb Smirnoff Cc: Cy Schubert , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4cDzy557TMz3CHY On Sat, Aug 30, 2025 at 4:22=E2=80=AFPM Rick Macklem wrote: > > On Sat, Aug 30, 2025 at 8:56=E2=80=AFAM Rick Macklem wrote: > > > > On Fri, Aug 29, 2025 at 1:05=E2=80=AFPM Rick Macklem wrote: > > > > > > On Fri, Aug 29, 2025 at 7:43=E2=80=AFAM Rick Macklem wrote: > > > > > > > > On Wed, Aug 27, 2025 at 8:39=E2=80=AFPM Rick Macklem wrote: > > > > > > > > > > On Wed, Aug 27, 2025 at 7:43=E2=80=AFPM Rick Macklem wrote: > > > > > > > > > > > > On Tue, Aug 26, 2025 at 9:35=E2=80=AFAM Gleb Smirnoff wrote: > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff wrote= : > > > > > > > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem wro= te: > > > > > > > T> R> Ok. If you install FreeBSD-13.5 and then "pkg install h= eimdal", you get a > > > > > > > T> R> working Heimdal-7.8 in ports. > > > > > > > T> R> > > > > > > > T> R> Now, I have another challenge. Fixing the master passwo= rds. > > > > > > > T> R> I'll work on it later to-day. > > > > > > > T> > > > > > > > T> I have applied two commits from Heimdal from 2012 that add= 'kadmin dump -f MIT' > > > > > > > T> feature to our base heimdal and polished them to compile. = So far it doesn't > > > > > > > T> work yet, either create an empty dump or create a core dum= p, instead of > > > > > > > T> database dump :) I'll see how difficult it is going to fur= ther resolve that to > > > > > > > T> a working condition. If I succeed, then having 'dump -f MI= T' in base without > > > > > > > T> any ports would be the best solution. Can also be merged = to FreeBSD 14.4. > > > > > > > > > > > > > > Good news. In the above paragraph I was testing my change in= correctly - threw > > > > > > > the new binary on a system running unpatched libraries. When= run correctly, > > > > > > > it successfully produced something that looks like a correct = dump in MIT format. > > > > > > > I haven't yet tried to load it into MIT kdc yet, though. > Well, would you like the not so bad news or the bad news??;-) > Your patch works, in that it produces a dump that "kdb5_util load > -update" can load. > After loading, if the principal only has keys for the newer encryption ty= pes of > aes256-cts-hmac-sha1-96 > aes128-cts-hmac-sha1-96 > then you can look at the principal via kadmin.local, but the password mus= t > be changed before it works. > --> This is the same behaviour as you get if you use Heimdal-7.8 to do th= e > dump conversion. > So far, so good... > > Now, the not so good news. Once you update the Heimdal libraries > (libhdb.so and libkadm5srv.so) "kadmin -l" is broken on the system > running the old KDC. "kadmin -l dump" works, but something like: > # kadmin -l > kadmin> get rmacklem > kadmin: get rmacklem: Service key not available > - I have not yet looked in your patched sources to see where this > failure comes from? > > Now, more not so good news... > My patch doesn't help. > It does re-encrypt the key in the master key from the MIT KDC > system, but that doesn't make the password work. > When I compared the dump generated via kadmin with both > your patch and mine, the key for aes256-cts-hmac-sha1-96 > is 34bytes long. > After doing the change_password so that it works, a dump > generated by "kdb5_util dump -r13" (the same dump format) > has a key that is 62bytes long. > --> So, there is more to converting the key than just re-ecrypting > it. (I'll try and find where the MIT code encrypts a key in a maste= r > key to see why it ends up at 62bytes and whether that can be done > in the old code.) > > So, if we are going to continue with this... > - We need to figure out why your patch breaks "kadmin" for other > things and fix that. > - I/we need to figure out how to convert the 34byte key to the MIT > 62byte key (and then maybe the password won't need to be changed?). > > Or do we just say "When you convert the KDC database, all the passwords > must be changed to get them to work?". All I've got sofar is this patch... https://people.freebsd.org/~rmacklem/print.patch It tweaks entry2mit_string_int() so that it skips over the keys for old encryption types and fills in a fake "modified by" entry if none exists. These changes at least make the MIT dump such that the records don't end up "incomplete or corrupted" when you try to do something like "get_principal " in kadmin.local. As noted, your patch makes "kadmin -l" break for most things, reporting "Service key not available". The failures go away if you revert back to the non-patched libraries. I have not located the problem yet. As for the passwords...no luck yet, rick > > rick > > > > > > Oh, and one more thing... > > > > > - If there are keys for old encryption types like des.. or arcfou= r.. > > > > > in the MIT dump, > > > > > those will screw up the load. (You can check and delete them in= the > > > > > Heimdal-1.5.2 > > > > > kdc system via.. > > > > > # kadmin -l > > > > > get > > > > > - if old keys are listed in Keytypes: > > > > > del_enctype > > > > > exit > > > > > > > > > > Ideally the conversion code would skip over these and not put th= em in the dump. > > > > > > > > > > rick > > > > > ps: If you don't do this, when you "get_principal" in kadmin.loca= l on > > > > > the MIT KDC > > > > > system, it will give you a "Database record is incomplete o= r corrupted..". > > > > > > > > > > > > > > > > > > > I will finalize the branch promptly and share it. The above = experience also > > > > > > > indicated that I need to do a library version bump. > > > > > > I don't know if you are enthusiastic about pursuing this, but h= opefully this > > > > > > works and gets the principals in (although I doubt the password= s will > > > > > > work without changing them). > > > > > > > > > > > > To get the passwords to work, I think the following *might* do = it: > > > > > > - If you look in the Heimdal sources, when "--decrypt" is speci= fied, > > > > > > I think it finds its way down into a function called hdb_unse= al_key_mkey() > > > > > > which decrypts the key using the master key by calling _hdb_m= key_decrypt(). > > > > > > To get the passwords to work, I think the call to _hdb_mkey_d= ecrypt() would > > > > > > need to be followed by a call to _hdb_mkey_encrypt() with the= "key" > > > > > > argument being the master key for the MIT database. (It it a = keytab > > > > > > entry called /var/db/krb5kdc/.k5.YOUR.REALM created when you = do a > > > > > > "kdb5_util create -s" on the system that will be the MIT KDC.= ) > > > > > > - Just to make it even more fun, there is a flag called HDB_K= U_MKEY > > > > > > which is set to the Heimdal way and not for the MIT way (wh= atever > > > > > > that really means?). > > > > > > - There is also some stuff about padding in hdb_unseal_key_mk= ey(), > > > > > > but hopefully that won't be a problem? > > > > > > > > > > > > I think hdb_read_master_key() can be used to read in the MIT ma= ster > > > > > > key from the file you provide as an argument to it. > > > > > > > > > > > > This all is just a hunch, based on what I've seen so far. > > > > > > > > > > > > I'll admit since the hardware I have takes forever to "make bui= ldworld" > > > > > > and I don't know a quick way to build/test these changes, I'm n= ot > > > > > > inspired to try it. > > > > Although not inspired, I have taken a stab at it. > > > > I am still trying to figure out how to build/test it, but I have fo= rked > > > > glebius@'s github and added some code to... > > > > - Not dump the weak encryption keys (they just cause MIT's kadmin.l= ocal > > > > to complain that the principal's database entry is corrupted. > > > > - If the argument to "kadmin -l dump" is "-f "= instead > > > > of "-f MIT" it re-encrypts the keys in MIT's master key. (I hope = that will > > > > make the passwords work. > > > > (Basically, someone will "kdb5_util create -s" on the MIT KDC sys= tem > > > > and then copy the /var/db/krbkdc/.k5.YOUR.REALM file over to the > > > > Heimdal KDC system and do "kadmin -l dump -f <.k5-filename> mit.= dump" > > > > then copy "mit.dump" over to the MIT KDC system and > > > > "kdb5_util load -update mit.dump". Then, hopefully, the principa= ls will > > > > work??) > > > > > > > > Anyhow, it is currently sitting here: > > > > github.com/rmacklem/FreeBSD in the kadmin-dump-MIT branch. > > > > (I'm as unconversant with git and github as anyone, so if you have > > > > trouble finding it, just let me know.) > > > Actually, it hasn't made it there yet. For some reason (I think it is > > > glebius@s large # of branches) it takes a very long time to "git push= " > > > a patch involving 4 files. It failed after over an hour with an unexp= ected > > > TCP disconnect. I am running it again. > > > > > > I will stick the patch here, in case the push fails again. > > > (It needs to be applied on top of glebius@'s kadmin-dump-MIT branch. > > The patch is here. (For some reason, I couldn't push so I deleted the > > github fork.) > > https://people.freebsd.org/~rmacklem/kadmin.patch > > > > I haven't yet been able to test it, but will be able to do so later to-= day, rick > > > > > > > > Meanwhile I've given up trying to build it on a universe system and > > > an now trying the "make buildworld" locally. This will take days, > > > so I guess I'll go do something else.;-) > > > > > > rick > > > > > > > > > > > I'll keep updating this github fork as I get to test it, but if oth= ers > > > > know how to build it, feel free to test, rick > > > > > > > > > > > > > > > > rick > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Gleb Smirnoff From nobody Sun Aug 31 09:24:10 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cF6770HCHz66fyH for ; Sun, 31 Aug 2025 09:25:39 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (prime256v1) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cF675037nz3cML for ; Sun, 31 Aug 2025 09:25:36 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=XuDsWHnx; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1756632298; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=33/MIwANkGkof2y8kYvpUARH8KQS8Cyd9Zt5TpCi83g=; b=XuDsWHnxxwGhIm+GL23OKwqfYsqsnnyEMev9N4WZILF4IEBAFdt+Ile+UwwlqJ7eSi0/4e cer4xwO/9oF98CtP6iCeb7mw2DypapGP3pi1nABiAjI3Qtwvxswb/aDajTHNc4vLFzE+51 amJ2R5Cd22sDLvgwK2W3VlOF4dj5W4AketQl1f0wKKS52iZMtUrftoJ5kaLqgf4aXqMdIr NM7FUeWhO3fF8jreimg4xJUbU02O1QXfEpAzlXUicUrhuPhfnr6nTt1cWmFE7A+rNsOFku PPijy+mpAQsomHs5ec8M5vPFXvb+FdhI8Mzu62fruFplRqBuL4uUvs2ZCMJHqQ== Date: Sun, 31 Aug 2025 11:24:10 +0200 From: Alexander Leidinger To: Chris Torek , freebsd-current Subject: Re: a few observations with 15-prerelease as of early this week In-Reply-To: References: Message-ID: Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_f9f62e8dacc3563bd8d9591c4f48746c"; micalg=pgp-sha256 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-6.00 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; R_SPF_ALLOW(-0.20)[+mx]; ONCE_RECEIVED(0.10)[]; HAS_ATTACHMENT(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; DKIM_TRACE(0.00)[leidinger.net:+]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; HAS_ORG_HEADER(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~] X-Rspamd-Queue-Id: 4cF675037nz3cML This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_f9f62e8dacc3563bd8d9591c4f48746c Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2025-08-30 22:45, schrieb Lexi Winter: > Chris Torek: >> I ran into the libcurl issue and had a heck of a time rebuilding >> it with the krb5 changes and "git fetch" failing, but a quick >> temporary update of the curl port to disable gssapi entirely got >> past it. :-) > > assuming you have an up-to-date base system and ports tree, building > curl with base (MIT) Kerberos should work fine. if you were unable > to build it, please provide more details. Does p5-GSSAPI build with base kerberos for you? With a world as of 2025-08-21-223348 and an up-to-date ports tree it fails for me in the configure step: ---snip--- # make ===> License ART10 GPLv1+ accepted by the user ===> p5-GSSAPI-0.28_2 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by p5-GSSAPI-0.28_2 for building ===> Extracting for p5-GSSAPI-0.28_2 => SHA256 Checksum OK for GSSAPI-0.28.tar.gz. ===> Patching for p5-GSSAPI-0.28_2 ===> Applying FreeBSD patches for p5-GSSAPI-0.28_2 from /usr/ports/security/p5-GSSAPI/files ===> p5-GSSAPI-0.28_2 depends on package: perl5>=5.40.r<5.41 - found ===> p5-GSSAPI-0.28_2 depends on file: /usr/local/bin/ccache - found ===> Configuring for p5-GSSAPI-0.28_2 Welcome to GSSAPI.pm setup! (./Makefile.PL Version 0.03) run "perl Makefile.PL --help" to see further installation options ---------------------------------------------------------- Searching krb5-config command... using krb5-config command '/bin/krb5-config'. ---------------------------------------------------------- using GSSAPI implementation /bin/krb5-config does not respond libconf! at ./Makefile.PL line 116. *** Error code 2 ---snip--- Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_f9f62e8dacc3563bd8d9591c4f48746c Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmi0FMgACgkQEg2wmwP4 2IalRBAAi+OQ1z6gmKuAHiwv6b3nS7e/gYxnpEIEbHd8vqusi2tWNV44zLp+SZDp Xk7dOwiFs/mIoMNSCX70Frs8TKlocHfjN12IHwkdbU/o81GmlTBvGM4vX6vz0RL3 NyKlUWFDG50bNaWvq0bcyj6XigP0R8vEKm52VgpltweFl5ZLcM4TMRcSwpL4reip i1FmAsht52C0vV6v/vp6urYCT0loRSy306yytevEXNFeNUZYqETGBR6vATruaBsy vmhMOBgw03cglhGOWAifmIrdW+ZDGjrC59N9pTUtrJPZGi3mTuXc3SkiE/6p25in Sqx6pkIz1xhIJ0q13p3nV9zWr5ffWnz8XxzVRm8puH7u3+kjaJDwWnphNAWA2Xgd lWVcvsF4ke8uTNcYZDkapx1RoOctq/ropAwnNpE5W4U5yE3+I6pX5D84Ll8zLjGc CPSq2wOTf6cY9e36skXpwIe1By8dR2Zb3Jp6YRv1kFcVvaX7WyxfdC7sGINFQrVi mwdQc33ldaP0HrvsESIvJfpIdXqfXFUnvky5Noci+YC6qNwBrK8UIk+s5qkQhnSM Z1Gd9vqnnwu+OZ6nsiLaO4DJjudtnZMu32N+4tNtz1idusQPKlYSz1E1ms9SnE5/ fFO3JIlcUTHXnZE47nPkjHS33eULtOL3kKIEHOWqX7z9ILLGAPY= =Eklu -----END PGP SIGNATURE----- --=_f9f62e8dacc3563bd8d9591c4f48746c-- From nobody Sun Aug 31 12:55:54 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cFBpW4073z65mbM for ; Sun, 31 Aug 2025 12:56:35 +0000 (UTC) (envelope-from herbert@fastmail.jp) Received: from fout-a3-smtp.messagingengine.com (fout-a3-smtp.messagingengine.com [103.168.172.146]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cFBpV4BTcz3vQH for ; Sun, 31 Aug 2025 12:56:34 +0000 (UTC) (envelope-from herbert@fastmail.jp) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=fastmail.jp header.s=fm1 header.b=KF8wJRvp; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=JdvVczmi; dmarc=pass (policy=none) header.from=fastmail.jp; spf=pass (mx1.freebsd.org: domain of herbert@fastmail.jp designates 103.168.172.146 as permitted sender) smtp.mailfrom=herbert@fastmail.jp Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfout.phl.internal (Postfix) with ESMTP id DAD2DEC00C4 for ; Sun, 31 Aug 2025 08:56:33 -0400 (EDT) Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-01.internal (MEProxy); Sun, 31 Aug 2025 08:56:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.jp; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1756644993; x=1756731393; bh=Hg7xq5T3seipGilJ8VPGDIn0JPtTjW1Ice+BXPAb06k=; b= KF8wJRvp97YEPjDZ1h2fCKE0XXoSAvzgLIgfNMMLpFM/n/45ay2by6s/98tO/Isl ovuDAMgEX/D7gmwMEnnDnvhc2MU6/NpIcUZ+LBqVD+Qmqi+swevnI+HUbsl3eL59 xcK09gEpcScS5jCQZ3EOATLFU77AHs46czkRQkQ+JvZcnoR2m4ueWwu+OKCm1xyd U7b9ZcHOV1N+liiX01SzmRRqWTd2riSBDdwEeOGGjUD9irXgz53hbOuOi+A4lgxi 6UhsSWvf44EaNiDME/S7b8U0w26kLUPfao5P5vQ6ogh1kWd+/FXGpOYzALgd59ss /jjWCJK7D58QAEA7Y0Oaww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1756644993; x=1756731393; bh=H g7xq5T3seipGilJ8VPGDIn0JPtTjW1Ice+BXPAb06k=; b=JdvVczmi1YYfbkcOE Tn0Twtv45IxmF2fTTvBLxKtiHorZYGxxzTIWyc8IVLtwD7J067+KamZmCKWXVapC FacHs0SpkJKiXSvCZBBoSAHToLn2n9msATy+2gpSw/6iDdU7+lHKIkS+puPHcxz+ Kq7RsC7B9y6phYAfvh+oNXTLuQ6vGWOncVLOdwtNww9ONgxFqd4ZrVWQDbDDNC4J 58RWYtbsdcZ2Ush0IaF4AehqIvLRlrql82tY8chOTftKjGBKVnZWdT8agHhD3Oo1 HR46RopHHpkZLLQ97mm/ZYAqhPIDyLpB0nUFKJFncNYX9bwH/Uw1d/yNYSu3155c XcwqA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddukeelfeefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefoggffhffvkfgjfhfutgfgsehtjeertd ertddtnecuhfhrohhmpefjvghrsggvrhhtuceohhgvrhgsvghrthesfhgrshhtmhgrihhl rdhjpheqnecuggftrfgrthhtvghrnheptdegkeelteffgfdtheejfffgieffudffkeevue eiffefledtvefgudekfeeghefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhephhgvrhgsvghrthesfhgrshhtmhgrihhlrdhjphdpnhgspghrtg hpthhtohepuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdq tghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i8e7149f9:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 9B451700065; Sun, 31 Aug 2025 08:56:33 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 X-ThreadId: Ar-P-GH_rYOV Date: Sun, 31 Aug 2025 14:55:54 +0200 From: Herbert To: freebsd-current@freebsd.org Message-Id: In-Reply-To: References: Subject: Re: a few observations with 15-prerelease as of early this week Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.09 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[fastmail.jp,none]; R_DKIM_ALLOW(-0.20)[fastmail.jp:s=fm1,messagingengine.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.146:from]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[fastmail.jp]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[fastmail.jp]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[fastmail.jp:+,messagingengine.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[103.168.172.146:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:151847, ipnet:103.168.172.0/24, country:AU]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4cFBpV4BTcz3vQH On Sun, Aug 31, 2025, at 11:24, Alexander Leidinger wrote: > Am 2025-08-30 22:45, schrieb Lexi Winter: >> Chris Torek: >>> I ran into the libcurl issue and had a heck of a time rebuilding >>> it with the krb5 changes and "git fetch" failing, but a quick >>> temporary update of the curl port to disable gssapi entirely got >>> past it. :-) >> >> assuming you have an up-to-date base system and ports tree, building >> curl with base (MIT) Kerberos should work fine. if you were unable >> to build it, please provide more details. > > Does p5-GSSAPI build with base kerberos for you? With a world as of > 2025-08-21-223348 and an up-to-date ports tree it fails for me in the > configure step: > ---snip--- > # make > ===> License ART10 GPLv1+ accepted by the user > ===> p5-GSSAPI-0.28_2 depends on file: /usr/local/sbin/pkg - found > ===> Fetching all distfiles required by p5-GSSAPI-0.28_2 for building > ===> Extracting for p5-GSSAPI-0.28_2 > => SHA256 Checksum OK for GSSAPI-0.28.tar.gz. > ===> Patching for p5-GSSAPI-0.28_2 > ===> Applying FreeBSD patches for p5-GSSAPI-0.28_2 from > /usr/ports/security/p5-GSSAPI/files > ===> p5-GSSAPI-0.28_2 depends on package: perl5>=5.40.r<5.41 - found > ===> p5-GSSAPI-0.28_2 depends on file: /usr/local/bin/ccache - found > ===> Configuring for p5-GSSAPI-0.28_2 > > Welcome to GSSAPI.pm setup! > > (./Makefile.PL Version 0.03) > > run "perl Makefile.PL --help" to see further installation options > > > ---------------------------------------------------------- > Searching krb5-config command... > > using krb5-config command '/bin/krb5-config'. > > ---------------------------------------------------------- > using GSSAPI implementation > /bin/krb5-config does not respond libconf! at ./Makefile.PL line 116. > *** Error code 2 Yes, it's broken. The problematic part: GSSAPI_MIT_VARS_OFF= KRB5CONF=${HEIMDAL_HOME}/bin/krb5-config and on main HEIMDAL_HOME is empty. Maybe we need an OSVERSION check fpr this line? From nobody Sun Aug 31 13:33:29 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cFCd94MhKz65qbx for ; Sun, 31 Aug 2025 13:33:33 +0000 (UTC) (envelope-from ivy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cFCd93X7Nz418V; Sun, 31 Aug 2025 13:33:33 +0000 (UTC) (envelope-from ivy@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756647213; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pG3ErIK5x+loNZx1WUf+qvu5rAXM8jLG8/aruHB86kU=; b=r53O4HISI1ckydgDCLVOVE8MUTF17Aup4D0qKhFfbcjiuEAD4LVeLeAPFin1WeDXSqlLaf FdLsEkwVtwXM9L1gAZCi2dc3n8SiA5NvLI8Tdl36iRaj/AmyhvQMFWWOnCOZZhD5xV12CC YYp3zS52e2E94iAd38BBqXSKFiPMvboYi/uBxX1sDOkt9WXwABYlIW+cIkZ2VAqa86SJto IlsZ8EnDn56aTF6Sle7rfOql1kqKlR+D3uwdaKZ74ho/6Sy8tEI0ojqxPo7fXJ2dd3E+Xv boZi/cm7swEeHFgi0g4GjswkgH5WSbPnvCOiCAWutSv/unxtSZWZgR3m/tbyLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756647213; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pG3ErIK5x+loNZx1WUf+qvu5rAXM8jLG8/aruHB86kU=; b=XRe+5TiYZRA/c1n8XNdZJMk3M9CGlxBk3mFJ8mtDWpI+NzLbFyTOXebjPcNrTlvaGxkCSP WKgxhJV0Fu1wL/M1mHtqy97fpJHZQS26YhpfhhhjzhhJErzoiA8ya5K/6se+IRfDYVmSBF ve9E7oa4b4BtrKjN6WlizZSN6nTugExbqT9XgCChJJBnuSOC3XV0N+vHTie1EM3NrZ5nGm o8FphR/z22IwFMLsUdxjge+++rsStWl1kG43ynM9hvRDSZ2+43ECYjGLnQjj8SVugnaAL/ PtWy5Udld1M0hTun3JsisS4kuCX5uvAW90+87hMXowu9Aq8y25QcOL0VwLQz1Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756647213; a=rsa-sha256; cv=none; b=sEt1HPkaBnip1XzqVDvz39NtHJZ1Js8QWJC4TLdxcQbwYGz2naDhrRF7ji5FQem/1QzJDJ X/73CtfeZDJFM3fy/hQIV6dMPW96KuH8Bqd+7un/PavsVvw1yrR357Vg+yaMDu7ju/9TCu TlIaWghr+hiVYQO2E96bgiLmPY73TW3TpHeeR+XVX1z+0qayF69ZQp1MnPqcV4WEyvHZkL ng/Wj0dgrTi/17Y5ujVUkfxjfS0e1wYAvTV3VkVtwnyyKgpRKAUKbnbXZRElswE/UEba5b jqK4ATxmeoAtGCx7D3J7q6MyJCiAMg5nZERbn5O+xh7ynU66krHNcy8jbg6pAQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from amaryllis.le-fay.org (amaryllis.le-fay.org [IPv6:2a00:1098:6b:400::9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cFCd90RXrzH1f; Sun, 31 Aug 2025 13:33:32 +0000 (UTC) (envelope-from ivy@freebsd.org) Date: Sun, 31 Aug 2025 14:33:29 +0100 From: Lexi Winter To: Herbert Cc: freebsd-current@freebsd.org Subject: Re: a few observations with 15-prerelease as of early this week Message-ID: Mail-Followup-To: Herbert , freebsd-current@freebsd.org References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uHWebDp4BJWoieSa" Content-Disposition: inline In-Reply-To: --uHWebDp4BJWoieSa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Herbert: > Yes, it's broken. The problematic part: >=20 > GSSAPI_MIT_VARS_OFF=3D KRB5CONF=3D${HEIMDAL_HOME}/bin/krb5-config >=20 > and on main HEIMDAL_HOME is empty. >=20 > Maybe we need an OSVERSION check fpr this line? you can't use OSVERSION to check for this because the user can build 15.0 with Heimdal instead of MIT Kerberos. instead, check for the existence of /usr/libdata/pkgconfig/mit-krb5.pc; for example, from www/squid: =2Eif exists(/usr/libdata/pkgconfig/mit-krb5.pc) GSSAPI_BASE_CONFIGURE_ON+=3D --with-mit-krb5=3D${GSSAPIBASEDIR} =2Eelse GSSAPI_BASE_CONFIGURE_ON+=3D --with-heimdal-krb5=3D${GSSAPIBASEDIR} =2Eendif alternatively, perhaps you can assume that if ${HEIMDAL_HOME} is empty then the base system is using MIT Kerberos, but i don't know where that variable comes from. i wonder if Uses/gssapi.mk should provide some sort of variable to allow ports to check what Kerberos version the base system is using without having knowledge of specific files. --uHWebDp4BJWoieSa Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaLRPJgAKCRD1nT63mIK/ YFyeAQDNTLuFg7kjRBWdPZYU+LLd6m4b5v4U2SeWntrBPTBsugEAqPmt6v4hrI4s mprY1cacJyF69L2nqww8exaFbNm1hg0= =t2Kc -----END PGP SIGNATURE----- --uHWebDp4BJWoieSa-- From nobody Sun Aug 31 14:57:12 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cFFTm4B9Nz6605X for ; Sun, 31 Aug 2025 14:57:16 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-b3-smtp.messagingengine.com (fout-b3-smtp.messagingengine.com [202.12.124.146]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cFFTl21LSz4B75 for ; Sun, 31 Aug 2025 14:57:15 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm1 header.b=Qft5YuHl; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="H P8Yt5U"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.146 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfout.stl.internal (Postfix) with ESMTP id E67781D000A9 for ; Sun, 31 Aug 2025 10:57:14 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Sun, 31 Aug 2025 10:57:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm1; t=1756652234; x=1756738634; bh=RYYvVwG0bYLC6j4O0wXaiGTGqT82NjnV urG/OvE3/oA=; b=Qft5YuHl+L663xe/7fsYNnx09/PTW67YohKcrOvl+veuqTAe Deh4aQ6h029btinioenSmRZDUBSny9Nz1QDTPV6Vvo81AULgeh1OgIIRoY4/e2j8 b+lXJVqVpqfY6FAxZ0i7sUQ8A/M7AlEJ9wKd0BwhzB4VbQvOnQTo8nbclkbbgVTr WyV0Uc9e7uvfZTjRtQ3LAiD9MMgoMQNeMrRMgqLhx0qBw0fR+B6pBz9ZBGHE78Ia ex/vjuyeIIuUJIwTicPNufBRC7aXNANH5C+KRKZBHOJVFbnEkfpDBTxRKBA3/PYC k0pKG1u5a7fNrmz8b9kgQPUfQxz2xnLDNe1fqg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1756652234; x= 1756738634; bh=RYYvVwG0bYLC6j4O0wXaiGTGqT82NjnVurG/OvE3/oA=; b=H P8Yt5UV1gbc1bknnlH3PccjH/kFWKriDGYoWqQRobI1l9+Ggol641c8638PIkC0g OPqS5M3DkK2YA3/sQerKIVIra9a5tpPW/5otCvDXUadObYM4K+6vAbKyavzW7WwF 3zd44Hlz1/IXG+OdslRL4sqh59/F/E426OKyg1yeKsCMCE/AzH3e4zKvjh4nG9kj dsUuFD4xgZ5x1kN9BlyflO/M29Gkv3oGm5mATjiVtL0LMSzK3PlOpXQ2FX10PdNt MYCFkV0DwP4jRXJVQHOdGzAquYj9/S7WtZuc0iJiElzftgjWkwihG3VOA3Texaes 0lGB2fi2x43LxxV+Ti0QQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddukeelheejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttddtvd enucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthhtvghr nhepveduffeivdfffffghfegfeejfefftdeiteehteekfefhvdefgfettdeuheegffeune cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgu sehfqdhmrdhfmhdpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpdhrtg hpthhtohepfhhrvggvsghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 31 Aug 2025 10:57:14 -0400 (EDT) Date: Sun, 31 Aug 2025 15:57:12 +0100 From: void To: freebsd-current@freebsd.org Subject: nfsd_server_flags="-h ipaddress" has no effect Message-ID: Mail-Followup-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.60 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.146:from]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:151847, ipnet:202.12.124.0/24, country:AU]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4cFFTl21LSz4B75 Hi, On relatively recent -current (main-n278917-233a26b5c5d7 amd64) I was alarmed to find that on a dual-NIC host that if nfsd is enabled with the -h flag set, the port appears open on all NICs and not just the internal facing one. This behaviour is in contrast to rpcbind_flags="-h 192.168.1.100" which when set means rpcbind cannot be seen on the external-facing interface when tested. Is this expected? I would have expected port 2047 to be inaccessible from outside the network if nfsd is bound with -h to an internal-only interface/ip address -- From nobody Sun Aug 31 19:50:45 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cFN0g0mnGz66S1B for ; Sun, 31 Aug 2025 19:50:59 +0000 (UTC) (envelope-from saper@saper.info) Received: from q.saper.info (q.saper.info [IPv6:2605:2700:0:2:a800:ff:fec7:5c61]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (secp384r1) client-digest SHA384) (Client CN "q.saper.info", Issuer "E6" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cFN0f5CpFz3l8H; Sun, 31 Aug 2025 19:50:58 +0000 (UTC) (envelope-from saper@saper.info) Authentication-Results: mx1.freebsd.org; none Received: from q.saper.info (localhost [127.0.0.1]) by q.saper.info (8.18.1/8.18.1) with ESMTPS id 57VJojDB012298 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 31 Aug 2025 19:50:46 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1756669846; bh=PNM1KKbtePc/HZd5lPZdwDo8eAkFbqOuvipx/LZqnQ0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=GxxINpvdL5ooIsbCIN+Zh3wR4OViGqXkff8vB/Mkv7zcYYRLunBnqroodkhx8f8ae LrhjuoPlV7+pGncXkywwwqijj77hMCrprJ1HcKMHfDTfLQkKZz1QmHgETDzkhiFfjf 15ZnlluYduKuueePYKC9PEmSLNjo6uQLNzK6BSrU= Received: from localhost (saper@localhost) by q.saper.info (8.18.1/8.18.1/Submit) with ESMTP id 57VJojDX012295; Sun, 31 Aug 2025 19:50:45 GMT (envelope-from saper@saper.info) X-Authentication-Warning: q.saper.info: saper owned process doing -bs Date: Sun, 31 Aug 2025 19:50:45 +0000 From: Marcin Cieslak To: Herbert cc: FreeBSD Current , Lexi Winter Subject: Re: a few observations with 15-prerelease as of early this week In-Reply-To: Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="2201072851-1811127995-1756669845=:5490" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:47066, ipnet:2605:2700::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cFN0f5CpFz3l8H --2201072851-1811127995-1756669845=:5490 Content-Type: text/plain; format=flowed; charset=US-ASCII On Sun, 31 Aug 2025, Lexi Winter wrote: > Herbert: >> Yes, it's broken. The problematic part: >> >> GSSAPI_MIT_VARS_OFF= KRB5CONF=${HEIMDAL_HOME}/bin/krb5-config >> >> and on main HEIMDAL_HOME is empty. >> >> Maybe we need an OSVERSION check fpr this line? > > you can't use OSVERSION to check for this because the user can build > 15.0 with Heimdal instead of MIT Kerberos. instead, check for the > existence of /usr/libdata/pkgconfig/mit-krb5.pc; for example, from > www/squid: > > .if exists(/usr/libdata/pkgconfig/mit-krb5.pc) > GSSAPI_BASE_CONFIGURE_ON+= --with-mit-krb5=${GSSAPIBASEDIR} > .else > GSSAPI_BASE_CONFIGURE_ON+= --with-heimdal-krb5=${GSSAPIBASEDIR} > .endif I think Mk/Uses/gssapi.mk does this check for us already and sets KRB5CONFIG as well as GSSAPICPPFLAGS GSSAPILIBS GSSAPILDFLAGS accordingly. So probably there is no need to set GSSAPI_MIT_VARS or GSSAPI_MIT_VARS_OFF just do post-patch: @${REINPLACE_CMD} -e 's|%%KRB5CONF%%|${KRB5CONFIG}|g' ${WRKSRC}/Makefile.PL It should be simpler and still compatible with older FreeBSD versions. --2201072851-1811127995-1756669845=:5490 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIOdgYJKoZIhvcNAQcCoIIOZzCCDmMCAQExDzANBglghkgBZQMEAgEFADAL BgkqhkiG9w0BBwGgggq9MIIEvDCCA6SgAwIBAgIQeEqpEhjRpCYIUTzTZlVD ozANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3Qg Q0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFs U2lnbjAeFw0yMDA5MTYwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFsxCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhH bG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24gMSBDQSAyMDIwMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvxvJBqEapaux2/z3J7fFslRO WjKVJ5rCMfWGsg17dmD7NSnG7Spoa8d3htXsls1IMxoO8PyouQajNQqYmlYo xinlqenMNv7CJyEKMOAtglBmD6C/QC7kT+dSx4HfSTs8xmv8veJOldMzF8S/ BEn/tD4w/Dvpg+oXOqDyOiHPTacRFK0QHoq5eEbBmVS8W0rwcaRotO9fGTA+ NjF0My7GLRNK0eMPGh2hcPZURQhXy7wRQ8XFIfEA6kaQHHN22ncnVtwqiTmA wTR+4GNNVinG3KjNZLAVSnGrdCvT2I4Zo19hKy5PX6o7wrVXvMR4zV5VBFwV 6ZDM+xewao7Mup+SbwIDAQABo4IBiTCCAYUwDgYDVR0PAQH/BAQDAgGGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBSFu/DMxDa1CmJ2o5kuj7s6aq3FUTAfBgNVHSMEGDAW gBSP8Et/qC5FJK5NUPpjmove4t0bvDB6BggrBgEFBQcBAQRuMGwwLQYIKwYB BQUHMAGGIWh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL3Jvb3RyMzA7Bggr BgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQv cm9vdC1yMy5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9i YWxzaWduLmNvbS9yb290LXIzLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIB KDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9y ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAWWtqju12g524FdD2HwUX U1rSxeM5aSU1cUC1V/xBjXW0IjA7/3/vG2cietPPP/g3lpoQePVJpQAKZml8 1fHwPPivFK9Ja41jJkgqGzkORSC0xYkh2gGeQg1JVaCzcrRzJElRjT442m6F pbLHCebxIHLu0WBNjLZreB6MYMaqdPL6ItbXtD/BU4k517cEuUbczoBFZAra jq7oUBWXuroln5AMnRwVNwgJN4Np0s4kkJ94KepzbFOLzcbnfUB0+xT4foXm bM0GmmcPGOy0qvqEHJsBwDZXDxIk8oqCnnLngi7N94Sn4eTcmpZ9NH2dDN1O TEPVXgRG5X1pBcNtMWG6MDCCBfkwggThoAMCAQICDCKqoJRMYYx5sYJHGzAN BgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFs U2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMgUGVyc29u YWxTaWduIDEgQ0EgMjAyMDAeFw0yMzAzMDcxNjExMDlaFw0yNjAzMDcxNjEx MDlaMDwxGTAXBgNVBAMMEHNhcGVyQHNhcGVyLmluZm8xHzAdBgkqhkiG9w0B CQEWEHNhcGVyQHNhcGVyLmluZm8wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw ggIKAoICAQC8MB3fTYVrTadH5qE2CIa4VLvlL6QHgDriMRLkTA49SPszYCO0 fZTEpdSw8fc6kK9p2fD63LAfOHeD7jzey5aHBzpIGlxeFkn0Ce2BCYY5yLxK i9byoCwrpLchTR1Itpk1w+zy5E4T9KBTL1+c+w+TKpaIvFLXtjZtz4wQGi0p e/nRkRK9htGG3mETh+APitedl+ImGaI8NK9PELxuSkXnYAvGPpnXir8vbszk tJU1b0TevL/i3Sy6fhOhunZmTo1QDM7Zw4UyVjkQgTvL3y4I0tIrVjlam08x XZeMp+i/Gl51eHGvRVfvdJUJAjrWhrFEp8+2FZouWxWzAlHdd2sRp1AekNdP CeRgHeIF6uNtSseL1grKAjU+4BiixWPp1y1niB0humoQHoub/6fO/mU+//rW l3gTwZNu4FuKgZlfPw+qnvuka0c9dUNIZRCE5z8yXjS8R9yZWirnHNhYxf/e R2y4jaiHzPAjZlZZ2rGx8xVfB2n2JsAicj2+ZxmXlQ1yd5RW1pfxG3cdNNC5 uZ+j4JIN2ElsIjEKmMn9gHdoaEMAy/ENwNiMDBadLnc8qWirq/Ktp2dBSf2y /sH9xMpVyk8wuYjpbCnX4xslAensno5A20MYdKGPRFaItEhNPNbfzc1+4br8 exoXFX1F9ZJK9gGUO2nLbdRycphdyzxzgQIDAQABo4IB2jCCAdYwDgYDVR0P AQH/BAQDAgWgMIGjBggrBgEFBQcBAQSBljCBkzBOBggrBgEFBQcwAoZCaHR0 cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NnY2NyM3BlcnNv bmFsc2lnbjFjYTIwMjAuY3J0MEEGCCsGAQUFBzABhjVodHRwOi8vb2NzcC5n bG9iYWxzaWduLmNvbS9nc2djY3IzcGVyc29uYWxzaWduMWNhMjAyMDBMBgNV HSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3 dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEkGA1Ud HwRCMEAwPqA8oDqGOGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NnY2Ny M3BlcnNvbmFsc2lnbjFjYTIwMjAuY3JsMBsGA1UdEQQUMBKBEHNhcGVyQHNh cGVyLmluZm8wHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB8GA1Ud IwQYMBaAFIW78MzENrUKYnajmS6PuzpqrcVRMB0GA1UdDgQWBBTW/RrdlRFR y6MgS7liTThMnQA5ozANBgkqhkiG9w0BAQsFAAOCAQEAAwoUJShHMueocVlD 1+vYJbTTTbk9tabr2L4Iyyy4Btu1d1wwl6d9Yx2N9qaVERWcEeP0aR+NB2B7 xIKl/ZnZVuSxep0Raw4s284a/jSIJlsAi4SJItDCU2VrYJDWxP7MxzZHnzPI MLDoTHXPV18gvYTewoNk5/Yo89Kb0v/GpPTpP2sVdrWLHa4uKUHYrAZ0aByp kNw6lXp6o6DXvXaOd6KDTQN5XhmmHwLnuLceODF1t9gicsZIOY+KAxN6YZ6t EqwN48b4OFMpckDE3fm1iTZRqnEIqUHOKOcoCImkub1woEN0zXDQmLXaZigl uVztWSTM4/fapWLrlHBNxfjs1TGCA30wggN5AgEBMGswWzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMTAvBgNVBAMTKEdsb2Jh bFNpZ24gR0NDIFIzIFBlcnNvbmFsU2lnbiAxIENBIDIwMjACDCKqoJRMYYx5 sYJHGzANBglghkgBZQMEAgEFAKCB5DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0yNTA4MzExOTUwNDVaMC8GCSqGSIb3DQEJ BDEiBCBeYWR8wffdFWJqz+voRprFEuNda64Ua2JjJYIvoMC8PjB5BgkqhkiG 9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUD BAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAgCC uONrtoDAv5Ahwe8EZHDnkEXQ0pQUGYfcb7qMkjwEqOVi+bRlYo2FV5YStGqG QwFleKcMdYOxu1m1u3o9dW9f57rp8bkcfSPs3S99Etp4g5Sh6pLyL0Y0RFyQ FnTni5zkauSnM95ILYyNoQpX+ky4SdBa8KNMSQRtdV0NhLt6QHrlGSgR8ArF 5//aLNBGa6ywN2u9Fcycf/b1vjttt5s5rZVYG7tqBcINL4Zj4gG6HlDqgOFx g1B5KMqVIspso42nmROoB6wWQmr72hYEtYwzLbryz/UEHKnXosomQdr+vfN5 k7PBDRf9a/x8wwIxCcsgssT09eOJkFtZL6fx+Op3jztK0vJFin76hIjZOGay 9+Vcm8VRLMmiLjoDXx9s+pfGvtw8NpW1z7IwkONwBhUY63mwBta6Iha32lnK JUW5O8bBdXFc6L1WQ3UNLJWiqq/ayFlm6O9rMs8Ffwz0zTCRAhevUKSK08Zc 6b5wXXKOIhJyd9qt1ke41yCqTfu8xjkVrJq33eQ6G6KnbP6GNcEPYtUdZIb/ yYsoxwmzxJuC5eu3CA79quZhxaMZxiGTcpwNyT3kjHsA9Ja+J+7tCh++2+gy 54BtSjDR7rlZTqa+SNfVhAOi2hoEubQB1iBS1sXlY3s4Holt0yu1OHC9SkRb OsajRJ4tnztJrk84axewCA== --2201072851-1811127995-1756669845=:5490--