coordination #36712: [saga] Use YaST specific framework for GUI testing
[functional][y][epic] Separate YaST UI framework to individual project
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.
- YaST UI testing framework parts which are irrelevant for libyui, are separated and having separate project
#6 Updated by riafarov about 3 years 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.
#13 Updated by cwh almost 3 years ago
I'd like to add the outcome from my (informal) request to the Security Team.
"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
"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 email@example.com 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
#21 Updated by riafarov almost 3 years ago
- Status changed from Feedback to In Progress
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.
#29 Updated by riafarov over 2 years 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.
#31 Updated by szarate about 1 year ago
See for the reason of tracker change: http://mailman.suse.de/mailman/private/qa-sle/2020-October/002722.html