On Fri, Jul 24, 2026 at 10:05 AM Ian McInerney <[email protected]> wrote: > > Peter Robinson wrote: > > Hi Ondrej. > > > Wiki - https://fedoraproject.org/wiki/Changes/Disable_CRYPTO_USER_API > > > Discussion thread - > > > https://discussion.fedoraproject.org/t/f45-change-proposal-disable-in-kernel... > > > (..) > > > There's not a lot of known users of the in kernel Crypto Userspace API > > > so the impact should be minimal and there's upstream planning for most > > > of those. > > > The known Fedora users of the Crypto Userspace API are iwd, cryptsetup > > > (just used for > > > [https://www.man7.org/linux/man-pages/man8/cryptsetup.8.html#TCRYPT_(TRUECRYP... > > > TrueCrypt, tcplay, or VeraCrypt] and some kernel level benchmarking) > > > Also for cryptsetup: Adiantum cipher is not implemented in any userspace > > > crypto library AFAICT. There might be some users with low-end devices > > > without HW support for AES (AESNI). Fedora IoT could be affected?. The > > > Adiantum case was discussed several times in AF_ALG deprecation topics > > > in kernel mailing lists and should remain accessible in limited AF_ALG > > > in future kernels. > > > So Fedora IoT won't be affected there, we use the distro defaults and > > all aarch64 chips we support have the arm crypto extensions. > > I don't believe, but I am by no means sure, that using default install > > tools/settings users should end up with Adiantum encryption in Fedora, > > AFAICT it was primarily used by low end android phones. > > version 2.8.7 also has a bunch of mitigation for the changes > > > Also what is missing from the discussion: In latest 2.8.7 release we > > > re-introduced dm-crypt based fallbacks for block ciphers not available > > > in userspace crypto libraries, but the fallback requires root privileges. > > > I'm sure there are users of libcryptsetup (systemd-repart?) not > > > expecting to require root privileges for file based images. > > > (...) > > > The first phase uses the upstream patches due to land shortly, likely > > > in 7.3, to limit the use of the API to the known apps and restricts > > > the use. This allows Fedora to identify unknown users and gracefully > > > deal with them before the active demise of the interface upstream > > > providing users a more graceful process rather than universally > > > pulling the rug without any notice. > > > I don't understand what is the purpose of this change request. Do you > > > want to take additional steps beyond what kernel upstream currently > > > plans and switch off AF_ALG in before it's limited by upstream kernel? > > > Do you plan to "backport" those patches in earlier fedora kernels? Or > > > it's simply to announce that there's a upstream kernel change coming and > > > people should get ready for it? > > > It's primarily communication and awareness and adding the upstream > > pieces at a release boundary, F-45 will ship with the 7.2 kernel, we > > don't want the upstream patches heading to 7.3 to suddenly break users > > mid release when upstream yanks whatever rug they choose whenever they > > choose. It doesn't make for a good user experience does it? > > Since this change is targeted at F45 and kernel 7.2, does this mean that F44 > will not get kernel 7.2 released to it and stay on kernel 7.1? Would that 7.1 > stream still be supported and get patches backported to it (either by > upstream as a supported release or by the Fedora kernel maintainers)? I seem > to remember that new versions of the kernel do usually get released onto the > older Fedora releases during their lifetime so that all branches match.
I do actually have a method to patch/remove patches for specific Fedora releases. Nothing is stopping F44 from getting 7.2. The only time I do not rebase is if the rebase is within 30 days or so of EOL, and even then, I do backport securty fixes until EOL. Justin > -Ian > > -Ian > -- > _______________________________________________ > devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] > Do not reply to spam, report it: > https://forge.fedoraproject.org/infra/tickets/issues/new -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
