[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130603173743.GL1472@yuggoth.org>
Date: Mon, 3 Jun 2013 17:37:44 +0000
From: Jeremy Stanley <fungi@...goth.org>
To: oss-security@...ts.openwall.com, openstack@...ts.launchpad.net
Subject: Re: [Openstack] [OSSA 2013-013] Keystone client local information
disclosure (CVE-2013-2013)
On 2013-06-03 10:01:03 -0700 (-0700), Lloyd Dewolf wrote:
> I appreciate that it often isn't appropriate, but in this case it
> might have been beneficial to include python-keystoneclient
> version 0.2.4 where this is first resolved.
What's the better way to do that, do you think? Delay the
announcement until a new release is tagged, guess what the release
will be numbered (possibly doable with the assistance of the
developers as long as they don't change their minds), or follow up
to the announcement after the fact? I opted for expediency and
accuracy, indicating the date and commit hash stating "will appear
in the next release," but am happy to entertain alternative
approaches there.
I agree it's less than ideal for end users reading the announcement
and trying to decide whether they're running a new enough version of
the client to have access to that feature, though I guess the
manpage or --help output is the first place I would look as a user
if it came into question. Also, with many users running
stable-distribution-packaged clients with fixes backported, upstream
version numbers can be fairly irrelevant to those users in the short
term as they may have the fix in a client reporting to be running an
older version.
--
Jeremy Stanley
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
