we'll see :)
nor did i say that (actually, what i said is that it didn't belong into
the commit message, see below for more).
you're wrong on that however. it is important for many people to able
to perform the same verification that you do. just imagine the backports
to versions that you don't do yourselves. but organizing the dissemination
of such code is not what i've been talking about all this time.
don't mistake my presence in this thread as me, an invidual arguing for his
own benefit. i already know when you fix security bugs, even when you don't
sometimes. so when i say something is relevant, it's not merely my opinion,
it's what most people dealing with security issues (both inside and outside
the linux universe) think. with that said, let's move on:
you keep saying that, but you don't explain *why*.
fine with me, i wasn't talking about that at all though ;).
fully understood and agreed. never even asked for that.
agreed (with the same additonal thoughts as above on the trigger code).
ok, so let's make it simpler for everyone to understand what is at issue
here. it seems that we agree that there're several levels of information
that exist when it comes to security bugs and we don't understand each
other as to what should go into a commit and what should stay out. let
me propose a categorization and you tell me what you think you would be
willing to put into a commit (feel free to break them up further if that's
what it takes).
1. simple words/phrases that one can grep for (mentally or automated)
examples: 'security', 'exploitable', 'DoS', 'buffer overflow', etc
2. simple sentence describing roughly what kind of security bug it is
example: fix exploitable null function pointer dereference in foo.
3. sample code able to trigger the bug and cause an oops/crash but not
privilege elevation, no effort made to be 'weapons grade' (does not
support several archs, kernel versions, etc)
4. proof-of-concept exploit that triggers the bug, and demonstrates its
effect (say privilege elevation) with manual tweaking (say, you look
up an address in System.map and the like, but nothing automated)
5. full blown weaponized exploit
i believe 3-5 are definitely not commit message material. 1 or 2 are.
5 should never be published or disseminated, 3 and 4 may be distributed
to interested parties.
cheers,
PaX Team
--
