Patches & Modules - Questions and your Opinion?
Jean-Michel Brünn
jean.bruenn at ip-minds.de
Mon Mar 17 19:36:51 CET 2008
Hello tchan,
thanks for your answer.
On Mon, 17 Mar 2008 12:15:25 -0500
Terry Chan <tpchan at comcast.net> wrote:
> To date there are probably both types of patches in moonbase. Mostly we strive
> for patches that are only necessary to get a module to compile/run/install
> correctly. Occaisionally we have the patches that are for security updates too,
> but those tend to be in the security-related apps, like moonbase/crypto or
> moonbase/security.
do we have developers reading and having the time to search and look for important security updates? Or is that again the game "if someone saw something, we will decide to use it"? I think it's again the game ;-) As we're doing a non-commercial job by working on, at, with, for lunar linux, thats okay.
Question is now: If some application has a bug. Is it possible to use this bug in a way, we would talk about a security risk? For example: There's a patch because of FIFO for Bash. Here's the description:
Under certain circumstances, when using FIFOs for process substitution,
bash fails to unlink the FIFOs. This leaves open file descriptors that
can cause the shell to hang and litters the file system.
now my question: How many opened file descriptors we need, to consider that as a security risk?
Indeed. Thats a bad example, but i think you know what i mean or what i try to say.
Using Bugfixes is always a good thing, it doesn't matter wether it runs with or without.
> We try NOT to include bash patches, unless someone can show they are absolutely
> critical-type patches. GLIBC patches tend to fall into the same category. Your
> glibc example is moot as glibc is at 2.7 in moonbase currently.
I understand that. But we have here again two ways to look at it:
1. We try NOT to patch bash - I think because lunar is using bash for many things.
2. Lunar is using bash for many things. Wouldn't it be better to be sure that bash is running and that bugs are fixed?
More information about the Lunar-dev
mailing list