Replacing oauth2 by oauthlib
See the discussion @ https://review.openstack.org/#/c/70750/
I think this is not an acceptable change for the stable branch. We promise a "safe source of fixes", which means seamless upgrades that do not require extra actions for followers of the stable branch. IMHO replacing a library dependency by another library requires extra actions to be taken on the deployer side (making sure you have the new dependency packaged / present), so it's out of line.
Now I hear the pressure from the distributions which have already ripped out oauth2 -- the change is indeed harmless and desirable for them. But I still think we'd break our promise for a safe source of fixes to every user of the stablebranch if we accepted that patch.
In that case it seems fair for distributions which want to replace oauth2 with a safer alternative to carry a specific patch.
Thoughts ? Do we have past examples of introducing new deps in stable branch updates ?
On Mon, Mar 24, 2014 at 8:54 AM, Thierry Carrez thierry@openstack.orgwrote:
See the discussion @ https://review.openstack.org/#/c/70750/
I think this is not an acceptable change for the stable branch. We promise a "safe source of fixes", which means seamless upgrades that do not require extra actions for followers of the stable branch. IMHO replacing a library dependency by another library requires extra actions to be taken on the deployer side (making sure you have the new dependency packaged / present), so it's out of line.
Now I hear the pressure from the distributions which have already ripped out oauth2 -- the change is indeed harmless and desirable for them. But I still think we'd break our promise for a safe source of fixes to every user of the stablebranch if we accepted that patch.
In that case it seems fair for distributions which want to replace oauth2 with a safer alternative to carry a specific patch.
Thoughts ? Do we have past examples of introducing new deps in stable branch updates ?
-- Thierry Carrez (ttx)
Openstack-stable-maint mailing list Openstack-stable-maint@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
I tend to agree that a dependency change like this is "too big." OTOH, do we have any security ramifications for leaving the code as-is? Would it make sense to try to figure out which library is available and use it, rather than requiring one or the other?
Doug
2014-03-24 19:14 GMT+01:00 Doug Hellmann doug.hellmann@dreamhost.com:
I tend to agree that a dependency change like this is "too big." OTOH, do we have any security ramifications for leaving the code as-is? Would it make sense to try to figure out which library is available and use it, rather than requiring one or the other?
That would be stable-only patch so it would be even more risky IMHO. I guess the solution here is to document security issues clearly in 2013.2.3 release notes as Adam suggested.
Cheers, Alan
On Mon, Mar 24, 2014 at 5:55 PM, Alan Pevec apevec@gmail.com wrote:
2014-03-24 19:14 GMT+01:00 Doug Hellmann doug.hellmann@dreamhost.com:
I tend to agree that a dependency change like this is "too big." OTOH,
do we
have any security ramifications for leaving the code as-is? Would it make sense to try to figure out which library is available and use it, rather than requiring one or the other?
That would be stable-only patch so it would be even more risky IMHO. I guess the solution here is to document security issues clearly in 2013.2.3 release notes as Adam suggested.
Cheers, Alan
OK, I can go along with that.
Doug
Doug Hellmann wrote:
On Mon, Mar 24, 2014 at 5:55 PM, Alan Pevec <apevec@gmail.com mailto:apevec@gmail.com> wrote:
2014-03-24 19:14 GMT+01:00 Doug Hellmann <doug.hellmann@dreamhost.com <mailto:doug.hellmann@dreamhost.com>>: > I tend to agree that a dependency change like this is "too big." OTOH, do we > have any security ramifications for leaving the code as-is? Would it make > sense to try to figure out which library is available and use it, rather > than requiring one or the other? That would be stable-only patch so it would be even more risky IMHO. I guess the solution here is to document security issues clearly in 2013.2.3 release notes as Adam suggested.
FWIW the security issues detected so far are mostly weaknesses in nonce generators. The main issue is that it's security-sensitive and abandoned, so distributions want to get rid of it proactively.
In our case I would document in the release notes that oauth2 is abandoned upstream and that distributions that want to avoid it for Havana may apply this optional patch at [URL].
This is a typical case where distro-side patches make sense. It's temporary (icehouse fixed it) and distro-specific (not every distribution dumped it yet).
I don't know of any examples of introducing *new* deps in stable branch updates, but there have been several occasions where version requirements were bumped higher to unblock gate issues. IMHO that can be worse for stable distros (as opposed to requiring a new dependency that most can provide)
That said, I'm heavily leaning toward -1 on this as well. This isn't a new bug. Concerns about the use of the use python-oauth2 in Keystone on LP go a while now and a decision was made to ship optional oauth support in Havana's using python-oauth2. I don't think we can undo that now. A better solution would be to add a big ugly warning to documentation referencing relevant CVEs and mentioning the issue is fixed in Icehouse.
I also don't think its unreasonable for distros to carry their own cherry-picked patch from Icehouse to address the issue.
On Mon, Mar 24, 2014 at 5:54 AM, Thierry Carrez thierry@openstack.orgwrote:
See the discussion @ https://review.openstack.org/#/c/70750/
I think this is not an acceptable change for the stable branch. We promise a "safe source of fixes", which means seamless upgrades that do not require extra actions for followers of the stable branch. IMHO replacing a library dependency by another library requires extra actions to be taken on the deployer side (making sure you have the new dependency packaged / present), so it's out of line.
Now I hear the pressure from the distributions which have already ripped out oauth2 -- the change is indeed harmless and desirable for them. But I still think we'd break our promise for a safe source of fixes to every user of the stablebranch if we accepted that patch.
In that case it seems fair for distributions which want to replace oauth2 with a safer alternative to carry a specific patch.
Thoughts ? Do we have past examples of introducing new deps in stable branch updates ?
-- Thierry Carrez (ttx)
Openstack-stable-maint mailing list Openstack-stable-maint@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
2014-03-24 22:16 GMT+01:00 Adam Gandelman adamg@ubuntu.com:
I don't know of any examples of introducing *new* deps in stable branch updates, but there have been several occasions where version requirements were bumped higher to unblock gate issues. IMHO that can be worse for stable distros (as opposed to requiring a new dependency that most can provide)
We recently had a version bump for neutronclient and documented it in release notes https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.2#Neutron But OpenStack clients don't have official stable branch, so in theory should be safe to update.
That said, I'm heavily leaning toward -1 on this as well. This isn't a new bug. Concerns about the use of the use python-oauth2 in Keystone on LP go a while now and a decision was made to ship optional oauth support in Havana's using python-oauth2. I don't think we can undo that now. A better solution would be to add a big ugly warning to documentation referencing relevant CVEs and mentioning the issue is fixed in Icehouse.
ok, let's do that - what would be the right place, under https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.3#Known_Issues_and_Limit... or somewhere in official docs?
I also don't think its unreasonable for distros to carry their own cherry-picked patch from Icehouse to address the issue.
The other option would be to drop the optional code due to security concerns.
Cheers, Alan
2014-03-24 22:16 GMT+01:00 Adam Gandelman adamg@ubuntu.com:
I don't know of any examples of introducing *new* deps in stable branch updates, but there have been several occasions where version requirements were bumped higher to unblock gate issues. IMHO that can be worse for stable distros (as opposed to requiring a new dependency that most can provide)
We recently had a version bump for neutronclient and documented it in release notes https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.2#Neutron But OpenStack clients don't have official stable branch, so in theory should be safe to update.
Actually, the version bump still didn't reach the stable/havana branch [updated in master only]. The review is still 'in progress' (aka 'stuck') [first patch sent Feb 21]: https://review.openstack.org/#/c/82154/
/Ihar
participants (5)
-
Adam Gandelman
-
Alan Pevec
-
Doug Hellmann
-
Ihar Hrachyshka
-
Thierry Carrez