> I guess the question is, was it really a cover up?
that's easy to answer. using your example, you're saying that it is a matter of opinion whether a security fix says 'security fix' or just 'fix'. by that logic it is also a matter of opinion whether a filesystem corruption fix simply says 'filesystem corruption fix' or 'fix'. we know from existing commits that this opinion thing favours the first kind of description for filesystem corruptions. why does the same opinion favour the second kind then for security fixes? isn't a bug a bug after all? and let's not forget that security bugs (e.g., memory corruption ones) can very well cause filesystem corruption, one would think that they would at least be described as such in the commit, but not even that happens. inquiring minds would like to know the reason for these seemingly inconsequential decisions ;).
> One would not want to revert a commit that is a security fix.
i don't think he said everything he wanted to. my guess is that he would have continued with '...and fix it another way' but that would have given away even more hints as to the severity of the situation (it would have shown that one way or another, something really truly must be done here whereas a casual 'we will revert if needed' will make the less observative reader think that 'ok, nothing really important is going on here, at most i will see a revert in the coming days').