On Thu, 2 Feb 2012, dann frazier <email@example.com> wrote: > Whilte it may help the kernel team to not have to worry about problems > in the grsec flavor when preparing uploads, preventing delays for the > non-grsec images. But, that just pushes the coordination down a ways - > for stable updates we would need to add the grsec build into the > pipeline, and there'd be delays in grsec security updates that go in > via linux-2.6. Not nak'ing the idea, but it does extend some critical > paths. The current approach of having a kernel patch package seems to work well. It removes the need for involvement of the kernel and security teams (presumably security changes to the kernel will usually not require changes to the grsecurity patch) and allows the users to easily build their own kernels. If a user has a choice between using Spender's Debian package and a kernel- patch package to build their own kernel then I think that they should be able to do whatever they want. Spender suggested that people who want GRSecurity on Debian would be better off using a .deb he provides and working on user-space hardening. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Met vriendelijke groet,
Kees de Jong
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde(n).
Description: This is a digitally signed message part