Hi Ben, all, In the wake of the OpenSSL publicity (and controversy) I today signed up to the mailing lists to find out whether and what I could do to help.
I had a look at http://rt.openssl.org/NoAuth/Buglist.html and got the impression it indeed is out of date to the point of absurdity. But that might just have been me. I had a look at a few random items on that list and some of their communication threads ended open or even seemed to suggest things are resolved, yet the items were still showing in the bug list. Following your suggestion I'd be more than happy to try and help clean it up. I am not sure I can do much systematic work there, though. Let's just say I find a bug there that I feel can be closed. How would I communicate this and to whom? Cheers, Joerg > 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 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
