[Development] Submitting Qt to oss-fuzz

[Edward Welbourne]

El divendres, 31 d’agost de 2018, a les 10:27:08 CEST, Edward Welbourne va escriure:
>> By "fixed" do they mean "we have told them we've fixed it" or "we've
>> released all currently releasing branches of Qt with fixes" ?

Albert Astals Cid (31 August 2018 10:52)
> Fixed means "the daily bot has run again and it has found that what
> was wrong before is now fine"

OK, so that'll be shortly after we release an update to whatever branch
they're testing.  I suppose we have some say in which version they test,
so we could start with LTS and work our way closer to the bleeding edge
as we get all our old horrors out of the way - and maybe one day get to
test live on dev.

>> So it would be better to run this *ourselves*, if we can, so that the
>> Qt community has more control over how and when the results get to be
>> published.

> This is scarily close to the security by obscurity argument ;)
>
> "what if we have an horrible bug, we fix it, it becomes public in 30
> days and we've not been able yet to put out a release?"
>
> My answer to that is, you had an horrible bug, it's fixed, that is a
> great thing, so just put and advisory out with the patch if we can't
> get a release out.

Yet we have a security group, whose business is to manage the timing of
advisories and co-ordinate those with releases.  I'm not saying we
should try to hide our dirty laundry; just that we should let our
security team actually have a chance to have some control over the
things they're there to control.

>> So it *can* be used locally, without giving Google yet more power ...
>> Good to know.

> But you lose the daily bot runs and the free hardware. I am not sure,
> but i think the bot part is not actually free software, though i may
> be wrong. Also when i run it, it stops at the first found issue, i
> guess there may be a parameter to have it continue since the bot will
> find N issues in a given day.

Indeed, running it ourselves would be One More Thing that the poor
infrastructure team would have to take care of, and One More System to
maintain; all the more so if we have to implement our own replacement
for some non-free parts.  So the question is whether the impedance
mismatch - between Google's disclosure time-line (optimised for
Chromium-style software that doesn't care about old versions or
backwards-compatibility) and our security team's processes - is a big
enough issue that it's worth going to all that effort ourselves ...

I'm not saying "let's not do this" only "let's just think about this for
a moment, first" - in particular, about how it'll interact with our
existing security and release processes,

	Eddy.