[Cryptography] Would open source solve current security issues? (was "Re: EFF amicus brief in support of Apple")

Jerry Leichter leichter at lrw.com
Thu Mar 10 06:28:48 EST 2016


I agree overall, but want to point out one additional bias in the data:

> Where the data is mostly clear is that "time to fix" once a security vulnerability is made public (say, with 0days) is much quicker for getting an initial fix for open source projects than it is for closed source projects.
It depends on the kind of patch and the length of supply lines.

Open source projects can very quickly ship a source patch for the particular module involved.  This is fine for those who build from source - a tiny minority.

The next step is getting the patch into a binary build.  Depending on the project to which the patch is made, that can take a couple of days.  The delays can also mount for the more branched distributions.  SuSE Linux, for example, always seems to take longer than many of the more mainstream distributions because they have their own variants of all the patches.  (Exactly what's different and why, I don't know, but their version id's are consistently different - which causes all kinds of grief for audits based on "version x.y.z and earlier have the bug".)  We're not talking big numbers - a couple of days at most - but the effect is there.

Beyond that, of course, are products built on top of the binary distributions - and products built on top of *them*.  All of these take time to incorporate changes and push them out to clients.  Some - most famously Android phones, all the way at the end of supply lines running through handset makers and Telco's - never receive the changes at all.

That's all open source.  On the closed source side, all the supply chains and testing and related processes are internalized.  There is, of course, never a source code patch.  But the closed source suppliers - pushed by their customers - are these days loath to push large numbers of small patches.  Hence the "patch Tuesday" phenomenon.  This also puts more pressure on them to test - all the way down the supply chain - since "fixing the fix" if it goes wrong is also disruptive.

So, again, there's theory and there's reality.  In theory, open source can get a patch out very quickly - and users who are willing to track the latest patches, in source, continuously, can apply them very quickly.  In practice, this mainly applies to a small coterie of developers of the software.  Others have to wait for the patch to make it through the layers of distributions - and on top of that, while open source projects may not have a "patch Tuesday" distribution policy, most sites have some kind of "patch day" *intake* policy since no one wants to spend all their time updating their systems.

The net effect is, I suspect, close to a wash in terms of *actual spread of security patches throughout the community of users*.  Open source probably wins if you measure actual time, but not by much.

Of course, there are always the high-priority emergency patches - e.g., Heartbleed.  Recently, these have been reported to the software vendors privately and coordinated announcements and releases of patches have been standard.  In this case, the delays were all "up front", before the announcement - and the differences between open and closed source have *largely* been nil.  (Apple delayed on shipping a Heartbleed patch - but then it was pretty much irrelevant to the vast majority of their devices, which don't run HTTP servers.)

I think the important take-away from the whole discussion is that these are *systems* issues and have to be analyzed at that level.  How long it takes for someone to get out there and produce a patch is dwarfed by the time it takes for working secure code to actually get deployed on a significant proportion (ideally, all!) vulnerable systems.  Both open and closed source communities have been improving their approaches for a number of years now, and both have (in general - let's not get started on, say, industrial controller makers) improved things, often dramatically.
                                                        -- Jerry



More information about the cryptography mailing list