On 1/11/14, 5:02 AM, Jeff Trawick wrote:
> I think a lot of your concerns revolve around assessment of when a
> vulnerability can be disclosed, and that has to be determined on a case by
> case
> basis. The vote is just about whether there will be an in-between situation
> where we share some information we have (the code change) without sharing the
> rest, vs. deciding that, separate from the timing of how we release
> information
> about a vulnerability, we either release all we have (code + impact) or none
> of it.
I guess my point is that there is a lot of process involved in not having that
in-between situation. The vast majority of the situations do not present a
critical threat. It's a serious effort to take on that task.
How do you see the release process working if you delay committing code until
we're ready to announce the vulnerability?
Are security advisories going to be separated from releases?
Will the advisories include patches for released versions? If so does that
constitute a release and require a vote? If so how does that vote take place?
If we're not putting out advisories when the code is committed, how do we
expect users to know about the fixes?
If we're not putting out releases with the advisories: For users that are
dependent on only using released version (binary packages that don't patch,
have policies against patching, etc...) are we committed to limiting the time
between that code commit/advisory and a release version? Are we committed to
releasing all supported versions at roughly the same time? Are we not
concerned that we're increasing the time frame that these users receive the
fixes since there is now a gap between us describing the vulnerability and the
release being available to package.
I know there are fixes that impact security that slip through the gaps.
Compare this change (which was handled as a security issue):
*) SECURITY: CVE-2013-1896 (cve.mitre.org)
mod_dav: Sending a MERGE request against a URI handled by mod_dav_svn with
the source href (sent as part of the request body as XML) pointing to a
URI that is not configured for DAV will trigger a segfault. [Ben Reser
<ben reser.org>]
vs this change (which was not):
*) mod_dav: When a PROPPATCH attempts to remove a non-existent dead
property on a resource for which there is no dead property in the same
namespace httpd segfaults. PR 52559 [Diego Santa Cruz
<diego.santaCruz spinetix.com>]
What happens when someone commits a fix for something like this without
considering the possible security implications? Is someone going to
immediately update the log message to point out the security impact?
Given that the issues are usually relatively minor and that they've usually
existed for a long time I'm not sure that the level of effort such a change
would constitute a positive change. I'm all for keeping things as confidential
as can be done, but I don't think that you can make a policy decision like this
without considering all the support for the decision.
If we can't resolve some of these issues, the policy may have a negative effect
on the security of our users. I suspect there are very few people interested
in monitoring all our commits for security issues. The signal to noise ratio
is too low to justify it.
However, once you start including CVE numbers in every issue immediately upon
commit then it will be very easy to monitor for these issues. That creates the
opportunity for exploitation that may not have existed before.
As such I don't think given what discussion has gone on so far that I'm
comfortable voting for the mandatory option. I could be convinced to vote for
it with the effort to make the decisions necessary to support it. But based on
the votes cast so far I guess my vote really won't matter. So consider this
email as asking how you plan to implement your policy.
