DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; q=dns; s=default; b=Mr
	kMaQTBWPbpoVNCYhLHXPbQiqlWmpMPfMttmuhi0KqyZI37Ir2pBcP8/D2Vf3Qet6
	wMLYV9pXCcybxD2NSp8uAwK0uos4FBOsOWetJN6znDuZYESvpR5hcGL2Sv7Elp3B
	JGVq4zzicu6r2vK8vcxx3YXlIB7HZFMmjCPcwHsmE=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
MIME-Version: 1.0
In-Reply-To: <1115493.20150223212142@yandex.ru>
References: <CAMKht8jUmyh9==NdBHLs52CcgSXrxKTtx9m_+UJYqd+=+3vvrg AT mail DOT gmail DOT com>	<mce70e$g7q$1 AT ger DOT gmane DOT org>	<CAMKht8jNLyA_hkAzdNvvANe5FhR0UYC=3w4t-XDwcapd5ywtUA AT mail DOT gmail DOT com>	<1115493 DOT 20150223212142 AT yandex DOT ru>
Date: Mon, 23 Feb 2015 19:16:08 -0500
Message-ID: <CAMKht8h5EZ-3CeSECExLEcw1YLFeh8vaO=W+PuY8upTMmBcrZQ@mail.gmail.com>
Subject: Re: Cygwin DLLs being modified somehow?
From: Michael DePaulo <mikedep333 AT gmail DOT com>
To: The Cygwin Mailing List <cygwin AT cygwin DOT com>
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 23, 2015 at 1:21 PM, Andrey Repin <anrdaemon AT yandex DOT ru> wrote:
> Greetings, Michael DePaulo!
>
>> I found this too:
>> http://cygwin.wikia.com/wiki/Rebaseall
>
>> However, this leads to a another question. On the X2Go project, we
>> compile nxproxy, a 3rd-party piece of software that we are now
>> maintaining, against Cygwin. We also recompile Cygwin OpenSSH with an
>> X2Go-compatibility patch applied and with Kerberos support disabled.
>
> Is this really necessary? What parts of the OpenSSH need patching, and why
> disabling Kerberos support?

1. It looks like if I followed your recommended approach below, we
would not need to apply our 1 patch.
http://code.x2go.org/gitweb?p=x2goclient-contrib.git;a=blob;f=openssh-server/6.6p1-3-x2go1_src/openssh-6.6p1-1.x2go.patch;h=4ba4148fc7351c9a24986e340d59d88cdef2475a;hb=HEAD

Note that with my user account,
C:\Users\mike.DEPAULO\.x2go\etc\sshd_config is written to by
x2goclient.exe to contain these 3 lines (the 1st 2 lines are
referenced in the patch), plus 2 other lines:
Subsystem shell C:/PROGRA~2/X2GOCL~4.2-2/sh
Subsystem sftp C:/PROGRA~2/X2GOCL~4.2-2/sftp-server
AuthorizedKeysFile "/cygdrive/C/Users/%u.DEPAULO/.x2go/.ssh/authorized_keys"

2. I compile it without Kerberos support in order to slim down
dependencies, and reduce the number of necessary security updates. We
don't use MIT Kerberos, and it receives security updates fairly often.
(That said, if we do follow your recommended approach below, then
linking to MIT Kerberos is a trade-off I would accept.)

>
>> (We make sure to comply with the GPL.)
>
> Noted. Though, it took several attempts to find links to a source code on your
> website.
> And "Download binary" links dumping visitor into a directory full of
> different versions isn't speaking to your advantage.
> Take example from virtualbox.org and rework your downloads page.

I will improve our wiki after I update this email, thanks.

(I always update the link on the homepage though. It links to the
latest version.)

>> So far we have just been distributing these .exe files and .dll
>> files[1] in the X2Go Client directory (C:\Program Files
>> (x86)\x2goclient\), which also contains regular win32 code. We do not
>> run the Cygwin installer or call rebase. We use NSIS for our
>> installer, and it simply copies the files.
>
>> So my question is: Is there a better way to distribute/install these 2
>> programs?
>> (We want to make X2Go Client for Windows easy to install, even for
>> people who have never used Cygwin. We also want to update/upgrade
>> these files in between X2Go Client maintenance releases (like 4.0.3.x)
>> only when there is a need to, such as a security update.)
>
>> Also, in the absence of a doing things differently, should we just
>> distribute the original .exe and .dll files from the cygwin binary
>> packages?
>
> I have a counter-question. Any objection you have to distribute your
> application as part of Cygwin infrastructure?
> You can still keep your NSIS installer, assuming you change it to download
> appropriate setup.exe, and you could offer an option to make portable
> installation from live system, knowing well that it's already rebased and
> ready to work.

Good question :)

tl;dr: We would have to port a lot of other code from native win32 to Cygwin.

1st of all, note that X2Go Client itself (x2goclient.exe) uses libssh
to authenticate and tunnel the nx-libs traffic. (nxagent on the X2Go
Server,  nxproxy on the X2Go Client) traffic. OpenSSH is used for our
folder and printer sharing feature specifically.

2nd, nxproxy and openssh are only 2 of our Windows components.  We
also have the following native win32 executables/components (plus all
their native win32 libraries):
1. x2goclient.exe
2. VcXsrv
3. PulseAudio
4. PuTTY

1. x2goclient.exe I assume we are keeping as a native win32 executable
because we want to have it use the user's %USERPROFILE% for the user's
config files, ssh known_hosts, etc. If we could make a cygwin port of
x2goclient.exe use %USERPROFILE%, that would be great.

I would also need to package libssh for Cygwin. Cygwin only has
libssh2. Fortunately, I am in contact with upstream libssh and they
are very helpful. (Note: libssh is being actively developed, despite
the competing "libssh2" existing.)

The x2goclient source code is also full of ifdefs for Linux vs Windows
vs Mac that I would need to fix for cygwin.

2. VcXsrv could be replaced with Cygwin XWin. However, I've tried it
and there are some integration bugs between nxproxy and Cygwin XWin
that I/we need to resolve 1st.

I really want to move from VcXsrv to Cygwin XWin anyway, even if
x2goclient remains native win32, because the upstream VcXsrv developer
has only responded to 1 bug report / pull request I ever sent him. (He
even ignores bug reports and pull requests like "CVE-2013-6462 in
libXfont 1.4.6").

He also does git updates to the latest master branch versions of X11
libraries, rather than stable releases.

In contrast, the Cygwin X11 devs (Jon Turney for example) are very responsive.

Also, I need to do some performance testing (of Cygwin Xwin vs VcXsrv)
1st. I intend to package gtkperf for Cygwin.

3. PulseAudio could probably be easily switched to the cygwin version.
I haven't tried though.

(I am maintaining PulseAudio Windows builds on the OBS. I need to
release 6.0 and discuss listing them on the PulseAudio website.)

4. PuTTY is used as a replacement for libssh when the user selects to
use Kerberos/GSSAPI authentication. In reality, this is Microsoft SSPI
authentication, which we do want to use. We want users to be able to
authenticate with their Windows Kerberos ticket, and Cygwin MIT
Kerberos does not appear to support this. (Neither does libssh.) PuTTY
does though.

> And Cygwin users, who also happened to be users of your app, will benefit from
> NOT having to solve conflicts between multiple Cygwin1 DLL's.

So you are suggesting we install Cygwin to the system-wide location
like C:\Cygwin\ rather than a subfolder like C:\Program Files
(x86)\x2goclient\Cygwin\ (with /bin, etc underneath it?)

I also do not understand this issue fully. I am unable to find a good
article on the web (via DDG or Google) that explains it. I think I
have experienced it though. Having multiple cygwin1 DLL files in RAM
causes them to conflict with eachother? Wouldn't cygwin executables
would search for cygwin1.dll according to %PATH%?

> --
> WBR,
> Andrey Repin (anrdaemon AT yandex DOT ru) 23.02.2015, <21:13>
>
> Sorry for my terrible english..
.
Your English is pretty good!

Thanks,
-Mike

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple