Avoiding Future Security Bug Regressions

[Bradley Baetz]

On Thu, Feb 5, 2009 at 12:18 PM, Max Kanat-Alexander
<mkanat at bugzilla.org> wrote:
>> What we could have done is to put out an rc, with the promise that the
>> only difference to the final would be any regression fixes from the
>> security patch (and the version number bump).
> I think that would be confusing and difficult, since that would
> be two release processes, and we don't have any mechanisms in place to
> have RCs of point releases.

True, but it'd be less confusing and difficult than releasing another
security fix the next day, then another one shortly for any other
regression fixes.

>> Admins on public
>> instances could have upgraded and would have been no worse off, while
>> internal/less critical installations could have waited.
>
>        In this particular case public instances would have been much
> worse off--private attachments were accessible with a predictable token
> when before they were secure. All existing CSRF protection was
> defeated. Internal installations were always fine.

Well, the token was repeatable not necessarily predictable or usable
(the tokens are invalidated after use, so an attacker would have to
get in between the request and the redirecct). Not that thats much
better....

This particular issue was different to most, both because it was
obvious what was changing and because it was very invasive. In general
I'm agreeing with your original mail, but where the fix and issue is
obvious even without the code, what do we do for the other sites?

Bradley