From: | Chris Reffett <creffett@g.o> |
---|---|

To: | gentoo-dev@l.g.o |

Cc: | security@g.o |

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

Date: | Sat, 18 Jan 2014 18:57:16 |

Message-Id: | 20140118185711.1855DE0C3B@pigeon.gentoo.org |

1 | On Jan 18, 2014 1:35 PM, Pacho Ramos <pacho@g.o> wrote: |

2 | > |

3 | > El sáb, 18-01-2014 a las 19:19 +0100, Alex Legler escribió: |

4 | > [...] |

5 | > > So you observed correctly there's still plenty of delays. There are |

6 | > > three parts to an advisory that take time: |

7 | > > - Drafting: Collecting information, linking references, getting package |

8 | > > versions done right (slots are a huge pain still). |

9 | > > |

10 | > > - Reviewing: Our current process asks for two independent positive |

11 | > > reviews from other team members before an advisory can be sent. |

12 | > > |

13 | > > - Sending: The original author gets a .txt to email and have to check in |

14 | > > the .xml to CVS. |

15 | > > |

16 | > > Going through these three steps requires at least three people, and the |

17 | > > (group of) people whose action is required shifts twice. That overall |

18 | > > process is spot #1 we are planning to improve. The current plan contains |

19 | > > requiring only one review and the reviewer sends the advisory directly. |

20 | > > So we go from author -> reviewer 1 -> reviewer 2 -> author to just |

21 | > > author -> reviewer. |

22 | > |

23 | > This looks a nice improvement indeed :) |

24 | > |

25 | > > |

26 | > > Concerning the single steps here are other measures: |

27 | > > - Drafting: Implement a new GLSA format to |

28 | > > * reduce the amount of editorial text written by us |

29 | > > * support slots (makes specifying vulnerable ranges in slotted package |

30 | > > much easier) |

31 | > > * (cleanup old stuff no longer needed) |

32 | > |

33 | > That looks interesting as doing all the draft manually is really a huge |

34 | > work (with leads to not so enhancement). I am unsure how will the |

35 | > cleanup be done, as soon as the portage tree doesn't break (due some |

36 | > other package requiring the old buggy version), why are not all devs |

37 | > allowed to drop (or, at least, hardmask if needed for some base-system |

38 | > package :/) the vulnerable versions? Looks like currently security team |

39 | > waits for maintainers to do that, I try to do it fast but maybe will |

40 | > take much more time in other situations. I think this could be improved |

41 | > if other people like security team members or the last one stabilizing |

42 | > the fixed version could do the cleanup too. |

43 | 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. |

44 | |

45 | > Also, currently looks like, when we (maintainers) get asked to bump the |

46 | > package fixing it, we tend to wait for security team members to CC |

47 | > arches, maybe the maintainers could do that directly to gain a bit of |

48 | > time. |

49 | 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. |

50 | |

51 | > > |

52 | > > - Reviewing: Reduced editorial text means less to review. |

53 | > > |

54 | > > - Sending: We want to improve our tooling to automatically send |

55 | > > advisories and push them to a git repository. |

56 | > > |

57 | > > The new GLSA format was up for review on -security last week. Next up |

58 | > > will be getting it specified formally, implemented in our tooling, |

59 | > > glsa-check and a new security.g.o frontend. [1] |

60 | > > Then, we can adopt the new workflow. |

61 | > > |

62 | > > > |

63 | > > > Then, instead of blaming on how should I have asked for clarification on |

64 | > > > this (well, looks like the main topic here is that I have asked about |

65 | > > > this in ML instead of the real problem :O), I think you should focus on |

66 | > > > explaining how are you fixing this problem. |

67 | > > |

68 | > > Your original email didn't reflect actual interest in the details. Now |

69 | > > that we've established you do care, I hope my explanations helped you |

70 | > > out there. |

71 | > > |

72 | > |

73 | > They helped for sure :) and I appreciate them, I simply thought nothing |

74 | > was being worked out as I explained in previous mail (I was still saying |

75 | > long delays) |

76 | > |

77 | > > > I have been long time wondering about this because: |

78 | > > > 1. I usually get lots of bugs from alias I am a member whose we go fast |

79 | > > > bumping, calling for stabilization and dropping vulnerable versions and, |

80 | > > > the, the bugs get stalled. |

81 | > > > 2. Once of the machines I maintain would benefit from being able to use |

82 | > > > glsacheck to only update vulnerable packages as not always have enough |

83 | > > > time for updating the full world |

84 | > > > |

85 | > > > |

86 | > > > |

87 | > > |

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

89 | > > |

90 | > |

91 | > |

92 | > |

All times displayed are in UTC (GMT+0).

Contents reflect the opinion of the author, not the Gentoo project or the Gentoo Foundation.

Gentoo is a trademark of the Gentoo Foundation, Inc. The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-4.0 license. The Gentoo Name and Logo Usage Guidelines apply.