Project

General

Profile

Actions
Copy link

action #16434

closed

openssh test fails due to update which disables pre-auth compression support

Added by vpelcak over 7 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
osukup
Category:
Bugs in existing tests
Target version:
-
Start date:
2017-02-03
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

https://openqa.suse.de/tests?match=%3A127591.openssh.3552

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.

Actions
Copy link
 #1

Updated by okurz over 7 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.

Actions
Copy link
 #2

Updated by okurz over 7 years ago

also make sure according test failures are labeled, e.g. like I did just now for one test result: https://openqa.suse.de/tests/755252#comments

Actions
Copy link
 #3

Updated by vpelcak over 7 years ago

Sorry, I thought there is only one tracker.

According this bug on SSH https://bugzilla.suse.com/show_bug.cgi?id=1016370 it looks that product indeed changed in acceptable way.

I am not able to change the assignee. I think Ondrej is the right guy for this.

Actions
Copy link
 #4

Updated by osukup over 7 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

Actions
Copy link
 #5

Updated by pgeorgiadis over 7 years ago

osukup wrote:

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/etc/ssh/ssh_config.

For example, if ForwardX11Trusted yes then there's no difference between -X and -Y.

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 X and Y.

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:

  1. Compression
  2. X Forwarding
  3. 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.

Actions
Copy link
 #6

Updated by pluskalm about 7 years ago

  • Status changed from New to Closed

Nothing to fix - update was at fault

Actions
Copy link

Also available in: Atom PDF