Bug#1053559: Feature: argon2id support

[Julian Andres Klode]

On Fri, Oct 06, 2023 at 01:36:04PM +0300, Alexey Kuznetsov wrote:
> > Feel free to land the support upstream, but it's not something that
> > we should be shipping downstream.
> 
> I report upstream. But seems like it not going to be fixed anytime
> soon. So, I share my smartmem.patch here. But I have no idea how it
> works here at Debian. Maybe I better to keep it as is, rebuilding grub
> locally.

Regarding the memory allocation, it is much more complex than you think
it is. Unfortunately plenty of devices have broken firmware and will
fail to work with allocations over 4GB, some just DMA files to different
regions when you pass them high memory.

Luckily we managed to fit most initrds into 4GB now so we're probably
safe for now if you don't do crazy things like high-memory password
hashing.

> 
> > Going forward, for secure boot, our focus is not on adding things,
> but on removing
> > existing things like f2fs file support again. It stands to reason
> > that encrypted /boot should not be supported either as there is no
> > practical use case (it is security by obscurity) and you are better
> > served by an unencrypted boot with a pre-built signed initrd or
> > a MOK-signed initrd (or really UKI), and decrypting untrusted data
> > hence is unnecessary danger.
> > 
> 
> Saying things I put in my pocket are untrusted, but items gaven to me
> by other guys with sign, are trusted?! That how security treated here
> at debian from all members?

I have absolutely no idea what you're saying, but as you may have seen
by the recent CVE again, we have a lot of problem with code quality and
need to minimize the attack surface as much as reasonably possible.

> 
> Beside security point, having hudge many GB boot partition with all
> kernel installed is a pain. I keep my EFI under 50MB for binaries to
> boot.

In an optimal world, /boot would be a separate FAT partition (or well
the ESP directly) and kernels would be copied there [and would be UKI
with pre-built initrd] and we would not have any support for other
file systems or luks or crap. Heck optimally we'd not have any disk
drivers and file systems and just use the firmware implementations :D

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en