[gentoo-dev] Regarding long delays on GLSA generation

[gentoo-dev] Regarding long delays on GLSA generation

[Pacho Ramos]

Was looking to existing gedit bug reports and I found:
https://bugs.gentoo.org/show_bug.cgi?id=257004

That is only one more example of a really old bug report still opened
and waiting for a GLSA. Was wondering what really causes this long
delays, can't GLSA be done automatically? Would a GLSA even have any
sense for cases like this (after 5 years)

Thanks for your help

Re: [gentoo-dev] Regarding long delays on GLSA generation

[Alex Legler]

On 18.01.2014 16:34, Pacho Ramos wrote:
> Was looking to existing gedit bug reports and I found:
> https://bugs.gentoo.org/show_bug.cgi?id=257004
> 
> That is only one more example of a really old bug report still opened
> and waiting for a GLSA. Was wondering what really causes this long
> delays, can't GLSA be done automatically?

Nope. But we do make constant refinements to speed up the process.

> Would a GLSA even have any
> sense for cases like this (after 5 years)
> 

Yope. (I've answered this questions a trillion times by now, so care to
use $searchengine?)

> Thanks for your help
> 
> 

Not sure what you wanted to achieve by sending this email. Posting
$old_bug assigned to a specific team to -dev to point fingers at them is
just lame, as I'm pretty sure there's bug skeletons in every team's closet.

Appreciatively of your appreciation of our efforts,
Alex

-- 
Alex Legler <a3li@gentoo.org>
Gentoo Security/Ruby/Infrastructure

Re: [gentoo-dev] Regarding long delays on GLSA generation

[Pacho Ramos]

El sáb, 18-01-2014 a las 17:02 +0100, Alex Legler escribió:
> On 18.01.2014 16:34, Pacho Ramos wrote:
> > Was looking to existing gedit bug reports and I found:
> > https://bugs.gentoo.org/show_bug.cgi?id=257004
> > 
> > That is only one more example of a really old bug report still opened
> > and waiting for a GLSA. Was wondering what really causes this long
> > delays, can't GLSA be done automatically?
> 
> Nope. But we do make constant refinements to speed up the process.
> 
> > Would a GLSA even have any
> > sense for cases like this (after 5 years)
> > 
> 
> Yope. (I've answered this questions a trillion times by now, so care to
> use $searchengine?)
> 
> > Thanks for your help
> > 
> > 
> 
> Not sure what you wanted to achieve by sending this email. Posting
> $old_bug assigned to a specific team to -dev to point fingers at them is
> just lame, as I'm pretty sure there's bug skeletons in every team's closet.
> 
> Appreciatively of your appreciation of our efforts,
> Alex
> 

What I want to achieve is to try to get this problem solved, I don't
think has any sense to have pending GLSA bugs waiting for ages (yes,
ages), I see this for really a lot of packages, the pointed one was only
one example, but there are many more (like glib, dotnet stuff...)

Regarding sending this to the whole list (well, I don't understand why
people in security team want to not get gentoo-dev ML involved), I
simply did that as I though maybe some help/suggestions could be needed
taking care clearly the security team is not able to fix this situation
for really a long time and, hopefully, some other people could help with
their effort and ideas to fix this long standing issue.

The issue is still present even if we don't talk about it and keep
simply ignoring all bug reports assigned to security and accumulating
for years. The idea is to try to solve the situation, not to point to
you, I didn't pointed to you, you will know why do you feel offended
about this.

Re: [gentoo-dev] Regarding long delays on GLSA generation

[Dirkjan Ochtman]

On Sat, Jan 18, 2014 at 5:30 PM, Pacho Ramos <pacho@gentoo.org> wrote:
> What I want to achieve is to try to get this problem solved, I don't
> think has any sense to have pending GLSA bugs waiting for ages (yes,
> ages), I see this for really a lot of packages, the pointed one was only
> one example, but there are many more (like glib, dotnet stuff...)

From my perception, the security team in recent months has gone
through great lengths to improve the process and to work on the
backlog of old security bugs. AIUI, this *is* getting fixed, it just
takes some time to fix it properly.

Cheers,

Dirkjan

[gentoo-dev] Re: Regarding long delays on GLSA generation

[Duncan]

Dirkjan Ochtman posted on Sat, 18 Jan 2014 17:33:36 +0100 as excerpted:

> On Sat, Jan 18, 2014 at 5:30 PM, Pacho Ramos <pacho@gentoo.org> wrote:
>> What I want to achieve is to try to get this problem solved, I don't
>> think has any sense to have pending GLSA bugs waiting for ages (yes,
>> ages), I see this for really a lot of packages, the pointed one was
>> only one example, but there are many more (like glib, dotnet stuff...)
> 
> From my perception, the security team in recent months has gone through
> great lengths to improve the process and to work on the backlog of old
> security bugs. AIUI, this *is* getting fixed, it just takes some time to
> fix it properly.

Same here. I've been glad to see the GLSAs moving again, even if seeing 
LWN mention that it's a three-year-out (or was it five?) notice is a 
bit ... gulp-worthy... even if on ~arch plus hard-unmasked pre-release 
overlays I rarely see a GLSA that actually applies to me.  (Tho I'd just 
done the NTP update, noting the security issue from the changelog, and 
was glad to see the official GLSA for it with additional detail.)

Still, if it's five years out and catching up, at least we have people 
working on it now and it's happening! =:^)

But it's good to see this thread with the details posted.  There was 
mention that it had been discussed on dev before, but if so, I hadn't 
seen it, at least in that detail.  So I believe it was a reasonable 
question, with now a reasonable answer. =:^)

Thanks again.  That's a vital bit of gentoo that got stuck for a bit, and 
I'm very appreciative that /someone/ is doing that hard and unglamorous 
work without a lot of thanks. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Regarding long delays on GLSA generation

[Pacho Ramos]

El sáb, 18-01-2014 a las 17:30 +0100, Pacho Ramos escribió:
[..]
> The issue is still present even if we don't talk about it and keep
> simply ignoring all bug reports assigned to security and accumulating
> for years.

[Bah, the touchpad]

I was referring the, until know, I was simply ignoring that bug reports
but I thought that maybe more could be done to fix the situation

>  The idea is to try to solve the situation, not to point to
> you, I didn't pointed to you, you will know why do you feel offended
> about this.
> 
> 

Re: [gentoo-dev] Regarding long delays on GLSA generation

[Alex Legler]

On 18.01.2014 17:30, Pacho Ramos wrote:
> […]
> 
> What I want to achieve is to try to get this problem solved, I don't
> think has any sense to have pending GLSA bugs waiting for ages (yes,
> ages), I see this for really a lot of packages, the pointed one was only
> one example, but there are many more (like glib, dotnet stuff...)

Your message is profoundly lacking any proposed solutions, however it
does contain plenty of complaining. That's not a good way to solve problems.

> 
> Regarding sending this to the whole list (well, I don't understand why
> people in security team want to not get gentoo-dev ML involved), I
> simply did that as I though maybe some help/suggestions could be needed
> taking care clearly the security team is not able to fix this situation
> for really a long time and, hopefully, some other people could help with
> their effort and ideas to fix this long standing issue.

Assuming that posing to -dev generates magical help or solutions is
quite naive. You're not the first one to post here, but and you're
certainly not the first one whose message didn't help in the slightest.
Thanks for trying though.

As others on the list have noticed, we are working on fixing things.
Your diagnosis of us being 'clearly' unable to do so is quite
unsubstantiated. You should understand that we can't just make a bug
pile gathered over years disappear in one day.

> 
> The issue is still present even if we don't talk about it and keep
> simply ignoring all bug reports assigned to security and accumulating
> for years. The idea is to try to solve the situation, not to point to
> you, I didn't pointed to you, you will know why do you feel offended
> about this.
> 
> 

Noone's offended here. I'm just saying your email doesn't serve a
purpose. If a -dev post was the solution, we'd have it by now. If you'd
like to help in a way we actually think is useful, we'd be glad to have
you fill one of our staffing needs posted or to engage in the
discussions we have on the -security list and on IRC.

-- 
Alex Legler <a3li@gentoo.org>
Gentoo Security/Ruby/Infrastructure

Re: [gentoo-dev] Regarding long delays on GLSA generation

[Pacho Ramos]

El sáb, 18-01-2014 a las 18:26 +0100, Alex Legler escribió:
> On 18.01.2014 17:30, Pacho Ramos wrote:
> > […]
> > 
> > What I want to achieve is to try to get this problem solved, I don't
> > think has any sense to have pending GLSA bugs waiting for ages (yes,
> > ages), I see this for really a lot of packages, the pointed one was only
> > one example, but there are many more (like glib, dotnet stuff...)
> 
> Your message is profoundly lacking any proposed solutions, however it
> does contain plenty of complaining. That's not a good way to solve problems.
> 
> > 
> > Regarding sending this to the whole list (well, I don't understand why
> > people in security team want to not get gentoo-dev ML involved), I
> > simply did that as I though maybe some help/suggestions could be needed
> > taking care clearly the security team is not able to fix this situation
> > for really a long time and, hopefully, some other people could help with
> > their effort and ideas to fix this long standing issue.
> 
> Assuming that posing to -dev generates magical help or solutions is
> quite naive. You're not the first one to post here, but and you're
> certainly not the first one whose message didn't help in the slightest.
> Thanks for trying though.
> 
> As others on the list have noticed, we are working on fixing things.
> Your diagnosis of us being 'clearly' unable to do so is quite
> unsubstantiated. You should understand that we can't just make a bug
> pile gathered over years disappear in one day.
> 
> > 
> > The issue is still present even if we don't talk about it and keep
> > simply ignoring all bug reports assigned to security and accumulating
> > for years. The idea is to try to solve the situation, not to point to
> > you, I didn't pointed to you, you will know why do you feel offended
> > about this.
> > 
> > 
> 
> Noone's offended here. I'm just saying your email doesn't serve a
> purpose. If a -dev post was the solution, we'd have it by now. If you'd
> like to help in a way we actually think is useful, we'd be glad to have
> you fill one of our staffing needs posted or to engage in the
> discussions we have on the -security list and on IRC.
> 

Then, how are you finally going to fix this? Only for knowing, I still
was seeing some delays and, then, I though situation was not improved.
For example, since this year started, I have only seen 8 GLSAs filled:
http://www.gentoo.org/security/en/glsa/

Then, I thought something was still wrong as that rate didn't seem
enough to me for handling upcoming security issues and the really old
ones. Also, if you that 8 GLSAs, you will see the only one that has been
done in a fast way is the ntp one, the other 7 took months (or years) to
be handled.

Then, instead of blaming on how should I have asked for clarification on
this (well, looks like the main topic here is that I have asked about
this in ML instead of the real problem :O), I think you should focus on
explaining how are you fixing this problem. I have been long time
wondering about this because:
1. I usually get lots of bugs from alias I am a member whose we go fast
bumping, calling for stabilization and dropping vulnerable versions and,
the, the bugs get stalled.
2. Once of the machines I maintain would benefit from being able to use
glsacheck to only update vulnerable packages as not always have enough
time for updating the full world

Re: [gentoo-dev] Regarding long delays on GLSA generation

[Alex Legler]

On 18.01.2014 18:38, Pacho Ramos wrote:
> […]
> 
> Then, how are you finally going to fix this?

Thank you for finally showing interest in anything we do. Here is how we
are 'finally' going to fix this.

> Only for knowing, I still
> was seeing some delays and, then, I though situation was not improved.
> For example, since this year started, I have only seen 8 GLSAs filled:
> http://www.gentoo.org/security/en/glsa/

Er, we're 18 days in…

You shouldn't look at this purely by the numbers, you should see that we
have now again a steady stream of advisories going not. No gaps like
from 2013-01 to 2013-07. That is largely the effort of the
recently-joined members.

> 
> Then, I thought something was still wrong as that rate didn't seem
> enough to me for handling upcoming security issues and the really old
> ones. Also, if you that 8 GLSAs, you will see the only one that has been
> done in a fast way is the ntp one, the other 7 took months (or years) to
> be handled.

So you observed correctly there's still plenty of delays. There are
three parts to an advisory that take time:
- Drafting: Collecting information, linking references, getting package
versions done right (slots are a huge pain still).

- Reviewing: Our current process asks for two independent positive
reviews from other team members before an advisory can be sent.

- Sending: The original author gets a .txt to email and have to check in
the .xml to CVS.

Going through these three steps requires at least three people, and the
(group of) people whose action is required shifts twice. That overall
process is spot #1 we are planning to improve. The current plan contains
requiring only one review and the reviewer sends the advisory directly.
So we go from author -> reviewer 1 -> reviewer 2 -> author to just
author -> reviewer.

Concerning the single steps here are other measures:
- Drafting: Implement a new GLSA format to
  * reduce the amount of editorial text written by us
  * support slots (makes specifying vulnerable ranges in slotted package
    much easier)
  * (cleanup old stuff no longer needed)

- Reviewing: Reduced editorial text means less to review.

- Sending: We want to improve our tooling to automatically send
advisories and push them to a git repository.

The new GLSA format was up for review on -security last week. Next up
will be getting it specified formally, implemented in our tooling,
glsa-check and a new security.g.o frontend. [1]
Then, we can adopt the new workflow.

> 
> Then, instead of blaming on how should I have asked for clarification on
> this (well, looks like the main topic here is that I have asked about
> this in ML instead of the real problem :O), I think you should focus on
> explaining how are you fixing this problem. 

Your original email didn't reflect actual interest in the details. Now
that we've established you do care, I hope my explanations helped you
out there.

> I have been long time wondering about this because:
> 1. I usually get lots of bugs from alias I am a member whose we go fast
> bumping, calling for stabilization and dropping vulnerable versions and,
> the, the bugs get stalled.
> 2. Once of the machines I maintain would benefit from being able to use
> glsacheck to only update vulnerable packages as not always have enough
> time for updating the full world
> 
> 
> 

[1] Lots of code to be written here. .py+.rb, help wanted!

-- 
Alex Legler <a3li@gentoo.org>
Gentoo Security/Ruby/Infrastructure

Re: [gentoo-dev] Regarding long delays on GLSA generation

[Pacho Ramos]

El sáb, 18-01-2014 a las 19:19 +0100, Alex Legler escribió:
[...]
> So you observed correctly there's still plenty of delays. There are
> three parts to an advisory that take time:
> - Drafting: Collecting information, linking references, getting package
> versions done right (slots are a huge pain still).
> 
> - Reviewing: Our current process asks for two independent positive
> reviews from other team members before an advisory can be sent.
> 
> - Sending: The original author gets a .txt to email and have to check in
> the .xml to CVS.
> 
> Going through these three steps requires at least three people, and the
> (group of) people whose action is required shifts twice. That overall
> process is spot #1 we are planning to improve. The current plan contains
> requiring only one review and the reviewer sends the advisory directly.
> So we go from author -> reviewer 1 -> reviewer 2 -> author to just
> author -> reviewer.

This looks a nice improvement indeed :)

> 
> Concerning the single steps here are other measures:
> - Drafting: Implement a new GLSA format to
>   * reduce the amount of editorial text written by us
>   * support slots (makes specifying vulnerable ranges in slotted package
>     much easier)
>   * (cleanup old stuff no longer needed)

That looks interesting as doing all the draft manually is really a huge
work (with leads to not so enhancement). I am unsure how will the
cleanup be done, as soon as the portage tree doesn't break (due some
other package requiring the old buggy version), why are not all devs
allowed to drop (or, at least, hardmask if needed for some base-system
package :/) the vulnerable versions? Looks like currently security team
waits for maintainers to do that, I try to do it fast but maybe will
take much more time in other situations. I think this could be improved
if other people like security team members or the last one stabilizing
the fixed version could do the cleanup too.

Also, currently looks like, when we (maintainers) get asked to bump the
package fixing it, we tend to wait for security team members to CC
arches, maybe the maintainers could do that directly to gain a bit of
time.

> 
> - Reviewing: Reduced editorial text means less to review.
> 
> - Sending: We want to improve our tooling to automatically send
> advisories and push them to a git repository.
> 
> The new GLSA format was up for review on -security last week. Next up
> will be getting it specified formally, implemented in our tooling,
> glsa-check and a new security.g.o frontend. [1]
> Then, we can adopt the new workflow.
> 
> > 
> > Then, instead of blaming on how should I have asked for clarification on
> > this (well, looks like the main topic here is that I have asked about
> > this in ML instead of the real problem :O), I think you should focus on
> > explaining how are you fixing this problem. 
> 
> Your original email didn't reflect actual interest in the details. Now
> that we've established you do care, I hope my explanations helped you
> out there.
> 

They helped for sure :) and I appreciate them, I simply thought nothing
was being worked out as I explained in previous mail (I was still saying
long delays)

> > I have been long time wondering about this because:
> > 1. I usually get lots of bugs from alias I am a member whose we go fast
> > bumping, calling for stabilization and dropping vulnerable versions and,
> > the, the bugs get stalled.
> > 2. Once of the machines I maintain would benefit from being able to use
> > glsacheck to only update vulnerable packages as not always have enough
> > time for updating the full world
> > 
> > 
> > 
> 
> [1] Lots of code to be written here. .py+.rb, help wanted!
> 

Re: [gentoo-dev] Regarding long delays on GLSA generation

[Pacho Ramos]

El sáb, 18-01-2014 a las 19:35 +0100, Pacho Ramos escribió:
[...]
> They helped for sure :) and I appreciate them, I simply thought nothing
> was being worked out as I explained in previous mail (I was still saying
> long delays)

-> seeing (not sure why I type so wrongly :S)

Re: [gentoo-dev] Regarding long delays on GLSA generation

[creffett]

Oops, didn't send to @-dev.

On Jan 18, 2014 10:58 AM, creffett@gentoo.org wrote:
>
> Short version since I'm on my phone: we're working on reducing the number of fields, can't really auto generate, current blocker is getting two additional devs (beyond the author) to sign off on the GLSA. We are aware of the issues. You could have just asked the team this, not sure why this needed to go to @-dev.
>
> creffett
>
> On Jan 18, 2014 10:34 AM, Pacho Ramos <pacho@gentoo.org> wrote:
>>
>> Was looking to existing gedit bug reports and I found: 
>> https://bugs.gentoo.org/show_bug.cgi?id=257004 
>>
>> That is only one more example of a really old bug report still opened 
>> and waiting for a GLSA. Was wondering what really causes this long 
>> delays, can't GLSA be done automatically? Would a GLSA even have any 
>> sense for cases like this (after 5 years) 
>>
>> Thanks for your help 
>>
>>

Re: [gentoo-dev] Regarding long delays on GLSA generation

[Chris Reffett]

On Jan 18, 2014 1:35 PM, Pacho Ramos <pacho@gentoo.org> wrote:
>
> El sáb, 18-01-2014 a las 19:19 +0100, Alex Legler escribió: 
> [...] 
> > So you observed correctly there's still plenty of delays. There are 
> > three parts to an advisory that take time: 
> > - Drafting: Collecting information, linking references, getting package 
> > versions done right (slots are a huge pain still). 
> > 
> > - Reviewing: Our current process asks for two independent positive 
> > reviews from other team members before an advisory can be sent. 
> > 
> > - Sending: The original author gets a .txt to email and have to check in 
> > the .xml to CVS. 
> > 
> > Going through these three steps requires at least three people, and the 
> > (group of) people whose action is required shifts twice. That overall 
> > process is spot #1 we are planning to improve. The current plan contains 
> > requiring only one review and the reviewer sends the advisory directly. 
> > So we go from author -> reviewer 1 -> reviewer 2 -> author to just 
> > author -> reviewer. 
>
> This looks a nice improvement indeed :) 
>
> > 
> > Concerning the single steps here are other measures: 
> > - Drafting: Implement a new GLSA format to 
> >   * reduce the amount of editorial text written by us 
> >   * support slots (makes specifying vulnerable ranges in slotted package 
> >     much easier) 
> >   * (cleanup old stuff no longer needed) 
>
> That looks interesting as doing all the draft manually is really a huge 
> work (with leads to not so enhancement). I am unsure how will the 
> cleanup be done, as soon as the portage tree doesn't break (due some 
> other package requiring the old buggy version), why are not all devs 
> allowed to drop (or, at least, hardmask if needed for some base-system 
> package :/) the vulnerable versions? Looks like currently security team 
> waits for maintainers to do that, I try to do it fast but maybe will 
> take much more time in other situations. I think this could be improved 
> if other people like security team members or the last one stabilizing 
> the fixed version could do the cleanup too. 
We prefer that the maintainers do the drop in case there's some dependency situation we're not aware of, but we will drop if maintainers are unresponsive.

> Also, currently looks like, when we (maintainers) get asked to bump the 
> package fixing it, we tend to wait for security team members to CC 
> arches, maybe the maintainers could do that directly to gain a bit of 
> time. 
By all means, maintainer should be the one to call for the stable. It's your package, I cannot think of any situation where security would not want the maintainer to do that.

> > 
> > - Reviewing: Reduced editorial text means less to review. 
> > 
> > - Sending: We want to improve our tooling to automatically send 
> > advisories and push them to a git repository. 
> > 
> > The new GLSA format was up for review on -security last week. Next up 
> > will be getting it specified formally, implemented in our tooling, 
> > glsa-check and a new security.g.o frontend. [1] 
> > Then, we can adopt the new workflow. 
> > 
> > > 
> > > Then, instead of blaming on how should I have asked for clarification on 
> > > this (well, looks like the main topic here is that I have asked about 
> > > this in ML instead of the real problem :O), I think you should focus on 
> > > explaining how are you fixing this problem. 
> > 
> > Your original email didn't reflect actual interest in the details. Now 
> > that we've established you do care, I hope my explanations helped you 
> > out there. 
> > 
>
> They helped for sure :) and I appreciate them, I simply thought nothing 
> was being worked out as I explained in previous mail (I was still saying 
> long delays) 
>
> > > I have been long time wondering about this because: 
> > > 1. I usually get lots of bugs from alias I am a member whose we go fast 
> > > bumping, calling for stabilization and dropping vulnerable versions and, 
> > > the, the bugs get stalled. 
> > > 2. Once of the machines I maintain would benefit from being able to use 
> > > glsacheck to only update vulnerable packages as not always have enough 
> > > time for updating the full world 
> > > 
> > > 
> > > 
> > 
> > [1] Lots of code to be written here. .py+.rb, help wanted! 
> > 
>
>
>

Re: [gentoo-dev] Regarding long delays on GLSA generation

[Pacho Ramos]

El sáb, 18-01-2014 a las 13:57 -0500, Chris Reffett escribió:
[...]
> We prefer that the maintainers do the drop in case there's some
> dependency situation we're not aware of, but we will drop if
> maintainers are unresponsive.
> 
[...] 
> By all means, maintainer should be the one to call for the stable.
> It's your package, I cannot think of any situation where security
> would not want the maintainer to do that.

OK, will take care of it in the future

Thanks!