coordination #43742
closed
coordination #36712: [saga] Use YaST specific framework for GUI testing
[functional][y][epic] Separate YaST UI framework to individual project
Added by riafarov over 5 years ago.
Updated over 3 years ago.
Target version:
SUSE QA - Milestone 25
Estimated time:
(Total: 39.00 h)
Description
Motivation¶
As an outcome of #37327, it was decided that we cannot afford having this functionality in libyui directly, as it also might introduce security flows allowing remote control on the applications.
So solution to that it to extract part to the separate package which will be using existing libyui and therefore lowering risks of missing bugs cause of using different libyui version in comparison to the one which will be shipped.
As a next step here, we need to split changes in http_server branch (https://github.com/libyui/libyui/compare/http_server?expand=1) to separate package, submitting only required parts for parsing to the libyui, or ideally overriding those objects.
It might requiring some changes to libyui as well.
Task requires more research on C++ plugins, however libyui-qt or libyui-ncurses can serve as a base for the solution, as are using similar approach while being loaded.
Acceptance criteria¶
- YaST UI testing framework parts which are irrelevant for libyui, are separated and having separate project
- Copied from coordination #38876: [functional][y][epic] Automate yast2 hostname test suite using YaST framework which is not relying on shortcuts added
- Copied from deleted (coordination #38876: [functional][y][epic] Automate yast2 hostname test suite using YaST framework which is not relying on shortcuts)
- Due date set to 2018-12-04
- Status changed from New to Workable
- Parent task set to #38876
- Estimated time set to 13.00 h
- Status changed from Workable to In Progress
So libyui already has mechanism to load libraries using dlopen calls, see (YUIPlugin)[[https://github.com/libyui/libyui/blob/master/src/YUIPlugin.h]]. So that would be best choice to simply reuse it. As for the framework, we still will need some changes in the libyui itself, like changes to src/YPushButton.h, src/YTable.cc, src/YWizard.h, etc. Experimenting on it to make it work.
- Start date set to 2018-06-13
due to changes in a related task
- Due date changed from 2018-12-04 to 2018-12-18
- Due date changed from 2018-12-18 to 2019-01-15
Missing parts:
- project on OBS for new packages
- loading of the module in libyui
- Target version changed from Milestone 21 to Milestone 22
- Status changed from In Progress to Feedback
I'd like to add the outcome from my (informal) request to the Security Team.
mgerstner@suse.de writes:
"I would like to see (additionally) to restrict such a REST API to be
enabled only when e.g. a file in a trusted location exists like
/etc/yast.debug or a config file entry or similar. The thing with
environment variables alone is that they can be inherited sometimes even
across su/sudo boundaries. This makes them more susceptive to unexpected
security issues."
"What kind of authentication do you have in mind here? If authentication credentials
are sent over the socket and YUI_HTTP_REMOTE is involved then you should
take care not to do this unauthenticated/unencrypted. Except you can
really make sure this will never be used outside of lab environments."
Additionally jsegitz@suse.de suggests to show a popup or any kind of status line in the UI in case if the remote API is enabled.
In my opinion the file in a trusted location even could be the Plugin itself.
Before we push it into any product we better open a Security Audit Bug as described in
https://en.opensuse.org/openSUSE:Package_security_guidelines#Audit_Bugs_for_the_Security_Team
- Subject changed from [functional][y] Separate YaST UI framework to individual project to [functional][y][epic] Separate YaST UI framework to individual project
- Parent task deleted (
#38876)
- Parent task set to #36712
- Due date changed from 2019-01-29 to 2019-02-12
due to changes in a related task
- Due date changed from 2019-02-12 to 2019-02-26
due to changes in a related task
- Due date changed from 2019-02-26 to 2019-03-12
due to changes in a related task
- Target version changed from Milestone 22 to Milestone 23
@riafarov I can see two subtasks still open so we could set this ticket to be "Blocked by subtasks". However IMHO #43742#note-13 is a reasonable concern so I guess this should be adressed first?
- Status changed from Feedback to In Progress
okurz wrote:
@riafarov I can see two subtasks still open so we could set this ticket to be "Blocked by subtasks". However IMHO #43742#note-13 is a reasonable concern so I guess this should be adressed first?
I don't really like to block epics because subtasks are not resolved, as it means it's in progress, so I put in progress. Comment from #43742#note-13 has been already addressed, there might be minor changes required when we have fully working solution.
sure, "In Progress" works as well.
- Due date changed from 2019-03-12 to 2019-01-08
due to changes in a related task
- Due date set to 2019-03-26
due to changes in a related task
- Due date changed from 2019-03-26 to 2019-04-09
due to changes in a related task
- Target version changed from Milestone 23 to Milestone 25
- Due date changed from 2019-04-09 to 2019-04-23
due to changes in a related task
- Due date changed from 2019-04-23 to 2019-04-09
due to changes in a related task
- Status changed from In Progress to Resolved
- Tracker changed from action to coordination
Also available in: Atom
PDF