198914 2007-11-12 11:34 0000 dev-libs/openssl-0.9.8g failure with SSLv3 handshakes when enable-tlsext 2008-05-29 13:50:26 0000 1 1 1 Unclassified Gentoo Linux Ebuilds unspecified All Linux RESOLVED FIXED http://rt.openssl.org/Ticket/Display.html?id=1629 P2 normal --- 224095 1 drear@iki.fi base-system@gentoo.org anton.bugs@gmail.com caster@gentoo.org polynomial-c@gentoo.org ShadowMaster@Shadow-Realm.org drear@iki.fi 2007-11-12 11:34:24 0000 Hi. As openssl-0.9.8g went stable, I fail to fetch mail from one server via fetchmail: 1247:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1053:SSL alert number 40 Bear in mind that I know practically nothing about SSL/OpenSSL, but I can verify that everything works perfectly fine with dev-libs/openssl-0.9.8f. * * * zealot ~ # emerge --info --ignore-default-opts Portage 2.1.3.19 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.23-hardened-r1 x86_64) ================================================================= System uname: 2.6.23-hardened-r1 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ Timestamp of tree: Mon, 12 Nov 2007 03:46:01 +0000 app-shells/bash: 3.2_p17 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.9-r2 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.6.3, 1.7.9-r1, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -msse3 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d /usr/kde/*/share/apps/kjava/kjava.policy /usr/kde/*/shutdown/agent-shutdown.sh /usr/kde/3.5/share/services/rlogin.protocol" CXXFLAGS="-march=athlon64 -msse3 -O2 -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--ask --verbose" FEATURES="buildpkg collision-protect distlocks fixpackages metadata-transfer multilib-strict parallel-fetch sandbox sfperms suidctl unmerge-orphans userfetch userpviv usersandbox" GENTOO_MIRRORS="http://trumpetti.atm.tut.fi/gentoo http://mirror.uni-c.dk/pub/gentoo http://ds.thn.htu.se/linux/gentoo http://mirror.gentoo.no/ http://distfiles.gentoo.org" LANG="en_US.utf8" LC_ALL="en_US.utf8" LINGUAS="en en_GB en_US" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X alsa amd64 berkdb bitmap-fonts bzip2 cli cracklib crypt cups curl dri fortran gdbm gif gpm iconv isdnlog jpeg kde kdehiddenvisibility midi mmx mmxext mudflap ncurses nls nptl nptlonly opengl openmp pam pcre perl png pppd python qt3 readline reflection session spell spl sse sse2 ssl tcl tcltk tcpd threads tiff tk truetype truetype-fonts type1-fonts unicode xcomposite xinerama xorg zlib" ALSA_CARDS="emu10k1 intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LINGUAS="en en_GB en_US" USERLAND="GNU" VIDEO_CARDS="nv" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS drear@iki.fi 2007-11-12 11:45:40 0000 I forgot to mention: all tests are passed with openssl-0.9.8g. polynomial-c@gentoo.org 2007-11-24 07:50:31 0000 Hi, I have a similar problem with net-irc/xchat-2.8.4 and dev-libs/openssl-0.9.8g: [08:46:06] --- Looking up irc.mozilla.org.. [08:46:06] --- Connecting to irc.mozilla.org (63.245.208.159) port 6697.. [08:46:07] --- Connection failed. Error: (336151568) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure This doesn't happen on all networks/servers but for irc.mozilla.org it's 100% reproduceable. I don't know if this problem started after upgrade to openssl-0.9.8g or after upgrade to glibc-2.6.1... Cheers Poly-C polynomial-c@gentoo.org 2007-11-24 07:54:04 0000 Created an attachment (id=136861) emerge --info P.S.: I know, I'm using masked app-shells/bash-3.2_p25 but that's intentional (I already patched portage to work with this bash version) and this problem already occured with bash-3.2_p17... ShadowMaster@Shadow-Realm.org 2007-11-29 00:01:09 0000 Confirming openssl-0.9.8g causing xchat amongst others to fail SSL handshakes. emerge --info: Portage 2.1.4_rc3 (default-linux/x86/2006.1, gcc-4.1.2, glibc-2.7-r0, 2.6.22-gentoo-r9 i686) ================================================================= System uname: 2.6.22-gentoo-r9 i686 AMD Athlon(tm) XP 2400+ Timestamp of tree: Tue, 27 Nov 2007 23:00:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p17 dev-java/java-config: 1.3.7, 2.1.2-r1 dev-lang/python: 2.4.4-r4, 2.5.1-r4 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 dev-util/confcache: 0.4.2-r1 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -mtune=athlon -fomit-frame-pointer -march=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -mtune=athlon -fomit-frame-pointer -march=athlon-xp -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps y" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.gentoo.no/ ftp://ftp.du.se/pub/os/gentoo http://ds.thn.htu.se/linux/gentoo http://gd.tuwien.ac.at/opsys/linux/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X aiglx async bcmath beagle berkdb bitmap-fonts bittorrent bootsplash bzip2 cairo ccache chroot clamav cli contentcache cpudetection cracklib crypt css cups curl dbus dri dvd emerald epiphany fbsplash ffmpeg finger firefox flac font-server fontconfig fortran ftp gaim gd gdbm glitz gmail gmailtimestamps gnome gnome-print gnutls gpm gstreamer gtalk gtk gtk2 hal iconv icq imap ipv6 isdnlog jabber java javascript jpeg kde lm_sensors logitech-mouse maildir matroska mbox midi mime mmap mmx mono mp3 mp4 mpeg mplayer mudflap ncurses nls nptl nptlonly nsplugin ogg opengl openmp pam pam_chroot pam_timestamp pango pcre pdf perl png ppds python qt3 qt4 readline reflection reiser4 reiserfs ruby samba session snmp spell spl sqlite3 sse sse-filters ssl stream subversion svg symlink tcpd theora threads tiff tk truetype-fonts type1-fonts unicode vcd vorbis wv x264 x86 xface xorg xv yahoo zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia vesa" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS caster@gentoo.org 2007-12-14 11:03:17 0000 Not sure if it's exactly the same problem, but I cannot connect to google talk with net-im/sim and openssl-0.9.8g, and 0.9.8f works fine There's a bug report that suggests that on debian, both versions work (so maybe they have some patch?): http://developer.berlios.de/bugs/?func=detailbug&bug_id=12510&group_id=4482 brad@mainstreetsoftworks.com 2008-03-21 12:27:49 0000 just as an FYI, this is in OpenSSL's request tracker with a patch an explanation: http://rt.openssl.org/index.html?q=1629 vapier@gentoo.org 2008-03-23 17:49:45 0000 we added enable-tlsext by default in 0.9.8g ... if you remove that from the ebuild, things should probably work caster@gentoo.org 2008-03-24 12:51:08 0000 Right, disabling tlsext helped with my issue from comment 5. Making it a USE flag would make it easier, but your call, dunno how far is a fixed upstream version. vapier@gentoo.org 2008-03-24 13:54:47 0000 a USE flag would just ignore the issue ... and then people would just complain about the same thing when the flag was turned on ... has anyone tried the upstream patch (user/pass = guest/guest) ? we can either apply that or just drop tlsext until it's fixed ... it was only added on a lark anyways; nothing is needing it at the moment caster@gentoo.org 2008-03-24 14:44:45 0000 (In reply to comment #9) > a USE flag would just ignore the issue ... and then people would just complain > about the same thing when the flag was turned on ... > > has anyone tried the upstream patch (user/pass = guest/guest) ? Not yet, I guessed it's not upstream patch but an user attached patch (please prove me wrong) and that no upstream dev commented on it yet. (is your guest/guest also from bugmenot or something that's suggested on the page itself? couldn't even find a "register" link, not to mention the tracker is localised to czech in a fugly way and there's no english option :) > we can either > apply that or just drop tlsext until it's fixed ... it was only added on a lark > anyways; nothing is needing it at the moment I can test and it will probably work, just questioning the upstream intention. gtg655b@mail.gatech.edu 2008-03-24 14:51:18 0000 I have similar results: openssl-0.9.8g doesn't work on one particular e-mail server, but 0.9.8f works fine. If someone cares to supply an ebuild with the potential patch, I'll happily test it and report whether the patch fixes it. But I would urge either patching this or removing the offending flag, especially seeing as it doesn't appear to be needed by anything. vapier@gentoo.org 2008-03-24 19:26:56 0000 the guest/guest part i read somewhere in the openssl docs ... dont ask me where; their site is a pita to find stuff :p will people stop posting that "downgrading to 0.9.8f fixes things" ... we dont care about the version difference. all that matters is removing of the tlsext flag in the 0.9.8g ebuild and things work after that. cardoe@gentoo.org 2008-03-25 00:25:38 0000 I feel the proper resolution here is going to be to merge the patch provided in OpenSSL's RT. Some servers can not handle TLS (which is technically SSLv3.1) Extensions (which are present in TLSv1.1/SSLv3.2) on SSLv3 connections. It's a simple version check and omission of the extensions. If we've got SSLv3.0, don't offer extensions since extension support wasn't formally in a spec until SSLv3.1. If we have at least SSLv3.1, offer extensions. It seems straight forward. Additionally, based on Caster's bug link I reduced this down to a simple test case. $ openssl s_client -ssl3 -no_ssl2 -showcerts -connect talk.google.com:5223 In doing so I tested the supplied patch in OpenSSL's RT. This also resolves several complains people have had with Pidgin and Google Talk. Please use openssl-0.9.8g-r1 caster@gentoo.org 2008-03-25 11:03:10 0000 (In reply to comment #13) > $ openssl s_client -ssl3 -no_ssl2 -showcerts -connect talk.google.com:5223 I can confirm this test case now works in -r1, however: > In doing so I tested the supplied patch in OpenSSL's RT. This also resolves > several complains people have had with Pidgin and Google Talk. Unfortunately SIM still doesn't work with Google Talk (but works without enable-tlsext in -r0). Either the patch is incomplete and the extensions are also used elsewhere, or SIM sets the connection in a way that doesn't trigger the if clauses? Unfortunately can't see from the intergrated network monitor if the error seems different than without patch. cardoe@gentoo.org 2008-03-25 14:18:22 0000 What port is SIM connecting to over at Google Talk? 5222 is the default Google Talk port which uses TLS. Where as 5223 appears to use SSLv3. cardoe@gentoo.org 2008-03-25 14:19:33 0000 This patch allowed be to be successful in connecting to Google Talk via both ports using Pidgin, while not using the patch only allowed me to connect via 5222. caster@gentoo.org 2008-03-29 19:26:01 0000 (In reply to comment #15) > What port is SIM connecting to over at Google Talk? 5222 is the default Google > Talk port which uses TLS. Where as 5223 appears to use SSLv3. SIM uses 5223, I think it never worked with 5222, including now. anton.bugs@gmail.com 2008-04-12 17:32:28 0000 (In reply to comment #14) Thanks. The same sim problems and fix here. The -r1 patch doesn't work fully. cardoe@gentoo.org 2008-04-14 04:04:12 0000 Still need code to re-produce or steps to reproduce this on my machine OTHER then installing/using sim. matthew4196@gmail.com 2008-04-20 23:54:10 0000 I've had a look at the SIM code and it looks like it is using TLSv1_method in sim/sslclient.cpp to connect. Patching it to use SSLv23_client_method allows it to work with the -r1 patch. This can be tested with: $ openssl s_client -tls1 -no_ssl2 -showcerts -connect talk.google.com:5223 which works without enable-tlsext but fails with enable-tlsext enabled even with the -r1 patch. This seems to be critical as openssl-0.9.8g has been marked as stable since November and is also installed in stage3-i686-2008.0_beta1. anton.bugs@gmail.com 2008-04-23 13:34:55 0000 Created an attachment (id=150701) sim-0.9.4.3-sslv23.patch Thanks Matthew, nice one. Everything is working fine now. I guess I'll need to file a separate bug report for it. And openssl -r1 should really go stable now. caster@gentoo.org 2008-04-23 13:53:14 0000 (In reply to comment #21) > Thanks Matthew, nice one. Everything is working fine now. I guess I'll need to > file a separate bug report for it. And openssl -r1 should really go stable now. Um, the question is if sim is really doing something it shouldn't, and tlsext just revealed it, or if it's still a problem of openssl (or perhaps the gmail server) and the patch is just working around it? cardoe@gentoo.org 2008-04-23 13:59:32 0000 (In reply to comment #22) > (In reply to comment #21) > > Thanks Matthew, nice one. Everything is working fine now. I guess I'll need to > > file a separate bug report for it. And openssl -r1 should really go stable now. > > Um, the question is if sim is really doing something it shouldn't, and tlsext > just revealed it, or if it's still a problem of openssl (or perhaps the gmail > server) and the patch is just working around it? > SIM is connecting to a known SSL-only port with TLSv1 and relying on the fallback to SSLv3. I'd say it's a broken assumption on SIM's part simply because if you advertised "Connect to my SSL port" and you ran SSLv2 (stupidly), then TLSv1_client_method would not work. As I previously explained, TLSv1 is really SSLv3.1, which is why TLSv1_client_method works when connecting to an SSLv3 server.... usually. However, TLS has a few things in it's spec that SSLv3 stuff doesn't expect and SSLv3 implementations don't have to follow the "if you see something you don't know, ignore it" that TLS follows (due to extensions). anton.bugs@gmail.com 2008-04-23 14:45:51 0000 I know at least 1 more https server which require openssl -r1 so it's not gmail's problem and the openssl patch looks good. The patch for sim is more a workaround for now. I think they should redesign ssl init sections and do something similar what stunnel does, stunnel-4.21/src/options.c: /* sslVersion */ switch(cmd) { case CMD_INIT: section->client_method=SSLv3_client_method; break; case CMD_EXEC: if(strcasecmp(opt, "sslVersion")) break; if(!strcasecmp(arg, "all")) { section->client_method=SSLv23_client_method; } else if(!strcasecmp(arg, "SSLv2")) { section->client_method=SSLv2_client_method; } else if(!strcasecmp(arg, "SSLv3")) { section->client_method=SSLv3_client_method; } else if(!strcasecmp(arg, "TLSv1")) { section->client_method=TLSv1_client_method; } else return "Incorrect version of SSL protocol"; but I'm not an expert here, so it's just IMHO. johannes@truschnigg.info 2008-05-21 18:11:36 0000 I'm apparently hitting the very same or a similar problem when trying to connect to cacert.org: colo@zealot ~ $ openssl s_client -connect cacert.org:443 -no_ssl2 -bugs CONNECTED(00000003) [... snip ...] verify return:1 1660:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac:s3_pkt.c:1053:SSL alert number 20 1660:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: colo@zealot ~ $ openssl version OpenSSL 0.9.8g 19 Oct 2007 ~amd64: * dev-libs/openssl [R 0.9.8g-r1] <target> Reasons: app-misc/ca-certificates-20070303-r1:0::installed -bindist -gmp -kerberos (sse2) -test zlib CHOST="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=nocona -fomit-frame-pointer" cardoe@gentoo.org 2008-05-21 19:47:03 0000 (In reply to comment #25) > I'm apparently hitting the very same or a similar problem when trying to > connect to cacert.org: I believe you're having a different error since I'm able to reproduce this on multiple versions of OpenSSL. 0.9.8e, 0.9.8f, 0.9.8g cardoe@gentoo.org 2008-05-21 19:51:07 0000 (In reply to comment #25) > I'm apparently hitting the very same or a similar problem when trying to > connect to cacert.org: > > colo@zealot ~ $ openssl s_client -connect cacert.org:443 -no_ssl2 -bugs > CONNECTED(00000003) > [... snip ...] > verify return:1 > 1660:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record > mac:s3_pkt.c:1053:SSL alert number 20 > 1660:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake > failure:s23_lib.c:188: However, additionally, you're connecting to an SSLv2/SSLv3 port with TLSv1/TLSv1.1, this is an improper way to connect and you should fix the code that spawned you to write this test case. caster@gentoo.org 2008-05-29 11:03:14 0000 BTW the patch for sim was applied in svn and works fine here. But it's available only in sim-9999 live svn, so people can still hit the problem. I guess a separate bug for sim should be opened? As for openssl itself, looks like upstream didn't apply the patch in 0.9.8h and we apply it ourselves. anton.bugs@gmail.com 2008-05-29 13:44:21 0000 I already suggested to split it in the comment #21, so here we go, bug #224095 You might want to close this bug now and/or investigate why the patch for openssl hasn't been included into the version 0.9.8h. cardoe@gentoo.org 2008-05-29 13:50:26 0000 (In reply to comment #29) > I already suggested to split it in the comment #21, so here we go, bug #224095 > You might want to close this bug now and/or investigate why the patch for > openssl hasn't been included into the version 0.9.8h. > Because 0.9.8h wasn't a bug fix release, it was a security fix release. 136861 2007-11-24 07:54 0000 emerge --info emerge--info.txt text/plain UG9ydGFnZSAyLjEuMy4xOSAoZGVmYXVsdC1saW51eC94ODYvMjAwNy4wL2Rlc2t0b3AsIGdjYy00 LjIuMiwgZ2xpYmMtMi42LjEtcjAsIDIuNi4yMi4xNCBpNjg2KQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpTeXN0ZW0gdW5h bWU6IDIuNi4yMi4xNCBpNjg2IEFNRCBBdGhsb24odG0pIFhQIDMwMDArClRpbWVzdGFtcCBvZiB0 cmVlOiBTYXQsIDI0IE5vdiAyMDA3IDA2OjQ2OjAxICswMDAwCmFwcC1zaGVsbHMvYmFzaDogICAg IDMuMl9wMjUKZGV2LWphdmEvamF2YS1jb25maWc6IDEuMy43LCAyLjEuMi1yMQpkZXYtbGFuZy9w eXRob246ICAgICAyLjUuMS1yNApzeXMtYXBwcy9iYXNlbGF5b3V0OiAxLjEyLjEwLXI1CnN5cy1h cHBzL3NhbmRib3g6ICAgIDEuMi4xOC4xLXIyCnN5cy1kZXZlbC9hdXRvY29uZjogIDIuMTMsIDIu NjEtcjEKc3lzLWRldmVsL2F1dG9tYWtlOiAgMS41LCAxLjcuOS1yMSwgMS44LjUtcjMsIDEuOS42 LXIyLCAxLjEwCnN5cy1kZXZlbC9iaW51dGlsczogIDIuMTgtcjEKc3lzLWRldmVsL2djYy1jb25m aWc6IDEuNC4wLXI0CnN5cy1kZXZlbC9saWJ0b29sOiAgIDEuNS4yNAp2aXJ0dWFsL29zLWhlYWRl cnM6ICAyLjYuMjItcjIKQUNDRVBUX0tFWVdPUkRTPSJ4ODYgfng4NiIKQ0JVSUxEPSJpNjg2LXBj LWxpbnV4LWdudSIKQ0ZMQUdTPSItbWFyY2g9YXRobG9uLXhwIC1tdHVuZT1hdGhsb24teHAgLU8y IC1waXBlIC1mb21pdC1mcmFtZS1wb2ludGVyIC1maW5saW5lLWZ1bmN0aW9ucyIKQ0hPU1Q9Imk2 ODYtcGMtbGludXgtZ251IgpDT05GSUdfUFJPVEVDVD0iL2V0YyAvaG9tZSAvdXNyL2tkZS8zLjUv ZW52IC91c3Iva2RlLzMuNS9zaGFyZS9jb25maWcgL3Vzci9rZGUvMy41L3NodXRkb3duIC91c3Iv c2hhcmUvY29uZmlnIgpDT05GSUdfUFJPVEVDVF9NQVNLPSIvZXRjL1gxMS9TZXNzaW9ucyAvZXRj L1gxMS9hcHAtZGVmYXVsdHMgL2V0Yy9YMTEveGluaXQgL2V0Yy9iYXNoX2NvbXBsZXRpb24uZCAv ZXRjL2Jvbm9iby1hY3RpdmF0aW9uIC9ldGMvY3VwcyAvZXRjL2RidXMtMSAvZXRjL2Vudi5kIC9l dGMvZW52LmQvamF2YS8gL2V0Yy9lc2VsZWN0L2NvbXBpbGVyIC9ldGMvZm9udHMgL2V0Yy9mb250 cy9mb250cy5jb25mIC9ldGMvZm9vbWF0aWMgL2V0Yy9nY29uZiAvZXRjL2dpbXAgL2V0Yy9nbm9t ZS12ZnMtMi4wIC9ldGMvZ3RrIC9ldGMvZ3RrLTIuMCAvZXRjL2hvdHBsdWcgL2V0Yy9ob3RwbHVn LmQgL2V0Yy9pbWxpYiAvZXRjL2luaXQuZCAvZXRjL2lwcm91dGUyIC9ldGMvbmFzIC9ldGMvbnRv cCAvZXRjL3BhbS5kIC9ldGMvcGFuZ28gL2V0Yy9wcm9maWxlLmQgL2V0Yy9yZXZkZXAtcmVidWls ZCAvZXRjL3Nhc2wyIC9ldGMvc2dtbCAvZXRjL3NzbCAvZXRjL3NzbXRwIC9ldGMvdDFsaWIgL2V0 Yy90ZXJtaW5mbyAvZXRjL3VkZXYvcnVsZXMuZCAvZXRjL3hpbmV0ZC5kIC9ldGMveG1sIgpDWFhG TEFHUz0iLW1hcmNoPWF0aGxvbi14cCAtbXR1bmU9YXRobG9uLXhwIC1PMiAtcGlwZSAtZm9taXQt ZnJhbWUtcG9pbnRlciAtZmlubGluZS1mdW5jdGlvbnMiCkRJU1RESVI9Ii91c3IvcG9ydGFnZS9k aXN0ZmlsZXMiCkVNRVJHRV9ERUZBVUxUX09QVFM9Ii0tYWxwaGFiZXRpY2FsIC0td2l0aC1iZGVw cz15IgpGRUFUVVJFUz0iZGlzdGxvY2tzIG1ldGFkYXRhLXRyYW5zZmVyIHNhbmRib3ggc2ZwZXJt cyBzdHJpY3QgdW5tZXJnZS1vcnBoYW5zIHVzZXJmZXRjaCB1c2VycHJpdiB1c2Vyc2FuZGJveCIK R0VOVE9PX01JUlJPUlM9ImZ0cDovL2xpbnV4LnJ6LnJ1aHItdW5pLWJvY2h1bS5kZS9nZW50b28t bWlycm9yIGZ0cDovL2Z0cC50dS1jbGF1c3RoYWwuZGUvcHViL2xpbnV4L2dlbnRvbyBodHRwOi8v ZGlzdGZpbGVzLmdlbnRvby5vcmcgaHR0cDovL3d3dy5pYmlibGlvLm9yZy9wdWIvTGludXgvZGlz dHJpYnV0aW9ucy9nZW50b28iCkxBTkc9ImRlX0RFQGV1cm8iCkxERkxBR1M9Ii1XbCwtLWFzLW5l ZWRlZCIKTElOR1VBUz0iZGUiClBLR0RJUj0iL2hvbWUvLnBvcnRhZ2UvcGFja2FnZXMiClBPUlRB R0VfUlNZTkNfT1BUUz0iLS1yZWN1cnNpdmUgLS1saW5rcyAtLXNhZmUtbGlua3MgLS1wZXJtcyAt LXRpbWVzIC0tY29tcHJlc3MgLS1mb3JjZSAtLXdob2xlLWZpbGUgLS1kZWxldGUgLS1kZWxldGUt YWZ0ZXIgLS1zdGF0cyAtLXRpbWVvdXQ9MTgwIC0tZXhjbHVkZT0vZGlzdGZpbGVzIC0tZXhjbHVk ZT0vbG9jYWwgLS1leGNsdWRlPS9wYWNrYWdlcyAtLWZpbHRlcj1IXyoqL2ZpbGVzL2RpZ2VzdC0q IgpQT1JUQUdFX1RNUERJUj0iL2hvbWUvLnBvcnRhZ2UvdG1wIgpQT1JURElSPSIvdXNyL3BvcnRh Z2UiClBPUlRESVJfT1ZFUkxBWT0iL3Vzci9sb2NhbC9wb3J0YWdlIgpTWU5DPSJyc3luYzovLzE5 Mi4xNjguMC4yNTQvZ2VudG9vLXBvcnRhZ2UiClVTRT0iM2Rub3cgM2Rub3dleHQgWCBhNTIgYWFj IGFjcGkgYWxzYSBhcnRzIGFzZiBhdmkgYmVya2RiIGJpdG1hcC1mb250cyBiemlwMiBjYWlybyBj ZHBhcmFub2lhIGNkciBjbGkgY3JhY2tsaWIgY3J5cHQgY3VwcyBkdmQgZHZkcmVhZCBlbWJvc3Mg ZW5jb2RlIGV2byBmYW0gZmZtcGVnIGZsYWMgZ2RibSBnaWYgZ251dGxzIGdwZyBndGsgZ3RrMiBp Y29udiBpZG4gaW1hZ2VtYWdpY2sgaW1saWIgaXNkbmxvZyBqcGVnIGtkZSBrZGVoaWRkZW52aXNp YmlsaXR5IGxpYnd3dyBtYWQgbWlkaSBtaWttb2QgbWpwZWcgbW14IG1teGV4dCBtcDMgbXBlZyBt dWRmbGFwIG5jdXJzZXMgbmxzIG5wdGwgbnB0bG9ubHkgbnNwbHVnaW4gb2dnIG9nZ3ZvcmJpcyBv cGVuZ2wgb3Blbm1wIHBhbSBwY3JlIHBkZiBwZXJsIHBuZyBwcHBkIHB5dGhvbiBxdDMgcXQzc3Vw cG9ydCBxdWlja3RpbWUgcmVhZGxpbmUgcmVhbCByZWZsZWN0aW9uIHNkbCBzZWFtb25rZXkgc2Vz c2lvbiBzaWxjIHNsYW5nIHNwZWxsIHNwbCBzc2Ugc3NsIHN2ZyB0Z2EgdGhlb3JhIHRpZmYgdHJ1 ZXR5cGUgdHJ1ZXR5cGUtZm9udHMgdHlwZTEtZm9udHMgdjRsMiB2Y2Qgdm9yYmlzIHdpbjMyY29k ZWNzIHgyNjQgeDg2IHhjb21wb3NpdGUgeG1sIHhtbDIgeG9yZyB4cHJpbnQgeHYgeHZpZCB6bGli IiBBTFNBX0NBUkRTPSJlbXUxMGsxIHZpYTgyeHgiIEFMU0FfUENNX1BMVUdJTlM9ImFkcGNtIGFs YXcgYXN5bSBjb3B5IGRtaXggZHNoYXJlIGRzbm9vcCBlbXB0eSBleHRwbHVnIGZpbGUgaG9va3Mg aWVjOTU4IGlvcGx1ZyBsYWRzcGEgbGZsb2F0IGxpbmVhciBtZXRlciBtdWxhdyBtdWx0aSBudWxs IHBsdWcgcmF0ZSByb3V0ZSBzaGFyZSBzaG0gc29mdHZvbCIgRUxJQkM9ImdsaWJjIiBJTlBVVF9E RVZJQ0VTPSJrZXlib2FyZCBtb3VzZSIgS0VSTkVMPSJsaW51eCIgTENEX0RFVklDRVM9ImJheXJh ZCBjZm9udHogY2ZvbnR6NjMzIGdsayBoZDQ0NzgwIGxiMjE2IGxjZG0wMDEgbXR4b3JiIG5jdXJz ZXMgdGV4dCIgTElOR1VBUz0iZGUiIFVTRVJMQU5EPSJHTlUiIFZJREVPX0NBUkRTPSJudiBudmlk aWEiClVuc2V0OiAgQ1BQRkxBR1MsIENUQVJHRVQsIElOU1RBTExfTUFTSywgTENfQUxMLCBNQUtF T1BUUywgUE9SVEFHRV9DT01QUkVTUywgUE9SVEFHRV9DT01QUkVTU19GTEFHUywgUE9SVEFHRV9S U1lOQ19FWFRSQV9PUFRTCgo= 150701 2008-04-23 13:34 0000 sim-0.9.4.3-sslv23.patch sim-0.9.4.3-sslv23.patch text/plain LS0tIHNpbS9zc2xjbGllbnQuY3BwLm9yaWcJMjAwNi0wMi0wMSAwNDoyNDoyNS4wMDAwMDAwMDAg KzA4MDAKKysrIHNpbS9zc2xjbGllbnQuY3BwCTIwMDgtMDQtMjMgMjA6NTk6NDcuMDAwMDAwMDAw ICswODAwCkBAIC00MDYsNyArNDA2LDcgQEAKIAogYm9vbCBTU0xDbGllbnQ6OmluaXRUTFMxKGJv b2wgYkRIKQogewotICAgIG1wQ1RYID0gU1NMX0NUWF9uZXcoVExTdjFfbWV0aG9kKCkpOworICAg IG1wQ1RYID0gU1NMX0NUWF9uZXcoU1NMdjIzX2NsaWVudF9tZXRob2QoKSk7CiAgICAgaWYgKG1w Q1RYID09IE5VTEwpCiAgICAgICAgIHJldHVybiBmYWxzZTsKICAgICBpZiAoYkRIKXsK