Re: How to help OpenSSL
I see. Thank you. 2014-04-28 0:48 GMT+08:00 Dr. Stephen Henson st...@openssl.org: On Sun, Apr 27, 2014, Weibin Yao wrote: Is it accessable for read (rt.openssl.org) ? I can't access it and don't know where to register. Read access is possible through the guest account: https://www.openssl.org/support/rt.html Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- Weibin Yao Developer @ Server Platform Team of Taobao __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
Is it accessable for read (rt.openssl.org) ? I can't access it and don't know where to register. 2014-04-27 5:35 GMT+08:00 Matt Caswell fr...@baggins.org: On 25 April 2014 18:24, Kurt Roeckx k...@roeckx.be wrote: On Thu, Apr 24, 2014 at 06:31:34PM +0100, Ben Laurie wrote: 1. Triage RT (https://rt.openssl.org/). I think part of this means that you'll need to give some people access to it so they can actually modify the tickets. I now have access to RT. I'll investigate what can be done to get more people set up. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- Weibin Yao Developer @ Server Platform Team of Taobao __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
On Sun, Apr 27, 2014, Weibin Yao wrote: Is it accessable for read (rt.openssl.org) ? I can't access it and don't know where to register. Read access is possible through the guest account: https://www.openssl.org/support/rt.html Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
I should've said: if a fix is for a potential security issue, please don't create a pull request (they are public), instead send a patch to openssl-secur...@openssl.org. You can create an appropriate patch file by doing something like this: $ git format-patch revision to diff against --stdout your.patch On 24 April 2014 10:06, Ben Laurie b...@links.org wrote: Note that this is just how to help me, not a consensus view from the whole team, though I have no doubt much of it will be helpful to the team, too. 1. Triage RT (https://rt.openssl.org/). RT has been neglected for a long time. People could usefully go through it and identify: a) Tickets that can be closed b) Tickets that should have action taken, and how urgent that action is. If a ticket describes a potential security issue, then please don't just announce it to the list. Instead send it to openssl-secur...@openssl.org. In order to avoid duplication of effort, perhaps someone should set up a github repo (or something else) assigning ranges to volunteers? It might also be useful to use the same repo to hold the triage results (so things can be ticked off as they are actioned). See also points 3, 4 and 5. 2. Triage Github pull requests There are less of these, and I do try to look at them from time to time, nevertheless I think we are behind. 3. Write fixes Where an issue does not come with a patch, write a fix for it. Please try to remain consistent with local style (yes, I know style is all over the place, sorry about that, but there's no need to make it worse). Please make sure fixes build and that make test passes. 4. Convert fixes to pull requests Pull requests are the easiest way to deal with incoming code. Note: please _don't_ make public pull requests for security issues! 5. Port pull requests across all branches Whilst it is often possible to cherry-pick pulls across the branches, it also fairly often fails. Having someone do the legwork to fix that is very helpful (or say that the pull works across all branches). 6. Write new tests Our test suite sucks. More tests is better. NOTE: I have not suddenly got more time to deal with OpenSSL stuff, so this process may well result in a backlog, but it will certainly make the use of what time I have more efficient. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
On 24 April 2014 18:44, Mike Bland mbl...@acm.org wrote: On Thu, Apr 24, 2014 at 1:31 PM, Ben Laurie b...@links.org wrote: 6. Write new tests Our test suite sucks. More tests is better. Shall I send a pull request for this: https://github.com/mbland/openssl/commit/a7a9e18b550edf059dfd54683ac1f45170ff9fb2 Yes, please! Ideally, as I say, for all branches. Have you verified that the test fails pre-fix? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
On 25 April 2014 00:08, Matt Caswell fr...@baggins.org wrote: Ben - Is it possible for some of us to get RT users created? The above assumes we can configure RT statuses - is this possible? I think you now have RT access, right? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
On 24 April 2014 19:54, Kurt Roeckx k...@roeckx.be wrote: On Thu, Apr 24, 2014 at 06:31:34PM +0100, Ben Laurie wrote: Note that this is just how to help me, not a consensus view from the whole team, though I have no doubt much of it will be helpful to the team, too. 1. Triage RT (https://rt.openssl.org/). RT has been neglected for a long time. People could usefully go through it and identify: a) Tickets that can be closed b) Tickets that should have action taken, and how urgent that action is. If a ticket describes a potential security issue, then please don't just announce it to the list. Instead send it to openssl-secur...@openssl.org. In order to avoid duplication of effort, perhaps someone should set up a github repo (or something else) assigning ranges to volunteers? It might also be useful to use the same repo to hold the triage results (so things can be ticked off as they are actioned). I already created a github branch for this, I'm a little unclear what this is? Also, how this fits into Matt's coordinated effort? but I stopped adding patches at it since I didn't know if this was going to be useful or not. See: https://github.com/kroeckx/openssl/commits/master-proposed 2. Triage Github pull requests There are less of these, and I do try to look at them from time to time, nevertheless I think we are behind. I've looked over them several time already, and I've merged a few of those. But it's hard for me to know what you would find an acceptable change and what not, so I've tried to be conservative. 3. Write fixes 4. Convert fixes to pull requests I'll try to work on that. 5. Port pull requests across all branches I wasn't really sure what to do here, and was planning to have branches you can pull for the various branches. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
Oh, absolutely I've verified it. :-) I'll get that turned around to you shortly. Mike On Sat, Apr 26, 2014 at 6:33 AM, Ben Laurie b...@links.org wrote: On 24 April 2014 18:44, Mike Bland mbl...@acm.org wrote: On Thu, Apr 24, 2014 at 1:31 PM, Ben Laurie b...@links.org wrote: 6. Write new tests Our test suite sucks. More tests is better. Shall I send a pull request for this: https://github.com/mbland/openssl/commit/a7a9e18b550edf059dfd54683ac1f45170ff9fb2 Yes, please! Ideally, as I say, for all branches. Have you verified that the test fails pre-fix? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
On Sat, Apr 26, 2014 at 11:39:13AM +0100, Ben Laurie wrote: On 24 April 2014 19:54, Kurt Roeckx k...@roeckx.be wrote: On Thu, Apr 24, 2014 at 06:31:34PM +0100, Ben Laurie wrote: Note that this is just how to help me, not a consensus view from the whole team, though I have no doubt much of it will be helpful to the team, too. 1. Triage RT (https://rt.openssl.org/). RT has been neglected for a long time. People could usefully go through it and identify: a) Tickets that can be closed b) Tickets that should have action taken, and how urgent that action is. If a ticket describes a potential security issue, then please don't just announce it to the list. Instead send it to openssl-secur...@openssl.org. In order to avoid duplication of effort, perhaps someone should set up a github repo (or something else) assigning ranges to volunteers? It might also be useful to use the same repo to hold the triage results (so things can be ticked off as they are actioned). I already created a github branch for this, I'm a little unclear what this is? Also, how this fits into Matt's coordinated effort? It's a branch with patches that I've reviewed, but they didn't all come in via RT. This branch also already started before Matt's suggestion. I think we currently have different paths of how bugs and patches get to here: - RT - github - distro's And Matt's suggest only seems to deal with RT, but then still creates the patch in github. It's not clear if we should now go and create an RT ticket for each patch we want to get applied. It also talks about patches on github, but it's not clear to me how you would find which branches to merge from github. It would make most sense to me that there are a few people who create branches that you can look at and know that someone has already reviewed them and that they are ready to be merged. For tickets that are already in RT, it makes sense that we have people who take ownership of the various tickets and get them in the correct state, but I see that as something different of how patches get to you. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
On 25 April 2014 18:24, Kurt Roeckx k...@roeckx.be wrote: On Thu, Apr 24, 2014 at 06:31:34PM +0100, Ben Laurie wrote: 1. Triage RT (https://rt.openssl.org/). I think part of this means that you'll need to give some people access to it so they can actually modify the tickets. I now have access to RT. I'll investigate what can be done to get more people set up. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
On 25 April 2014 01:14, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Thu, Apr 24, 2014 at 04:56:09PM -0700, Quanah Gibson-Mount wrote: The problem with this approach are significant requests that have languished for years. One such example would be http://rt.openssl.org/Ticket/Display.html?id=1365, which is 8 years old now. The best place to get the fix these days is probably directly from Debian (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589520). Perhaps patches that are added in major O/S platforms and are not fundamentally specific to the platform in question should get a higher priority. * They are in most cases proposed by relatively experienced users, (the Debian PRNG fiasco aside :-). * They have been widely tested by users of said platforms. So the easiest approach may be for Debian, RedHat, ... to look through the various patches they apply and decide which are generally applicable, and, perhaps not today, but once new processes are more clearly established, open new tickets clearly re-stating the status and motivation of the patch, the origin platform and patch maturity. Then I would recommend that the OpenSSL team and volunteers look at these before most other requests. Yes. This seems like a sensible refinement. I'd suggest though that if a new ticket is raised then we should encourage people to identify the older ticket so that it can be closed off. I have written up the proposed process as a Wiki page. That way we have it captured and as we make refinements we can update it and have a definitive statement of the approach. My first draft version is here: http://wiki.openssl.org/index.php/Defect_and_Feature_Review_Process I have added a Principles section at the beginning which outlines my suggestion around tackling defects from newest to oldest, and have added a new one to basically say we can on an ad-hoc basis tackle older defects if someone identifies them as significant. So this now reads: * Start looking at the newest entries in RT first and work backwards in time. This is on the basis that the newest bugs are likely to still be present and most relevant. As we go back in time we will see more and more which are no longer relevant - we will start hitting the law of diminishing returns. * Older entries can be looked at on an ad-hoc basis if a person doing triage identifies them (probably on the basis of some post to the dev list) as being important * Any new RT entries coming in should get the very highest priority. We can only start to make progress if the problem doesn't continue to grow. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
On 25 April 2014 01:58, Daniel Reynolds daniel.reyno...@providenceday.org wrote: I am not totally sure how many people would be working on this project, but is seems to me like it would make sense to split up into 3 groups. I would be concerned about spreading ourselves too thinly. I hope that my amendment to the process I just posted captures the concern about important older defects not being addressed. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
On Thu, Apr 24, 2014 at 7:08 PM, Matt Caswell fr...@baggins.org wrote: On 24 April 2014 18:31, Ben Laurie b...@links.org wrote: Note that this is just how to help me, not a consensus view from the whole team, though I have no doubt much of it will be helpful to the team, too. 1. Triage RT (https://rt.openssl.org/). ... Meta-suggestion: a. Get this and any other information needed by patch submitters and more involved contributers on the wiki ASAP (I guess the wiki allows the widest possible group to maintain it). b. Get someone with web site commit access and code commit access to axe inconsistent and/or out of date instructions about contributions and point to the wiki. This is probably also out of date, but, for example, it has the one true info on using svn (in httpd's case) for http://httpd.apache.org/dev/ --/-- I doubt that I can help much in general, but I can put the recap of this thread in an appropriate place there and create some sort of structure to contain information needed by contributors, and I guess submit patches to axe out of date information from other places. Concerns? -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: How to help OpenSSL
On Fri, Apr 25, 2014 at 10:03 AM, Jeff Trawick traw...@gmail.com wrote: On Thu, Apr 24, 2014 at 7:08 PM, Matt Caswell fr...@baggins.org wrote: On 24 April 2014 18:31, Ben Laurie b...@links.org wrote: Note that this is just how to help me, not a consensus view from the whole team, though I have no doubt much of it will be helpful to the team, too. 1. Triage RT (https://rt.openssl.org/). ... Meta-suggestion: a. Get this and any other information needed by patch submitters and more involved contributers on the wiki ASAP (I guess the wiki allows the widest possible group to maintain it). Silly me, now I see http://wiki.openssl.org/index.php/Defect_and_Feature_Review_Process Something I wonder about for the sake of onetime/sometime contributors... Is it practical for the triage team to give the onetime/sometime contributor a heads up that it looks promising before they backport to supported branches? b. Get someone with web site commit access and code commit access to axe inconsistent and/or out of date instructions about contributions and point to the wiki. This is probably also out of date, but, for example, it has the one true info on using svn (in httpd's case) for http://httpd.apache.org/dev/ --/-- I doubt that I can help much in general, but I can put the recap of this thread in an appropriate place there and create some sort of structure to contain information needed by contributors, and I guess submit patches to axe out of date information from other places. Concerns? -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/ -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: How to help OpenSSL
On Thu, Apr 24, 2014 at 06:31:34PM +0100, Ben Laurie wrote: Note that this is just how to help me, not a consensus view from the whole team, though I have no doubt much of it will be helpful to the team, too. 1. Triage RT (https://rt.openssl.org/). RT has been neglected for a long time. People could usefully go through it and identify: a) Tickets that can be closed b) Tickets that should have action taken, and how urgent that action is. If a ticket describes a potential security issue, then please don't just announce it to the list. Instead send it to openssl-secur...@openssl.org. In order to avoid duplication of effort, perhaps someone should set up a github repo (or something else) assigning ranges to volunteers? It might also be useful to use the same repo to hold the triage results (so things can be ticked off as they are actioned). I already created a github branch for this, but I stopped adding patches at it since I didn't know if this was going to be useful or not. See: https://github.com/kroeckx/openssl/commits/master-proposed 2. Triage Github pull requests There are less of these, and I do try to look at them from time to time, nevertheless I think we are behind. I've looked over them several time already, and I've merged a few of those. But it's hard for me to know what you would find an acceptable change and what not, so I've tried to be conservative. 3. Write fixes 4. Convert fixes to pull requests I'll try to work on that. 5. Port pull requests across all branches I wasn't really sure what to do here, and was planning to have branches you can pull for the various branches. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
That seems completely reasonable to me. On Thu, Apr 24, 2014 at 7:08 PM, Matt Caswell fr...@baggins.org wrote: On 24 April 2014 18:31, Ben Laurie b...@links.org wrote: Note that this is just how to help me, not a consensus view from the whole team, though I have no doubt much of it will be helpful to the team, too. 1. Triage RT (https://rt.openssl.org/). RT has been neglected for a long time. People could usefully go through it and identify: a) Tickets that can be closed b) Tickets that should have action taken, and how urgent that action is. If a ticket describes a potential security issue, then please don't just announce it to the list. Instead send it to openssl-secur...@openssl.org. In order to avoid duplication of effort, perhaps someone should set up a github repo (or something else) assigning ranges to volunteers? It might also be useful to use the same repo to hold the triage results (so things can be ticked off as they are actioned). See also points 3, 4 and 5. I would suggest the following process to do as Ben has requested: 1) We start looking at the newest entries in RT first and work backwards in time. This is on the basis that the newest bugs are likely to still be present and most relevant. As we go back in time I suspect we'll see more and more which are no longer relevant - we will start hitting the law of diminishing returns. 2) Any new RT entries coming in should get the very highest priority. We can only start to make progress if the problem doesn't continue to grow. 3) The first step is for someone assigned to triage duty to do a first pass assessment about what the RT entry is about. I'm not sure what RT supports here? Can it be configured to record these somewhere (the queue perhaps)? I would suggest classifying as one of: - Bug report - Feature request And given a status of one of (the initial status is New - I'm not sure what statuses RT supports but I'm assuming it can be configured): - Closed (the report has already been dealt with; or the report is not relevant or appropriate) - Open (the report appears to be sane from reading it and requires further investigation) Possibly we could further classify by the area of code this report is about, e.g. - Documentation - Command line app - libssl - libcrypto - Compilation installation - Platform specific - etc Not sure how granular you might want to go here. 4) The next step is for someone (not necessarily the same person who has done the initial triage) to pick up Open requests and mark them as owned by them. They then attempt to recreate the bug (I suggest we focus on bug reports rather than feature requests at this stage). This could be done on the basis of expertise, e.g. John knows most about libcrypto and so will focus on libcrypto reports. The status is then updated to be either: - Confirmed - Not Confirmed (this is effectively a closed status - it could be reopened if the initial person reporting the defect provides further information) 5a) If the bug is confirmed and a patch has been supplied then the owner verifies that the patch fixes the issue. They can also sanity check the patch to make sure it looks reasonable. If all is ok the owner should also check that the patch can be applied to all branches. If not the owner can either port the patch themselves to all branches, or request that the submitter do it. The status is updated to either: - Rejected (the patch is not suitable, appropriate, or available for all branches) - Approved (the patch is in github for all branches and appears sane - it is ready for the dev team to review) 5b) If the bug is confirmed and no patch is available then the same process as in 5a applies, but the owner creates the patch themselves. 6) The dev team only look at Approved RT reports and verify that they are happy with the patch before committing it. Thoughts? Ben - Is it possible for some of us to get RT users created? The above assumes we can configure RT statuses - is this possible? Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
On Thu, Apr 24, 2014 at 04:56:09PM -0700, Quanah Gibson-Mount wrote: The problem with this approach are significant requests that have languished for years. One such example would be http://rt.openssl.org/Ticket/Display.html?id=1365, which is 8 years old now. The best place to get the fix these days is probably directly from Debian (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589520). Perhaps patches that are added in major O/S platforms and are not fundamentally specific to the platform in question should get a higher priority. * They are in most cases proposed by relatively experienced users, (the Debian PRNG fiasco aside :-). * They have been widely tested by users of said platforms. So the easiest approach may be for Debian, RedHat, ... to look through the various patches they apply and decide which are generally applicable, and, perhaps not today, but once new processes are more clearly established, open new tickets clearly re-stating the status and motivation of the patch, the origin platform and patch maturity. Then I would recommend that the OpenSSL team and volunteers look at these before most other requests. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
I am not totally sure how many people would be working on this project, but is seems to me like it would make sense to split up into 3 groups. One would do what Viktor suggested, and hunt down patches added in major OS platforms. Another would do what Matt suggested, and simply go from the newest submissions to the oldest ones. To resolve the issue Quanah was talking about with old issues remaining unpatched, the final group would do the exact same thing as the group that goes from newest to oldest, except they would go from oldest to newest. As far as I can tell this would resolve many of the issues that we are facing, as the group that looks at major OS stuff would hopefully find many of the big issues while the other two groups would prevent anything from falling through cracks. Just my 2 cents. On Thu, Apr 24, 2014 at 8:14 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Thu, Apr 24, 2014 at 04:56:09PM -0700, Quanah Gibson-Mount wrote: The problem with this approach are significant requests that have languished for years. One such example would be http://rt.openssl.org/Ticket/Display.html?id=1365, which is 8 years old now. The best place to get the fix these days is probably directly from Debian (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589520). Perhaps patches that are added in major O/S platforms and are not fundamentally specific to the platform in question should get a higher priority. * They are in most cases proposed by relatively experienced users, (the Debian PRNG fiasco aside :-). * They have been widely tested by users of said platforms. So the easiest approach may be for Debian, RedHat, ... to look through the various patches they apply and decide which are generally applicable, and, perhaps not today, but once new processes are more clearly established, open new tickets clearly re-stating the status and motivation of the patch, the origin platform and patch maturity. Then I would recommend that the OpenSSL team and volunteers look at these before most other requests. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
