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-crypto-userspace-api-phase-1-self-contained/197422 > > (..) > > 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_(TRUECRYPT_AND_VERACRYPT_COMPATIBLE)_EXTENSION > > 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? -- _______________________________________________ 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
