DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=bRXWqiLgTGNcsJZJ
	HnCUy7wx+5p6KRLH1zsQNj/JqxhQoWVr/XB1rU2sJTgH2P+xF4dTYjzYfF39O/47
	8YXtMvpqNvR2Ix8vHI1cqgvb5XvOLN+1IEqd1tA2pGQEkVOY86Lzp4OjTi0JzQYd
	tFQ3K33Cz+qaIrCJapCkmgu5/y4=
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
Date: Tue, 24 Feb 2015 06:36:18 +0300
From: Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To: cygwin AT cygwin DOT com
Message-ID: <545299221.20150224063618@yandex.ru>
To: Michael DePaulo <mikedep333 AT gmail DOT com>, cygwin AT cygwin DOT com
Subject: Re: Cygwin DLLs being modified somehow?
In-Reply-To: <CAMKht8h5EZ-3CeSECExLEcw1YLFeh8vaO=W+PuY8upTMmBcrZQ@mail.gmail.com>
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>  <CAMKht8h5EZ-3CeSECExLEcw1YLFeh8vaO=W+PuY8upTMmBcrZQ AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Greetings, Michael DePaulo!

>> 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.

Not necessarily. It's not a rule that "everything should be cygwin", but I
guess, in your case it may make life actually easier for you.
Cygwin is more POSIX, than Windows, and your code would have fewer "ifdefs".

> 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.

With release of 1.7.34, it is already possible.
Please refer to documentation at http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch

> 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").

Sounds bad.

> 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.

Please do try it. There was issues with it in the past, I recall, and I don't
rememeber, if they all were resolved.

> (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.

This is an interesting question, that you should investigate further.
I'm very interested in GSSAPI/SSPI auth myself, and will need it soon'ish.
Would be a shame to be limited to putty.

>> 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%?

They do search them according to Windows loader rules, which imply %PATH%
search amongst other locations, but as with any indirect system, it prone to
crash in the slightest sight of misconfiguration.
So, yes, you CAN have multiple Cygwin1 dlls in the system, and they will not
conflict with each other, provided you took enough care to separate the
environment in which they are used.
Still, it is better to avoid such scenarios, if possible.


--
WBR,
Andrey Repin (anrdaemon AT yandex DOT ru) 24.02.2015, <06:17>

Sorry for my terrible english...


--
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