[gnutls-devel] handling security issues

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[gnutls-devel] handling security issues

Nikos Mavrogiannopoulos-2
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?

regards,
Nikos

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] handling security issues

Daniel P. Berrange-2
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 ?

As an app dev using gnutls, I'd like to think the time between security
bugs being reported & info + fix being made public, would be measured
in days, or weeks, and certainly no more than 1 month at a maximum.

Regards,
Daniel
--
|: 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/ :|

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] handling security issues

Nikos Mavrogiannopoulos-2
On Tue, Feb 21, 2017 at 2:06 PM, Daniel P. Berrange <[hidden email]> 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?

> As an app dev using gnutls, I'd like to think the time between security
> bugs being reported & info + fix being made public, would be measured
> in days, or weeks, and certainly no more than 1 month at a maximum.

Certainly and I believe the average time of fixes is typically counted
in days (though fixes get bundled in the monthly based release).
However, there cannot be strict SLAs, but more like recommended
guidelines/principles.

regards,
Nikos

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] handling security issues

Daniel P. Berrange-2
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 <[hidden email]> 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.

> > As an app dev using gnutls, I'd like to think the time between security
> > bugs being reported & info + fix being made public, would be measured
> > in days, or weeks, and certainly no more than 1 month at a maximum.
>
> Certainly and I believe the average time of fixes is typically counted
> in days (though fixes get bundled in the monthly based release).
> However, there cannot be strict SLAs, but more like recommended
> guidelines/principles.

Yep, understood.

Regards,
Daniel
--
|: 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/ :|

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] handling security issues

Nikos Mavrogiannopoulos-2
On Wed, Feb 22, 2017 at 1:19 PM, Daniel P. Berrange <[hidden email]> 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 <[hidden email]> 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."


regards,
Nikos

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] handling security issues

Daniel P. Berrange-2
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 <[hidden email]> 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 <[hidden email]> 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/ :|

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Loading...