Hi all,
I would like to discuss a possible release date for X2Go Client 4.0.2.0.
As I see we need to fix #434 before a release is sensible. Any other
open issues that people would like to see fixed before the release?
Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Now that we have automated builds of x2goclient, I would like to try to fix 422 so we can include pulseaudio 5.0: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=422
This will be a "better fix" for 363, which is already marked "Done": http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=363
On Wed, Feb 19, 2014 at 11:03 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Hi all,
I would like to discuss a possible release date for X2Go Client 4.0.2.0.
As I see we need to fix #434 before a release is sensible. Any other open issues that people would like to see fixed before the release?
Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
How are things going? Now that libssh 0.6.3 is out my distro wants to update it. How's x2goclient doing? Can we expect a quick release or how's git status?
-Andy ArchLinux
Hi Andreas,
On So 09 Mär 2014 16:33:54 CET, Andreas Radke wrote:
How are things going? Now that libssh 0.6.3 is out my distro wants to update it. How's x2goclient doing? Can we expect a quick release or how's git status?
The current Git master's HEAD builds against and runs well with libssh
0.6.1 and later (AFAIK).
We are close to releasing X2Go Client 4.0.2.0.
Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
I did some more investigation today, but could not find the cause of bug 422 or a fix for it.
At this point, I recommend that we do not delay X2Go Client 4.0.2.0 for bug 422 / PulseAudio 5.0.
On Wed, Mar 5, 2014 at 8:28 AM, Michael DePaulo <mikedep333@gmail.com> wrote:
Now that we have automated builds of x2goclient, I would like to try to fix 422 so we can include pulseaudio 5.0: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=422
This will be a "better fix" for 363, which is already marked "Done": http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=363
On Wed, Feb 19, 2014 at 11:03 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Hi all,
I would like to discuss a possible release date for X2Go Client 4.0.2.0.
As I see we need to fix #434 before a release is sensible. Any other open issues that people would like to see fixed before the release?
Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
I believe I've found a simple fix for bug 422. I posted the details to the bug tracker. Please give me until Sunday night to write, test and commit it.
On Tue, Mar 11, 2014 at 11:56 PM, Michael DePaulo <mikedep333@gmail.com> wrote:
I did some more investigation today, but could not find the cause of bug 422 or a fix for it.
At this point, I recommend that we do not delay X2Go Client 4.0.2.0 for bug 422 / PulseAudio 5.0.
On Wed, Mar 5, 2014 at 8:28 AM, Michael DePaulo <mikedep333@gmail.com> wrote:
Now that we have automated builds of x2goclient, I would like to try to fix 422 so we can include pulseaudio 5.0: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=422
This will be a "better fix" for 363, which is already marked "Done": http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=363
On Wed, Feb 19, 2014 at 11:03 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Hi all,
I would like to discuss a possible release date for X2Go Client 4.0.2.0.
As I see we need to fix #434 before a release is sensible. Any other open issues that people would like to see fixed before the release?
Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
Hi Michael,
On Fr 14 Mär 2014 06:27:28 CET, Michael DePaulo wrote:
I believe I've found a simple fix for bug 422. I posted the details to the bug tracker. Please give me until Sunday night to write, test and commit it.
On Tue, Mar 11, 2014 at 11:56 PM, Michael DePaulo
<mikedep333@gmail.com> wrote:I did some more investigation today, but could not find the cause of bug 422 or a fix for it.
At this point, I recommend that we do not delay X2Go Client 4.0.2.0 for bug 422 / PulseAudio 5.0.
On Wed, Mar 5, 2014 at 8:28 AM, Michael DePaulo
<mikedep333@gmail.com> wrote:Now that we have automated builds of x2goclient, I would like to try to fix 422 so we can include pulseaudio 5.0: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=422
This will be a "better fix" for 363, which is already marked "Done": http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=363
On Wed, Feb 19, 2014 at 11:03 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Hi all,
I would like to discuss a possible release date for X2Go Client 4.0.2.0.
As I see we need to fix #434 before a release is sensible. Any other open issues that people would like to see fixed before the release?
Mike
Please, once the tests succeed, apply the commit to the
release/4.0.1.x branch and then cherry-pick it to the master branch. I
want #422 fixed in versions 4.0.1.4 and 4.0.2.0 of X2Go Client.
Greets, Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Mike,
As I mentioned on IRC, I accidentally applied the commit to the master branch. Let me know how you want me to proceed.
Also, since it is a regression, I would like to spend until the end of Monday (tomorrow) night looking into bug 448 and hopefully fixing it by then.
On Fri, Mar 14, 2014 at 7:18 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Hi Michael,
On Fr 14 Mär 2014 06:27:28 CET, Michael DePaulo wrote:
I believe I've found a simple fix for bug 422. I posted the details to the bug tracker. Please give me until Sunday night to write, test and commit it.
On Tue, Mar 11, 2014 at 11:56 PM, Michael DePaulo <mikedep333@gmail.com> wrote:
I did some more investigation today, but could not find the cause of bug 422 or a fix for it.
At this point, I recommend that we do not delay X2Go Client 4.0.2.0 for bug 422 / PulseAudio 5.0.
On Wed, Mar 5, 2014 at 8:28 AM, Michael DePaulo <mikedep333@gmail.com> wrote:
Now that we have automated builds of x2goclient, I would like to try to fix 422 so we can include pulseaudio 5.0: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=422
This will be a "better fix" for 363, which is already marked "Done": http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=363
On Wed, Feb 19, 2014 at 11:03 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Hi all,
I would like to discuss a possible release date for X2Go Client 4.0.2.0.
As I see we need to fix #434 before a release is sensible. Any other open issues that people would like to see fixed before the release?
Mike
Please, once the tests succeed, apply the commit to the release/4.0.1.x branch and then cherry-pick it to the master branch. I want #422 fixed in versions 4.0.1.4 and 4.0.2.0 of X2Go Client.
Greets,
Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi Michael,
On So 16 Mär 2014 17:16:35 CET, Michael DePaulo wrote:
As I mentioned on IRC, I accidentally applied the commit to the master branch. Let me know how you want me to proceed.
The way to do such a dual branch commit properly is this:
o Checkout the release/4.0.1.x branch o Fix the code there. o Add a changelog entry for the upcoming release on that branch (4.0.1.4). o Add the "(Fixes: #nnn)." identifier to the changelog entry o commit everything together on that release branch
o then do a git checkout master o cherry-pick that special commit from the release/4.0.1.x branch to the master branch o if you are lucky (mostly) the commit will apply cleanly to the code base on the master branch o if you are unlucky, resolve the conflicts manually (if you need help on this, we can join up on IRC for a session once that happens) o the changelog entry should automatically appear in the master branch's changelog file at the correct position
o push everything to git.x2go.org
The way to fix a commit that does not have a "(Fixes: #nnn)." statement:
o revert that commit o re-cherry-pick the fixing commit o do a "git reset HEAD~" o fix-up the changelog o and re-commit the amended changelog together with the code fixup
For the current situation, I would only:
o move the changelog entry to the stanza for 4.0.1.4 (on master branch) o copy the changelog entry o checkout release/4.0.1.x branch o paste the copied changelog entry to that branch's changelog file o commit the updated changelog o push it
Also, since it is a regression, I would like to spend until the end of Monday (tomorrow) night looking into bug 448 and hopefully fixing it by then.
We should definitely see to that. Thanks for taking over that task.
Take more time if needed.
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi Michael,
a follow-up thought...
We should not provide 4.0.1.4 for Windows. Only 4.0.2.0.
The reason for the dual upcoming release is that distros that have an
old libssh have the choice to use a legacy X2Go Client (4.0.1.4)
whereas all other distros should use the 4.0.2.0 version.
For your commits on Git: don't change anything... (superseding myself
in my previous mail!!!).
Mike
On So 16 Mär 2014 18:20:37 CET, Mike Gabriel wrote:
Hi Michael,
On So 16 Mär 2014 17:16:35 CET, Michael DePaulo wrote:
As I mentioned on IRC, I accidentally applied the commit to the master branch. Let me know how you want me to proceed.
The way to do such a dual branch commit properly is this:
o Checkout the release/4.0.1.x branch o Fix the code there. o Add a changelog entry for the upcoming release on that branch (4.0.1.4). o Add the "(Fixes: #nnn)." identifier to the changelog entry o commit everything together on that release branch
o then do a git checkout master o cherry-pick that special commit from the release/4.0.1.x branch to the master branch o if you are lucky (mostly) the commit will apply cleanly to the code base on the master branch o if you are unlucky, resolve the conflicts manually (if you need help on this, we can join up on IRC for a session once that happens) o the changelog entry should automatically appear in the master branch's changelog file at the correct position
o push everything to git.x2go.org
The way to fix a commit that does not have a "(Fixes: #nnn)." statement:
o revert that commit o re-cherry-pick the fixing commit o do a "git reset HEAD~" o fix-up the changelog o and re-commit the amended changelog together with the code fixup
For the current situation, I would only:
o move the changelog entry to the stanza for 4.0.1.4 (on master branch) o copy the changelog entry o checkout release/4.0.1.x branch o paste the copied changelog entry to that branch's changelog file o commit the updated changelog o push it
Also, since it is a regression, I would like to spend until the end of Monday (tomorrow) night looking into bug 448 and hopefully fixing it by then.
We should definitely see to that. Thanks for taking over that task.
Take more time if needed.Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Sun, Mar 16, 2014 at 1:24 PM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Hi Michael,
a follow-up thought...
We should not provide 4.0.1.4 for Windows. Only 4.0.2.0.
The reason for the dual upcoming release is that distros that have an old libssh have the choice to use a legacy X2Go Client (4.0.1.4) whereas all other distros should use the 4.0.2.0 version.
For your commits on Git: don't change anything... (superseding myself in my previous mail!!!).
Understood & agreed.
Mike
On So 16 Mär 2014 18:20:37 CET, Mike Gabriel wrote:
Hi Michael,
On So 16 Mär 2014 17:16:35 CET, Michael DePaulo wrote:
As I mentioned on IRC, I accidentally applied the commit to the master branch. Let me know how you want me to proceed.
The way to do such a dual branch commit properly is this:
o Checkout the release/4.0.1.x branch o Fix the code there. o Add a changelog entry for the upcoming release on that branch (4.0.1.4). o Add the "(Fixes: #nnn)." identifier to the changelog entry o commit everything together on that release branch
o then do a git checkout master o cherry-pick that special commit from the release/4.0.1.x branch to the master branch o if you are lucky (mostly) the commit will apply cleanly to the code base on the master branch o if you are unlucky, resolve the conflicts manually (if you need help on this, we can join up on IRC for a session once that happens) o the changelog entry should automatically appear in the master branch's changelog file at the correct position
o push everything to git.x2go.org
Thanks. I'll do this for 448 once I figure out how to fix it and I write the fix.
The way to fix a commit that does not have a "(Fixes: #nnn)." statement:
o revert that commit o re-cherry-pick the fixing commit o do a "git reset HEAD~" o fix-up the changelog o and re-commit the amended changelog together with the code fixup
But what do I do if I already pushed it?
Also, since it is a regression, I would like to spend until the end of Monday (tomorrow) night looking into bug 448 and hopefully fixing it by then.
We should definitely see to that. Thanks for taking over that task. Take more time if needed.
Greets, Mike
Thanks. I'll keep you posted via the bugtracker.
On Sun, Mar 16, 2014 at 1:37 PM, Michael DePaulo <mikedep333@gmail.com> wrote:
On Sun, Mar 16, 2014 at 1:24 PM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Also, since it is a regression, I would like to spend until the end of Monday (tomorrow) night looking into bug 448 and hopefully fixing it by then.
We should definitely see to that. Thanks for taking over that task. Take more time if needed.
Greets, Mike
Thanks. I'll keep you posted via the bugtracker.
bug 448: Alex provided the patched libssh 0.5.5 build and I included it in the nightly build system. I believe he should update the changelog and list his name though.
The issue we discussed on IRC with with downgrading PulseAudio 5.0 to 1.1 or 0.9.6 after 5.0 created a cookie: The fix is committed: ed895e030c52025c7e1ebce6e1d6b6e7c524f8d3
Tomorrow I would put out a nightly build out with following newer dependencies. I would appreciate a few days for testing: -Latest Cygwin files -OpenSSH 6.6p1 with our patch ported and applied (patch here: http://code.x2go.org/releases/source/openssh-cygwin/) -nx-libx 3.5.0.22 linked against the latest cygwin (I have been providing 3.5.0.22 linked against the older cygwin) -VcXsrv 1.14.5 (see the email thread "Windows X2Go Client: Windows XP & VcXsrv security vulnerabilities" for more info.) -libpng 1.2.51
The main reason for these dependency updates/upgrades is that there are some security vulnerabilities in the current cygwin files, OpenSSH 6.1p1, and in VcXsrv 1.14.2.1.
-Mike#2
On Mi 19 Mär 2014 04:59:30 CET, Michael DePaulo wrote:
On Sun, Mar 16, 2014 at 1:37 PM, Michael DePaulo
<mikedep333@gmail.com> wrote:On Sun, Mar 16, 2014 at 1:24 PM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Also, since it is a regression, I would like to spend until the end of Monday (tomorrow) night looking into bug 448 and hopefully fixing it by then.
We should definitely see to that. Thanks for taking over that task. Take more time if needed.
Greets, Mike
Thanks. I'll keep you posted via the bugtracker.
bug 448: Alex provided the patched libssh 0.5.5 build and I included it in the nightly build system. I believe he should update the changelog and list his name though.
The issue we discussed on IRC with with downgrading PulseAudio 5.0 to 1.1 or 0.9.6 after 5.0 created a cookie: The fix is committed: ed895e030c52025c7e1ebce6e1d6b6e7c524f8d3
Tomorrow I would put out a nightly build out with following newer dependencies. I would appreciate a few days for testing: -Latest Cygwin files -OpenSSH 6.6p1 with our patch ported and applied (patch here: http://code.x2go.org/releases/source/openssh-cygwin/) -nx-libx 3.5.0.22 linked against the latest cygwin (I have been providing 3.5.0.22 linked against the older cygwin) -VcXsrv 1.14.5 (see the email thread "Windows X2Go Client: Windows XP & VcXsrv security vulnerabilities" for more info.) -libpng 1.2.51
The main reason for these dependency updates/upgrades is that there are some security vulnerabilities in the current cygwin files, OpenSSH 6.1p1, and in VcXsrv 1.14.2.1.
-Mike#2
+1 from me!
Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Wed, Mar 19, 2014 at 3:03 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
On Mi 19 Mär 2014 04:59:30 CET, Michael DePaulo wrote:
- Tomorrow I would put out a nightly build out with following newer dependencies. I would appreciate a few days for testing: -Latest Cygwin files -OpenSSH 6.6p1 with our patch ported and applied (patch here: http://code.x2go.org/releases/source/openssh-cygwin/) -nx-libx 3.5.0.22 linked against the latest cygwin (I have been providing 3.5.0.22 linked against the older cygwin) -VcXsrv 1.14.5 (see the email thread "Windows X2Go Client: Windows XP & VcXsrv security vulnerabilities" for more info.) -libpng 1.2.51
The main reason for these dependency updates/upgrades is that there are some security vulnerabilities in the current cygwin files, OpenSSH 6.1p1, and in VcXsrv 1.14.2.1.
-Mike#2
+1 from me!
The build is out: https://lists.berlios.de/pipermail/x2go-user/2014-March/002121.html I would like either 1 or 2 more days of testing. Nobody has replied yet.
Also, I confirmed that bug 421 (X2goclient on Windows: sshd.exe does not start.) is a bug. http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=421
However, I recommend that we do not delay the 4.0.2.0 release for a fix because:
- It only affects Windows XP.
- It was introduced in 4.0.1.2. However, 4.0.0.3 (the previous win32 build) had folder sharing broken for some other reason. (4.0.0.3 actually had folder sharing broken on newer Windows client OSs too.)
- I do not know what the cause is or how long it will take to fix.
-Mike#2
The latest version of VcXsrv, 1.15.0, contains the vulnerability CVE-2013-6462 in the component libXfont 1.4.6.
The vulnerability is fixed in libXfont 1.4.7 and VcXsrv's master branch contains that update/fix.
I just sent the VcXsrv developer "marha" a message through SourceForge.net. I am hoping he will respond soon. I would like to avoid releasing X2Go Client 4.0.2.0 with the vulnerable VcXsrv if at all possible. As I mentioned below, I'll try to compile VcXsrv's master branch if he will not release a new VcXsrv soon. I will also try to compile the master this evening if he does not respond by then.
-Mike
Hi,
I'm the Windows maintainer on the X2Go project. We bundle VcXsrv in our Windows builds of the X2Go Client. http://www.x2go.org
We are about to release X2Go Client 4.0.2.0, but I'd very much not like to do so with VcXsrv 1.15.0 because of the vulnerability in libXfont 1.4.6: https://sourceforge.net/p/vcxsrv/bugs/17/ Even if we and most users would never trigger that vulnerability, shipping vulnerable code is still an issue because vulnerability scanning software like Mcafee Vulnerability Manager might flag VcXsrv 1.15.0 and tell system administrators that they must upgrade.
So I ask that you please release a new version of VcXsrv (presumably 1.15.0.1) within the next few days based on commit [d02e67] or later. I would be happy to test it.
If you do not, I will look into compiling [d02e67] or later myself.
Thanks, Mike DePaulo
On Wed, Mar 19, 2014 at 11:03 PM, Michael DePaulo <mikedep333@gmail.com> wrote:
On Wed, Mar 19, 2014 at 3:03 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
On Mi 19 Mär 2014 04:59:30 CET, Michael DePaulo wrote:
- Tomorrow I would put out a nightly build out with following newer dependencies. I would appreciate a few days for testing: -Latest Cygwin files -OpenSSH 6.6p1 with our patch ported and applied (patch here: http://code.x2go.org/releases/source/openssh-cygwin/) -nx-libx 3.5.0.22 linked against the latest cygwin (I have been providing 3.5.0.22 linked against the older cygwin) -VcXsrv 1.14.5 (see the email thread "Windows X2Go Client: Windows XP & VcXsrv security vulnerabilities" for more info.) -libpng 1.2.51
The main reason for these dependency updates/upgrades is that there are some security vulnerabilities in the current cygwin files, OpenSSH 6.1p1, and in VcXsrv 1.14.2.1.
-Mike#2
+1 from me!
The build is out: https://lists.berlios.de/pipermail/x2go-user/2014-March/002121.html I would like either 1 or 2 more days of testing. Nobody has replied yet.
Also, I confirmed that bug 421 (X2goclient on Windows: sshd.exe does not start.) is a bug. http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=421
However, I recommend that we do not delay the 4.0.2.0 release for a fix because:
- It only affects Windows XP.
- It was introduced in 4.0.1.2. However, 4.0.0.3 (the previous win32 build) had folder sharing broken for some other reason. (4.0.0.3 actually had folder sharing broken on newer Windows client OSs too.)
- I do not know what the cause is or how long it will take to fix.
-Mike#2
Also, I did report the vulnerability as a bug in VcXsrv's bug tracker 6 days ago: https://sourceforge.net/p/vcxsrv/bugs/17/
On Mon, Mar 31, 2014 at 9:19 AM, Michael DePaulo <mikedep333@gmail.com> wrote:
The latest version of VcXsrv, 1.15.0, contains the vulnerability CVE-2013-6462 in the component libXfont 1.4.6.
The vulnerability is fixed in libXfont 1.4.7 and VcXsrv's master branch contains that update/fix.
I just sent the VcXsrv developer "marha" a message through SourceForge.net. I am hoping he will respond soon. I would like to avoid releasing X2Go Client 4.0.2.0 with the vulnerable VcXsrv if at all possible. As I mentioned below, I'll try to compile VcXsrv's master branch if he will not release a new VcXsrv soon. I will also try to compile the master this evening if he does not respond by then.
-Mike
Hi,
I'm the Windows maintainer on the X2Go project. We bundle VcXsrv in our Windows builds of the X2Go Client. http://www.x2go.org
We are about to release X2Go Client 4.0.2.0, but I'd very much not like to do so with VcXsrv 1.15.0 because of the vulnerability in libXfont 1.4.6: https://sourceforge.net/p/vcxsrv/bugs/17/ Even if we and most users would never trigger that vulnerability, shipping vulnerable code is still an issue because vulnerability scanning software like Mcafee Vulnerability Manager might flag VcXsrv 1.15.0 and tell system administrators that they must upgrade.
So I ask that you please release a new version of VcXsrv (presumably 1.15.0.1) within the next few days based on commit [d02e67] or later. I would be happy to test it.
If you do not, I will look into compiling [d02e67] or later myself.
Thanks, Mike DePaulo
On Wed, Mar 19, 2014 at 11:03 PM, Michael DePaulo <mikedep333@gmail.com> wrote:
On Wed, Mar 19, 2014 at 3:03 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
On Mi 19 Mär 2014 04:59:30 CET, Michael DePaulo wrote:
- Tomorrow I would put out a nightly build out with following newer dependencies. I would appreciate a few days for testing: -Latest Cygwin files -OpenSSH 6.6p1 with our patch ported and applied (patch here: http://code.x2go.org/releases/source/openssh-cygwin/) -nx-libx 3.5.0.22 linked against the latest cygwin (I have been providing 3.5.0.22 linked against the older cygwin) -VcXsrv 1.14.5 (see the email thread "Windows X2Go Client: Windows XP & VcXsrv security vulnerabilities" for more info.) -libpng 1.2.51
The main reason for these dependency updates/upgrades is that there are some security vulnerabilities in the current cygwin files, OpenSSH 6.1p1, and in VcXsrv 1.14.2.1.
-Mike#2
+1 from me!
The build is out: https://lists.berlios.de/pipermail/x2go-user/2014-March/002121.html I would like either 1 or 2 more days of testing. Nobody has replied yet.
Also, I confirmed that bug 421 (X2goclient on Windows: sshd.exe does not start.) is a bug. http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=421
However, I recommend that we do not delay the 4.0.2.0 release for a fix because:
- It only affects Windows XP.
- It was introduced in 4.0.1.2. However, 4.0.0.3 (the previous win32 build) had folder sharing broken for some other reason. (4.0.0.3 actually had folder sharing broken on newer Windows client OSs too.)
- I do not know what the cause is or how long it will take to fix.
-Mike#2
Hi Michael,
On Mo 31 Mär 2014 15:19:07 CEST, Michael DePaulo wrote:
The latest version of VcXsrv, 1.15.0, contains the vulnerability CVE-2013-6462 in the component libXfont 1.4.6.
The vulnerability is fixed in libXfont 1.4.7 and VcXsrv's master branch contains that update/fix.
I just sent the VcXsrv developer "marha" a message through SourceForge.net. I am hoping he will respond soon. I would like to avoid releasing X2Go Client 4.0.2.0 with the vulnerable VcXsrv if at all possible. As I mentioned below, I'll try to compile VcXsrv's master branch if he will not release a new VcXsrv soon. I will also try to compile the master this evening if he does not respond by then.
-Mike
are you sure you want to dive into building VcXsrv? We can also wait a
little more to get that fixed by marha.
Or we could release and provide builds for Win32 a little later.
On the other hand, it problable might be a benefit to be in charge of
your own VcXsrv builds. Maybe not now, but maybe later.
Greets, Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Mon, Mar 31, 2014 at 10:09 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Hi Michael,
On Mo 31 Mär 2014 15:19:07 CEST, Michael DePaulo wrote:
The latest version of VcXsrv, 1.15.0, contains the vulnerability CVE-2013-6462 in the component libXfont 1.4.6.
The vulnerability is fixed in libXfont 1.4.7 and VcXsrv's master branch contains that update/fix.
I just sent the VcXsrv developer "marha" a message through SourceForge.net. I am hoping he will respond soon. I would like to avoid releasing X2Go Client 4.0.2.0 with the vulnerable VcXsrv if at all possible. As I mentioned below, I'll try to compile VcXsrv's master branch if he will not release a new VcXsrv soon. I will also try to compile the master this evening if he does not respond by then.
-Mike
are you sure you want to dive into building VcXsrv? We can also wait a little more to get that fixed by marha.
Or we could release and provide builds for Win32 a little later.
Wow. He didn't reply to my sourceforge message or the bug report. But he did post a new version of VcXsrv with the fix, and some other updates: https://sourceforge.net/projects/vcxsrv/files/vcxsrv/1.15.0.1/
I will update X2Go-WinBuilder, do a nightly build, and test X2Go Client.
On the other hand, it problable might be a benefit to be in charge of your own VcXsrv builds. Maybe not now, but maybe later.
This is on the back of my mind (along with a 64-bit windows build of x2goclient + nx-libs.) You see, VcXsrv is now compiled with VS 2012, so the official releases are incompatible with XP. However, as stated on their site, only the makefiles are incompatible with VS 2010 (XP compatible), the source code is still compatible. So later on, I'll look into how much work it would be to compile the latest VcXsrv with VS 2010 so that XP users can get security fixes (in addition to the other changes in newer versions.)
-Mike#2
Note: Most of this was discussed on IRC.
On Mon, Mar 31, 2014 at 6:20 PM, Michael DePaulo <mikedep333@gmail.com> wrote:
On Mon, Mar 31, 2014 at 10:09 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Hi Michael,
On Mo 31 Mär 2014 15:19:07 CEST, Michael DePaulo wrote:
The latest version of VcXsrv, 1.15.0, contains the vulnerability CVE-2013-6462 in the component libXfont 1.4.6.
The vulnerability is fixed in libXfont 1.4.7 and VcXsrv's master branch contains that update/fix.
VcXsrv released version 1.15.0.1 with that update/fix.
I just sent the VcXsrv developer "marha" a message through SourceForge.net. I am hoping he will respond soon. I would like to avoid releasing X2Go Client 4.0.2.0 with the vulnerable VcXsrv if at all possible. As I mentioned below, I'll try to compile VcXsrv's master branch if he will not release a new VcXsrv soon. I will also try to compile the master this evening if he does not respond by then.
-Mike
are you sure you want to dive into building VcXsrv? We can also wait a little more to get that fixed by marha.
Or we could release and provide builds for Win32 a little later.
Wow. He didn't reply to my sourceforge message or the bug report. But he did post a new version of VcXsrv with the fix, and some other updates: https://sourceforge.net/projects/vcxsrv/files/vcxsrv/1.15.0.1/
I will update X2Go-WinBuilder, do a nightly build, and test X2Go Client.
On the other hand, it problable might be a benefit to be in charge of your own VcXsrv builds. Maybe not now, but maybe later.
This is on the back of my mind (along with a 64-bit windows build of x2goclient + nx-libs.) You see, VcXsrv is now compiled with VS 2012, so the official releases are incompatible with XP. However, as stated on their site, only the makefiles are incompatible with VS 2010 (XP compatible), the source code is still compatible. So later on, I'll look into how much work it would be to compile the latest VcXsrv with VS 2010 so that XP users can get security fixes (in addition to the other changes in newer versions.)
-Mike#2
marha has still not responded to my message or the bug report.
However, after trying lots of things out, I managed to compile VcXsrv 1.14.3 (2013-09-20) with Windows XP support, and with the fixes for CVE-2013-4396 (2013-10-08) & CVE-2013-6462 (2014-01-07).
I also determined that VcXsrv 1.14.3 already included the fixes for CVE-2013-1981..2005, CVE-2013-2062..2066 (2013-05-23). Therefore, my bulid contains 0 known vulnerabilities!
I am calling my build 1.14.3.1. The build is here: http://code.x2go.org/releases/binary-win32/3rd-party/vcxsrv-modified-by-x2go...
And for now, the source code is here: https://sourceforge.net/u/mikedep333/vcxsrv/ci/xp-fixesonly/tree/
I updated X2Go-WinBuilder VM to use my 1.14.3.1 build. The X2Go Client nightly build with 1.14.3.1 is here: http://code.x2go.org/releases/binary-win32/x2goclient/heuler/mingw32-4.4/qt-...
Here's more information on my decision to create this VcXsrv build: the last version built with MSVC 2010. VcXsrv 1.14.3 was built with
- MSVC 2012 can produce XP compatible builds as long as you are using version "Update 1" or later, and you specify the v110_xp platform toolset. This is what I used for my 1.14.3.1 build.
- VcXsrv 1.14.2.1 is the last version with XP support because it is
MSVC 2012 and VcXsrv 1.14.4 was built with MSVC 2013. The VcXsrv project's homepage still states that they are built with MSVC 2012, but the commit messages specify otherwise. 3. Although only the VcXsrv build system / makefiles were updated for MSVC 2013 with VcXsrv 1.14.4, the build system is very large. Therefore, I did not try to modify VcXsrv 1.14.4 for MSVC 2012 & v110_xp compatibility. 4. VcXsrv 1.15's source code is incompatible with MSVC 2012 because it contains certain C99 statements. 5. It looks like VcXsrv normally builds using cmd.exe, rather than cygwin's bash shell. VcXsrv includes cygwin bash shell scripts, but they are outdated. gawk had trouble with the .bat files used during the build of xkeyboard-config, so I switched to using cygwin's bash shell for the build and updated those scripts. Building using cygwin's bash shell was successful, it used .sh files instead for the build of xkeyboard-config.
-Mike#2
On Sun, Apr 6, 2014 at 8:58 AM, Michael DePaulo <mikedep333@gmail.com> wrote: .
However, after trying lots of things out, I managed to compile VcXsrv 1.14.3 (2013-09-20) with Windows XP support, and with the fixes for CVE-2013-4396 (2013-10-08) & CVE-2013-6462 (2014-01-07).
I also determined that VcXsrv 1.14.3 already included the fixes for CVE-2013-1981..2005, CVE-2013-2062..2066 (2013-05-23). Therefore, my bulid contains 0 known vulnerabilities!
I am calling my build 1.14.3.1. The build is here: http://code.x2go.org/releases/binary-win32/3rd-party/vcxsrv-modified-by-x2go...
And for now, the source code is here: https://sourceforge.net/u/mikedep333/vcxsrv/ci/xp-fixesonly/tree/
I updated X2Go-WinBuilder VM to use my 1.14.3.1 build. The X2Go Client nightly build with 1.14.3.1 is here: http://code.x2go.org/releases/binary-win32/x2goclient/heuler/mingw32-4.4/qt-...
Here's more information on my decision to create this VcXsrv build: the last version built with MSVC 2010. VcXsrv 1.14.3 was built with
- MSVC 2012 can produce XP compatible builds as long as you are using version "Update 1" or later, and you specify the v110_xp platform toolset. This is what I used for my 1.14.3.1 build.
- VcXsrv 1.14.2.1 is the last version with XP support because it is
MSVC 2012 and VcXsrv 1.14.4 was built with MSVC 2013. The VcXsrv project's homepage still states that they are built with MSVC 2012, but the commit messages specify otherwise. 3. Although only the VcXsrv build system / makefiles were updated for MSVC 2013 with VcXsrv 1.14.4, the build system is very large. Therefore, I did not try to modify VcXsrv 1.14.4 for MSVC 2012 & v110_xp compatibility. 4. VcXsrv 1.15's source code is incompatible with MSVC 2012 because it contains certain C99 statements. 5. It looks like VcXsrv normally builds using cmd.exe, rather than cygwin's bash shell. VcXsrv includes cygwin bash shell scripts, but they are outdated. gawk had trouble with the .bat files used during the build of xkeyboard-config, so I switched to using cygwin's bash shell for the build and updated those scripts. Building using cygwin's bash shell was successful, it used .sh files instead for the build of xkeyboard-config.
-Mike#2
Hmm, I thought I compiled VcXsrv 1.14.3.1 correctly with the v110_xp platform toolset, but when I go to start it on my XP SP3 32-bit VM (instead of on my Windows 8.1 64-bit machine), I get the error:
C:\Program Files\x2goclient\VcXsrv\vcxsrv.exe is not a valid Win32 application.
Similarly, x2goclient.exe states:
Can't start X server Please check your installation
I will investigate further. It is a 32-bit executable though.
-Mike
On Sun, Apr 6, 2014 at 10:11 AM, Michael DePaulo <mikedep333@gmail.com> wrote:
On Sun, Apr 6, 2014 at 8:58 AM, Michael DePaulo <mikedep333@gmail.com> wrote: .
However, after trying lots of things out, I managed to compile VcXsrv 1.14.3 (2013-09-20) with Windows XP support, and with the fixes for CVE-2013-4396 (2013-10-08) & CVE-2013-6462 (2014-01-07).
I also determined that VcXsrv 1.14.3 already included the fixes for CVE-2013-1981..2005, CVE-2013-2062..2066 (2013-05-23). Therefore, my bulid contains 0 known vulnerabilities!
I am calling my build 1.14.3.1. The build is here: http://code.x2go.org/releases/binary-win32/3rd-party/vcxsrv-modified-by-x2go...
And for now, the source code is here: https://sourceforge.net/u/mikedep333/vcxsrv/ci/xp-fixesonly/tree/
I updated X2Go-WinBuilder VM to use my 1.14.3.1 build. The X2Go Client nightly build with 1.14.3.1 is here: http://code.x2go.org/releases/binary-win32/x2goclient/heuler/mingw32-4.4/qt-...
Here's more information on my decision to create this VcXsrv build: the last version built with MSVC 2010. VcXsrv 1.14.3 was built with
- MSVC 2012 can produce XP compatible builds as long as you are using version "Update 1" or later, and you specify the v110_xp platform toolset. This is what I used for my 1.14.3.1 build.
- VcXsrv 1.14.2.1 is the last version with XP support because it is
MSVC 2012 and VcXsrv 1.14.4 was built with MSVC 2013. The VcXsrv project's homepage still states that they are built with MSVC 2012, but the commit messages specify otherwise. 3. Although only the VcXsrv build system / makefiles were updated for MSVC 2013 with VcXsrv 1.14.4, the build system is very large. Therefore, I did not try to modify VcXsrv 1.14.4 for MSVC 2012 & v110_xp compatibility. 4. VcXsrv 1.15's source code is incompatible with MSVC 2012 because it contains certain C99 statements. 5. It looks like VcXsrv normally builds using cmd.exe, rather than cygwin's bash shell. VcXsrv includes cygwin bash shell scripts, but they are outdated. gawk had trouble with the .bat files used during the build of xkeyboard-config, so I switched to using cygwin's bash shell for the build and updated those scripts. Building using cygwin's bash shell was successful, it used .sh files instead for the build of xkeyboard-config.
-Mike#2
Hmm, I thought I compiled VcXsrv 1.14.3.1 correctly with the v110_xp platform toolset, but when I go to start it on my XP SP3 32-bit VM (instead of on my Windows 8.1 64-bit machine), I get the error:
C:\Program Files\x2goclient\VcXsrv\vcxsrv.exe is not a valid Win32 application.
Similarly, x2goclient.exe states:
Can't start X server Please check your installation
I will investigate further. It is a 32-bit executable though.
-Mike
I've fixed the build scripts and makefiles so that it is now compatible with XP.
The 3 URLs I specified previously have been updated. The version # is the same, 1.14.3.1 .
Now that I've also updated the approach for fixing #422 (as documented in the BTS,) I am OK with releasing 4.0.2.0.
-Mike#2
-
Andreas Radke -
Michael DePaulo -
Mike Gabriel -
Stefan Baur