[gnutls-devel] handling security issues

[Daniel P. Berrange]

On Wed, Feb 22, 2017 at 04:42:46PM +0100, Nikos Mavrogiannopoulos wrote:
> On Wed, Feb 22, 2017 at 1:19 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> > On Wed, Feb 22, 2017 at 01:16:00PM +0100, Nikos Mavrogiannopoulos wrote:
> >> On Tue, Feb 21, 2017 at 2:06 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> >> > On Tue, Feb 21, 2017 at 01:38:45PM +0100, Nikos Mavrogiannopoulos wrote:
> >> >> Hi,
> >> >>  I've tried to make the current ad-hoc handling of security issues
> >> >> with something more formally defined at:
> >> >> https://gitlab.com/gnutls/gnutls/blob/master/SECURITY.md
> >> >>
> >> >> My goal is to establish some more objective criteria than my opinion
> >> >> on when an issue will be handled as a security issue and an advisory
> >> >> will be issued. In the text above I've used the CVSS scoring which
> >> >> seems to be generic and objective enough. Any comments or suggestions
> >> >> on the above text?
> >> > The text indicates a permissible 3 month window between bug report
> >> > and comitting of a fix. Can you clarify that further, in particular
> >> > does that mean you'd accept requests for many month long embargo
> >> > periods on non-public bug reports ?
> >>
> >> I meant it to be as an upper bound on the time between report and fix.
> >> Do you suggest that we make a distinction between that time and the
> >> acceptable embargo time imposed by reporters?
> >
> > Yeah, if you consider acceptable embargo times to be different/less than
> > this 3 month upper bound for code fix, then I think it'd be worth making
> > that explicit so people don't mis-interpret it as I did.
> 
> Do you mean something like amending with:
> "Issues reported by third parties which request an embargo time of less than
> two weeks are granted. Otherwise the issue is handled as soon as possible
> and committed at two weeks time, or when available."

Yeah, something like that is reasonable.

FWIW, as a point of reference, for libvirt we wrote[1]

 "The general aim of the team is to have embargo dates which are two 
  weeks or less in duration. If a problem is identified with a proposed
  patch for a security issue, requiring further investigation and bug 
  fixing, the embargo clock may be restarted. In exceptional circumstances
  longer initial embargoes may be negotiated by mutual agreement between
  members of the security team and other relevant parties to the problem.
  Any such extended embargoes will aim to be at most one month in duration." 

Regards,
Daniel

[1] http://libvirt.org/securityprocess.html
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|