info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
How to help OpenSSL
77 views
Skip to first unread message
Ben Laurie
Apr 24, 2014, 1:31:34 PM4/24/14
to
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-...@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 opens...@openssl.org
Automated List Manager majo...@openssl.org
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-...@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 opens...@openssl.org
Automated List Manager majo...@openssl.org
Mike Bland
Apr 24, 2014, 1:44:47 PM4/24/14
to
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:
Mike
Kurt Roeckx
Apr 24, 2014, 2:54:35 PM4/24/14
to
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-...@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
> 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-...@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).
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.
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
branches you can pull for the various branches.
Kurt
Jörg Bullmann
Apr 24, 2014, 3:11:43 PM4/24/14
to
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-...@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).
>
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-...@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.
>
>
> 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.
>
>
> 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!
>
> 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).
>
> 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.
>
>
> 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.
> this process may well result in a backlog, but it will certainly make
> the use of what time I have more efficient.
Matt Caswell
Apr 24, 2014, 7:08:08 PM4/24/14
to
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-...@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:
> 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-...@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.
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
Daniel Reynolds
Apr 24, 2014, 7:14:20 PM4/24/14
to
That seems completely reasonable to me.
Quanah Gibson-Mount
Apr 24, 2014, 7:56:09 PM4/24/14
to
--On April 25, 2014 at 12:08:08 AM +0100 Matt Caswell <fr...@baggins.org>
wrote:
> 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.
The problem with this approach are significant requests that have
>
> 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.
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>).
Note it also has dupes/related:
<http://rt.openssl.org/Ticket/Display.html?id=1832>
<http://rt.openssl.org/Ticket/Display.html?id=2051>
<http://rt.openssl.org/Ticket/Display.html?id=2069>
I've been patching my own openssl build with the ipv6 support for s_client
for a few years now, as we have IPv6 only clients where it is necessary for
debugging purposes. There are likely other extremely useful fixes that
also have gone nowhere for nearly a decade that would provide immediate
pluses to have them committed.
> 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.
addressed, causing additional work overhead.
--Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Viktor Dukhovni
Apr 24, 2014, 8:14:05 PM4/24/14
to
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
>
> 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>).
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.
Daniel Reynolds
Apr 24, 2014, 8:58:30 PM4/24/14
to
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.
Matt Caswell
Apr 25, 2014, 4:09:52 AM4/25/14
to
On 25 April 2014 01:14, Viktor Dukhovni <openss...@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
> 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.
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
of diminishing returns.
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
grow.
Matt Caswell
Apr 25, 2014, 4:15:14 AM4/25/14
to
On 25 April 2014 01:58, Daniel Reynolds
my amendment to the process I just posted captures the concern about
important older defects not being addressed.
<daniel....@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
> 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.
>
my amendment to the process I just posted captures the concern about
important older defects not being addressed.
Matt Caswell
Apr 25, 2014, 4:22:47 AM4/25/14
to
On 25 April 2014 00:56, Quanah Gibson-Mount <qua...@zimbra.com> wrote:
>
>
> --On April 25, 2014 at 12:08:08 AM +0100 Matt Caswell <fr...@baggins.org>
> wrote:
>
>> 2) Any new RT entries coming in should get the very highest priority.
>
>
> --On April 25, 2014 at 12:08:08 AM +0100 Matt Caswell <fr...@baggins.org>
> wrote:
>
>> We can only start to make progress if the problem doesn't continue to
>> grow.
>
>
>> grow.
>
>
> This may induce people to file more duplicates to get older issues
> addressed, causing additional work overhead.
Agreed. But I think the alternative is worse (i.e. we ignore new
> addressed, causing additional work overhead.
issues until we have dealt with the backlog which may take some
considerable time). Actually though I suspect the number of
resubmitted defects will be relatively small compared to the total
number of defects in the system. We can attempt to encourage people to
only resubmit "significant" defects - and where they do so identify
the older defects so that they can be closed off.
Jeff Trawick
Apr 25, 2014, 10:03:51 AM4/25/14
to
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
--/--
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?
Jeff Trawick
Apr 25, 2014, 10:13:41 AM4/25/14
to
On Fri, Apr 25, 2014 at 10:03 AM, Jeff Trawick <tra...@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--/--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?--
Ben Laurie
Apr 24, 2014, 5:06:08 AM4/24/14
to
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/).
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-...@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.
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-...@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.
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.
Jeff Trawick
Apr 25, 2014, 11:56:37 AM4/25/14
to
On Fri, Apr 25, 2014 at 10:03 AM, Jeff Trawick <tra...@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).
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
Along the lines of one of the pages on that site, I created a consolidate-all-git-info page at
Pester me here or off-line or edit the page to add hints about missing pieces, as I have in a couple of cases.
--/--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?
Kurt Roeckx
Apr 25, 2014, 1:24:28 PM4/25/14
to
On Thu, Apr 24, 2014 at 06:31:34PM +0100, Ben Laurie wrote:
>
I think part of this means that you'll need to give some people
>
access to it so they can actually modify the tickets.
Kurt
Ben Laurie
Apr 26, 2014, 3:08:45 AM4/26/14
to
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-...@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.
>
don't create a pull request (they are public), instead send a patch to
openssl-...@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.
>
Ben Laurie
Apr 26, 2014, 6:33:07 AM4/26/14
to
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:
>>
> 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.
>
>
>>
>> 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.
>
> https://github.com/mbland/openssl/commit/a7a9e18b550edf059dfd54683ac1f45170ff9fb2
Have you verified that the test fails pre-fix?
Ben Laurie
Apr 26, 2014, 6:36:24 AM4/26/14
to
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?
> Ben - Is it possible for some of us to get RT users created? The above
> assumes we can configure RT statuses - is this possible?
Ben Laurie
Apr 26, 2014, 6:39:13 AM4/26/14
to
On 24 April 2014 19:54, Kurt Roeckx <ku...@roeckx.be> wrote:
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
>
>
> 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-...@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).
>
>> 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-...@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.
>
>>
>> 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
> 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
>
> branches you can pull for the various branches.
>
>
>
> Kurt
>
Mike Bland
Apr 26, 2014, 7:15:13 AM4/26/14
to
Oh, absolutely I've verified it. :-)
I'll get that turned around to you shortly.
Mike
Yes, please! Ideally, as I say, for all branches.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
Have you verified that the test fails pre-fix?
Kurt Roeckx
Apr 26, 2014, 7:39:50 AM4/26/14
to
On Sat, Apr 26, 2014 at 11:39:13AM +0100, Ben Laurie wrote:
> On 24 April 2014 19:54, Kurt Roeckx <ku...@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-...@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
> On 24 April 2014 19:54, Kurt Roeckx <ku...@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-...@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?
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
Matt Caswell
Apr 26, 2014, 5:35:45 PM4/26/14
to
On 25 April 2014 18:24, Kurt Roeckx <ku...@roeckx.be> wrote:
> On Thu, Apr 24, 2014 at 06:31:34PM +0100, Ben Laurie wrote:
>>
>> 1. Triage RT (https://rt.openssl.org/).
>
> 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
> access to it so they can actually modify the tickets.
people set up.
Matt
Weibin Yao
Apr 27, 2014, 9:50:39 AM4/27/14
to
Is it accessable for read (rt.openssl.org) ? I can't access it and
don't know where to register.
--
Weibin Yao
Developer @ Server Platform Team of Taobao
don't know where to register.
Weibin Yao
Developer @ Server Platform Team of Taobao
Dr. Stephen Henson
Apr 27, 2014, 12:48:18 PM4/27/14
to
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:
> Is it accessable for read (rt.openssl.org) ? I can't access it and
> don't know where to register.
>
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
Weibin Yao
Apr 28, 2014, 12:03:41 AM4/28/14
to
I see. Thank you.
--
Weibin Yao
Developer @ Server Platform Team of Taobao
Weibin Yao
Developer @ Server Platform Team of Taobao
0 new messages