[Starlingx-discuss] FW: Mar 5th 2019 Distro.openstack meeting

[Jones, Bruce E]

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 at intel.com>; Jones, Bruce E <bruce.e.jones at 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 at intel.com<mailto:bruce.e.jones at intel.com>>; Chen, Yan <yan.chen at intel.com<mailto:yan.chen at 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-django111<http://logs.openstack.org/32/637732/1/check/horizon-openstack-tox-python3-django111/37f9be4/>SUCCESS in 11m 04s
horizon-selenium-headless<http://logs.openstack.org/32/637732/1/check/horizon-selenium-headless/25743a3/>SUCCESS in 6m 02s (non-voting)
horizon-integration-tests<http://logs.openstack.org/32/637732/1/check/horizon-integration-tests/8ddbd9c/>SUCCESS in 53m 12s (non-voting)
horizon-dsvm-tempest-plugin<http://logs.openstack.org/32/637732/1/check/horizon-dsvm-tempest-plugin/31c0444/>SUCCESS in 34m 10s
horizon-dsvm-tempest-plugin-py27<http://logs.openstack.org/32/637732/1/check/horizon-dsvm-tempest-plugin-py27/5ce87a1/>SUCCESS in 30m 39s
horizon-tox-bandit-baseline<http://logs.openstack.org/32/637732/1/check/horizon-tox-bandit-baseline/c101d71/>SUCCESS in 6m 02s (non-voting)


thx. - cindy

From: Jones, Bruce E
Sent: Wednesday, March 6, 2019 9:11 AM
To: Chen, Yan <yan.chen at intel.com<mailto:yan.chen at intel.com>>
Cc: Xie, Cindy <cindy.xie at intel.com<mailto:cindy.xie at 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 at intel.com<mailto:bruce.e.jones at intel.com>>
Cc: Xie, Cindy <cindy.xie at intel.com<mailto:cindy.xie at 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 at intel.com<mailto:yan.chen at intel.com>>
Cc: Xie, Cindy <cindy.xie at intel.com<mailto:cindy.xie at 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 at intel.com<mailto:bruce.e.jones at intel.com>>
Cc: Xie, Cindy <cindy.xie at intel.com<mailto:cindy.xie at intel.com>>
Subject: RE: Mar 5th 2019 Distro.openstack meeting


  *   AR Bruce to ping Yan re: line item 34 "CSRF AngularJS Fixes"

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 at intel.com<mailto:yongli.he at intel.com>>; Chen, Yan <yan.chen at intel.com<mailto:yan.chen at intel.com>>
Cc: Ding, Jian-feng <jian-feng.ding at intel.com<mailto:jian-feng.ding at intel.com>>; Xie, Cindy <cindy.xie at intel.com<mailto:cindy.xie at 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 at intel.com]
Sent: Tuesday, March 5, 2019 7:30 AM
To: starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at 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/

  *   Suggest that we plan to backport the patches from Train to stx.2019.05 once they merge.

  *   We reviewed several different options for handling this situation:
?  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

  *   AR Frank to review the issues with his team and update as needed
*         Review upstream updates: https://docs.google.com/spreadsheets/d/1udAtEpQljV2JZVs-525UhWyx-5ePOaSSkKD1CS27ohU/edit?ts=5c1933cc#gid=0

  *   AR Bruce to ping Yong Li re: line item 7 "Clean up orphan instances"

  *   AR Yong Li to ask for an exception for line item 9 "NUMA Topology API"

  *   AR Frank re: line item 30 "RPC timeout handling" please have this re-tested

  *   AR Bruce to ping Yan re: line item 34 "CSRF AngularJS Fixes"


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20190306/5b93c7f8/attachment-0001.html>