Bug#951565: freerdp2-x11: does not work at all, immediately exits, against xrdp server (rdesktop works)
Hi Thorsten, On Tue, Feb 18, 2020 at 07:18:23AM +0100, Thorsten Glaser wrote: > tglase@tglase-nb:~ $ xfreerdp /v:tglase-edge > > .. > [07:15:08:628] [29233:29234] [INFO][com.winpr.clipboard] - initialized POSIX > local file subsystem > [07:15:08:744] [29233:29234] [ERROR][com.freerdp.core.update] - [0x03] Cache > Glyph - SERVER BUG: The support for this feature was not announced! Use > /relax-order-checks to ignore > [07:15:08:745] [29233:29234] [INFO][com.freerdp.client.common] - Network > disconnect! > [07:15:08:745] [29233:29234] [ERROR][com.freerdp.client.x11] - Failed to > check FreeRDP file descriptor > .. > > I also tried xfreerdp /size:1000x768 /v:tglase-edge but that > does not change anything. FreeRDP does strict protocol level checks per default since a while. xrdp does use the glyph cache without announcing/negotiating it - this causes xfreerdp to close the connection. Give the options /relax-order-checks (as the error above indicates) and +glyph-cache a try. As reference also See: https://github.com/neutrinolabs/xrdp/issues/1229 and https://github.com/neutrinolabs/xrdp/issues/1266 Best regards, Bernhard
Bug#921374: libfreerdp2-2: Fails to connect Windows 7 x64 using NLA
Hi, On Mon, Feb 04, 2019 at 11:29:00AM -0600, Omer Ozarslan wrote: > Package: libfreerdp2-2 > Version: 2.0.0~git20190204.1.2693389a+dfsg1-1 > Severity: important > Tags: upstream > RDP connection to Windows 7 x64 failed. I ran command "WLOG_LEVEL=DEBUG > remmina", which resulted the error message pointing to freerdp core: > > [11:21:19:450] [21683:21688] [ERROR][com.freerdp.core] - > freerdp_set_last_error > ERRCONNECT_PASSWORD_CERTAINLY_EXPIRED [0x0002000F] do you have installed KB4480970 on the windows machine and the user you are using is in the "Administrators" group? Best regards, Bernhard
Bug#919281: freerdp2-x11: fails for smartcard login with SCARD_E_INSUFFICIENT_BUFFER
Hi Christoph, On Mon, Jan 14, 2019 at 04:46:56PM +0100, Christoph Martin wrote: > Am 14.01.19 um 15:51 schrieb Bernhard Miklautz: > Gemalto USB Shell Token V2 (C5B57B07) 01 00 > > Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): > 3B F8 18 00 FF 81 31 FE 45 4A 43 4F 50 76 32 34 31 43 > The log is attached. thank you very much! The log shows the same problems as reported upstream. Interestingly, but possible not relates because you don’t use it, the upstream issues are all related to Yubikeys. Just to make sure, is there any difference if the Yubikey isn't connected? Best regards, Bernhard
Bug#919281: freerdp2-x11: fails for smartcard login with SCARD_E_INSUFFICIENT_BUFFER
Hi, There are two open upstream issues reported with the same error. On Mon, Jan 14, 2019 at 02:40:10PM +0100, Christoph Martin wrote: > in contrast to freerdp-x11 1.1.0~git20140921.1.440916e+dfsg1-13+deb9u2 > freerdp2-x11 fails while trying a smartcard-logon to our several > windows servers. The error messages is: > > [14:11:49:046] [14684:14732] > [WARN][com.freerdp.channels.smartcard.client] - IRP failure: > SCardStatusW (0x000900CC), status: SCARD_E_INSUFFICIENT_BUFFER > (0x8018) > > It might be depending on the size of the certificate we have on our > smartcards. what's your certificate size and the smartcard(s) and reader you use? Could you provide a trace when the error happens (either here or in upstream bug tracker)? Should be sufficient to set the following variables to your environment before you run the failing command export WLOG_PREFIX='%yr%mo%dyT%hr%mi%se.%ml:%fl:%ln:%lv %fn ' export WLOG_APPENDER=FILE export WLOG_FILEAPPENDER_OUTPUT_FILE_PATH=/tmp/ export WLOG_FILEAPPENDER_OUTPUT_FILE_NAME=freerdp.log export WLOG_LEVEL=DEBUG The log file is /tmp/freerdp.log. Best regards, Bernhard
Bug#879177: Remmina: Not connecting to Windows 7 using RDP connection
Hi, On Mon, Oct 23, 2017 at 02:49:03PM +0200, Matteo F. Vescovi wrote: > I did some more tests and it came out that only on non-up-to-date > Windows 7 machines freerdp2 doesn't connect, while it works just fine > on those updated. > Ali, can you confirm that your Windows 7 machine is not actually > updated to latest upgrades? as reference it would be interesting to know what patch level the machines have that don't work. If you could run "winver" in a cmd and post the output line starting with "Version" that would be great. Thank you.
Bug#869880: CVE-2017-2834 CVE-2017-2835 CVE-2017-2836 CVE-2017-2837 CVE-2017-2838 CVE-2017-2839
We fixed it upstream on branch stable-1.1 as well now: https://github.com/FreeRDP/FreeRDP/commit/03ab68318966c3a22935a02838daaea7b7fbe96c Here is an updated version of the freerdp package with the patch included: https://github.com/bmiklautz/FreeRDP-debian/commit/68c33cec893630a6b6abbce82956739854158dca Best regards, Bernhard
Bug#869880: CVE-2017-2834 CVE-2017-2835 CVE-2017-2836 CVE-2017-2837 CVE-2017-2838 CVE-2017-2839
Hi, On Thu, Jul 27, 2017 at 01:21:58PM +0200, Moritz Muehlenhoff wrote: > Source: freerdp > Severity: grave > Tags: security > > Hi, > please see: > https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0341 > https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0340 > https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0339 > https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0338 > https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0337 > https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0336 > > Fix is here: > https://github.com/FreeRDP/FreeRDP/pull/4055/commits/8292b4558f0684065ce1f58db7783cc426099223 This fix is for master. I'm working on a back port of it for 1.1 right now and will prepare a patch. Best regards, Bernhard
Bug#820711: [debhelper-devel] Bug#820711: Bug#820711: dh_compress: fails if the debian directory is a symlink
Hi, On Mon, Apr 11, 2016 at 06:19:11PM +, Niels Thykier wrote: > > On Mon, Apr 11, 2016 at 04:12:30PM +, Niels Thykier wrote: > I have devised a fix in [1418796], which I believe will fix this issue. > I expect the next debhelper release to happen this weekend, so you may > want to cherry-pick it. > > > [1418796]: > https://anonscm.debian.org/git/debhelper/debhelper.git/commit/?id=1418796f85ce27401673442e19977957d94079fe > Works like a charm again. I've re-tested all the described cases. Thank you very much for your efforts and the quick fix ;). Best regards, Bernhard
Bug#820711: [debhelper-devel] Bug#820711: dh_compress: fails if the debian directory is a symlink
Hi, On Mon, Apr 11, 2016 at 04:12:30PM +, Niels Thykier wrote: > "debian" folder as in the "debian" folder itself? > debian/control -> ../../another/dir/control I didn't test this case. > debian -> ../../another/dir/ For the package I'm building the folder structure looks like this: -nightly - packaging - deb - nightly - control - rules - ... - debian -> packaging/deb/nightly The debian folder is a symlink to another folder within the same directory. I also tested the case when the link destination is outside the directory structure like: - packaging - deb - nightly - control - rules - ... -nightly - debian -> ../packaging/deb/nightly This basically ends up in the same error but with a different path prefix (../../../): chmod: cannot access '../../../packaging/deb/freerdp-nightly/freerdp-nightly/usr/share/doc/freerdp-nightly/changelog': No such file or directory However if the link is only "one level" like the following it works: -nightly - nightly - control - rules - ... - debian -> nightly All of the above combinations worked before 9.20160306. When I narrowing it down the problem seems to be related to commit https://anonscm.debian.org/git/debhelper/debhelper.git/commit/dh_compress?id=ef24f6405d14d1359d4b4e4c2028a28b47035d8b Thank you.
Bug#820711: dh_compress: fails if the debian directory is a symlink
Package: debhelper Version: 9.20160403 Severity: important Dear Maintainer, if the debian folder is a symlink to a directory, a call to dh_compress, directly or during a build, causes an error. For example if the package "nightly" has a debian folder that is symlinked to packaging/deb/nightly/ the following error will be raised during a debuild chmod: cannot access '../../packaging/deb/nightly/nightly/usr/share/doc/nightly/changelog': No such file or directory dh_compress: chmod a-x ../../packaging/deb/nightly/nightly/usr/share/doc/nightly/changelog returned exit code 1 It seems that the paths aren't calculated properly. This happens since dephelper version 9.20160306. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0 (SMP w/12 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages debhelper depends on: ii autotools-dev20150820.1 ii binutils 2.26-8 ii dh-autoreconf12 ii dh-strip-nondeterminism 0.016-1 ii dpkg 1.18.4 ii dpkg-dev 1.18.4 ii file 1:5.25-2 ii libdpkg-perl 1.18.4 ii man-db 2.7.5-1 ii perl 5.22.1-9 ii po-debconf 1.0.19 debhelper recommends no packages. Versions of packages debhelper suggests: ii dh-make 2.201605 -- no debconf information
Bug#739962: xscreensaver: segfault if no PATH is set in environment
On Tue, Feb 25, 2014 at 12:56:32PM -0800, Jamie Zawinski wrote: > Under what circumstances would xscreensaver be launched with no $PATH? I had different situations lately where no PATH was set in the environment. And it always ended up in: [8060651.170293] xscreensaver[27148]: segfault at 0 ip 7fbd2e06aedf sp 7fff27f08588 error 4 in libc-2.13.so[7fbd2df5+182000] An example would be running /usr/bin/Xephyr :99 & DISPLAY=:99 xscreensaver in a shell that was started after fork/execve with envp set to NULL. Anyway. Even if this isn't probably the common use case I would expect a program *not* to segfault if an expected environment variable, like PATH in this case, isn't set. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739962: xscreensaver: segfault if no PATH is set in environment
Package: xscreensaver Version: 5.15-3 Severity: important Tags: patch This can easily be reproduced: env -u PATH /usr/bin/xscreensaver PATH is set in circumstances but it shouldn't crash otherwise. -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12.0 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xscreensaver depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-38+deb7u1 ii libcairo2 1.12.2-3 ii libfontconfig1 2.9.0-7.1 ii libfreetype62.4.9-1.1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglade2-0 1:2.6.4-1 ii libglib2.0-02.33.12+really2.32.4-5 ii libgtk2.0-0 2.24.10-2 ii libice6 2:1.0.8-2 ii libpam0g1.1.3-7.1 ii libpango1.0-0 1.30.0-1 ii libsm6 2:1.2.1-2 ii libx11-62:1.5.0-1+deb7u1 ii libxext62:1.3.1-2+deb7u1 ii libxi6 2:1.6.1-1+deb7u1 ii libxinerama12:1.1.2-1+deb7u1 ii libxml2 2.8.0+dfsg1-7+nmu2 ii libxmu6 2:1.1.1-1 ii libxpm4 1:3.5.10-1 ii libxrandr2 2:1.3.2-2+deb7u1 ii libxrender1 1:0.9.7-1+deb7u1 ii libxt6 1:1.1.3-1+deb7u1 ii libxxf86vm1 1:1.1.2-1+deb7u1 ii xscreensaver-data 5.15-3 Versions of packages xscreensaver recommends: ii libjpeg-progs 8d-1 ii perl [perl5] 5.14.2-21+deb7u1 ii wamerican [wordlist] 7.1-1 Versions of packages xscreensaver suggests: ii fortune-mod [fortune] 1:1.99.1-4 ii gdm3 3.4.1-8 ii google-chrome-beta [www-browser] 33.0.1750.117-1 ii iceweasel [www-browser] 17.0.10esr-1~deb7u1 pn qcam | streamer ii w3m [www-browser] 0.5.3-8 pn xdaliclock pn xfishtank ii xscreensaver-gl 5.15-3 -- no debconf information diff --git a/driver/subprocs.c b/driver/subprocs.c index fb621cd..3b13ae0 100644 --- a/driver/subprocs.c +++ b/driver/subprocs.c @@ -1099,11 +1099,22 @@ hack_environment (saver_info *si) if (def_path && *def_path) { const char *opath = getenv("PATH"); - char *npath = (char *) malloc(strlen(def_path) + strlen(opath) + 20); + char *npath; + unsigned int len; + + if (opath) +len = strlen(def_path) + strlen(opath) + strlen("PATH=:") + 1; + else +len = strlen(def_path) + strlen("PATH=") + 1; + npath = (char *) malloc(len); strcpy (npath, "PATH="); strcat (npath, def_path); - strcat (npath, ":"); - strcat (npath, opath); + + if (opath) +{ + strcat (npath, ":"); + strcat (npath, opath); +} if (putenv (npath)) abort ();
Bug#703031: libssl1.0.0: Segfault in SSL_get_certificate (1.0.1e-1)
Package: libssl1.0.0 Version: 1.0.1e-1 Severity: important Tags: patch upstream SSL_get_certificate results in a segfault when called before SSL_accept. Attached you find sample code that triggres the problem. In in the upstream openssl git repository this problem is already fixed with commit 147dbb2fe3bead7a10e2f280261b661ce7af7adc in the OpenSSL_1_0_1-stable branch (patch also attached). -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.8.0 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libssl1.0.0 depends on: ii debconf [debconf-2.0] 1.5.49 ii libc6 2.13-38 ii multiarch-support 2.13-38 ii zlib1g 1:1.2.7.dfsg-13 libssl1.0.0 recommends no packages. libssl1.0.0 suggests no packages. -- debconf information: libssl1.0.0/restart-failed: libssl1.0.0/restart-services: commit 147dbb2fe3bead7a10e2f280261b661ce7af7adc Author: Dr. Stephen Henson Date: Mon Feb 11 18:24:03 2013 + Fix for SSL_get_certificate Now we set the current certificate to the one used by a server there is no need to call ssl_get_server_send_cert which will fail if we haven't sent a certificate yet. diff --git a/ssl/ssl_lib.c b/ssl/ssl_lib.c index 14d143d..ff5a85a 100644 --- a/ssl/ssl_lib.c +++ b/ssl/ssl_lib.c @@ -2792,9 +2792,7 @@ void ssl_clear_cipher_ctx(SSL *s) /* Fix this function so that it takes an optional type parameter */ X509 *SSL_get_certificate(const SSL *s) { - if (s->server) - return(ssl_get_server_send_cert(s)); - else if (s->cert != NULL) + if (s->cert != NULL) return(s->cert->key->x509); else return(NULL); /* compile: gcc -o ssl_test -lssl -g ssl_test.c -Wall */ #include #include #include #define SERVER_KEY "server.key" #define SERVER_CRT "server.crt" #define RETURN_IF_ERROR(err) if ((err)==-1) { ERR_print_errors_fp(stderr); exit(1); } int main(void){ X509* server_cert = NULL; SSL *ssl = NULL; SSL_CTX * ctx = NULL; SSL_library_init(); ctx = SSL_CTX_new(SSLv23_server_method()); if (ctx == NULL) { printf("SSL_CTX_new failed\n"); return 1; } SSL_CTX_set_options(ctx, SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS|SSL_OP_TLS_BLOCK_PADDING_BUG|SSL_OP_NO_SSLv2); RETURN_IF_ERROR(SSL_CTX_use_RSAPrivateKey_file(ctx, SERVER_KEY, SSL_FILETYPE_PEM)) RETURN_IF_ERROR(SSL_CTX_use_certificate_file(ctx, SERVER_CRT, SSL_FILETYPE_PEM)) ssl = SSL_new(ctx); if (ssl == NULL) { printf("SSL_new failed\n"); return 1; } //-> SEGFAULT server_cert = SSL_get_certificate(ssl); if (server_cert == NULL) { printf("tls_connect: tls_get_certificate failed to return the server certificate.\n"); return 1; } SSL_free(ssl); SSL_CTX_free(ctx); return 0; }
Bug#502548: Not fixed in 1.4.2-5
found 502548 1.4.2-5 thanks Hi, in version 1.4.2-5 the bug still exists. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#502548: closed by "Laurence J. Lane" (iptables cleanup)
Tags: lenny Severity: important Debian Bug Tracking System wrote: Version: 1.4.2-1 Fixed upstream. Is it possible to get this fix into lenny? - For us this bug causes serious problems. In case of a name server outage it takes up to 10 minutes to list the iptables. This also breaks shorewall then. Thanks, best regards, Bernhard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#502548: Acknowledgement (Numeric not considered for conntrack when listing)
Hi, Debian Bug Tracking System wrote: > Thank you for filing a new Bug report with Debian. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > [EMAIL PROTECTED] (Laurence J. Lane) and here the actual patch. Best regards, Bernhard --- iptables-1.4.1.1/extensions/libxt_conntrack.c 2008-06-16 15:12:40.0 +0200 +++ iptables-1.4.1.1.modified/extensions/libxt_conntrack.c 2008-10-17 18:33:39.0 +0200 @@ -761,14 +761,20 @@ printf("anywhere "); return; } - printf("%s ", ipaddr_to_anyname(&addr->in)); + if (numeric) + printf("%s ", ipaddr_to_numeric(&addr->in)); + else + printf("%s ", ipaddr_to_anyname(&addr->in)); } else if (family == AF_INET6) { if (!numeric && addr->ip6[0] == 0 && addr->ip6[1] == 0 && addr->ip6[2] == 0 && addr->ip6[3] == 0) { printf("anywhere "); return; } - printf("%s ", ip6addr_to_anyname(&addr->in6)); + if (numeric) + printf("%s ", ip6addr_to_numeric(&addr->in6)); + else + printf("%s ", ip6addr_to_anyname(&addr->in6)); } }
Bug#502548: Numeric not considered for conntrack when listing
Package: iptables Version: 1.4.1.1-3 Severity: serious Justification: 3 Tags: patch *** Please type your report below this line *** Iptables tries to resolve host names even if numeric (-n) parameter is set. This applies to conntrack (revision 1). Steps to reproduce: iptables -N testct iptables -A testct -d 172.16.27.29/32 -p tcp -m tcp --dport 80 -m \ conntrack --ctorigdst 77.244.240.226 -j ACCEPT iptables -L testct -n The listing is resolving the host. Attached you find a patch which solved the problem for me but it is only tested for ipv4. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages iptables depends on: ii libc6 2.7-13 GNU C Library: Shared libraries iptables recommends no packages. iptables suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#483168: Parted crashes when using GPT and a volume is resized
With the version 1.8.8.git.2008.03.24-7 from unstable the bug does not occur anymore. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475150: apache2.2-common: No possibility to supply defines (-D) on startup
Package: apache2.2-common Version: 2.2.3-4+etch4 Severity: minor Tags: patch It is not possible to set defines for use in directive. The attached patch add a variable APACHE_DEFINES to /etc/default/apache2 which is evaluated at startup and passes the defines to apachectl. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-028stab053-dl3xx-openvz Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages apache2.2-common depends on: ii apache2-utils 2.2.3-4+etch4 utility programs for webservers ii libmagic1 4.17-5etch3 File type determination library us ii lsb-base 3.1-23.2etch1 Linux Standard Base 3.1 init scrip ii mime-support 3.39-1MIME files 'mime.types' & 'mailcap ii net-tools 1.60-17 The NET-3 networking toolkit ii procps 1:3.2.7-3 /proc file system utilities apache2.2-common recommends no packages. -- no debconf information diff -urN etc_org/default/apache2 etc/default/apache2 --- etc_org/etc/default/apache2 2008-04-08 14:03:26.0 + +++ etc/default/apache2 2008-04-08 14:45:18.0 + @@ -1,2 +1,4 @@ # 0 = start on boot; 1 = don't start on boot NO_START=0 +# Pass defines to apache (e.g. -D Harden) +APACHE_DEFINES="" diff -urN etc_org/init.d/apache2 etc/init.d/apache2 --- etc_org/init.d/apache2 2008-01-31 08:41:24.0 + +++ etc/init.d/apache2 2008-04-08 14:37:22.0 + @@ -117,6 +117,21 @@ fi } +apache_start() { + DEFINES=""; + if [ "$APACHE_DEFINES" != "" ] ; then + for i in ${APACHE_DEFINES} ;do + DEFINES+="-D $i "; + done + fi + + if $APACHE2CTL $DEFINES -k start; then + return 0 + else + return 1 + fi +} + # Stupid hack to keep lintian happy. (Warrk! Stupidhack!). case $1 in start) @@ -126,7 +141,7 @@ #ssl_scache shouldn't be here if we're just starting up. [ -f /var/run/apache2/ssl_scache ] && rm -f /var/run/apache2/*ssl_scache* log_begin_msg "Starting web server (apache2)..." - if $APACHE2CTL start; then + if apache_start; then log_end_msg 0 else log_end_msg 1 @@ -160,11 +175,11 @@ if ! apache_sync_stop; then log_end_msg 1 fi - if $APACHE2CTL start; then -log_end_msg 0 -else -log_end_msg 1 -fi + if apache_start ; then + log_end_msg 0 + else + log_end_msg 1 + fi ;; *) log_success_msg "Usage: /etc/init.d/apache2 {start|stop|restart|reload|force-reload}"