| |||||||||||||
LCA: Bruce Schneier on the two sides of securityLCA: Bruce Schneier on the two sides of securityPosted Feb 1, 2008 12:24 UTC (Fri) by kleptog (subscriber, #1183)Parent article: LCA: Bruce Schneier on the two sides of security
The thought occurred to me that perhaps this is one of the things MS did get right. By having their Patch <day of the week> they provide the feeling that it's all planned, everything is under control. I wonder what would have happened if the Wireshark guys had annouced they were doing a proactive audit and that a new release would happen every first day of the month with all the issues found in the last month. Now, the free software community to too large to coordinate anything like that. But imagine if a distributor decided that all non-critical security updates would happen only on wednesdays, would people "feel" safer due to it being planned, even though you're sacrificing a little security (a few days delay).
(Log in to post comments)
LCA: Bruce Schneier on the two sides of security Posted Feb 1, 2008 21:33 UTC (Fri) by jamesh (guest, #1159) [Link] If you are going to delay disclosure of vulnerabilities, then you need to make sure you aren't leaking information about those vulnerabilities before that date. If the project uses CVS or Subversion, then there is no reason that the bad guys wouldn't be watching the commits. The contents of the commits may be enough for such a person to deduce the vulnerability and be able to exploit it in the window the developers have provided (in addition to the time it takes for people to patch their systems). So you really want to delay exposure of the commits to the same point where you expose the vulnerabilities. With a public CVS/Subversion server, that probably means not committing the work until that point which is not particularly helpful if you have multiple vulnerabilities to track. If you really do want to batch up the security vulnerabilities, perhaps one of the distributed VCS systems would be appropriate. The ability to perform disconnected development also means that it is possible to keep a line of development private but disclose it at a later date with full history, which is what is wanted here.
|
|||||||||||||