fix wrong compression applied ('none',) when compress = True, but no compression tuple provided to cnopts

[shashfrankenstien]

In the current version of the code, test_compression_enabled fails and it's been disabled in CI tests. I was able to find the issue and implement a fix (also enabled in CI tests).

In the _start_transport method, if cnopts.compress is True, it calls self._transport.use_compression(compress=bool(compress)). This sets the compression options within paramiko Transport -

        if compress:
            self._preferred_compression = ("zlib@openssh.com", "zlib", "none")
        else:
            self._preferred_compression = ("none",)

After this step however, if cnopts.compression is not provided, it defaults to ("none",), and _start_transport method assigns this back into the transport through security options. This resets paramiko's _preferred_compression to ("none",) and disables compression. This is effectively equivalent to self._transport.use_compression(compress=False).

It also makes the behavior inaccurate per cnopts docstring which states that the default cnopts.compression is paramiko.Transport.SecurityOptions.compression

            compression = self._cnopts.compression
            self._transport.get_security_options().compression = compression

The fix is to only set security options compression if cnopts compress is enabled and compression is not the default value ('none',)

            compression = self._cnopts.compression
            if bool(compress) and compression != ('none',):
                self._transport.get_security_options().compression = compression

---

Additionally, I have created one instance of security options so the object is not initialized multiple times for each option. This also keeps line width within pep8 recommendations

security_options = self._transport.get_security_options()

[byteskeptical]

Allowing the default compression algorithm list set by paramiko is fine and I see your point from a user's perspective of thinking something is enabled only to have it not be. I'm not sure about enabling the compression test in CI though. Also unsure about the benefit of th security_options line as everything is within the pep8 line width already and direct calling attributes of the object doesn't reinit it every time as far as I'm aware, though aesthetically I do think it may looks better.

[byteskeptical]

Compression changes/ line moves look good. Lets see what happens with the test on actions. Will need you to add those secrets to your fork for all OS platforms to run correctly (Linux & Windows).

[shashfrankenstien]

Will need you to add those secrets to your fork for all OS platforms to run correctly (Linux & Windows).

I really don't know why the CI isn't seeing my secrets. I've setup the secrets as you've instructed.
These should be under Secrets and Variables > Actions > Secrets right? Can you see if I did something wrong here in the below screenshot?

I tried to look it up, and a lot of sources say Github may not allow CIs triggered on pull_request to access secrets. I haven't done this before, so please let me know if I can try anything else!

[byteskeptical]

Thanks again, everything looks good, I did end up moving the enable/disable compress lines back out as I realized that I have originally done that to seperate the settings set on the transport itself from the ones set on the security options object.