>On Tue, 4 Aug 1998, Alan Cox wrote:
>> Its actually very hard to get anything beyond a denial of service attack
>> via libc vectors. Its doable
[... more about stack stuff ...]
I don't want to add to this discussion, but IMHO two things surfaced
in this discussion:
- There is an official kernel where you call the shots
- There are some unofficial "real world" extensions:
- Security patch (noexec-stack, the fd patch ...)
- Crypto-patch (CIFS, crypto fs ...)
- devfs patch
... and so on ...
One of these are collected in a centralized repository structure from
ftp.kernel.org onward to all the mirrors.
The others are collected in various unrelated sites with at least no
"real" mirroring structure.
The result is, that many people use the "mainstream baseline" kernel
and many other collect their additions from lots of sites, get old
patches, build unstable systems and will sometimes move away from
Linux because of these problems.
I would propose to all "official" versions of Linux a "semi-official"
contrib counterpart. Here another maintainer could collect these
patches and keep them up to date with the mainline kernel.
It may be true that you does not want to see the no-exec patch in the
main kernel but how about some "contrib-security-2.1.11x.patch.gz"
which can be cleanly applied to the linux-2.1.11x.tar.gz archive and
adds all these features.
If there are maintainers for say, security and crypto, and if you are
willing to tolerate (and cooperate with) these maintainers, we could
get a stable and working structure to maintain and distribute such
patches (except where void as in some of the more brain dead parts of
the world). And if this would be overlaid to the "kernel.org"
structure, we could also get a consistent view to the linux baseline
kernel and the various real-world additions.
It would depend however on at least some form of cooperation with the
main kernel maintainers (e.g. you for 2.x, x>0 and Alan for 2.0).
(We were once talking about world domination. To achieve this, we may
need some additions that must not in the main kernel or you don't want
to see in the main kernel but nevertheless are necessary to achieve
this goal. So it would IMHO a step forward to at least tolerate such
additions and the needs of us real world people...)
-- Dipl.-Inf. Henning P. Schmiedehausen -- email@example.com TANSTAAFL! Consulting - Unix, Internet, Security
Hutweide 15 Fon.: 09131 / 50654-0 "There ain't no such D-91054 Buckenhof Fax.: 09131 / 50654-20 thing as a free Linux"
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html