[gentoo-dev] Re: Opinion against /usr merge

[Duncan]

Michael Mol posted on Wed, 18 Jul 2012 15:18:35 -0400 as excerpted:

> On Wed, Jul 18, 2012 at 3:05 PM, Rich Freeman <rich0@g.o> wrote:
>> On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol <mikemol@×××××.com> wrote:
>>> AFAIK, neither genkernel nor dracut were expected to get tied to the
>>> Gentoo update process. Has that changed?
>>
>> We don't even update kernels as part of the regular update process, let
>> alone initramfs systems.
>>
>> In general you update them together.
>>
>> The only issue I could see is if problems arise if you have a different
>> version of udev in your initramfs than on your system.  I don't know if
>> that actually causes problems.  For the most part after the system is
>> booted the initramfs is done its job.
>
> The most widely touted benefit I've heard for initramfs is its
> capability to ease system recovery in case, e.g. a critical filesystem
> refuses to mount. With recovery roles come recovery tools, which quickly
> extends network-aware tools and a security attack surface.
>
> Hence why I tend to feel that if an initramfs is going to become the
> go-to solution for bootstrapping userland, it's important to consider
> the difficulties of keeping the packed tools up-to-date; it's not just a
> bootstrap tool, it's also the first recovery option a sysadmin faces.

As others have stated, that might be /a/ widely touted benefit, but the 
reason for initr* being there in the first place, is to solve the 
otherwise chicken/egg issue of having the tools/modules necessary to 
mount a filesystem, /on/ that filesystem, since now they're on the initr* 
as well, and that is maintained with the kernel.

But meanwhile, recovery /is/ /a/ widely touted benefit, which really 
presents its own problem, in the form of a choice:

a) automatically update the initr* and get the security benefits but risk 
breaking the recovery tools when they break with an update to the main 
system,

OR:

b) don't automatically update the initr* in ordered to keep a known/
tested-working first recovery mechanism, but at the cost of potentially 
unfixed security-vulns in the initr* that were already fixed on the main 
system.

Of course (b) is the usual case on an initr* (unless it's one-size-fits-
all automatically updated by the distro), due to static linking.  So 
security is already taking second priority to a known-working recovery 
mechanism, and updating the initr* on a user-configured/managed distro 
like gentoo pretty much must remain in that user-admin domain.  There's 
simply no way around it, without going the one-size-fits-all-distro-
configured route, which by accepted definition isn't palatable to 
gentooers, or they'd be using something else.

So IMO, updating the initr* is and must remain user-admin domain, not 
something gentoo really can worry about, other than to the extent of 
making those updates as easy and stupid-mistake-proof as can reasonably 
be done while still placing the responsibility of actually configuring 
and maintaining the initr* with the user-admin.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman