not to beat a dead horse

[Jake Edge]

but I am trying to puzzle out the kronolith advisories.  They do not 
include either a CVE reference or a bugzilla reference.  One contains 
the changelog, one not.  And the description of the problem is as follows:

Fix privilege escalation in Horde API.  Fix missing ownership validation 
on share changes.

This is for FEDORA-2008-2221 and FEDORA-2008-2212.

How am I (or anyone) supposed to figure out what's going on here?

thanks!

jake

-- 
Jake Edge - LWN - jake(a)lwn.net - http://lwn.net

[Kevin Fenzi]

On Mon, 10 Mar 2008 12:20:08 -0600
Jake Edge <jake(a)lwn.net&gt; wrote:

Feel free to keep beating... ;) This stuff needs to improve. :( 

>  but I am trying to puzzle out the kronolith advisories.  They do not
>
>  include either a CVE reference or a bugzilla reference.  One contains 
>  the changelog, one not.  And the description of the problem is as
>  follows:
>  
>  Fix privilege escalation in Horde API.  Fix missing ownership
>  validation on share changes.
>  
>  This is for FEDORA-2008-2221 and FEDORA-2008-2212.
>  
>  How am I (or anyone) supposed to figure out what's going on here? 
Not easily. ;( 

Kronolith upstream seems pretty happy go lucky. They fixed these things
in their cvs with no upstream bugs filed. As far as I know they never
requested a CVE or anything like it. Their viewcvs setup makes it
pretty impossible to see what changed. They added other changes into
this release instead of just releasing just the security updates, etc. 

Manually pulling down the two releases and diffing them, got me the
changes, but messy. ;( 

So, what should we do in this case? 

It really is a security update... should we always file
redhat.bugzilla.com bugs and make sure they are updated with info? 

Should we file upstream bugs and ask them to explain the changes? 

Should we request a CVE and wait for that before pushing the update? 

Some guidelines here would be good... 

>  jake 
kevin

[Lubomir Kundrak]

On Tue, 2008-03-11 at 12:25 -0600, Kevin Fenzi wrote:
>  On Mon, 10 Mar 2008 12:20:08 -0600
>  Jake Edge <jake(a)lwn.net&gt; wrote:
>  
>  Feel free to keep beating... ;) This stuff needs to improve. :( 
>  
>  > but I am trying to puzzle out the kronolith advisories.  They do not 
>  > include either a CVE reference or a bugzilla reference.  One contains 
>  > the changelog, one not.  And the description of the problem is as
>  > follows:
>  > 
>  > Fix privilege escalation in Horde API.  Fix missing ownership
>  > validation on share changes.
>  > 
>  > This is for FEDORA-2008-2221 and FEDORA-2008-2212.
>  > 
>  > How am I (or anyone) supposed to figure out what's going on here?
>  
>  Not easily. ;( 
>  
>  Kronolith upstream seems pretty happy go lucky. They fixed these things
>  in their cvs with no upstream bugs filed. As far as I know they never
>  requested a CVE or anything like it. Their viewcvs setup makes it
>  pretty impossible to see what changed. They added other changes into
>  this release instead of just releasing just the security updates, etc. 
>  
>  Manually pulling down the two releases and diffing them, got me the
>  changes, but messy. ;( 
>  
>  So, what should we do in this case? 
>  
>  It really is a security update... should we always file
>  redhat.bugzilla.com bugs and make sure they are updated with info? 
>  
>  Should we file upstream bugs and ask them to explain the changes? 
>  
>  Should we request a CVE and wait for that before pushing the update? 
>  
>  Some guidelines here would be good...  
Who approved these?

I noticed this before it got pushed and asked the maintainer to sort the
things out (add references to bugs, file them eventually).

-- 
Lubomir Kundrak (Red Hat Security Response Team)

[Luke Macken]

On Wed, Mar 12, 2008 at 04:37:32PM +0100, Lubomir Kundrak wrote:
>  
>  On Tue, 2008-03-11 at 12:25 -0600, Kevin Fenzi wrote:
>  > On Mon, 10 Mar 2008 12:20:08 -0600
>  > Jake Edge <jake(a)lwn.net&gt; wrote:
>  > 
>  > Feel free to keep beating... ;) This stuff needs to improve. :( 
>  > 
>  > > but I am trying to puzzle out the kronolith advisories.  They do not 
>  > > include either a CVE reference or a bugzilla reference.  One contains 
>  > > the changelog, one not.  And the description of the problem is as
>  > > follows:
>  > > 
>  > > Fix privilege escalation in Horde API.  Fix missing ownership
>  > > validation on share changes.
>  > > 
>  > > This is for FEDORA-2008-2221 and FEDORA-2008-2212.
>  > > 
>  > > How am I (or anyone) supposed to figure out what's going on here?
>  > 
>  > Not easily. ;( 
>  > 
>  > Kronolith upstream seems pretty happy go lucky. They fixed these things
>  > in their cvs with no upstream bugs filed. As far as I know they never
>  > requested a CVE or anything like it. Their viewcvs setup makes it
>  > pretty impossible to see what changed. They added other changes into
>  > this release instead of just releasing just the security updates, etc. 
>  > 
>  > Manually pulling down the two releases and diffing them, got me the
>  > changes, but messy. ;( 
>  > 
>  > So, what should we do in this case? 
>  > 
>  > It really is a security update... should we always file
>  > redhat.bugzilla.com bugs and make sure they are updated with info? 
>  > 
>  > Should we file upstream bugs and ask them to explain the changes? 
>  > 
>  > Should we request a CVE and wait for that before pushing the update? 
>  > 
>  > Some guidelines here would be good... 
>  
>  Who approved these?
>  
>  I noticed this before it got pushed and asked the maintainer to sort the
>  things out (add references to bugs, file them eventually). 
Kevin approved the F7 update, and then 3 days later I noticed the F8
update never made it out, so I approved it.

luke

[Kevin Fenzi]

On Wed, 12 Mar 2008 13:04:48 -0400
Luke Macken <lmacken(a)redhat.com&gt; wrote:

>  On Wed, Mar 12, 2008 at 04:37:32PM +0100, Lubomir Kundrak wrote:
>  > 
>  > On Tue, 2008-03-11 at 12:25 -0600, Kevin Fenzi wrote:
>  > > On Mon, 10 Mar 2008 12:20:08 -0600
>  > > Jake Edge <jake(a)lwn.net&gt; wrote:
>  > > 
>  > > Feel free to keep beating... ;) This stuff needs to improve. :( 
>  > > 
>  > > > but I am trying to puzzle out the kronolith advisories.  They
>  > > > do not include either a CVE reference or a bugzilla reference.
>  > > > One contains the changelog, one not.  And the description of
>  > > > the problem is as follows:
>  > > > 
>  > > > Fix privilege escalation in Horde API.  Fix missing ownership
>  > > > validation on share changes.
>  > > > 
>  > > > This is for FEDORA-2008-2221 and FEDORA-2008-2212.
>  > > > 
>  > > > How am I (or anyone) supposed to figure out what's going on
>  > > > here?
>  > > 
>  > > Not easily. ;( 
>  > > 
>  > > Kronolith upstream seems pretty happy go lucky. They fixed these
>  > > things in their cvs with no upstream bugs filed. As far as I know
>  > > they never requested a CVE or anything like it. Their viewcvs
>  > > setup makes it pretty impossible to see what changed. They added
>  > > other changes into this release instead of just releasing just
>  > > the security updates, etc. 
>  > > 
>  > > Manually pulling down the two releases and diffing them, got me
>  > > the changes, but messy. ;( 
>  > > 
>  > > So, what should we do in this case? 
>  > > 
>  > > It really is a security update... should we always file
>  > > redhat.bugzilla.com bugs and make sure they are updated with
>  > > info? 
>  > > 
>  > > Should we file upstream bugs and ask them to explain the changes? 
>  > > 
>  > > Should we request a CVE and wait for that before pushing the
>  > > update? 
>  > > 
>  > > Some guidelines here would be good... 
>  > 
>  > Who approved these?
>  > 
>  > I noticed this before it got pushed and asked the maintainer to
>  > sort the things out (add references to bugs, file them eventually).
>  
>  Kevin approved the F7 update, and then 3 days later I noticed the F8
>  update never made it out, so I approved it. 
Yeah, I didn't see the F8 one... but I approved the other one. ;( 

I did ask the submitter about bugs or docs or anything, but they said
they had no CVE or procedure to ask for one, or anything usefull from
upstream. 

Shall we require that at least a bug is filed against any security
update? That would allow us to add commentary on the bug at least and
hoepfully help people figuring things out. I am fine with that policy,
although it might mean that some updates are delayed while a bug is
filed and such. 

>  
>  luke
>   
kevin

[Lubomir Kundrak]

On Wed, 2008-03-12 at 11:09 -0600, Kevin Fenzi wrote:
>  On Wed, 12 Mar 2008 13:04:48 -0400
>  Luke Macken <lmacken(a)redhat.com&gt; wrote:
>  
>  > On Wed, Mar 12, 2008 at 04:37:32PM +0100, Lubomir Kundrak wrote:
>  > > 
>  > > On Tue, 2008-03-11 at 12:25 -0600, Kevin Fenzi wrote:
>  > > > On Mon, 10 Mar 2008 12:20:08 -0600
>  > > > Jake Edge <jake(a)lwn.net&gt; wrote:
>  > > > 
>  > > > Feel free to keep beating... ;) This stuff needs to improve. :( 
>  > > > 
>  > > > > but I am trying to puzzle out the kronolith advisories.  They
>  > > > > do not include either a CVE reference or a bugzilla reference.
>  > > > > One contains the changelog, one not.  And the description of
>  > > > > the problem is as follows:
>  > > > > 
>  > > > > Fix privilege escalation in Horde API.  Fix missing ownership
>  > > > > validation on share changes.
>  > > > > 
>  > > > > This is for FEDORA-2008-2221 and FEDORA-2008-2212.
>  > > > > 
>  > > > > How am I (or anyone) supposed to figure out what's going on
>  > > > > here?
>  > > > 
>  > > > Not easily. ;( 
>  > > > 
>  > > > Kronolith upstream seems pretty happy go lucky. They fixed these
>  > > > things in their cvs with no upstream bugs filed. As far as I know
>  > > > they never requested a CVE or anything like it. Their viewcvs
>  > > > setup makes it pretty impossible to see what changed. They added
>  > > > other changes into this release instead of just releasing just
>  > > > the security updates, etc. 
>  > > > 
>  > > > Manually pulling down the two releases and diffing them, got me
>  > > > the changes, but messy. ;( 
>  > > > 
>  > > > So, what should we do in this case? 
>  > > > 
>  > > > It really is a security update... should we always file
>  > > > redhat.bugzilla.com bugs and make sure they are updated with
>  > > > info? 
>  > > > 
>  > > > Should we file upstream bugs and ask them to explain the changes? 
>  > > > 
>  > > > Should we request a CVE and wait for that before pushing the
>  > > > update? 
>  > > > 
>  > > > Some guidelines here would be good... 
>  > > 
>  > > Who approved these?
>  > > 
>  > > I noticed this before it got pushed and asked the maintainer to
>  > > sort the things out (add references to bugs, file them eventually).
>  > 
>  > Kevin approved the F7 update, and then 3 days later I noticed the F8
>  > update never made it out, so I approved it.
>  
>  Yeah, I didn't see the F8 one... but I approved the other one. ;( 
>  
>  I did ask the submitter about bugs or docs or anything, but they said
>  they had no CVE or procedure to ask for one, or anything usefull from
>  upstream. 
>  
>  Shall we require that at least a bug is filed against any security
>  update? That would allow us to add commentary on the bug at least and
>  hoepfully help people figuring things out. I am fine with that policy,
>  although it might mean that some updates are delayed while a bug is
>  filed and such.  
Filing a bug is no delay. I'll try to put up some text to refer
maintainers to by tomorrow.

-- 
Lubomir Kundrak (Red Hat Security Response Team)

[Greg Metcalfe]

On Wednesday 12 March 2008 10:18:30 Lubomir Kundrak wrote:
<snip>
>  > Shall we require that at least a bug is filed against any
> security
>  > update? That would allow us to add commentary on the bug at least and
>  > hoepfully help people figuring things out. I am fine with that policy,
>  > although it might mean that some updates are delayed while a bug is
>  > filed and such.
>
>  Filing a bug is no delay. I'll try to put up some text to refer
>  maintainers to by tomorrow. 
It might be helpful for Red Hat people to mention a standard URL. There will 
always be new people coming in, wanting to add packages from the wishlist, 
etc., who could use the info.