[Yahoo-eng-team] [Bug 1840090] [NEW] Cannot reparent projects
Public bug reported: For a variety of reasons Keystone needs the ability to 'safely' reparent a project (and children). This should be able to be done via and API, and should be able to be done on an enabled project. It should invalidate any tokens related to that project (and children) as well. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1840090 Title: Cannot reparent projects Status in OpenStack Identity (keystone): New Bug description: For a variety of reasons Keystone needs the ability to 'safely' reparent a project (and children). This should be able to be done via and API, and should be able to be done on an enabled project. It should invalidate any tokens related to that project (and children) as well. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840090/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1839577] [NEW] totp should support previous windows
Public bug reported: TOTP auth should allow at least 1 previous window to be included during auth to limit time sync issues and generally better UX. Optionally this should be configurable (or disabled). ** Affects: keystone Importance: Undecided Assignee: Adrian Turjak (adriant-y) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1839577 Title: totp should support previous windows Status in OpenStack Identity (keystone): In Progress Bug description: TOTP auth should allow at least 1 previous window to be included during auth to limit time sync issues and generally better UX. Optionally this should be configurable (or disabled). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1839577/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1824484] [NEW] workflow modal add_item_link is broken
Public bug reported: When using add_item_link in a workflow action (like the workflow for allocating a floating ip to an instance), the modal throws an error and never returns to the original action. The form view for the floating ip allocation action is returning the following: "["f5aae610-0bed-45d7-a5e5-1cae9f3a30a7", "172.24.4.42"]" Which then the modal.js code can't parse as json and just stalls: https://github.com/openstack/horizon/blob/master/horizon/static/horizon/js/horizon.modals.js#L330 I'm not 100% sure what the hell "" is, or where it is coming from, but it's something I've only just now encountered in Devstack. I find it unlikely that Django itself does it, so it could be something like apache. The issue goes away when we set the content-type to text/plain. We can't set it to json because other parts of the modal.js parse it and then the code breaks in the same place but for different reasons... Basically, we aren't setting content-type, so it defaults to html: https://github.com/openstack/horizon/blob/master/horizon/forms/views.py#L195 ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1824484 Title: workflow modal add_item_link is broken Status in OpenStack Dashboard (Horizon): New Bug description: When using add_item_link in a workflow action (like the workflow for allocating a floating ip to an instance), the modal throws an error and never returns to the original action. The form view for the floating ip allocation action is returning the following: "["f5aae610-0bed-45d7-a5e5-1cae9f3a30a7", "172.24.4.42"]" Which then the modal.js code can't parse as json and just stalls: https://github.com/openstack/horizon/blob/master/horizon/static/horizon/js/horizon.modals.js#L330 I'm not 100% sure what the hell "" is, or where it is coming from, but it's something I've only just now encountered in Devstack. I find it unlikely that Django itself does it, so it could be something like apache. The issue goes away when we set the content-type to text/plain. We can't set it to json because other parts of the modal.js parse it and then the code breaks in the same place but for different reasons... Basically, we aren't setting content-type, so it defaults to html: https://github.com/openstack/horizon/blob/master/horizon/forms/views.py#L195 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1824484/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1823089] [NEW] modal js code can't handle file download
Public bug reported:
The modal js code doesn't know how to process and handle when the
response data is a file attachment. What it does is append the data from
the file to the modal_wrapper.
My reason for hitting this is that I have a form which asks for some
information, and then the handle function returns a file.
```
content = render_to_string(
template, context, request=request)
content = '\n'.join([line for line in content.split('\n')
if line.strip()])
response = http.HttpResponse(
content, content_type="text/plain")
filename = 'openstack_backup_codes.txt'
disposition = 'attachment; filename=%s' % filename
response['Content-Disposition'] = disposition.encode(
'utf-8')
response['Content-Length'] = str(len(response.content))
return response
```
** Affects: horizon
Importance: Undecided
Assignee: Adrian Turjak (adriant-y)
Status: In Progress
** Summary changed:
- modal js code breaks on file download
+ modal js code can't handle file download
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1823089
Title:
modal js code can't handle file download
Status in OpenStack Dashboard (Horizon):
In Progress
Bug description:
The modal js code doesn't know how to process and handle when the
response data is a file attachment. What it does is append the data
from the file to the modal_wrapper.
My reason for hitting this is that I have a form which asks for some
information, and then the handle function returns a file.
```
content = render_to_string(
template, context, request=request)
content = '\n'.join([line for line in content.split('\n')
if line.strip()])
response = http.HttpResponse(
content, content_type="text/plain")
filename = 'openstack_backup_codes.txt'
disposition = 'attachment; filename=%s' % filename
response['Content-Disposition'] = disposition.encode(
'utf-8')
response['Content-Length'] = str(len(response.content))
return response
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1823089/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1805469] [NEW] nova extension checking is broken
Public bug reported: A bug in nova extension checking was introduced by: https://github.com/openstack/horizon/commit/3acb28270a27837253d308f05d40240b04a6affa#diff-2f8897fc38ecf035f786ac562c878dcf we are comparing `ext` (an object) to a string, rather than `ext.name`: https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/nova.py#L1090 ** Affects: horizon Importance: Undecided Assignee: Adrian Turjak (adriant-y) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1805469 Title: nova extension checking is broken Status in OpenStack Dashboard (Horizon): In Progress Bug description: A bug in nova extension checking was introduced by: https://github.com/openstack/horizon/commit/3acb28270a27837253d308f05d40240b04a6affa#diff-2f8897fc38ecf035f786ac562c878dcf we are comparing `ext` (an object) to a string, rather than `ext.name`: https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/nova.py#L1090 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1805469/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1772345] [NEW] DEFAULT_SERVICE_REGIONS overrides services_region cookie
Public bug reported: DEFAULT_SERVICE_REGIONS makes it sound like it is setting default regions when a services_region cookie isn't present, when in fact it takes precedence over a cookie. This is terrible UX because a user that can change to another valid region is forced on login to the region always defined in DEFAULT_SERVICE_REGIONS, and then always change manually to the region they want every time. The cookie, a user controlled value, should always take precedence over a 'default' value. If we want to allow a forceful override then it should be called something else such as FORCED_SERVICE_REGIONS. The settings don't even make this behavior clear, which further makes me think this is a bug or an unconsidered part of the implementation: https://docs.openstack.org/horizon/latest/configuration/settings.html#default-service-regions We should change the precedence to: 1. services_region cookie 2. DEFAULT_SERVICE_REGIONS endpoint 3. any valid region from the catalog ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1772345 Title: DEFAULT_SERVICE_REGIONS overrides services_region cookie Status in OpenStack Dashboard (Horizon): New Bug description: DEFAULT_SERVICE_REGIONS makes it sound like it is setting default regions when a services_region cookie isn't present, when in fact it takes precedence over a cookie. This is terrible UX because a user that can change to another valid region is forced on login to the region always defined in DEFAULT_SERVICE_REGIONS, and then always change manually to the region they want every time. The cookie, a user controlled value, should always take precedence over a 'default' value. If we want to allow a forceful override then it should be called something else such as FORCED_SERVICE_REGIONS. The settings don't even make this behavior clear, which further makes me think this is a bug or an unconsidered part of the implementation: https://docs.openstack.org/horizon/latest/configuration/settings.html#default-service-regions We should change the precedence to: 1. services_region cookie 2. DEFAULT_SERVICE_REGIONS endpoint 3. any valid region from the catalog To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1772345/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1767924] [NEW] Horizon Glance tests are not using v2
Public bug reported: In the horizon tests we have data for V2 and models that look like the V2 data. Our tests don't use that, so even though our default version is V2, our tests are acting as if everything is v1: https://github.com/openstack/horizon/blob/master/openstack_dashboard/test/test_data/glance_data.py#L54 https://github.com/openstack/horizon/blob/master/openstack_dashboard/test/unit/api/test_glance.py#L37-L38 We should be calling `self.imagesV2.list()` or better yet building it so that the API constructs correctly pretend to be the correct version based on the active version. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1767924 Title: Horizon Glance tests are not using v2 Status in OpenStack Dashboard (Horizon): New Bug description: In the horizon tests we have data for V2 and models that look like the V2 data. Our tests don't use that, so even though our default version is V2, our tests are acting as if everything is v1: https://github.com/openstack/horizon/blob/master/openstack_dashboard/test/test_data/glance_data.py#L54 https://github.com/openstack/horizon/blob/master/openstack_dashboard/test/unit/api/test_glance.py#L37-L38 We should be calling `self.imagesV2.list()` or better yet building it so that the API constructs correctly pretend to be the correct version based on the active version. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1767924/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1767021] [NEW] Login form button text is inconsistent
Public bug reported: The login form button appears to be by default 'connect', which does not really match the common text for such a button. 'Log in' or 'Sign in' are more common, and it appears the code technically should show 'Sign in' under some circumstances (auth_type==='credentials'). I don't know in what context 'Connect' is ever actually appropriate, and I think we should just stick with 'Sign in' as the only text here. ** Affects: horizon Importance: Undecided Assignee: Adrian Turjak (adriant-y) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1767021 Title: Login form button text is inconsistent Status in OpenStack Dashboard (Horizon): In Progress Bug description: The login form button appears to be by default 'connect', which does not really match the common text for such a button. 'Log in' or 'Sign in' are more common, and it appears the code technically should show 'Sign in' under some circumstances (auth_type==='credentials'). I don't know in what context 'Connect' is ever actually appropriate, and I think we should just stick with 'Sign in' as the only text here. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1767021/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1763204] [NEW] wsgi.py is missing
Public bug reported: Horizon was likely started very early along with Django, and thus has the old format wsgi file as "django.wsgi". https://github.com/openstack/horizon/tree/master/openstack_dashboard/wsgi This is not how django names this file anymore, nor how it is really used. https://stackoverflow.com/questions/20035252/difference-between-wsgi-py-and-django-wsgi https://docs.djangoproject.com/en/1.11/howto/deployment/wsgi/modwsgi/ The expectation is having a wsgi.py file somewhere along your importable python path. Normally this is in the same place as your settings.py file when building a default django project. Ideally we should rename and move the file to a place it is easier to import from: horizon/openstack_dashboard/wsgi/django.wsgi horizon/openstack_dashboard/wsgi.py gunicorn cannot import and run it because it isn't a '.py' file, and is one of the most popular wsgi servers around. By doing the above move and rename the file can now be imported and run as: gunicorn openstack_dashboard.wsgi:application NOTE: This will likely break anyone using it right now. We may instead want to copy the file to the new location and add a deprecation log into the old one with a notice to remove in 2 cycles. Ideally also document that deployers should be using the new file. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1763204 Title: wsgi.py is missing Status in OpenStack Dashboard (Horizon): New Bug description: Horizon was likely started very early along with Django, and thus has the old format wsgi file as "django.wsgi". https://github.com/openstack/horizon/tree/master/openstack_dashboard/wsgi This is not how django names this file anymore, nor how it is really used. https://stackoverflow.com/questions/20035252/difference-between-wsgi-py-and-django-wsgi https://docs.djangoproject.com/en/1.11/howto/deployment/wsgi/modwsgi/ The expectation is having a wsgi.py file somewhere along your importable python path. Normally this is in the same place as your settings.py file when building a default django project. Ideally we should rename and move the file to a place it is easier to import from: horizon/openstack_dashboard/wsgi/django.wsgi horizon/openstack_dashboard/wsgi.py gunicorn cannot import and run it because it isn't a '.py' file, and is one of the most popular wsgi servers around. By doing the above move and rename the file can now be imported and run as: gunicorn openstack_dashboard.wsgi:application NOTE: This will likely break anyone using it right now. We may instead want to copy the file to the new location and add a deprecation log into the old one with a notice to remove in 2 cycles. Ideally also document that deployers should be using the new file. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1763204/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1757112] [NEW] wrong variable name in context_processors.py
Public bug reported: In the patch that added user menu links, the variable name for disabling v2 rc files was renamed by accident it seems in the context_processors.py module. https://github.com/openstack/horizon/commit/924239073ec8036265d13a3c6b09d6fa7865147f#diff-5a128d55603c030b687d1321df381ab0L100 vs https://github.com/openstack/horizon/commit/924239073ec8036265d13a3c6b09d6fa7865147f#diff-5a128d55603c030b687d1321df381ab0R91 Because of that the v2 download in the user dropdown wasn't being hidden correctly. The fix is easy. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1757112 Title: wrong variable name in context_processors.py Status in OpenStack Dashboard (Horizon): New Bug description: In the patch that added user menu links, the variable name for disabling v2 rc files was renamed by accident it seems in the context_processors.py module. https://github.com/openstack/horizon/commit/924239073ec8036265d13a3c6b09d6fa7865147f#diff-5a128d55603c030b687d1321df381ab0L100 vs https://github.com/openstack/horizon/commit/924239073ec8036265d13a3c6b09d6fa7865147f#diff-5a128d55603c030b687d1321df381ab0R91 Because of that the v2 download in the user dropdown wasn't being hidden correctly. The fix is easy. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1757112/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1755056] [NEW] role assignment query filter names inconsistent
Public bug reported: The role assignment list API has filters in the style of "user.id" rather than "user_id". This is odd since every other API in Keystone appears to be with "_", including some of the other filters on role assignment itself. https://developer.openstack.org/api-ref/identity/v3/#id595 The SDK incorrectly made the assumption that this was consistent and has been fixed now to map correctly to the expected server side filter names: https://review.openstack.org/#/c/550700/ But ideally we should be adding the "_" versions as well so that the APIs are consistent and make it a rule to keep using "_" rather than "." for future APIs. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1755056 Title: role assignment query filter names inconsistent Status in OpenStack Identity (keystone): New Bug description: The role assignment list API has filters in the style of "user.id" rather than "user_id". This is odd since every other API in Keystone appears to be with "_", including some of the other filters on role assignment itself. https://developer.openstack.org/api-ref/identity/v3/#id595 The SDK incorrectly made the assumption that this was consistent and has been fixed now to map correctly to the expected server side filter names: https://review.openstack.org/#/c/550700/ But ideally we should be adding the "_" versions as well so that the APIs are consistent and make it a rule to keep using "_" rather than "." for future APIs. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1755056/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1732298] [NEW] Migration unit tests incorrectly failing for 'alter' in contract phase
Public bug reported: The unit tests to ensure only the correct types of migrations occur at the given step (expand, migrate, contract), are flagging correct types as incorrect. This appears to be a failure in the unit tests for this themselves, and at least for now appears to be specific to 'alter' in the contract phase, a phase where alter is meant to go. An example is seen with the failures of this patch: https://review.openstack.org/#/c/440941/ ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1732298 Title: Migration unit tests incorrectly failing for 'alter' in contract phase Status in OpenStack Identity (keystone): New Bug description: The unit tests to ensure only the correct types of migrations occur at the given step (expand, migrate, contract), are flagging correct types as incorrect. This appears to be a failure in the unit tests for this themselves, and at least for now appears to be specific to 'alter' in the contract phase, a phase where alter is meant to go. An example is seen with the failures of this patch: https://review.openstack.org/#/c/440941/ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1732298/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1717847] [NEW] Policy does not work for trusts
Public bug reported: see: http://lists.openstack.org/pipermail/openstack- dev/2017-September/122115.html In short, the trusts APIs handle their policy in code rather than from the policy file. This is rather confusing seeing as we have policies for trusts in the policy json file which do nothing: https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json#L137-L142 We should set better default policies, and change the code to respect the policy files rather than handle the policy checking based on hardcoded values. This change needs to be handled carefully (and made very obvious in release notes), because anyone using an older policy file once the change to respect the policy file is part of a release, will mean any authed user can list trusts because of the existing (and incorrect) default policy rules. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1717847 Title: Policy does not work for trusts Status in OpenStack Identity (keystone): New Bug description: see: http://lists.openstack.org/pipermail/openstack- dev/2017-September/122115.html In short, the trusts APIs handle their policy in code rather than from the policy file. This is rather confusing seeing as we have policies for trusts in the policy json file which do nothing: https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json#L137-L142 We should set better default policies, and change the code to respect the policy files rather than handle the policy checking based on hardcoded values. This change needs to be handled carefully (and made very obvious in release notes), because anyone using an older policy file once the change to respect the policy file is part of a release, will mean any authed user can list trusts because of the existing (and incorrect) default policy rules. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1717847/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1669610] Re: Insecure defaults for `openstack security group rule create`
** Also affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1669610 Title: Insecure defaults for `openstack security group rule create` Status in neutron: New Status in python-openstackclient: Incomplete Bug description: It's really easy to open up access to anyone by mistake. If you supply no options when creating a new rule, it defaults to allowing access to all ports to any remote host. I'm not sure what the right fix is, but I would expect that sort of permissive access to be a bit harder to create. # allow anyone to access any tcp port - so simple! $ openstack security group rule create default +---+--+ | Field | Value| +---+--+ | created_at| None | | description | None | | direction | ingress | | ether_type| IPv4 | | id| 7d481fad-9b57-4e71-9d63-fbba895e1a6c | | name | None | | port_range_max| None | | port_range_min| None | | project_id| c6f313e10752449ea9b70acfba353c80 | | protocol | tcp | | remote_group_id | None | | remote_ip_prefix | 0.0.0.0/0| | revision_number | None | | security_group_id | a5fbd65f-e4da-47d3-90cb-8dfc81eccd66 | | updated_at| None | +---+--+ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1669610/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1669630] [NEW] Network RBAC acceptance workflow
Public bug reported: Network RBAC is hugely useful, but the policy is too limited and as such causes some potential security problems. It is either turned on for everyone, or off. No in between, with the only limitation being no wildcards for non-admins. If you know the project id, you can share a network to that project id. This allows you to name a network 'public' or 'default' and share it to others in hopes of them connecting to it where you then potentially compromise their instances. Effectively this allows honey-pot networks. The only layer of safely you have is first needing to gleam a project id before you can do this, effectively security through obscurity, which is a terrible approach. Ideally network RBAC should work the same as image sharing in Glance. You share a network, and the other project must accept it before it becomes usable. This doesn't stop a too trusting party from accepting an unsafe network, but it means they have some warning before doing anything silly. Otherwise the onus is on them to always be vigilant for shared networks that shouldn't be there, which is not exactly something we want user to have to worry about. This is particularly bad in a public cloud setting, less so in private cloud. The proposed fix is to add an acceptance workflow, and a new column on the RBAC models to allow that. There is no good way to make such a feature backwards compatible. As such the easiest and probably best solution is to setup a config entry that turns on acceptance for Network RBAC, with an initial default of no acceptance workflow. Combine this with a deprecation warning that the default would change to acceptance as default going forward, but would give enough people making use of the no acceptance feature time to set their configs to turn it off. A further extension would be the addition of an auto-acceptance feature which would be a second config setting (a list of possible conditions) linked to a series of optional checks during Network RBAC creation where if any of them are met, the Network RBAC policy is created without the need for acceptance. The two default conditions for this should be: - User has roles in both projects attempted to share between. - Both projects are in the same project tree. The first, a role check is a single call to the role assignment API in Keystone. The second is two API calls to project detail with "parents_as_ids=true" for both projects, and comparing if there is a matching ID in the two parent paths that isn't the domain. Both are simple enough and will not add much additional time, but will allow a nicer UX than always requiring acceptance. Since Neutron has an admin user to be able to validate tokens, using it as well to do these checks shouldn't be much of a stretch. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1669630 Title: Network RBAC acceptance workflow Status in neutron: New Bug description: Network RBAC is hugely useful, but the policy is too limited and as such causes some potential security problems. It is either turned on for everyone, or off. No in between, with the only limitation being no wildcards for non-admins. If you know the project id, you can share a network to that project id. This allows you to name a network 'public' or 'default' and share it to others in hopes of them connecting to it where you then potentially compromise their instances. Effectively this allows honey-pot networks. The only layer of safely you have is first needing to gleam a project id before you can do this, effectively security through obscurity, which is a terrible approach. Ideally network RBAC should work the same as image sharing in Glance. You share a network, and the other project must accept it before it becomes usable. This doesn't stop a too trusting party from accepting an unsafe network, but it means they have some warning before doing anything silly. Otherwise the onus is on them to always be vigilant for shared networks that shouldn't be there, which is not exactly something we want user to have to worry about. This is particularly bad in a public cloud setting, less so in private cloud. The proposed fix is to add an acceptance workflow, and a new column on the RBAC models to allow that. There is no good way to make such a feature backwards compatible. As such the easiest and probably best solution is to setup a config entry that turns on acceptance for Network RBAC, with an initial default of no acceptance workflow. Combine this with a deprecation warning that the default would change to acceptance as default going forward, but would give enough people making use of the no acceptance feature time to set their configs to turn it off. A further extension would be the add
[Yahoo-eng-team] [Bug 1659456] [NEW] panels in PANEL_GROUP="default" are hidden
Public bug reported: Default panel group items are collapsed and hidden if used in conjunction with non-default panel groups. The divs and panel links are present in the source for the page, but cannot be accessed without editing the html in browser. An example would be attempting to add a new panel to the default panel group for the 'project' dashboard. The panel would be accessible directly via the url, the code would be in the html, but the css classes would mean it would be hidden. On the menu the new panel should sit at the same level as 'compute'/'network'/etc but it is simply hidden and there is no way to as a normal user click or unhide that panel. This happens because of the following code: https://github.com/openstack/horizon/blob/master/horizon/templates/horizon/_sidebar.html#L35 In part this is a regression of: https://bugs.launchpad.net/horizon/+bug/1403094 Although in this case the default panel group seems to work, just the template logic is no honouring it. ** Affects: horizon Importance: Undecided Assignee: Adrian Turjak (adriant-y) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1659456 Title: panels in PANEL_GROUP="default" are hidden Status in OpenStack Dashboard (Horizon): In Progress Bug description: Default panel group items are collapsed and hidden if used in conjunction with non-default panel groups. The divs and panel links are present in the source for the page, but cannot be accessed without editing the html in browser. An example would be attempting to add a new panel to the default panel group for the 'project' dashboard. The panel would be accessible directly via the url, the code would be in the html, but the css classes would mean it would be hidden. On the menu the new panel should sit at the same level as 'compute'/'network'/etc but it is simply hidden and there is no way to as a normal user click or unhide that panel. This happens because of the following code: https://github.com/openstack/horizon/blob/master/horizon/templates/horizon/_sidebar.html#L35 In part this is a regression of: https://bugs.launchpad.net/horizon/+bug/1403094 Although in this case the default panel group seems to work, just the template logic is no honouring it. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1659456/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1607119] [NEW] TOTP auth not functional in python3
Public bug reported:
Because of how python3 handles byte>str conversion, the passcode
generation function produces a mangled result in python3. The reason the
unit tests still pass in python3 is because the tests also use the same
function and thus the server and the tests are both sending and
expecting the same mangled passcode.
This would then mean that anyone correctly generating the passcode and
attempting to authenticate via TOTP would fail because the server is
expecting a mangled passcode.
The fix is to not use six.text_type, as it does the wrong thing, and
instead use .decode('utf-8') which produces the correct result in both
python2 and python3.
Example of why and how this happens:
Python2:
>>> passcode = b'123456'
>>> print passcode
123456
>>> type(passcode)
>>> import six
>>> six.text_type(passcode)
u'123456'
>>> type(six.text_type(passcode))
>>> otherstring = "openstack"
>>> otherstring + passcode
'openstack123456'
>>> passcode.decode('utf-8')
u'123456'
>>> type(passcode.decode('utf-8'))
Python3:
>>> passcode = b'123456'
>>> print(passcode)
b'123456'
>>> type(passcode)
>>> import six
>>> six.text_type(passcode)
"b'123456'"
>>> type(six.text_type(passcode))
>>> otherstring = "openstack"
>>> otherstring + passcode
Traceback (most recent call last):
File "", line 1, in
TypeError: Can't convert 'bytes' object to str implicitly
>>> otherstring + str(passcode)
"openstackb'123456'"
>>> passcode.decode('utf-8')
'123456'
>>> type(passcode.decode('utf-8'))
** Affects: keystone
Importance: Undecided
Assignee: Adrian Turjak (adriant-y)
Status: New
** Description changed:
Because of how python3 handles byte>str conversion, the passcode
generation function produces a mangled result in python3. The reason the
unit tests still pass in python3 is because the tests also use the same
function and thus the server and the tests are both sending and
expecting the same mangled passcode.
+
+ This would then mean that anyone correctly generating the passcode and
+ attempting to authenticate via TOTP would fail because the server is
+ expecting a mangled passcode.
The fix is to not use six.text_type, as it does the wrong thing, and
instead use .decode('utf-8') which produces the correct result in both
python2 and python3.
Example of why and how this happens:
Python2:
>>> passcode = b'123456'
>>> print passcode
123456
>>> type(passcode)
>>> import six
>>> six.text_type(passcode)
u'123456'
>>> type(six.text_type(passcode))
>>> otherstring = "openstack"
>>> otherstring + passcode
'openstack123456'
>>> passcode.decode('utf-8')
u'123456'
>>> type(passcode.decode('utf-8'))
Python3:
>>> passcode = b'123456'
>>> print(passcode)
b'123456'
>>> type(passcode)
>>> import six
>>> six.text_type(passcode)
"b'123456'"
>>> type(six.text_type(passcode))
>>> otherstring = "openstack"
>>> otherstring + passcode
Traceback (most recent call last):
- File "", line 1, in
+ File "", line 1, in
TypeError: Can't convert 'bytes' object to str implicitly
>>> otherstring + str(passcode)
"openstackb'123456'"
>>> passcode.decode('utf-8')
'123456'
>>> type(passcode.decode('utf-8'))
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1607119
Title:
TOTP auth not functional in python3
Status in OpenStack Identity (keystone):
New
Bug description:
Because of how python3 handles byte>str conversion, the passcode
generation function produces a mangled result in python3. The reason
the unit tests still pass in python3 is because the tests also use the
same function and thus the server and the tests are both sending and
expecting the same mangled passcode.
This would then mean that anyone correctly generating the passcode and
attempting to authenticate via TOTP would fail because the server is
expecting a mangled passcode.
The fix is to not use six.text_type, as it does the wrong thing, and
instead use .decode('utf-8') which produces the corr
