action #43742

action #36712: [sle][functional][y][yast][hackweek][saga] Use YaST specific framework for GUI testing

[functional][y][epic] Separate YaST UI framework to individual project

Added by riafarov 9 months ago. Updated 4 months ago.

Status:ResolvedStart date:08/01/2019
Priority:NormalDue date:09/04/2019
Assignee:riafarov% Done:

100%

Category:Enhancement to existing testsEstimated time:39.00 hours
Target version:SUSE QA tests - Milestone 25
Difficulty:
Duration: 66

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

  1. YaST UI testing framework parts which are irrelevant for libyui, are separated and having separate project

Subtasks

action #45824: [functional][y] split libyuiResolvedriafarov

action #45827: [functional][y] Split libyui-ncursesResolvedriafarov

action #45830: [functional][y] Split libyui-qtResolvedriafarov

action #49430: [functional][y] Adjust testframework proposals to the fee...Resolvedriafarov

History

#1 Updated by riafarov 9 months ago

  • Copied from action #38876: [functional][y][epic] Automate yast2 hostname test suite using YaST framework which is not relying on shortcuts added

#2 Updated by riafarov 9 months ago

  • Copied from deleted (action #38876: [functional][y][epic] Automate yast2 hostname test suite using YaST framework which is not relying on shortcuts)

#3 Updated by riafarov 9 months ago

  • Due date set to 04/12/2018
  • Status changed from New to Workable
  • Parent task set to #38876

#4 Updated by riafarov 9 months ago

  • Estimated time set to 13.00

#5 Updated by riafarov 9 months ago

  • Assignee set to riafarov

#6 Updated by riafarov 9 months ago

  • 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.

#7 Updated by riafarov 9 months ago

  • Start date set to 13/06/2018

due to changes in a related task

#8 Updated by riafarov 9 months ago

  • Due date changed from 04/12/2018 to 18/12/2018

#9 Updated by riafarov 8 months ago

  • Due date changed from 18/12/2018 to 15/01/2019

Missing parts:
* project on OBS for new packages
* loading of the module in libyui

#10 Updated by riafarov 8 months ago

  • Target version changed from Milestone 21 to Milestone 22

#11 Updated by riafarov 8 months ago

https://github.com/libyui/libyui/pull/141

Solution for libyui provided, gathering feedback now before proceeding with libyui-ncurses and libyui-qt libraries.

#12 Updated by riafarov 8 months ago

  • Status changed from In Progress to Feedback

#13 Updated by cwh 8 months ago

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

#14 Updated by riafarov 7 months ago

  • Subject changed from [functional][y] Separate YaST UI framework to individual project to [functional][y][epic] Separate YaST UI framework to individual project

#15 Updated by riafarov 7 months ago

  • Parent task deleted (#38876)

#16 Updated by riafarov 7 months ago

  • Parent task set to #36712

#17 Updated by riafarov 7 months ago

  • Due date changed from 29/01/2019 to 12/02/2019

due to changes in a related task

#18 Updated by riafarov 7 months ago

  • Due date changed from 12/02/2019 to 26/02/2019

due to changes in a related task

#19 Updated by riafarov 6 months ago

  • Due date changed from 26/02/2019 to 12/03/2019

due to changes in a related task

#20 Updated by okurz 6 months ago

  • 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?

#21 Updated by riafarov 6 months ago

  • 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.

#22 Updated by okurz 6 months ago

sure, "In Progress" works as well.

#23 Updated by riafarov 5 months ago

  • Due date changed from 12/03/2019 to 08/01/2019

due to changes in a related task

#24 Updated by riafarov 5 months ago

  • Due date set to 26/03/2019

due to changes in a related task

#25 Updated by riafarov 5 months ago

  • Due date changed from 26/03/2019 to 09/04/2019

due to changes in a related task

#26 Updated by riafarov 5 months ago

  • Target version changed from Milestone 23 to Milestone 25

#27 Updated by riafarov 4 months ago

  • Due date changed from 09/04/2019 to 23/04/2019

due to changes in a related task

#28 Updated by riafarov 4 months ago

  • Due date changed from 23/04/2019 to 09/04/2019

due to changes in a related task

#29 Updated by riafarov 4 months ago

  • Status changed from In Progress to Resolved

So this one is done, I will create separate backlog items for the improvements we should include: https://github.com/libyui/libyui-rest-api/blob/master/TODO.md
and also trying things for yast modules.

Also available in: Atom PDF