Hello, Okuji!
> > Please stop this code bloat! Just the fact that people want (or even
> > implement) some features doesn't mean that such code should become part of
> > the official GNU GRUB.
>
> IMO, any kind of code should be included in GNU GRUB, unless it
> violates GRUB's policy (which is very ambiguous, though). I believe
> that local patches are evil, generally speaking.
Just to make your point more precise, they are evil when they are used
outside the area they were designed for.
> > The console should be properly secured. The keyboard can be secured. The
> > serial line can be secured. Ethernet is much harder to secure. There
> > are often hundreds computers on the same segment.
>
> As far as one uses the network support, he must always trust that
> his local net is enough secure, anyway, because we don't use any
> secure transport protocol, like SSH. Then, why is it less secure to
> add network console support?
It is not less secure than TFTP, but encryption _assumes_ better security.
We shouldn't fool users and give them code that only makes any difference
under very limited conditions.
One thing that could improve security in a generic situation would be
two-way authentication between the client (GRUB) and TFTP server. But it
is not what was proposed in this case.
> > GNU GRUB, as it is released by FSF, should not (IMHO) ship with potential
> > security holes, splash screens, startup sounds, embedded IPv6, kerberos
> > and OpenGL support :-)
>
> I can't see what is your criterion of if a thing should be official
> or not. I myself have no objection to adding startup sounds support
> into GNU GRUB, as long as I can disable the feature. ;)
My criterion was:
1) We don't want optional features that require support for more than one
piece of hardware except network cards. I.e. sounds are Ok as long as you
don't have to add support for different sound cards (e.g. only PC Speaker
is used). Graphics is Ok as long as it's for VGA.
2) We don't want support for protocols of any kind that require a
full-blown OS to be implemented correctly and securely, unless there is
already a commonly used protocol, regardless of how insecure it is. I.e.
RARP is Ok while Kerberos is not.
> > But I hope that fixing Linux zImage support will have higher priority.
>
> ? I have already announced that GRUB can boot zImage.
Sorry, I missed your announcement. Indeed, it works now. Thank you!
Regards,
Pavel Roskin
