On Tue, Jan 14, 2014 at 1:10 AM, Ben Reser b...@reser.org wrote:
On 1/11/14, 5:02 AM, Jeff Trawick wrote:
I think a lot of your concerns revolve around assessment of when a
vulnerability can be disclosed, and that has to be determined on a case
by case
basis. The vote is just about
On 1/14/14, 7:35 AM, Jeff Trawick wrote:
The simple answer to all of this is look how httpd releases with security
fixes have been handled in the past. The RM commits the fixes just before
Tag
Roll and, depending on the impact of the vulnerabilities, may call for an
abbreviated testing
On Tue, Jan 14, 2014 at 12:56 PM, Ben Reser b...@reser.org wrote:
On 1/14/14, 7:35 AM, Jeff Trawick wrote:
The simple answer to all of this is look how httpd releases with
security
fixes have been handled in the past. The RM commits the fixes just
before Tag
Roll and, depending on the
[X] It is mandatory to provide best available description and any available
tracking information when committing fixes for vulnerabilities to any
branch, delaying committing of the fix if the information shouldn't be
provided yet.
On 1/11/14, 5:02 AM, Jeff Trawick wrote:
I think a lot of your concerns revolve around assessment of when a
vulnerability can be disclosed, and that has to be determined on a case by
case
basis. The vote is just about whether there will be an in-between situation
where we share some
On 11.01.2014 14:02, Jeff Trawick wrote:
On Sat, Jan 11, 2014 at 2:51 AM, Ben Reser b...@reser.org
mailto:b...@reser.org wrote:
On 1/10/14, 5:38 AM, Jeff Trawick wrote:
[ ] It is an accepted practice (but not required) to obscure or
omit the
vulnerability impact in
On Fri, Jan 10, 2014 at 8:38 AM, Jeff Trawick traw...@gmail.com wrote:
Open source projects, ASF or otherwise, have varying procedures for
commits of fixes to vulnerabilities. ...
I plan to update http://httpd.apache.org/dev/guidelines.html based on the
outcome of the vote.
Folks, if you
On Sun, Jan 12, 2014 at 8:33 AM, Jeff Trawick traw...@gmail.com wrote:
On Fri, Jan 10, 2014 at 8:38 AM, Jeff Trawick traw...@gmail.com wrote:
Open source projects, ASF or otherwise, have varying procedures for
commits of fixes to vulnerabilities. ...
I plan to update
On 12 Jan 2014, at 13:33, Jeff Trawick wrote:
On Fri, Jan 10, 2014 at 8:38 AM, Jeff Trawick traw...@gmail.com wrote:
Open source projects, ASF or otherwise, have varying procedures for commits
of fixes to vulnerabilities. ...
I plan to update http://httpd.apache.org/dev/guidelines.html
On Sun, Jan 12, 2014 at 10:23 AM, Tim Bannister is...@jellybaby.net wrote:
On 12 Jan 2014, at 13:33, Jeff Trawick wrote:
On Fri, Jan 10, 2014 at 8:38 AM, Jeff Trawick traw...@gmail.com wrote:
Open source projects, ASF or otherwise, have varying procedures for
commits of fixes to
Am Freitag, 10. Januar 2014, 08:38:51 schrieb Jeff Trawick:
[X] It is mandatory to provide best available description and any
available tracking information when committing fixes for
vulnerabilities to any branch, delaying committing of the fix if
the information shouldn't be provided yet.
On Sat, Jan 11, 2014 at 2:51 AM, Ben Reser b...@reser.org wrote:
On 1/10/14, 5:38 AM, Jeff Trawick wrote:
[ ] It is an accepted practice (but not required) to obscure or omit the
vulnerability impact in CHANGES or commit log information when
committing fixes
for vulnerabilities to any
Open source projects, ASF or otherwise, have varying procedures for commits
of fixes to vulnerabilities. One important aspect of these procedures is
whether or not fixes to vulnerabilities can be committed to a repository
with commit logs and possibly CHANGES entries which purposefully obscure
[X] It is mandatory to provide best available description and any available
tracking information when committing fixes for vulnerabilities to any
branch, delaying committing of the fix if the information shouldn't be
provided yet.
--/--
IMO it is not appropriate to let skilled attackers see a
Von: Jeff Trawick [mailto:traw...@gmail.com]
Gesendet: Freitag, 10. Januar 2014 14:39
An: Apache HTTP Server Development List
Betreff: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to
vulnerabilities
Open source projects, ASF or otherwise, have varying procedures for commits of
+1
On Jan 10, 2014, at 8:44 AM, Jeff Trawick traw...@gmail.com wrote:
[X] It is mandatory to provide best available description and any available
tracking information when committing fixes for vulnerabilities to any branch,
delaying committing of the fix if the information shouldn't be
+1
in some cases re-consider if a used option is really needed
and disable it may close a vulnerability, the admin only
needs to know that there is danger
Am 10.01.2014 15:24, schrieb Jim Jagielski:
+1
On Jan 10, 2014, at 8:44 AM, Jeff Trawick traw...@gmail.com wrote:
[X] It is mandatory to
Le 10/01/2014 14:38, Jeff Trawick a écrit :
[ ] It is an accepted practice (but not required) to obscure or omit
the vulnerability impact in CHANGES or commit log information when
committing fixes for vulnerabilities to any branch.
[X] It is mandatory to provide best available description
On Fri, 2014-01-10 at 08:38 -0500, Jeff Trawick wrote:
[ X] It is mandatory to provide best available description and any
available tracking information when committing fixes for
vulnerabilities to any branch, delaying committing of the fix if the
information shouldn't be provided yet.
On 1/10/14, 5:38 AM, Jeff Trawick wrote:
[ ] It is an accepted practice (but not required) to obscure or omit the
vulnerability impact in CHANGES or commit log information when committing
fixes
for vulnerabilities to any branch.
[ ] It is mandatory to provide best available description and
20 matches
Mail list logo
