openssh test fails due to update which disables pre-auth compression support
This test is part of minimal tests which install original SLES 12 SP0/1/2 GM without any updates and then install just the tested updated package.
This particular update disables pre-auth compression support for openssh therefore test https://openqa.suse.de/tests/755252#step/sshxterm/6 fails to open new Xterm window.
All other tests not including this update are supposed to pass this test while the one including this update will fail.
Therefore I chose category "Needle Management" as 2 needles will be needed as well as decision which one to use. Not sure if it is correct assumption, though.
#1 Updated by okurz over 4 years ago
- Project changed from openQA Project to openQA Tests
- Category changed from 128 to Bugs in existing tests
- Assignee set to vpelcak
your assumption was not quite right because you used the wrong issue tracker for reporting :-)
I updated accordingly.
progress.opensuse.org/projects/openqatests/ should be used. Already included within the test results from a needle preview screens there are links to directly report product bugs or progress tickets with a template and prefilled content which should save a lot of working when reviewing test failures within openQA tests. If you want to use manual reporting of issues please follow the template https://progress.opensuse.org/projects/openqav3/wiki#defects
I am reassigning to you to clarify your decision why you think that the test needs an update. Are you saying the product behaviour changed in an acceptable way? What I see from the failing test case, e.g. https://openqa.suse.de/tests/755252#step/sshxterm/6 is that the simple command "ssh -XC root@localhost xterm" does not work anymore. Do you think this is acceptable behaviour? If yes, the test source code from http://github.com/os-autoinst/os-autoinst-distri-opensuse/ should be updated, i.e. provide a pull request (PR) updating the test code accordingly but I doubt it should be done in this case.
Feel free to find a more fitting person within QAM to work on this and reassign accordingly or let him/her reassign to himself.
#4 Updated by osukup over 4 years ago
- Assignee changed from vpelcak to osukup
In reality I don't understand why this test uses 'ssh -XC' . Compression has no any aded value for this test and SSH X forwarding is more secure and recomended with '-Y' - Trusted X forwarding.
okurz -- you are author and , this test in future Fail also in SLE12SP3+ and in openSUSE
#5 Updated by pgeorgiadis over 4 years ago
Compression has no any added value for this test
I agree. X forwarding and compression are two different things. Test one thing at a time. If you would like to test compression, create a second testcase.
and SSH X forwarding is more secure and recommended with '-Y' - Trusted X forwarding.
Recommended yes. More secure, not. If you use
-X the remote machine is considered as untrusted. As a result
-X is using the [X Security Extension] of 1990's, which means that if your command violates some security settings, you will receive an error. The problem is that this is old and inflexible and causes random problems (crashes) with some programs. Simply put,
-X tries to restrict remote programs to accessing only their own windows, and to using only those parts of X which are relatively secure. Which sounds good, but currently doesn't work well in practice.As a result, in other distributions (e.g. Ubuntu and Debian) they have disabled
-X. This can be done via the
ForwardX11Trusted which can be found at
For example, if
ForwardX11Trusted yes then there's no difference between
From Ubuntu man page:
(Debian-specific: X11 forwarding is not subjected to X11 SECURITY extension restrictions by default, because too many programs currently crash in this mode. Set the ForwardX11Trusted option to “no” to restore the upstream behavior. This may change in future depending on client-side improvements.)
We, in SUSE, we also suse
ForwardX11Trusted yes, so there's no difference between
In case you google around for this error
(fatal: buffer_uncompress: inflate returned -3) is sort of known but still investigated issue that comes with compression. Or if you still want to use the X Security extension, then make 3 tests:
- X Forwarding
- X Forwarding using X Security Extension (modify the configuration first)
Or, because this error might occur only when the combination of these 3 is triggered, then use these three isolated tests only if the
-CX fails. In any case, the point is that it should pass, and since it's not passing and we are supporting both
-CX we have to investigate further.