I would agree that it’s not worth the effort.  We’ve recently dropped this setting from stx-gui, so it will work with vanilla stein horizon anyways, and the recommendation to use the setting was removed from horizon’s documentation as well

 

Tyler

 

From: Jones, Bruce E [mailto:bruce.e.jones@intel.com]
Sent: Wednesday, March 6, 2019 6:18 PM
To: starlingx-discuss@lists.starlingx.io
Cc: Chen, Yan <yan.chen@intel.com>
Subject: [Starlingx-discuss] FW: Mar 5th 2019 Distro.openstack meeting

 

I have an issue to discuss about Yan’s work on the changes for line item 34 "CSRF AngularJS Fixes" in the distro.openstack upstream tracking spreadsheet.  The upstream submission has not been approved, due to lack of an automated test case.  In looking at Yan’s description of the work needed to get this change approved (below), it looks like the test framework changes will be more work than the feature is worth.

 

As such, I’d like to propose dropping this bugfix from the upstream work item list.  I’m looking for feedback on that proposal.

 

Thanks!

         brucej

 

From: Chen, Yan
Sent: Tuesday, March 5, 2019 5:22 PM
To: Xie, Cindy <cindy.xie@intel.com>; Jones, Bruce E <bruce.e.jones@intel.com>
Subject: RE: Mar 5th 2019 Distro.openstack meeting

 

Current test cases are all running on the HTTP environment.

This feature will only impact under HTTPS environment, when CSRF_COOKIE_HTTPONLY is enabled in Django (detailed introduction is here: https://docs.djangoproject.com/en/2.1/ref/settings/#csrf-cookie-httponly), according to the official document, this feature is kind of useless… So that’s why there’s no code in horizon to support this and no test case to test it either.

 

Designating the CSRF cookie as HttpOnly doesn’t offer any practical protection because CSRF is only to protect against cross-domain attacks. If an attacker can read the cookie via JavaScript, they’re already on the same domain as far as the browser knows, so they can do anything they like anyway. (XSS is a much bigger hole than CSRF.)

Although the setting offers little practical benefit, it’s sometimes required by security auditors.

 

Yan

 

From: Xie, Cindy
Sent: Wednesday, March 6, 2019 09:14
To: Jones, Bruce E <bruce.e.jones@intel.com>; Chen, Yan <yan.chen@intel.com>
Subject: RE: Mar 5th 2019 Distro.openstack meeting

 

Yan,

There are quite few Zuul testing like below, anything we can do to just insert one test case in?

 

horizon-openstack-tox-python3-django111SUCCESS in 11m 04s

horizon-selenium-headlessSUCCESS in 6m 02s (non-voting)

horizon-integration-testsSUCCESS in 53m 12s (non-voting)

horizon-dsvm-tempest-pluginSUCCESS in 34m 10s

horizon-dsvm-tempest-plugin-py27SUCCESS in 30m 39s

horizon-tox-bandit-baselineSUCCESS in 6m 02s (non-voting)

 

 

thx. - cindy

 

From: Jones, Bruce E
Sent: Wednesday, March 6, 2019 9:11 AM
To: Chen, Yan <yan.chen@intel.com>
Cc: Xie, Cindy <cindy.xie@intel.com>
Subject: RE: Mar 5th 2019 Distro.openstack meeting

 

How much work is it to modify the test framework?

 

From: Chen, Yan
Sent: Tuesday, March 5, 2019 5:10 PM
To: Jones, Bruce E <bruce.e.jones@intel.com>
Cc: Xie, Cindy <cindy.xie@intel.com>
Subject: RE: Mar 5th 2019 Distro.openstack meeting

 

Yes, exactly.

 

Yan

 

From: Jones, Bruce E
Sent: Wednesday, March 6, 2019 09:09
To: Chen, Yan <yan.chen@intel.com>
Cc: Xie, Cindy <cindy.xie@intel.com>
Subject: RE: Mar 5th 2019 Distro.openstack meeting

 

But if you don’t modify the tests, they won’t accept the code, right?

 

From: Chen, Yan
Sent: Tuesday, March 5, 2019 5:08 PM
To: Jones, Bruce E <bruce.e.jones@intel.com>
Cc: Xie, Cindy <cindy.xie@intel.com>
Subject: RE: Mar 5th 2019 Distro.openstack meeting

 

 

I just updated on the spreadsheet and modified the status to Unlikely:

There's no existing test case for the CSRF feature. Can not generate test framework for this patch.

 

This patch is only several lines but to test it automatically I need to modify the whole test framework. I don’t think it worth doing it. I’ve sent email to Tyler Smith (WRS) about this, still waiting for his reply.

 

Yan

 

From: Jones, Bruce E
Sent: Wednesday, March 6, 2019 02:15
To: He, Yongli <yongli.he@intel.com>; Chen, Yan <yan.chen@intel.com>
Cc: Ding, Jian-feng <jian-feng.ding@intel.com>; Xie, Cindy <cindy.xie@intel.com>
Subject: FW: Mar 5th 2019 Distro.openstack meeting

 

Hello Yong Li and Yan.   Can you please address your ARs as per below and update the tracking spreadsheet with the latest status?  Thank you!

         brucej

 

From: Jones, Bruce E [mailto:bruce.e.jones@intel.com]
Sent: Tuesday, March 5, 2019 7:30 AM
To: starlingx-discuss@lists.starlingx.io
Subject: [Starlingx-discuss] Mar 5th 2019 Distro.openstack meeting

 

Overall plan and status tracking document: https://etherpad.openstack.org/p/stx-openstack-patch-refactoring

·         Details: https://docs.google.com/spreadsheets/d/1udAtEpQljV2JZVs-525UhWyx-5ePOaSSkKD1CS27ohU/edit?usp=sharing

 

Meeting agenda and notes for the 3/5 meeting

·         NUMA aware live migration work is pushing to Train.  See Artom's latest update https://review.openstack.org/#/c/635669/

§  Wait for Train - unsatisfying, least effort

§  Carry forks (patches not necessarily accepted upstream)

·         Implement our own patches - expensive, deterministic, leads to new forks

·         Pull from upstream patch submissions - less expensive, risky, less perception of forks

§  Backport from Train to Stein (once the patches get accepted) - less expensive, some risk, less deterministic

§  Nova community doesn't merge things that aren’t' deployable or complete

§  We postponed decisions as to which options to apply to which patches - hopefully more will go in.

·         Review LP issues: https://bugs.launchpad.net/starlingx/+bugs?field.tag=stx.distro.openstack

·         Review upstream updates: https://docs.google.com/spreadsheets/d/1udAtEpQljV2JZVs-525UhWyx-5ePOaSSkKD1CS27ohU/edit?ts=5c1933cc#gid=0