On Fri, Dec 16, 2016 at 09:41:08AM -0800, Ryan Sleevi wrote:
>
> Not trying to be snarky - just that if we're going to act upon your
> comment, actionable data and concerns are needed.
>
> Put more concretely:
> - Hypotheticals ("What about software foo?") should not be considered
> unless they're demonstrated
> - If they are demonstrated, the author/maintainers of those packages
> should be engaging with the Mozilla community to represent those
> concerns
>
> So let's say, for example, that Curl was using the Mozilla set, but
> using it with a GnuTLS validator, and was concerned about a direction
> that Mozilla would take - wanting additional time or to push back on
> that. It seems eminently reasonable to expect that both the
> maintainers of Curl and GnuTLS's validator would step up and
> participate, representing those concerns, and be open/amenable to
> changes or to explaining why changes may not work.
>
> Absent that, as an upstream project, it seems entirely reasonable that
> a decision is made, on list, and unless someone comes up with specific
> and concrete objections (with a plan for remediating or exploring the
> problem more), then it goes forward. For example, "This would break
> Curl, and we'd need a new version of GnuTLS to support [X]. Could you
> wait on making this change for 3 months so that we can get a new
> release out?" is a concrete and actionable plan :)
So I guess I should also reply to the rest here.
I am a Debian Developer and an OpenSSL developer, but I'm not
speaking in anybody's name. But I do want to represent concerns
that the general open source community might have that just isn't
active on this list. Maybe more of them should be active here, but
probably they just don't know about it.
In Debian we actually ship libcurl linked against gnutls, nss and
openssl. Just like we ship a whole lot of other software. Almost
all of the software that supports X509 makes use of the Mozilla root
store. There are clearly problems with the way it uses it, but we
should at least avoiding making it worse.
If there are such changes needed in other software, having that
software fixed in 3 month shouldn't acutally be a problem. But
unless someone is going to assign a CVE to it, it's probably not
going to get deployed.
Kurt
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
