On Sat, Nov 13, 2021 at 07:12:44PM +0000, Chuck Lever III wrote: > > Certainly, the kernel could include a single set of base64 encoders > and decoders that can be used by all in-kernel consumers. See for > example net/ceph/armor.c and fs/crypto/fname.c . Not really, there are many variants of Base64 and different policy decisions that can be made: the chosen character set, whether to pad or not pad, whether to allow whitespace, how to handle invalid characters, how to handle invalid padding, whether to nul-terminate, and so on. There's lots of room for bugs and incompatibilities. > > Because PEM decoding does not require any policy decisions, and > because the kernel already has at least two existing partial > base64 implementations, I'm not aware of a technical reason a > system call like add_key(2) should not to accept PEM-encoded > asymmetric key material. Adding kernel UAPIs expands the kernel's attack surface, causing security vulnerabilities. It also increases the number of UAPIs that need to be permanently supported. It makes no sense to add kernel UAPIs for things that can be easily done in userspace. They work well as April Fools' jokes, though: https://lore.kernel.org/r/1459463613-32473-1-git-send-email-richard@xxxxxx Perhaps you meant to save your patch for April 1? - Eric
