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. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development