On Feb 13, 2009, at 5:31 PM, Jarek Gawor wrote:
On Fri, Feb 13, 2009 at 2:58 PM, Kevan Miller
wrote:
On Feb 13, 2009, at 11:47 AM, Joe Bohn wrote:
Based on the positive feedback to my proposal I updated out wiki
process
document with the steps I proposed earlier. See
http://cwiki.apach
>
>
> 8. Reach an agreement for the fix and announcement schedule with the
> submitter.
> 9. Announce the vulnerability (users, dev, secur...@a.o, bugtraq at
> securityfocus.com, full-disclosure at lists.grok.org.uk and project
> security pages). The vulnerability announcement must provide
> instru
On Fri, Feb 13, 2009 at 2:58 PM, Kevan Miller wrote:
>
> On Feb 13, 2009, at 11:47 AM, Joe Bohn wrote:
>
> Based on the positive feedback to my proposal I updated out wiki process
> document with the steps I proposed earlier. See
> http://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html f
On Feb 13, 2009, at 3:46 PM, Joe Bohn wrote:
Thanks for the quick response Kevan.
Kevan Miller wrote:
Hi Joe,
Good questions.
On Feb 13, 2009, at 3:13 PM, Joe Bohn wrote:
I have a few practical questions:
1) Must all affected releases be released before we can announce?
IMO, no. But I thin
Thanks for the quick response Kevan.
Kevan Miller wrote:
Hi Joe,
Good questions.
On Feb 13, 2009, at 3:13 PM, Joe Bohn wrote:
I have a few practical questions:
1) Must all affected releases be released before we can announce?
IMO, no. But I think users must have a reasonable upgrade path
Hi Joe,
Good questions.
On Feb 13, 2009, at 3:13 PM, Joe Bohn wrote:
I have a few practical questions:
1) Must all affected releases be released before we can announce?
IMO, no. But I think users must have a reasonable upgrade path to
receive the fix. A 2.0.x user could be reasonably expec
Kevan Miller wrote:
On Feb 13, 2009, at 11:47 AM, Joe Bohn wrote:
Based on the positive feedback to my proposal I updated out wiki
process document with the steps I proposed earlier. See
http://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html for
details.
Sorry, I thought that I'd
On Feb 13, 2009, at 11:47 AM, Joe Bohn wrote:
Based on the positive feedback to my proposal I updated out wiki
process document with the steps I proposed earlier. See http://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html
for details.
Sorry, I thought that I'd replied to this, al
Based on the positive feedback to my proposal I updated out wiki process
document with the steps I proposed earlier. See
http://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html for details.
Joe
Donald Woods wrote:
Sounds good.
-Donald
Joe Bohn wrote:
Donald Woods wrote:
Sounds go
Sounds good.
-Donald
Joe Bohn wrote:
Donald Woods wrote:
Sounds good. I was assuming the SNAPSHOT build in #10 would be
handled by Jarek's automated builds and we would just say "mmdd or
later SNAPSHOT build" and include the URL to our published snapshot
builds.
Thanks Donald - I agre
On Feb 3, 2009, at 11:20 AM, Joe Bohn wrote:
Donald Woods wrote:
Sounds good. I was assuming the SNAPSHOT build in #10 would be
handled by Jarek's automated builds and we would just say "mmdd
or later SNAPSHOT build" and include the URL to our published
snapshot builds.
Thanks Dona
Donald Woods wrote:
Sounds good. I was assuming the SNAPSHOT build in #10 would be handled
by Jarek's automated builds and we would just say "mmdd or later
SNAPSHOT build" and include the URL to our published snapshot builds.
Thanks Donald - I agree with using the automated build snapshot
Agree. Looks like we're ready to update the wiki and then request one
last round of reviews to a broader group of people.
-Donald
Kevan Miller wrote:
I've moved this back to the d...@. This is the danger of cross-posting.
The reply-to for your original message (at least the one that I
rece
Sounds good. I was assuming the SNAPSHOT build in #10 would be handled
by Jarek's automated builds and we would just say "mmdd or later
SNAPSHOT build" and include the URL to our published snapshot builds.
-Donald
Joe Bohn wrote:
I think the key question is when we will announce the v
I think the key question is when we will announce the vulnerability
(current #11).
My preference would be that we create a JIRA for the issue so that it
can be included in the release notes (#9 - either with or without the
CVE referenced).
But that (along with the code check-in) creates a
On Jan 19, 2009, at 12:32 PM, Donald Woods wrote:
Joe Bohn wrote:
Is the omission of any discussion of a JIRA intentional? In other
words, is it expected that a JIRA will *not* be created to document
or track the code change and that CVE will be the only
documentation of the issue (and
I've moved this back to the d...@. This is the danger of cross-posting.
The reply-to for your original message (at least the one that I
received) was u...@. This DISCUSS belongs on dev@
On Jan 19, 2009, at 5:10 PM, Donald Woods wrote:
Sounds good to me.
Should step #8 include a post to th
Joe Bohn wrote:
Is the omission of any discussion of a JIRA intentional? In other
words, is it expected that a JIRA will *not* be created to document or
track the code change and that CVE will be the only documentation of the
issue (and then only after a server image has already been release
Is the omission of any discussion of a JIRA intentional? In other
words, is it expected that a JIRA will *not* be created to document or
track the code change and that CVE will be the only documentation of the
issue (and then only after a server image has already been released by
changing the
There was a long discussion around mid-December on the private and
security Geronimo mailing lists about how to handle security
vulnerabilities. The outcome of that discussion (which is mainly a
boilerplate suggested by Mark Thomas for all projects to use) can be
found on our Project Policies
20 matches
Mail list logo
