From libssh2-devel-bounces@cool.haxx.se Thu Feb 4 13:48:57 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u14CmTde026123; Thu, 4 Feb 2016 13:48:53 +0100 Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06:0:0:0:22f]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u14CmRDp026028 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 4 Feb 2016 13:48:28 +0100 Received: by mail-oi0-x22f.google.com with SMTP id s2so14568309oie.2 for ; Thu, 04 Feb 2016 04:48:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=VlyEolNhD97d5COGMI76IxYyh4GIijorHE4a1vFLcxY=; b=C/egTHGIvGEcCSnjZOxcUVs0xzhWR6hfrv+sfoeioC9pE6X/TUTBvB/WaN5BBnGUh6 n20BAYJpK8BZbNvkhfGgA8GY7SZa6q8sKk6nPbjQJ2vT/njCuEKKOdCLnhXNOvY5PIQw UK+crWk0SPxgtT26UgfK+SqxRDSJIHqlR8I5oM1YLFaTYxk31Gf9orVGeztfjBONeWb4 tgNMeKW76lcmf3G7Fwlwlu/3lmaqMLap8N8p+K8hkQn7J887XOKkY1osI5YjFldCDqSB UxD2G4IwWL3+mrHZ+ukvgVAtFPs8SpPYKZBY+kz9MsjqEtLkURldiUnhs9GkHB2wIzF6 YFmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=VlyEolNhD97d5COGMI76IxYyh4GIijorHE4a1vFLcxY=; b=jqzahKejC/nATDAiQwzlwyVlXnhpvb+zL1q71RdJWBfQsZTfvzuFIorSEqkpanhaFM x8WPah+7wKWnLDuAKswrJe3PxOl5k01bIvNiKSAfBO2jAoP8k/4JraVE8aa5Sj1co+d3 VXaaSDgQflyAn7JQnqxdkFJ+eHha+PvC0RFQwdi/m8yQjOuKtxzsQxNlsxJ6UflfAqQf ZPS8BddBdR/ZRxZkrcUHStAZAg84phAJ6m8WX5Ty2DfmW5pHNFiNWu9DTkzeUEZqx2jd mXYT/SEwjbe5gtwFY25a+USwsPCgH1Us0b18hE1xlqVQulKpBr3FaGdHJP+p8kq2aAMm 1fig== X-Gm-Message-State: AG10YOQ6iJEJoXX/gWYDtxmxgyTZK3BfX5GGejaavNu6UVziYV0sajIX0K6O7oCGH9XyecNoXoTd0mVO4Dupqw== MIME-Version: 1.0 X-Received: by 10.202.178.10 with SMTP id b10mr3239063oif.131.1454590102573; Thu, 04 Feb 2016 04:48:22 -0800 (PST) Received: by 10.76.154.106 with HTTP; Thu, 4 Feb 2016 04:48:22 -0800 (PST) Date: Thu, 4 Feb 2016 16:48:22 +0400 Message-ID: Subject: Multiple authentications for SFTP connection From: Keith Martin To: libssh2-devel@cool.haxx.se X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============1272073804==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============1272073804== Content-Type: multipart/alternative; boundary=001a113ce0165bb08c052af12697 --001a113ce0165bb08c052af12697 Content-Type: text/plain; charset=UTF-8 Hi, I'm trying to connect to a SFTP service which requires both username/password and public/private key authentication at the same time. I can connect using the command line SFTP, for example: sftp -o "IdentityFile=keyfile.txt" username@server.com Connecting to server.com... EFT Server Enterprise 7.1.5.3Enter passphrase for key 'keyfile.txt': Authenticated with partial success. Enter password: sftp> What I can't figure out is a way within libssh2 to perform both of these authentication steps. If I try either libssh2_userauth_publickey_frommemory or libssh2_userauth_password both of these return an immediate failure. Is there any way within libssh2 to get this form of double authentication? Regards, Keith. --001a113ce0165bb08c052af12697 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I'm trying to connect to a SFTP= service which requires both username/password and public/private key authe= ntication at the same time.

I can connect using th= e command line SFTP, for example:

sftp -o &qu= ot;IdentityFile=3Dkeyfile.txt" = username@server.com
Connecting to server.com...
EFT= Server Enterprise 7.1.5.3Enter passphrase for key 'keyfile.txt':
Authenticated with partial success.
Enter password:
sftp>

What I can't figure out i= s a way within libssh2 to perform both of these authentication steps. If I = try either=C2=A0libssh2_userauth_publickey_frommemory or=C2=A0libssh2_usera= uth_password both of these return an immediate failure.

Is there any way within libssh2 to get this form of double authentica= tion?

Regards,
Keith.

--001a113ce0165bb08c052af12697-- --===============1272073804== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============1272073804==-- From libssh2-devel-bounces@cool.haxx.se Thu Feb 4 15:39:48 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u14EdW0I003934; Thu, 4 Feb 2016 15:39:46 +0100 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u14EdTrj003923 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 4 Feb 2016 15:39:30 +0100 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E1B5A207A4; Thu, 4 Feb 2016 09:39:27 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 04 Feb 2016 09:39:27 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=z9GeRX123rwkLpr76/plZYHI9NI=; b=rMV3P Z5vKujVYewq21kEzwn72Ys/eCOIVcQ+L4ueEY2r1J6uat81j+JPcRvU6vQ7q0Biu 49wfii5V2ncnnm3XbMI7E2TRc7xLcWaptGpToIDNUn7ryMfLoCTMU1fwEZuO6laJ L01UACaOkPU3rQsoaJwxco2nerg3GNSUz+7Hwk= X-Sasl-enc: 5b66yDTcpOqq8LduCFVoNgEVS/PDLiiLx6BjRQKFEC1V 1454596767 Received: from [192.168.0.6] (cm56-156-173.liwest.at [86.56.156.173]) by mail.messagingengine.com (Postfix) with ESMTPA id 3C804C0001E; Thu, 4 Feb 2016 09:39:27 -0500 (EST) From: Jakob Egger Message-Id: <6AD067A2-4333-466A-96E5-818E623DC324@eggerapps.at> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Multiple authentications for SFTP connection Date: Thu, 4 Feb 2016 15:39:25 +0100 References: To: libssh2 development , Keith Martin In-Reply-To: X-Mailer: Apple Mail (2.3112) X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============0027220120==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============0027220120== Content-Type: multipart/alternative; boundary="Apple-Mail=_82E3CAAE-F9FC-4EFD-95C4-015420126443" --Apple-Mail=_82E3CAAE-F9FC-4EFD-95C4-015420126443 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes, you just need to do both -> first publickey, which will fail, and = then password or keyboard-interactive, which will succeed. The process is something like this: 1) check which auth methods are allowed using libssh2_userauth_list() 2) try to authenticate using one of the methods 3) if it fails, go back to (1) You should probably somehow keep track what you've tried to avoid an = infinite loop. Jakob >=20 > On 04 Feb 2016, at 13:48, Keith Martin wrote: >=20 > Hi, >=20 > I'm trying to connect to a SFTP service which requires both = username/password and public/private key authentication at the same = time. >=20 > I can connect using the command line SFTP, for example: >=20 > sftp -o "IdentityFile=3Dkeyfile.txt" username@server.com = > Connecting to server.com... > EFT Server Enterprise 7.1.5.3Enter passphrase for key 'keyfile.txt': > Authenticated with partial success. > Enter password: > sftp> >=20 > What I can't figure out is a way within libssh2 to perform both of = these authentication steps. If I try either = libssh2_userauth_publickey_frommemory or libssh2_userauth_password both = of these return an immediate failure. >=20 > Is there any way within libssh2 to get this form of double = authentication? >=20 > Regards, > Keith. >=20 > _______________________________________________ > libssh2-devel = http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --Apple-Mail=_82E3CAAE-F9FC-4EFD-95C4-015420126443 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes, you just need to do both -> first publickey, which = will fail, and then password or keyboard-interactive, which will = succeed.

The process = is something like this:

1) check which auth methods are allowed = using libssh2_userauth_list()
2) try to = authenticate using one of the methods
3) if it = fails, go back to (1)

You should probably somehow keep track what you've tried to = avoid an infinite loop.

Jakob


On 04 = Feb 2016, at 13:48, Keith Martin <kthmrtn24@gmail.com>= wrote:

Hi,

I'm trying to connect to a SFTP service which requires both = username/password and public/private key authentication at the same = time.

I can = connect using the command line SFTP, for example:
sftp -o = "IdentityFile=3Dkeyfile.txt" username@server.com
Connecting to server.com...
EFT Server Enterprise 7.1.5.3Enter passphrase for key = 'keyfile.txt':
Authenticated with partial = success.
Enter password:
sftp>

What I can't figure out is a way within libssh2 to perform = both of these authentication steps. If I try = either libssh2_userauth_publickey_frommemory = or libssh2_userauth_password both of these return an immediate = failure.

Is = there any way within libssh2 to get this form of double = authentication?

Regards,
Keith.

_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel<= br class=3D"">

= --Apple-Mail=_82E3CAAE-F9FC-4EFD-95C4-015420126443-- --===============0027220120== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============0027220120==-- From libssh2-devel-bounces@cool.haxx.se Thu Feb 4 16:05:02 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u14F4rPF025126; Thu, 4 Feb 2016 16:05:00 +0100 Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01:0:0:0:233]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u14F4pqh025031 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 4 Feb 2016 16:04:51 +0100 Received: by mail-ob0-x233.google.com with SMTP id ba1so67125785obb.3 for ; Thu, 04 Feb 2016 07:04:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=90WFd2uN5/lK4alFiAwetppos8fKIid0QGboi1Zzrtc=; b=YDisqFdO4O9d7jULbjMcxaaabBNYSCsa/8/njFr0NJFKK+JSDGZwNwxKkL24hcUiMH 5/joyUs73F17cn+J7prcfVtE6YTC8ucpPyCBN0yod4/4WYneX7VKGVtzEGKQPlvZm35T FBYVHdz3jqzsNJymd+cFOAvoa2jQuk0EqDKeeFnUoaOksz5p3I8jljAI8vDLrwKkhuxC py6xZSFLFl7eeohI4KwHlzy/DhYVwcrmSbeVfZbhCec5dwmWoBnHnywuKcCfjWAYbTzR 6o6BY4HDsnEoJi8zY0bWdWg1gmN0L080LdGHL/KrvRX5EpMqXS2OPXqjqLnRwgM4GPK4 Flcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=90WFd2uN5/lK4alFiAwetppos8fKIid0QGboi1Zzrtc=; b=Aez43AuYi08lobrEoSupiJR9cJ46DPLPY+bhY1cgr3zWFwc1LnA6eL8Bw+WqMSSdfT lYxk2gpsMVsG+Zwu0GJUqBk00x93qX52aLnFX/Ic6U8FiSsAAI2BkuCqpitw9Z6jlPQn Hwtw8kOKbHQV/1TYDZEqNCuDMSdKDohgWQbfY6uvG72wD6VodwFEkfSDlCCpfgx9f0Qt pntv4jJIh0klNoE3MYBxIjwqKAaaAcFZJSSfmOqNo0XB0pIrHsOs0R/asvtbBIbK2NiI yvV5m+Ed0xvEiO8cqaj4o5iVFVp7t8uzQy6q+xJJa6AAGGrZ5/K0KjVceb36cUnoKkPj vO9g== X-Gm-Message-State: AG10YOTbkbpBCKMtaokFg2abZWeIrTBKYVwqv5YOCo9sAYUe+dlVwUZpnY6P7xfuN6tNZYOc23SPeO7FobbKgw== MIME-Version: 1.0 X-Received: by 10.182.103.167 with SMTP id fx7mr7635062obb.36.1454598284974; Thu, 04 Feb 2016 07:04:44 -0800 (PST) Received: by 10.76.154.106 with HTTP; Thu, 4 Feb 2016 07:04:44 -0800 (PST) In-Reply-To: <6AD067A2-4333-466A-96E5-818E623DC324@eggerapps.at> References: <6AD067A2-4333-466A-96E5-818E623DC324@eggerapps.at> Date: Thu, 4 Feb 2016 19:04:44 +0400 Message-ID: Subject: Re: Multiple authentications for SFTP connection From: Keith Martin To: Jakob Egger X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Cc: libssh2 development Content-Type: multipart/mixed; boundary="===============0790377860==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============0790377860== Content-Type: multipart/alternative; boundary=089e011602f8112237052af30ea0 --089e011602f8112237052af30ea0 Content-Type: text/plain; charset=UTF-8 Ah, that was simpler than I thought it was going to be! Got it working now, thanks. Just try each method in turn until one succeeds, don't abort on the first failure. Thanks again. Regards, Keith. On Thu, Feb 4, 2016 at 6:39 PM, Jakob Egger wrote: > Yes, you just need to do both -> first publickey, which will fail, and > then password or keyboard-interactive, which will succeed. > > The process is something like this: > > 1) check which auth methods are allowed using libssh2_userauth_list() > 2) try to authenticate using one of the methods > 3) if it fails, go back to (1) > > You should probably somehow keep track what you've tried to avoid an > infinite loop. > > Jakob > > > On 04 Feb 2016, at 13:48, Keith Martin wrote: > > Hi, > > I'm trying to connect to a SFTP service which requires both > username/password and public/private key authentication at the same time. > > I can connect using the command line SFTP, for example: > > sftp -o "IdentityFile=keyfile.txt" username@server.com > Connecting to server.com... > EFT Server Enterprise 7.1.5.3Enter passphrase for key 'keyfile.txt': > Authenticated with partial success. > Enter password: > sftp> > > What I can't figure out is a way within libssh2 to perform both of these > authentication steps. If I try either libssh2_userauth_publickey_frommemory > or libssh2_userauth_password both of these return an immediate failure. > > Is there any way within libssh2 to get this form of double authentication? > > Regards, > Keith. > > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel > > > --089e011602f8112237052af30ea0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah, that was simpler than I thought it was going to be!
Got it working now, thanks. Just try each method in turn u= ntil one succeeds, don't abort on the first failure.

Thanks again.

Regards,
Keith.


On Thu, Feb 4, 2016 at 6:39 PM, Jakob Egger <jakob@eggerapps.at= > wrote:
Yes, you just need to do both -> first publickey, which wi= ll fail, and then password or keyboard-interactive, which will succeed.
The process is something like this:

1) check which auth methods are allowed using=C2=A0libssh2_userauth_list(= )
2) try to authenticate using one of the methods
3) if= it fails, go back to (1)

You should probably some= how keep track what you've tried to avoid an infinite loop.
<= br>
Jakob


On 04 Feb 2016, at 13:48, Keith Martin <kthmrtn24@gmail.com&= gt; wrote:

_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel


--089e011602f8112237052af30ea0-- --===============0790377860== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============0790377860==-- From libssh2-devel-bounces@cool.haxx.se Sat Feb 6 19:58:11 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u16IveIY011128; Sat, 6 Feb 2016 19:58:06 +0100 Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u16IvaMt011037 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 6 Feb 2016 19:57:38 +0100 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3pyNCk2QFtz3hjBh for ; Sat, 6 Feb 2016 19:57:38 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 3pyNCk1PL2zvh26 for ; Sat, 6 Feb 2016 19:57:38 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavisd-new, port 10024) with ESMTP id as-WPlookJLw for ; Sat, 6 Feb 2016 19:57:36 +0100 (CET) X-Auth-Info: Rcyj2cQHJfQdx4T5g7P3+RkhKxORu3dDjceN85DPARLuZr1+fySxYUGAqPDEb83n Received: from colibri.localdomain (ppp-93-104-109-87.dynamic.mnet-online.de [93.104.109.87]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA for ; Sat, 6 Feb 2016 19:57:36 +0100 (CET) Received: by colibri.localdomain (Postfix, from userid 501) id C75D362162; Sat, 6 Feb 2016 19:57:35 +0100 (CET) Date: Sat, 6 Feb 2016 19:57:35 +0100 From: Dan Fandrich To: libssh2-devel@cool.haxx.se Subject: Re: libssh2 hangs in curl testsuite Message-ID: <20160206185735.GA22429@coneharvesters.com> Mail-Followup-To: libssh2-devel@cool.haxx.se References: <20160121080411.GA24376@coneharvesters.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160121080411.GA24376@coneharvesters.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id u16IveIY011128 On Thu, Jan 21, 2016 at 09:04:11AM +0100, Dan Fandrich wrote: > I upgraded to the git libssh2 with GnuTLS 3.2.21 on x86 Linux a few days ago > for my curl autobuilds, and they've been hanging ever since on many libssh2 > tests (e.g. 609, 620, 626, 635, but I suspect it's a race condition on connect > and the actual test number doesn't make a difference). I haven't spent much > time looking into it yet, but a high proportion of the tests end up with the > CPU spinning at 100%. I've attached gdb in a couple of cases and the backtrace > either looks like this: > > #0 0xb7682ee8 in Loop () from /lib/libgcrypt.so.11 > #1 0x07c09aa4 in ?? () > #2 0xb76b8000 in ?? () from /lib/libgcrypt.so.11 > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > or like this: > > #0 0xb761661f in mul_n () from /lib/libgcrypt.so.11 > #1 0xb7616762 in mul_n () from /lib/libgcrypt.so.11 > #2 0xb761647a in mul_n () from /lib/libgcrypt.so.11 > #3 0xb761732d in _gcry_mpih_mul_karatsuba_case () from /lib/libgcrypt.so.11 > #4 0xb7613324 in mul_mod () from /lib/libgcrypt.so.11 > #5 0xb7613baa in _gcry_mpi_powm () from /lib/libgcrypt.so.11 > #6 0xb75c2d94 in gcry_mpi_powm () from /lib/libgcrypt.so.11 > #7 0xb765c3dd in diffie_hellman_sha256 (packet_type_init=, > packet_type_reply=, exchange_state=, midhash_len=, > midhash=, group_order=, p=, g=, > session=) at /home/build/src/libssh2/src/kex.c:757 > #8 kex_method_diffie_hellman_group_exchange_sha256_key_exchange (session=0x9d245f8, > key_state=0x9d31170) at /home/build/src/libssh2/src/kex.c:1657 > #9 0xb765dc6b in _libssh2_kex_exchange (session=0x9d245f8, reexchange=0, key_state=0x9d31164) > at /home/build/src/libssh2/src/kex.c:2542 > #10 0xb76647d2 in session_startup (sock=3, session=0x9d245f8) > at /home/build/src/libssh2/src/session.c:723 > #11 libssh2_session_handshake (session=0x9d245f8, sock=3) at /home/build/src/libssh2/src/session.c:801 > #12 0xb770c0d5 in ssh_statemach_act () from /tmp/tmp.95BPIzfHtd/build-29924/lib/.libs/libcurl.so.4 > #13 0xb770fcf5 in ssh_multi_statemach () from /tmp/tmp.95BPIzfHtd/build-29924/lib/.libs/libcurl.so.4 > #14 0xb76f04f3 in Curl_protocol_connecting () > from /tmp/tmp.95BPIzfHtd/build-29924/lib/.libs/libcurl.so.4 > #15 0xb7703d58 in multi_runsingle () from /tmp/tmp.95BPIzfHtd/build-29924/lib/.libs/libcurl.so.4 > #16 0xb770487c in curl_multi_perform () from /tmp/tmp.95BPIzfHtd/build-29924/lib/.libs/libcurl.so.4 > #17 0xb76fbfbc in curl_easy_perform () from /tmp/tmp.95BPIzfHtd/build-29924/lib/.libs/libcurl.so.4 > #18 0x080520f2 in operate_do () > #19 0x08053af3 in operate () > #20 0x080499d7 in main () > > The couple of times I caught this, everything from level #7 to the bottom was the same. > I'll try to get a chance to bisect the problem, but in any case, it's not quite > in a releasable state. I looked into this and the loop is happening within gcry_mpi_powm due to an invalid internal condition. I've brought it to the gcrypt devel mailing list. The code calling this is new in libssh2 (commit fc4a969a) but still, gcrypt shouldn't be hanging like this. >>> Dan _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Feb 11 16:14:06 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1BFDhUT008500; Thu, 11 Feb 2016 16:14:04 +0100 Received: from giant.haxx.se (dast@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1BFDfG2008365 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 11 Feb 2016 16:13:41 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id u1BFDfet008360 for ; Thu, 11 Feb 2016 16:13:41 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Thu, 11 Feb 2016 16:13:41 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: ping for release In-Reply-To: <56377A0C.8090103@dbyron.com> Message-ID: References: <56377A0C.8090103@dbyron.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id u1BFDhUT008500 On Mon, 2 Nov 2015, David Byron wrote: > Sorry to nag, but is the repo in a good state to release? Still hoping for > the large file stuff to get a little farther out in the world. I've merged the "fix SFTP" patches from the patient Jakob Egger into master now. I _think_ we might be in a decent shape for release now. If you disagree, please tell us why. Also, please get the latest from git and have a go at it to help us polish out the last few quirks before we ship. I have also been notified about a security problem that will get fixed and announced with the pending release. -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sun Feb 14 21:05:21 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1EK4sQt002225; Sun, 14 Feb 2016 21:05:18 +0100 Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09:0:0:0:235]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1EK4qPZ002056 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 14 Feb 2016 21:04:52 +0100 Received: by mail-wm0-x235.google.com with SMTP id g62so124944192wme.0 for ; Sun, 14 Feb 2016 12:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=oZUi+0FAS+WadrhFSCaYeTCHS4I/RQ+YhR7G/CthpQA=; b=LtdyGHLwI3y6s4+/dsm+sRhflahZCqdgYQsmTq9o8Dv2zoiLlrGOMAje86rdoRHL9A LwwH27LtndBCdbS31/LPiK4MnO1Y54UVwebcbMHBUO1Ga3c720ZlvCOcEel/v8i5kqR9 9KCns9NXCP+cKJ1p3oQVdD1HEw/Q7uTDekMEjzb0em0a0TbBLDCeQwyMLQ9htBifxTZz 3FciMyKjR8AqkMbWtRXOSmU+zzvEJBp+zhCxE5HTgE+OHgdZFlQoTgR/gbbYCq4ljF41 t6DbDvtMrBHqfntnT/i0+Jeu6XGxcrnYNrB6JZThMR2hP/ijAEYRLmcifq4eZlNsL1DT blCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=oZUi+0FAS+WadrhFSCaYeTCHS4I/RQ+YhR7G/CthpQA=; b=kOJCqerWW6Cvm4EhImkdPY3+dKQpVrLBMdcGX9cJtk0tX5k+6hw66n54QYqVXjlV9O Ohjy5Ibdj0o4eiys1wxqTLukowVAl8Ae5+nPKC5qyGWiHuJW9yTQl7bLBm3SHYnlU2se yk43QQE5qPzukolvSXD2KvvDtPsmP4EcdZno452TzIbh6Ne9q6j9Yi5zNrmOd7XpMl1R wzxgfymA2yC/g+km5IB85AyXpm/q7irIRErRoZU4Lvrj0JlpQUg1mHxygEqON1q99ZwK UPz45ztH5W4GaE+5yzfyIEJYmV4yAgF4QxD6erdiLJnloaca2xGBa0AkhNVADbrlN+eQ Tsxg== X-Gm-Message-State: AG10YOQU0wz9mYcDv5Vhu0PRME/BRMuKxZTkJsBtsv8OrUYXZvO82JTWcLv5TlQVt/OE4NqJmAYkZVa020nMZQ== MIME-Version: 1.0 X-Received: by 10.28.60.11 with SMTP id j11mr4057656wma.99.1455480289122; Sun, 14 Feb 2016 12:04:49 -0800 (PST) Received: by 10.28.132.9 with HTTP; Sun, 14 Feb 2016 12:04:49 -0800 (PST) In-Reply-To: References: <56377A0C.8090103@dbyron.com> Date: Sun, 14 Feb 2016 20:04:49 +0000 X-Google-Sender-Auth: ajSJtd9T5sgwIMJJSp4T00F2ykw Message-ID: Subject: Re: ping for release From: Alexander Lamaison To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id u1EK4sQt002225 On 11 February 2016 at 15:13, Daniel Stenberg wrote: > On Mon, 2 Nov 2015, David Byron wrote: > >> Sorry to nag, but is the repo in a good state to release? Still hoping >> for the large file stuff to get a little farther out in the world. > > > I've merged the "fix SFTP" patches from the patient Jakob Egger into master > now. I _think_ we might be in a decent shape for release now. > > If you disagree, please tell us why. Also, please get the latest from git > and have a go at it to help us polish out the last few quirks before we > ship. I've just tested the latest from master and, unfortunately, it doesn't compile with Visual Studio 2005. The new SFTP fix introduced uint64_t and uint32_t, which aren't in C90. Please hold off releasing for now. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sun Feb 14 23:39:03 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1EMcn4C029186; Sun, 14 Feb 2016 23:39:00 +0100 Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09:0:0:0:236]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1EMck8O029061 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 14 Feb 2016 23:38:47 +0100 Received: by mail-wm0-x236.google.com with SMTP id g62so86509561wme.0 for ; Sun, 14 Feb 2016 14:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=xBg+85JF5iJsNPU1l9TpRPvz6b8OicCbZGt9FXjN4AQ=; b=ZzHuAv9fvKenZ68WPkw8JQZIw0mFh4NRXDv88KCvkHqhdUWJdnmluvKD3yrw6syOGG ogIrdOgx8UhzLWVxPtCegiLtI7MefbjFoojiBsBRHNH72ugL/6fFQchMef2EjdmD65Xf EQuETXi9+8oT+YQ89EfNK2HmZcetiSIg2fRcSqgCTqUanwZTe8KpSDwtD+7rQzZX4NhW gFoEuKTnyF6t+FqqeJWGHVQiHOppqjVlfegQh/1z9ic0avx/DuSwxXefd8Aa4GmbSw5Y KVkSg2kyRMQpCQ8Ckd75IhNNhuH+KjPlCLNoHspApsgim3B1da47ODLXt7clW310xg4c D0sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=xBg+85JF5iJsNPU1l9TpRPvz6b8OicCbZGt9FXjN4AQ=; b=dN/7Ryunclmhlrf8Hsj0xp4H9woDMJPX8pXjfbT9ufRsGzB+obLzMt8MQOBEiHNGMj 5XrTknx2ZxHppz9igm7jy3ztFXxkyZbAqNuXqGcK8j8ZRI85SAOLm3aE95zASQbcAJLZ GYzp9wgPjpObrFnE4IZylnI2iiInmY6IAekWJR2yjuWn9DycdL9XzG/ffXAyQ/XUnSHa Twchlbu0ZQ3Z5g70sTDjgt1KtdPGbhSb7pyivj8G+QJvd1FnHdlax2LmbvJc/7xPXVFG LD23VPqfiONs21eU2AUC1IBJmGpYxk9ifv1vBTmE71h002KJDSj12Fc7faLu3tH1eCgG a9ww== X-Gm-Message-State: AG10YOSenWCi+mZFFrltLViMJAqvboD+yO7XDoSAa7D9eI72+1T5AmzliqJU5CW/bclC1YWYga1rt3RiOwHNiw== MIME-Version: 1.0 X-Received: by 10.194.89.70 with SMTP id bm6mr12557027wjb.0.1455489522822; Sun, 14 Feb 2016 14:38:42 -0800 (PST) Received: by 10.28.132.9 with HTTP; Sun, 14 Feb 2016 14:38:42 -0800 (PST) In-Reply-To: References: <56377A0C.8090103@dbyron.com> Date: Sun, 14 Feb 2016 22:38:42 +0000 X-Google-Sender-Auth: ONjHRVhMFSfkPRiiGWaKwPJPa1M Message-ID: Subject: Re: ping for release From: Alexander Lamaison To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id u1EMcn4C029186 On 14 February 2016 at 20:04, Alexander Lamaison wrote: > On 11 February 2016 at 15:13, Daniel Stenberg wrote: >> On Mon, 2 Nov 2015, David Byron wrote: >> >>> Sorry to nag, but is the repo in a good state to release? Still hoping >>> for the large file stuff to get a little farther out in the world. >> >> >> I've merged the "fix SFTP" patches from the patient Jakob Egger into master >> now. I _think_ we might be in a decent shape for release now. >> >> If you disagree, please tell us why. Also, please get the latest from git >> and have a go at it to help us polish out the last few quirks before we >> ship. > > I've just tested the latest from master and, unfortunately, it doesn't > compile with Visual Studio 2005. The new SFTP fix introduced uint64_t > and uint32_t, which aren't in C90. Please hold off releasing for now. I've pushed a fix for the build failure, and added more versions of VS to Appveyor so that we catch this automatically next time. It turned out that only uint64_t was problematic, because we define uint32_t to int. I've also finally resurrected my old test suite that was really good at catching SFTP stream errors. It confirmed that commit d754fee2f24565d8c89dc37a7f05ba1222a7bfc4 introduced data corruption, and that it has been fixed in latest master. So I think we're good to go for a release now. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Feb 16 18:43:38 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1GHhBYE032709; Tue, 16 Feb 2016 18:43:34 +0100 Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01:0:0:0:230]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1GHh9k7032677 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 16 Feb 2016 18:43:10 +0100 Received: by mail-ob0-x230.google.com with SMTP id gc3so168076295obb.3 for ; Tue, 16 Feb 2016 09:43:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oI0da2ClliSmPkrHhklunJyjleDh1DUiENIUmHtw4AI=; b=MFxhdmDNEype9MEbsurLGtrHHgWPQZN4YFaOswKvbOnb8w4BMiABJmyDQeNodZGKOA FZrw+TebmVwBouM3/WzYVtVEWorrHLblEBHfm8fKLpcbsfGgAGBf46goYq4UD7lpByRb DSQXGwKXBTFnCYtcBC+C7//WulKMH32pP3bdBKcZmcN468c9MwSX+KuiDLVQXvjWCkDx HxehODIgeOyOV4Hgc2VvhOyGK7SPy8SbGwhQ4dyBABq0UvSqHFy2cjM2Wyuk+4NvdaA+ epViL6juUoVq2j584BZh70/2JVukjCZwwfViLaj40KVXYdj5k6ZQ9IEi+coFpiJfKrYP Fezw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=oI0da2ClliSmPkrHhklunJyjleDh1DUiENIUmHtw4AI=; b=DQAsN9UZNxGYoMwkNSg0QQUT4w+5O88jXKD3ZeOgZMNsRyFL6izto20DOYQyC78GYp Ei05epNFEX5beqIOmWegjlX5QIjAe+veTgVYEG3s+9WX6ITG+ZN9V17aNMpjudm6jRK6 k3WTyTfneTl5tbYcKE/YsEh7uZTuPC2B9Qwhm1qclguXt97RLz9ZoEtN7CzeVgDZunmS BNr3YmekLz8NdXfhb3XjjOZfF+eCiM8axDmL1uy8+3PfaKCvPR9LEb8rUfisNd46H6ik +cIKk7ruRnlgjDPIF8P73lhgc2oL0DcQxEzstyQtLnv5avj23IuknRPOdnwd8amTdg/b 8vqg== X-Gm-Message-State: AG10YOTt4Rk95PlRac7L4YaR0JW0MWzJQK/EMozHeQnnlS46DjP8KOtvd1IlwqOphaV0UHIYkWCSztP+aRhiQA== MIME-Version: 1.0 X-Received: by 10.182.108.201 with SMTP id hm9mr14266474obb.16.1455644585131; Tue, 16 Feb 2016 09:43:05 -0800 (PST) Received: by 10.76.159.229 with HTTP; Tue, 16 Feb 2016 09:43:05 -0800 (PST) Date: Tue, 16 Feb 2016 19:43:05 +0200 Message-ID: Subject: Memory leak on mac From: Velichko Yuriy To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============1840675145==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============1840675145== Content-Type: multipart/alternative; boundary=089e0149d2986a8518052be6aad6 --089e0149d2986a8518052be6aad6 Content-Type: text/plain; charset=UTF-8 Hello! I have application, that among other things, checks accessibility of the remote machine by connecting over ssh. The app immediately disconnect when connection is confirmed. All works fine on Mac and Windows. But on mac the app takes more and more memory (on windows is all right). The instruments for XCode shows that memory is leak in function libssh2_default_alloc but I do not call this function directly anywhere. To release ssh handlers methods are used: libssh2_channel_free( ); libssh2_session_disconnect( ); libssh2_session_free( ); All of them works without errors. IMPOTANT NOTE: the leak occur when session works in non-blocking mode: libssh2_session_set_blocking( ..., 0); if to use libssh2_session_set_blocking( ..., 1); There is no leak. Tell me please what a difference. What I doing wrong? Or may be this is a little bug in libssh2? --089e0149d2986a8518052be6aad6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello!

I have= application, that among other things, checks accessibility of the remote m= achine by connecting over ssh. The app immediately disconnect when connecti= on is confirmed. All works fine on Mac and Windows. But on mac the app take= s more and more memory (on windows is all right). The instruments for XCode= shows that memory is leak in function=C2=A0

<= div class=3D"gmail_default" style=3D"">l= ibssh2_default_alloc

but I do not call this fu= nction directly anywhere.

To release ssh handl= ers methods are used:
<= font face=3D"verdana, sans-serif">
libssh2_channel_free( = =C2=A0); =C2=A0 =C2=A0
= libssh2_session_disconnect( =C2=A0);
libssh2_session_free( =C2=A0);

All of= them works without errors.

IMPOTANT NOTE: th= e leak occur when session works in non-blocking mode:

libssh2_session_set_blocking( ..., 0);

if to use =C2=A0

libssh2_session_set_blocking= ( ..., 1);

There is no leak.
Tell me please what a difference. What I doing wrong? Or may = be this is a little bug in libssh2?

--089e0149d2986a8518052be6aad6-- --===============1840675145== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============1840675145==-- From libssh2-devel-bounces@cool.haxx.se Tue Feb 16 18:52:43 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1GHqd77027461; Tue, 16 Feb 2016 18:52:43 +0100 Received: from mail.panic.com (posh.panic.com [38.103.165.4]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1GHqcng027441 for ; Tue, 16 Feb 2016 18:52:38 +0100 Received: from [10.0.0.189] (unknown [38.103.165.36]) by mail.panic.com (Postfix) with ESMTPSA id 044CDD091E4F for ; Tue, 16 Feb 2016 09:52:25 -0800 (PST) From: Will Cosgrove Message-Id: <4D8C0CA0-14E9-4E7D-8630-335B88966649@panic.com> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Memory leak on mac Date: Tue, 16 Feb 2016 09:52:34 -0800 References: To: libssh2 development In-Reply-To: X-Mailer: Apple Mail (2.3112) X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============1996682998==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============1996682998== Content-Type: multipart/alternative; boundary="Apple-Mail=_D9F62016-F452-46D6-8505-B06F523915BA" --Apple-Mail=_D9F62016-F452-46D6-8505-B06F523915BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You=E2=80=99ll need to post an example app showing this leak; I use = libssh2 on the Mac and have done extensive profiling and it does not = leak in my use cases. Will > On Feb 16, 2016, at 9:43 AM, Velichko Yuriy = wrote: >=20 > Hello! >=20 > I have application, that among other things, checks accessibility of = the remote machine by connecting over ssh. The app immediately = disconnect when connection is confirmed. All works fine on Mac and = Windows. But on mac the app takes more and more memory (on windows is = all right). The instruments for XCode shows that memory is leak in = function=20 >=20 > libssh2_default_alloc >=20 > but I do not call this function directly anywhere. >=20 > To release ssh handlers methods are used: >=20 > libssh2_channel_free( ); =20 > libssh2_session_disconnect( ); > libssh2_session_free( ); >=20 > All of them works without errors. >=20 > IMPOTANT NOTE: the leak occur when session works in non-blocking mode: >=20 > libssh2_session_set_blocking( ..., 0); >=20 > if to use =20 >=20 > libssh2_session_set_blocking( ..., 1); >=20 > There is no leak. >=20 > Tell me please what a difference. What I doing wrong? Or may be this = is a little bug in libssh2? >=20 > _______________________________________________ > libssh2-devel = http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --Apple-Mail=_D9F62016-F452-46D6-8505-B06F523915BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
You=E2=80=99ll need to post an example app = showing this leak; I use libssh2 on the Mac and have done extensive = profiling and it does not leak in my use cases.

Will

On Feb 16, 2016, at 9:43 AM, = Velichko Yuriy <velichko.yuriy@gmail.com> wrote:

Hello!

I have application, that among other things, checks = accessibility of the remote machine by connecting over ssh. The app = immediately disconnect when connection is confirmed. All works fine on = Mac and Windows. But on mac the app takes more and more memory (on = windows is all right). The instruments for XCode shows that memory is = leak in function 

libssh2_default_alloc

but I do not call this function = directly anywhere.

To release ssh handlers methods = are used:

libssh2_channel_free(  );    
libssh2_session_disconnect(  );
libssh2_session_free(  );

All of them = works without errors.

IMPOTANT NOTE: the leak occur = when session works in non-blocking mode:

libssh2_session_set_blocking( ..., 0);

if to use =  

libssh2_session_set_blocking( ..., 1);

There is no = leak.

Tell me please what a difference. What I doing wrong? Or may = be this is a little bug in libssh2?

_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel<= br class=3D"">

= --Apple-Mail=_D9F62016-F452-46D6-8505-B06F523915BA-- --===============1996682998== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============1996682998==-- From libssh2-devel-bounces@cool.haxx.se Tue Feb 16 19:18:25 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1GI5QH3026606; Tue, 16 Feb 2016 19:05:32 +0100 Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01:0:0:0:22b]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1GI5O7C026500 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 16 Feb 2016 19:05:25 +0100 Received: by mail-ob0-x22b.google.com with SMTP id xk3so269468768obc.2 for ; Tue, 16 Feb 2016 10:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Fvc8n1+aY5PYMLRA+1ssyJca7YeDx/qwlYqmvgjOYJQ=; b=ptggCTbFYFda5KYtg+AUVuHj0ZSOygFlHQjzh5SZqD0ahGUvlo1tbAZoQ3GsGf8QQA Oe+n+OtnJaZP5nda/qAiKM1ACzPg30JdklV39tx0iEzapaZyiyFUBG35yB18g5sQPmd1 OdNuEM/CHndfLX6j0ZJrPnorAbNGGqQEuUGTgAbFFUQyhzcVBadEfetWuHViq3WK7dn+ ziChdy6C1IysowrUqm5Fg+JvosDdMK7qsCdvplL5HVsFdpor1mJJwTYtcrQIqFFXXhUP jdC722KYM9HzfLJbYrC/HreUSdSttxlPd7g+/XjW1cVARC/1bwlJQCp82HwrD2/ZvynY wxrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Fvc8n1+aY5PYMLRA+1ssyJca7YeDx/qwlYqmvgjOYJQ=; b=ehk1TAICjftL/bb3HZbm6hxhIYB4at+9STPRJIDwwuAaU+3A39+WfE/yOcTznRceU1 hF2ong3+Yy0Qaj2/jHJm33mgYOpc/91sf1S/sf3Rkuf0y8qSULfmoD6MjEYJHnXi57sJ t0tmXM4q59lvPR8Jx7z8ov3tRmOIsicdLAjvq8H4jAQwz1aiusg+h7SlDp7oayXqncgD UHDkVKEtySJJKlz7cNU7blOiyocwIi6XgDfSwRWMQOoM+vY8JK4JsKz+t4wvuLGtH20A LKa578dS0LAcls1exY/llRSRk6/4CXbRyynvdRVBDfNWDEkmDrPkO0nidm0NYYGBdeEU EA2g== X-Gm-Message-State: AG10YOR6uQdDebtwRnHSuJF3K70SEGgOaB6qqwtDJPN4kVJOk8Wwok2I+r6tCEIwQ/2KUZqraMsqneA2hT0Mbg== MIME-Version: 1.0 X-Received: by 10.202.102.69 with SMTP id a66mr17636859oic.93.1455645902160; Tue, 16 Feb 2016 10:05:02 -0800 (PST) Received: by 10.76.159.229 with HTTP; Tue, 16 Feb 2016 10:05:02 -0800 (PST) In-Reply-To: <4D8C0CA0-14E9-4E7D-8630-335B88966649@panic.com> References: <4D8C0CA0-14E9-4E7D-8630-335B88966649@panic.com> Date: Tue, 16 Feb 2016 20:05:02 +0200 Message-ID: Subject: Re: Memory leak on mac From: Velichko Yuriy To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============1520937021==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============1520937021== Content-Type: multipart/alternative; boundary=001a1140f400eacd6c052be6f882 --001a1140f400eacd6c052be6f882 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I will create a simple example in nearest time. On 16 February 2016 at 19:52, Will Cosgrove wrote: > You=E2=80=99ll need to post an example app showing this leak; I use libss= h2 on the > Mac and have done extensive profiling and it does not leak in my use case= s. > > Will > > On Feb 16, 2016, at 9:43 AM, Velichko Yuriy > wrote: > > Hello! > > I have application, that among other things, checks accessibility of the > remote machine by connecting over ssh. The app immediately disconnect whe= n > connection is confirmed. All works fine on Mac and Windows. But on mac th= e > app takes more and more memory (on windows is all right). The instruments > for XCode shows that memory is leak in function > > libssh2_default_alloc > > but I do not call this function directly anywhere. > > To release ssh handlers methods are used: > > libssh2_channel_free( ); > libssh2_session_disconnect( ); > libssh2_session_free( ); > > All of them works without errors. > > IMPOTANT NOTE: the leak occur when session works in non-blocking mode: > > libssh2_session_set_blocking( ..., 0); > > if to use > > libssh2_session_set_blocking( ..., 1); > > There is no leak. > > Tell me please what a difference. What I doing wrong? Or may be this is a > little bug in libssh2? > > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel > > > > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel > > --=20 =E2=80=8B=D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0= =92=D0=B5=D0=BB=D0=B8=D1=87=D0=BA=D0=BE =D0=AE=D1=80=D0=B8=D0=B9. --001a1140f400eacd6c052be6f882 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I will create a simple example in nearest time.

On 16 February 2016 a= t 19:52, Will Cosgrove <will@panic.com> wrote:
You=E2=80=99ll n= eed to post an example app showing this leak; I use libssh2 on the Mac and = have done extensive profiling and it does not leak in my use cases.

Will

On Feb 16, 2016, at 9:43 AM, Velichko Yuriy <velichko.yuriy@gmail.com= > wrote:

Hello!

I have application, that among other= things, checks accessibility of the remote machine by connecting over ssh.= The app immediately disconnect when connection is confirmed. All works fin= e on Mac and Windows. But on mac the app takes more and more memory (on win= dows is all right). The instruments for XCode shows that memory is leak in = function=C2=A0

libssh2_default_alloc

but I do not call this f= unction directly anywhere.

<= font face=3D"verdana, sans-serif">To release ssh handlers methods are used:=
libssh2_channel_free( =C2=A0); =C2=A0 =C2=A0
libssh2_session_disco= nnect( =C2=A0);
libssh2_session_free( =C2=A0);

All of them works wi= thout errors.

IMPOTANT NOTE: the leak occur when session works in no= n-blocking mode:

libssh2_session_set_blocking( ..., 0);

if t= o use =C2=A0

libssh2_session_set_blocking( ..., 1);

There is = no leak.

Tell me please what a difference. What I doing wrong? Or ma= y be this is a little bug in libssh2?

_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel


_________________________________________= ______
libssh2-devel http://cool.haxx.se/cgi-bin/= mailman/listinfo/libssh2-devel




--
=E2=80=8B=D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5= =D0=BD=D0=B8=D0=B5=D0=BC, =D0=92=D0=B5=D0=BB=D0=B8=D1=87=D0=BA=D0=BE =D0=AE= =D1=80=D0=B8=D0=B9.
--001a1140f400eacd6c052be6f882-- --===============1520937021== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============1520937021==-- From libssh2-devel-bounces@cool.haxx.se Wed Feb 17 09:02:09 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1H81mfU021092; Wed, 17 Feb 2016 09:02:05 +0100 Received: from giant.haxx.se (dast@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1H81k1a021085 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 17 Feb 2016 09:01:46 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id u1H81kEk021080 for ; Wed, 17 Feb 2016 09:01:46 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Wed, 17 Feb 2016 09:01:46 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: ping for release In-Reply-To: Message-ID: References: <56377A0C.8090103@dbyron.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id u1H81mfU021092 On Sun, 14 Feb 2016, Alexander Lamaison wrote: > So I think we're good to go for a release now. I'm scheduling the release to happen on February 23. That is Tuesday next week. Gives us a few more days to run tests and if possible correct obvious bugs. The most recent packages found at http://libssh2.org/snapshots/ are then what the release will look like in case anyone wants to get a "release candidate" for a spin. -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Feb 17 11:23:56 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1HANfkr012927; Wed, 17 Feb 2016 11:23:54 +0100 Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07:0:0:0:229]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1HANc7D012812 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 17 Feb 2016 11:23:38 +0100 Received: by mail-lf0-x229.google.com with SMTP id l143so7621778lfe.2 for ; Wed, 17 Feb 2016 02:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yI5xKgSUFnmggQKNIlAAFfV9BIvfA/iTq82ThH20vlY=; b=eCH642XKVfBK3cAyg01fKoFCizHVw3SI5WNPsRRKSAbKlako7+FU2ACcfnSvP4QA0Q 7KAv64sKsUxJ3rQucXCee7GusIpZlmDmKO+4M9bVvEOC/BKrUKS4hSWhzd9FyoYoi1rF Gi3Qt4G59L08fA7FCyhJKDEYurFKC7hs11LSKM77/4Z0bPoJJ1JwMX/d4I83o6e1w33e 1ovKc++tizlkW6c4ue9Xj/00i1NjBdaIwPe+Ranr6DJ9HjhpGepUlin8/+MT5hm69p95 pNC89733FpA+puxptNRugCjGw0MzVaEHf5dDsERaTjtYBO6dNpmTb1rFi467I+XVAzbP X1lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=yI5xKgSUFnmggQKNIlAAFfV9BIvfA/iTq82ThH20vlY=; b=Ajj252D0/9J+C4iNvtdLG0cEoVkijtS75HY5pdjU4x3gP+Qwqf9q4LUJRMYkh4tm6s 2J+e3QDLo3ykCM2OwIw+EpxW2FWAu8ci9rDx4aEprueENSMKrCPbu8S8FgCXcqC1mq6h ueiWAuDXN79HDlatYtFnlZgFMBITm6rs6/7EPXh1SXS1aW8jVS/7YxxvwVTinve8uI+X /OjMS1FUXea+8aaczcp+n4NoNhBs/IKCGI1XsJ4FrvdBqEG+I9tQBHoWhgM5a+U0qE71 HXNMPh4gRoXpVTjimxPJgdpEDqyXjZyMkG+eTbP8PTAIyLr4kz51KXSLhpkj91tXtwx6 gO0A== X-Gm-Message-State: AG10YOSOveQ07DOdkQX5HQhaV0r1IcB5Lce1kP1xp782bUT4aSwTDXmQGFyLyXDCjYoqzz+nNnocVdzhAdoEiQ== MIME-Version: 1.0 X-Received: by 10.25.19.28 with SMTP id j28mr381275lfi.50.1455704614378; Wed, 17 Feb 2016 02:23:34 -0800 (PST) Received: by 10.25.32.140 with HTTP; Wed, 17 Feb 2016 02:23:34 -0800 (PST) Date: Wed, 17 Feb 2016 14:53:34 +0430 Message-ID: Subject: libssh2_channel_read() issue From: Amirul Islam To: libssh2-devel@cool.haxx.se X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============1442439245==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============1442439245== Content-Type: multipart/alternative; boundary=001a1140679270228b052bf4a494 --001a1140679270228b052bf4a494 Content-Type: text/plain; charset=UTF-8 Hi All, I am having an issue with the libssh2_channel_read() function. I am using it in blocking mode to download files from remote server. Now, I have an instance where the file I am trying to download, I do not have read permission. This is causing the read() function to return 0. I am not sure, if I should break my read loop when 0 is returned, since the documentation implies we should break when there is a negative value returned. I am not if breaking on 0 will have unpredictable behavior on other instances. need help Also, I can check the file mode when I call libssh2_scp_recv() function, what would be the best way to check if my user has read permission? Thank you in advance. -- "Fame is a vapor; popularity an accident; the only earthly certainty is oblivion." --001a1140679270228b052bf4a494 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

I am having an issue with the= =C2=A0libssh2_channel_read() function. I am using it in blocking mode to do= wnload files from remote server. Now, I have an instance where the file I a= m trying to download, I do not have read permission. This is causing the re= ad() function to return 0. I am not sure, if I should break my read loop wh= en 0 is returned, since the documentation implies we should break when ther= e is a negative value returned. I am not if breaking on 0 will have unpredi= ctable behavior on other instances. need help

Also= , I can check the file mode when I call=C2=A0libssh2_scp_recv() function, w= hat would be the best way to check if my user has read permission?

Thank you in advance.

--

"Fame is a vapor; popularity an accid= ent; the only earthly certainty is oblivion."
--001a1140679270228b052bf4a494-- --===============1442439245== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============1442439245==-- From libssh2-devel-bounces@cool.haxx.se Wed Feb 17 13:27:34 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1HCR9NZ009017; Wed, 17 Feb 2016 13:27:29 +0100 Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1HCR74F009005 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 17 Feb 2016 13:27:07 +0100 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id u1HCR7vx030362 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 17 Feb 2016 13:27:08 +0100 Received: from DEFTHW99ERJMSX.ww902.siemens.net (defthw99erjmsx.ww902.siemens.net [139.22.70.135]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id u1HCR7l1028406 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 17 Feb 2016 13:27:07 +0100 Received: from DENBGAT9ER2MSX.ww902.siemens.net (139.22.70.79) by DEFTHW99ERJMSX.ww902.siemens.net (139.22.70.135) with Microsoft SMTP Server (TLS) id 14.3.279.2; Wed, 17 Feb 2016 13:27:06 +0100 Received: from DEFTHW99EH2MSX.ww902.siemens.net ([169.254.12.145]) by DENBGAT9ER2MSX.ww902.siemens.net ([139.22.70.79]) with mapi id 14.03.0279.002; Wed, 17 Feb 2016 13:27:06 +0100 From: "Belau, Rene (ext)" To: libssh2 development Subject: AW: libssh2_channel_read() issue Thread-Topic: libssh2_channel_read() issue Thread-Index: AQHRaW3UtxBEFiraj0ip5LDkC1+xbZ8wJtZg Date: Wed, 17 Feb 2016 12:27:05 +0000 Message-ID: <16C23041BD880F48901C072C51AC6A2E02E72E8F@DEFTHW99EH2MSX.ww902.siemens.net> References: In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.31] MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============1006620125==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============1006620125== Content-Language: de-DE Content-Type: multipart/alternative; boundary="_000_16C23041BD880F48901C072C51AC6A2E02E72E8FDEFTHW99EH2MSXw_" --_000_16C23041BD880F48901C072C51AC6A2E02E72E8FDEFTHW99EH2MSXw_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IG5lZWQgdG8gZG8gYW4gb3BlcmF0aW9uIGFuZCB0aGVuIGNoZWNrIHNlc3Npb24gZXJyb3Iu DQoNCmxpYnNzaDJfc2NwX3JlY3YoKSAvL2hhbmRsZSBudWxsLCByZXR1cm4gLTM3DQpsaWJzc2gy X3Nlc3Npb25fbGFzdF9lcnJubygpIC8vZXJyb3IgLTI4IHNjcCBwcm90b2NvbCBlcnJvciAobGli c3NoMiB2ZXJzaW9uIDEuNS4wKSBpZiB5b3UgaGF2ZSBubyByaWdodHMgYXQgdGFyZ2V0IGRldmlj ZQ0KDQpsaWJzc2gyX2NoYW5uZWxfcmVhZCgpIC8vZ290IHdlIHNvbWUgYnl0ZXMgPw0KbGlic3No Ml9zZXNzaW9uX2xhc3RfZXJybm8oKSAvL3dpdGhvdXQgZXJyb3I/DQoNCmxpYnNzaDJfY2hhbm5l bF9yZWFkKCkgLT4gMCBieXRlcyA9PiBubyBwYXlsb2FkLCBpdCBpcyBub3QgYW4gZXJyb3IgLT4g bGlic3NoMiB0ZWxscyB1cyBpZiBpdCBpcyBlcnJvciAhIC0+IGxpYnNzaDJfc2Vzc2lvbl9sYXN0 X2Vycm5vKCkNCg0KDQpSZW5lDQoNClZvbjogbGlic3NoMi1kZXZlbCBbbWFpbHRvOmxpYnNzaDIt ZGV2ZWwtYm91bmNlc0Bjb29sLmhheHguc2VdIEltIEF1ZnRyYWcgdm9uIEFtaXJ1bCBJc2xhbQ0K R2VzZW5kZXQ6IE1pdHR3b2NoLCAxNy4gRmVicnVhciAyMDE2IDExOjI0DQpBbjogbGlic3NoMi1k ZXZlbEBjb29sLmhheHguc2UNCkJldHJlZmY6IGxpYnNzaDJfY2hhbm5lbF9yZWFkKCkgaXNzdWUN Cg0KSGkgQWxsLA0KDQpJIGFtIGhhdmluZyBhbiBpc3N1ZSB3aXRoIHRoZSBsaWJzc2gyX2NoYW5u ZWxfcmVhZCgpIGZ1bmN0aW9uLiBJIGFtIHVzaW5nIGl0IGluIGJsb2NraW5nIG1vZGUgdG8gZG93 bmxvYWQgZmlsZXMgZnJvbSByZW1vdGUgc2VydmVyLiBOb3csIEkgaGF2ZSBhbiBpbnN0YW5jZSB3 aGVyZSB0aGUgZmlsZSBJIGFtIHRyeWluZyB0byBkb3dubG9hZCwgSSBkbyBub3QgaGF2ZSByZWFk IHBlcm1pc3Npb24uIFRoaXMgaXMgY2F1c2luZyB0aGUgcmVhZCgpIGZ1bmN0aW9uIHRvIHJldHVy biAwLiBJIGFtIG5vdCBzdXJlLCBpZiBJIHNob3VsZCBicmVhayBteSByZWFkIGxvb3Agd2hlbiAw IGlzIHJldHVybmVkLCBzaW5jZSB0aGUgZG9jdW1lbnRhdGlvbiBpbXBsaWVzIHdlIHNob3VsZCBi cmVhayB3aGVuIHRoZXJlIGlzIGEgbmVnYXRpdmUgdmFsdWUgcmV0dXJuZWQuIEkgYW0gbm90IGlm IGJyZWFraW5nIG9uIDAgd2lsbCBoYXZlIHVucHJlZGljdGFibGUgYmVoYXZpb3Igb24gb3RoZXIg aW5zdGFuY2VzLiBuZWVkIGhlbHANCg0KQWxzbywgSSBjYW4gY2hlY2sgdGhlIGZpbGUgbW9kZSB3 aGVuIEkgY2FsbCBsaWJzc2gyX3NjcF9yZWN2KCkgZnVuY3Rpb24sIHdoYXQgd291bGQgYmUgdGhl IGJlc3Qgd2F5IHRvIGNoZWNrIGlmIG15IHVzZXIgaGFzIHJlYWQgcGVybWlzc2lvbj8NCg0KVGhh bmsgeW91IGluIGFkdmFuY2UuDQoNCi0tDQoNCiJGYW1lIGlzIGEgdmFwb3I7IHBvcHVsYXJpdHkg YW4gYWNjaWRlbnQ7IHRoZSBvbmx5IGVhcnRobHkgY2VydGFpbnR5IGlzIG9ibGl2aW9uLiINCg== --_000_16C23041BD880F48901C072C51AC6A2E02E72E8FDEFTHW99EH2MSXw_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkUtTWFp bEZvcm1hdHZvcmxhZ2UxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJERSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllvdSBuZWVkIHRvIGRvIGFuIG9wZXJhdGlvbiBhbmQgdGhl biBjaGVjayBzZXNzaW9uIGVycm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+ PHNwYW4gbGFuZz0iRU4tVVMiPmxpYnNzaDJfc2NwX3JlY3YoKSAvL2hhbmRsZSBudWxsLCByZXR1 cm4gLTM3PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjkuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGU7 bXNvLWhpZ2hsaWdodDp3aGl0ZTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+bGlic3NoMl9z ZXNzaW9uX2xhc3RfZXJybm88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6OS41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPigpDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPi8vZXJyb3IgLTI4IHNj cCBwcm90b2NvbCBlcnJvciAobGlic3NoMiB2ZXJzaW9uIDEuNS4wKTwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4gaWYgeW91IGhhdmUg bm8gcmlnaHRzIGF0IHRhcmdldCBkZXZpY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5v bmUiPjxzcGFuIGxhbmc9IkVOLVVTIj5saWJzc2gyX2NoYW5uZWxfcmVhZCgpIC8vZ290IHdlIHNv bWUgYnl0ZXMgPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6 d2hpdGU7bXNvLWhpZ2hsaWdodDp3aGl0ZTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+bGli c3NoMl9zZXNzaW9uX2xhc3RfZXJybm88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPigpDQogLy93aXRob3V0IGVycm9yPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTpDb25z b2xhcztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3Nw YWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIj5saWJzc2gyX2NoYW5uZWxfcmVhZCgpIC0mZ3Q7 IDAgYnl0ZXMgPSZndDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpncmVlbjtiYWNrZ3JvdW5kOndoaXRl O21zby1oaWdobGlnaHQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPm5vIHBheWxv YWQsIGl0IGlzIG5vdCBhbiBlcnJvciAtJmd0OyBsaWJzc2gyIHRlbGxzIHVzIGlmIGl0IGlzIGVy cm9yICENCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjpncmVlbjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+LSZndDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjVw dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlO21zby1o aWdobGlnaHQ6d2hpdGU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPmxpYnNzaDJfc2Vzc2lv bl9sYXN0X2Vycm5vPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjku NXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj4oKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTo5LjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZW5lPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Wb246PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IGxpYnNzaDItZGV2ZWwgW21haWx0bzpsaWJzc2gyLWRldmVsLWJvdW5jZXNAY29vbC5oYXh4 LnNlXQ0KPGI+SW0gQXVmdHJhZyB2b24gPC9iPkFtaXJ1bCBJc2xhbTxicj4NCjxiPkdlc2VuZGV0 OjwvYj4gTWl0dHdvY2gsIDE3LiBGZWJydWFyIDIwMTYgMTE6MjQ8YnI+DQo8Yj5Bbjo8L2I+IGxp YnNzaDItZGV2ZWxAY29vbC5oYXh4LnNlPGJyPg0KPGI+QmV0cmVmZjo8L2I+IGxpYnNzaDJfY2hh bm5lbF9yZWFkKCkgaXNzdWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I aSBBbGwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFt IGhhdmluZyBhbiBpc3N1ZSB3aXRoIHRoZSZuYnNwO2xpYnNzaDJfY2hhbm5lbF9yZWFkKCkgZnVu Y3Rpb24uIEkgYW0gdXNpbmcgaXQgaW4gYmxvY2tpbmcgbW9kZSB0byBkb3dubG9hZCBmaWxlcyBm cm9tIHJlbW90ZSBzZXJ2ZXIuIE5vdywgSSBoYXZlIGFuIGluc3RhbmNlIHdoZXJlIHRoZSBmaWxl IEkgYW0gdHJ5aW5nIHRvIGRvd25sb2FkLCBJIGRvIG5vdCBoYXZlIHJlYWQgcGVybWlzc2lvbi4g VGhpcyBpcyBjYXVzaW5nDQogdGhlIHJlYWQoKSBmdW5jdGlvbiB0byByZXR1cm4gMC4gSSBhbSBu b3Qgc3VyZSwgaWYgSSBzaG91bGQgYnJlYWsgbXkgcmVhZCBsb29wIHdoZW4gMCBpcyByZXR1cm5l ZCwgc2luY2UgdGhlIGRvY3VtZW50YXRpb24gaW1wbGllcyB3ZSBzaG91bGQgYnJlYWsgd2hlbiB0 aGVyZSBpcyBhIG5lZ2F0aXZlIHZhbHVlIHJldHVybmVkLiBJIGFtIG5vdCBpZiBicmVha2luZyBv biAwIHdpbGwgaGF2ZSB1bnByZWRpY3RhYmxlIGJlaGF2aW9yIG9uIG90aGVyDQogaW5zdGFuY2Vz LiBuZWVkIGhlbHA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QWxzbywgSSBjYW4gY2hlY2sgdGhlIGZpbGUgbW9kZSB3aGVuIEkgY2FsbCZuYnNw O2xpYnNzaDJfc2NwX3JlY3YoKSBmdW5jdGlvbiwgd2hhdCB3b3VsZCBiZSB0aGUgYmVzdCB3YXkg dG8gY2hlY2sgaWYgbXkgdXNlciBoYXMgcmVhZCBwZXJtaXNzaW9uPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgaW4gYWR2YW5j ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ JnF1b3Q7RmFtZSBpcyBhIHZhcG9yOyBwb3B1bGFyaXR5IGFuIGFjY2lkZW50OyB0aGUgb25seSBl YXJ0aGx5IGNlcnRhaW50eSBpcyBvYmxpdmlvbi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_16C23041BD880F48901C072C51AC6A2E02E72E8FDEFTHW99EH2MSXw_-- --===============1006620125== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============1006620125==-- From libssh2-devel-bounces@cool.haxx.se Wed Feb 17 14:14:08 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1HDE0Jh020221; Wed, 17 Feb 2016 14:14:07 +0100 Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04:0:0:0:234]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1HDDxq1020199 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 17 Feb 2016 14:13:59 +0100 Received: by mail-lb0-x234.google.com with SMTP id x1so9117770lbj.3 for ; Wed, 17 Feb 2016 05:14:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zaBcNE6RIgX3R5VEAMU975L/MdRJN2HksN2h/AVX8eo=; b=u1GHUWYNNQE2uUTQiQhZTbxydmbfZl01WvzHU9X0uQPYblEICRBR8seyaj3eu8XfBm mduHCoicBsTAp1T1q2ezpIsLimMqEuDongjh+3fEI6xEXkdMSkboMKULQMSx+ilTawiM 1euzRtwWGR684SpNhH6Pm3KBGQjZVCxWi4MqeM4MGR6GFp5qggz7pwzID8mTRyzsRqk2 MEPDvsOxICza1Bw6QIoXF+LpePh/8IhZDJp6R798utVlB20qQMKLZ9H9jmnDODhJzrZP RrDUY0zupvEfccSC/ILGCWI6GcDhFtkV2SsU7fwatWse7Tga88wV9ulbPVQrSnAGdxg6 BnVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zaBcNE6RIgX3R5VEAMU975L/MdRJN2HksN2h/AVX8eo=; b=Y4ASzXygq73oal34DtvYKXfCAdPiQVNQAKpwl/SRwqwn1VImjeIEKsCvZhPVsP8nbF TdlevjbbKSteeO9N4LIE3PGi0Ye/qNl7rQ+cp6Fluw9t5TLUx4TPln2Mt9J7BsJPe3f3 6k+y083VovTbHFi0C0U8IV9rJGuvjdWC3XOnut1V0Hm3T5oS2Byn0LT7jwuoh7SWOz4P +X/e0Oz8fmrEFcGDYJWEPSnU2sO+pdQm4kHg8SA8Ec4KRGiLumqF6Z9K/jpARNKvvZKL ZHiPY8aHWpzbxflphtGLC1LoRPyRAYsOhaF9PiFbMDpsEBHi3T97xodqckolGB4aSYDT GtbQ== X-Gm-Message-State: AG10YOST0UVlA9vsU+KZXAo3zQFsUZrzp8ADnnmQxdLcujZxcfexhcGm2eZiaNcnTIi02z8cHmp99SpXRsMcAg== MIME-Version: 1.0 X-Received: by 10.112.16.168 with SMTP id h8mr711071lbd.90.1455714835038; Wed, 17 Feb 2016 05:13:55 -0800 (PST) Received: by 10.25.32.140 with HTTP; Wed, 17 Feb 2016 05:13:54 -0800 (PST) In-Reply-To: <16C23041BD880F48901C072C51AC6A2E02E72E8F@DEFTHW99EH2MSX.ww902.siemens.net> References: <16C23041BD880F48901C072C51AC6A2E02E72E8F@DEFTHW99EH2MSX.ww902.siemens.net> Date: Wed, 17 Feb 2016 17:43:54 +0430 Message-ID: Subject: Re: libssh2_channel_read() issue From: Amirul Islam To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============0665591884==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============0665591884== Content-Type: multipart/alternative; boundary=001a11c3acb2a30ab1052bf7051d --001a11c3acb2a30ab1052bf7051d Content-Type: text/plain; charset=UTF-8 Hi Rene, I have checked for last errno on both cases when libssh2_scp_recv() & libssh2_channel_read() is called, libssh2_session_last_errno() return 0. The issues is that my user has access to the remote folder, but does not have read permission on the target file which is contained in that folder. So the return value from libssh2_channel_read() is always 0 and sb.st_size is 1. you can simulate and check what you get On Wed, Feb 17, 2016 at 4:57 PM, Belau, Rene (ext) < belau.rene.ext@siemens.com> wrote: > You need to do an operation and then check session error. > > > > libssh2_scp_recv() //handle null, return -37 > > libssh2_session_last_errno() //error -28 scp protocol error (libssh2 > version 1.5.0) if you have no rights at target device > > > > libssh2_channel_read() //got we some bytes ? > > libssh2_session_last_errno() //without error? > > > > libssh2_channel_read() -> 0 bytes => no payload, it is not an error -> > libssh2 tells us if it is error ! -> libssh2_session_last_errno() > > > > > > Rene > > > > *Von:* libssh2-devel [mailto:libssh2-devel-bounces@cool.haxx.se] *Im > Auftrag von *Amirul Islam > *Gesendet:* Mittwoch, 17. Februar 2016 11:24 > *An:* libssh2-devel@cool.haxx.se > *Betreff:* libssh2_channel_read() issue > > > > Hi All, > > > > I am having an issue with the libssh2_channel_read() function. I am using > it in blocking mode to download files from remote server. Now, I have an > instance where the file I am trying to download, I do not have read > permission. This is causing the read() function to return 0. I am not sure, > if I should break my read loop when 0 is returned, since the documentation > implies we should break when there is a negative value returned. I am not > if breaking on 0 will have unpredictable behavior on other instances. need > help > > > > Also, I can check the file mode when I call libssh2_scp_recv() function, > what would be the best way to check if my user has read permission? > > > > Thank you in advance. > > > > -- > > > > "Fame is a vapor; popularity an accident; the only earthly certainty is > oblivion." > > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel > > -- "Fame is a vapor; popularity an accident; the only earthly certainty is oblivion." --001a11c3acb2a30ab1052bf7051d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Rene,

I have checked for last errno = on both cases when libssh2_scp_recv() & libssh2_channel_read() is calle= d, libssh2_session_last_errno() return 0. The issues is that my user has ac= cess to the remote folder, but does not have read permission on the target = file which is contained in that folder. So the return value from=C2=A0libss= h2_channel_read() is always 0 and sb.st_size is 1.

you can simulate and check what you get

On Wed, Feb 17, 2016 at 4:57 PM, Belau, = Rene (ext) <belau.rene.ext@siemens.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

You need to do an operation and then check session error.=

=C2=A0

l= ibssh2_scp_recv() //handle null, return -37

= libssh2_session_last_errno() //error -28 scp protocol error (libssh2 version= 1.5.0) if you have no right= s at target device

=C2=A0

l= ibssh2_channel_read() //got we some bytes ?

= libssh2_session_last_errno() //without error?

=C2=A0<= /u>

l= ibssh2_channel_read() -> 0 bytes =3D> no payload, it is not an error -> libssh2 t= ells us if it is error ! -> libssh2_session_last_errno()

=C2=A0<= /u>

=C2=A0

Rene

=C2=A0

Von: libssh2-d= evel [mailto:libssh2-devel-bounces@cool.haxx.se] Im Auftrag von Amirul Islam
Gesendet: Mittwoch, 17. Februar 2016 11:24
An: = libssh2-devel@cool.haxx.se
Betreff: libssh2_channel_read() issue

<= div class=3D"h5">

=C2=A0

Hi All,

=C2=A0

I am having an issue with the=C2=A0libssh2_channel_r= ead() function. I am using it in blocking mode to download files from remot= e server. Now, I have an instance where the file I am trying to download, I= do not have read permission. This is causing the read() function to return 0. I am not sure, if I should break my read = loop when 0 is returned, since the documentation implies we should break wh= en there is a negative value returned. I am not if breaking on 0 will have = unpredictable behavior on other instances. need help

=C2=A0

Also, I can check the file mode when I call=C2=A0lib= ssh2_scp_recv() function, what would be the best way to check if my user ha= s read permission?

=C2=A0

Thank you in advance.

=C2=A0

--

=C2=A0

"Fame is a vapor; popularity an accident; the o= nly earthly certainty is oblivion."


_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/= mailman/listinfo/libssh2-devel




--

"Fame is a vapo= r; popularity an accident; the only earthly certainty is oblivion."
--001a11c3acb2a30ab1052bf7051d-- --===============0665591884== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============0665591884==-- From libssh2-devel-bounces@cool.haxx.se Wed Feb 17 15:04:33 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1HE4J1v030007; Wed, 17 Feb 2016 15:04:31 +0100 Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01:0:0:0:235]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1HE4G5M029910 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 17 Feb 2016 15:04:16 +0100 Received: by mail-ob0-x235.google.com with SMTP id xk3so14995873obc.2 for ; Wed, 17 Feb 2016 06:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=wM8JaNp1G077mL2sNviSurfDYbOEw5W76CfYDXPXfM0=; b=M/yIqKvwlDZMeE+5VegyZVZ+sorKpk4fiCDQU1Hz5TNa68eURAVbv7ddrQzXQB2Wdq geyanLU3IcowWgXIfpGApOyCtow1c7cJ/nXQ9l/6/TXqABCBRe5r90B8J1NvBuiGyTlG sM4hUj6/VCpVqh5BLWvJMzt2t3O5GC2HiSjsvqnfyAdym8byo6bxryt/3ptlBFCQHHt4 SR7bju6ywTfs2ywYCCbNJoTogIbXLx1GvDqqcoNs0cI5xAPbKd195DX8592DD108k0Mn 9g4+ctNORZ7HVmbPUhNe/xixmOpr8QKmnFNUHDq00x7kCE4RppjQba4rgs9WVahU3j4l TBGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=wM8JaNp1G077mL2sNviSurfDYbOEw5W76CfYDXPXfM0=; b=TRwmCbDGNZyVNNV15tL0fCXt7AHymwlt8878eq3/N0AE8mk8kd68+kTfB9ChqiajaW KQNJzpI1qtwpxzeoz2q8LtY2C1TEfW6Mx/r+7GSNI5lQ1c6sDEfA+vTsb3sXPvk0VgWS rOqdtnf4z07fj6prQYRtig8atVFbUT9poOKdQ1sldI4S2X6NCbF3FEf+2bVeLUwjpd7W LqS3f3zvVeW8NWuoEpY48QPZRodbH9piaXLr6ekl6dObkNu40jEZMFHK2Si1jfOUSY39 qJi5G8h2rl1Tx02xdyqt1ODvIQGqTQun5alPE15/8gLdTSMJgrXrUsRBfO7mV4w1cTrZ fLLQ== X-Gm-Message-State: AG10YOSOfC23Z/NWCclyxpj3mJeFv7E0Re1afcNXPG4i7J8qcxFGG/QPmssfcl9VzHm+1BkOhS62Auq11IQzlA== MIME-Version: 1.0 X-Received: by 10.182.48.130 with SMTP id l2mr1375843obn.49.1455717850066; Wed, 17 Feb 2016 06:04:10 -0800 (PST) Received: by 10.76.159.229 with HTTP; Wed, 17 Feb 2016 06:04:06 -0800 (PST) In-Reply-To: References: <4D8C0CA0-14E9-4E7D-8630-335B88966649@panic.com> Date: Wed, 17 Feb 2016 16:04:06 +0200 Message-ID: Subject: Re: Memory leak on mac From: Velichko Yuriy To: libssh2 development Content-Type: multipart/mixed; boundary=089e0160b3dc684f95052bf7b97b X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --089e0160b3dc684f95052bf7b97b Content-Type: multipart/alternative; boundary=089e0160b3dc684f91052bf7b979 --089e0160b3dc684f91052bf7b979 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In the attached archive an example based on libssh2 docs: http://www.libssh2.org/examples/tcpip-forward.html In the attached code the port forwarding is implemented. In the infinity loop we preforms port forwarding of the PostgreSQL port on the remote computer. In the end of the loop all resources are freeing. But memory increases constantly. I think that I'm doing something wrong. Tell me please what exactly? ) On 16 February 2016 at 20:05, Velichko Yuriy wrote: > I will create a simple example in nearest time. > > On 16 February 2016 at 19:52, Will Cosgrove wrote: > >> You=E2=80=99ll need to post an example app showing this leak; I use libs= sh2 on >> the Mac and have done extensive profiling and it does not leak in my use >> cases. >> >> Will >> >> On Feb 16, 2016, at 9:43 AM, Velichko Yuriy >> wrote: >> >> Hello! >> >> I have application, that among other things, checks accessibility of the >> remote machine by connecting over ssh. The app immediately disconnect wh= en >> connection is confirmed. All works fine on Mac and Windows. But on mac t= he >> app takes more and more memory (on windows is all right). The instrument= s >> for XCode shows that memory is leak in function >> >> libssh2_default_alloc >> >> but I do not call this function directly anywhere. >> >> To release ssh handlers methods are used: >> >> libssh2_channel_free( ); >> libssh2_session_disconnect( ); >> libssh2_session_free( ); >> >> All of them works without errors. >> >> IMPOTANT NOTE: the leak occur when session works in non-blocking mode: >> >> libssh2_session_set_blocking( ..., 0); >> >> if to use >> >> libssh2_session_set_blocking( ..., 1); >> >> There is no leak. >> >> Tell me please what a difference. What I doing wrong? Or may be this is = a >> little bug in libssh2? >> >> _______________________________________________ >> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel >> >> >> >> _______________________________________________ >> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel >> >> > > > -- > =E2=80=8B=D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, = =D0=92=D0=B5=D0=BB=D0=B8=D1=87=D0=BA=D0=BE =D0=AE=D1=80=D0=B8=D0=B9. > --=20 =E2=80=8B=D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0= =92=D0=B5=D0=BB=D0=B8=D1=87=D0=BA=D0=BE =D0=AE=D1=80=D0=B8=D0=B9. --089e0160b3dc684f91052bf7b979 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In the attached archive an example based on libssh2 docs:
=

<= /div>
http://= www.libssh2.org/examples/tcpip-forward.html

In the attached code the por= t forwarding is implemented. In the infinity loop we preforms port forwardi= ng of the PostgreSQL port on the remote computer. In the end of the loop al= l resources are freeing.=C2=A0

But memory increases con= stantly.

I think that I'm doing something wrong. T= ell me please what exactly? )

On 16 February 2016 at 20:05, Velichko Yuriy <velichko.yuriy@gmail.com> wrote:
I will create a simple example in nearest time.
<= /div>

On 16 February 2016 at 19:52, Will Cosgrove &l= t;will@panic.com>= ; wrote:
You=E2=80=99ll need to p= ost an example app showing this leak; I use libssh2 on the Mac and have don= e extensive profiling and it does not leak in my use cases.

<= /div>
Will

On Fe= b 16, 2016, at 9:43 AM, Velichko Yuriy <velichko.yuriy@gmail.com> wrote:
=
Hello!

I have application, that among other things, checks accessibility of the= remote machine by connecting over ssh. The app immediately disconnect when= connection is confirmed. All works fine on Mac and Windows. But on mac the= app takes more and more memory (on windows is all right). The instruments = for XCode shows that memory is leak in function=C2=A0

libssh2_defaul= t_alloc

but I do not call this function directly anywhere.

To= release ssh handlers methods are used:

libssh2_channel_free( =C2=A0= ); =C2=A0 =C2=A0
libssh2_session_disconnect( =C2=A0);
libssh2_session_fre= e( =C2=A0);

All of them works without errors.

IMPOTANT NOTE: = the leak occur when session works in non-blocking mode:

<= div class=3D"gmail_default">libssh2_sess= ion_set_blocking( ..., 0);

<= font face=3D"verdana, sans-serif">if to use =C2=A0

libssh2_session= _set_blocking( ..., 1);

There is no leak.

Tell me please what= a difference. What I doing wrong? Or may be this is a little bug in libssh= 2?

_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel


_____________________________= __________________
libssh2-devel http://cool.haxx.se/cgi-bin/= mailman/listinfo/libssh2-devel


<= br clear=3D"all">

--
=E2=80=8B=D0=A1 =D1=83=D0= =B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0=92=D0=B5=D0=BB=D0=B8=D1= =87=D0=BA=D0=BE =D0=AE=D1=80=D0=B8=D0=B9.


--
=E2=80=8B=D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0= =BD=D0=B8=D0=B5=D0=BC, =D0=92=D0=B5=D0=BB=D0=B8=D1=87=D0=BA=D0=BE =D0=AE=D1= =80=D0=B8=D0=B9.
--089e0160b3dc684f91052bf7b979-- --089e0160b3dc684f95052bf7b97b Content-Type: application/zip; name="main.cpp.zip" Content-Disposition: attachment; filename="main.cpp.zip" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ikqwqfvw0 UEsDBBQACAAIAJh+UUgAAAAAAAAAAAAAAAAIABAAbWFpbi5jcHBVWAwAMXvEVi97xFb1ARQArVl7 U9tIEv+fTzEhFVYmwmBnby8Xkq3ygnO4lhgKk83lcimVkEZ4CllSzYzseO/y3a97JFkz0vgBGyWA PY9+92+6R89ZEsR5SMl+zO6EmPa9IE0idt+d7u89r+belnPd6a97MBqFNCKfRuNXfW3JgiVhuhC4 xBgUafDQb4yKvgwylqlRGguqzYmlOMYtVJp7EioZ/ByzxBz3eeYf44w5jGQkm9GCRRKyaE+bjYJE xuYGynmSNmjIkJVDSuOLwR9Db3J7fjn6zbsw14F9NE76+o/jEWwx1ucJgy3GekPsZUZFi+3niTcZ Xg7Pbk3WaC0a00CaikYJ7hyNB+fnN974ajzcew4DYCZ9jDgs8fww5J7sHPVWu8H/QpJg6nNy+ECX EYtpj7wj+8fTdEaPc0F54sOHLgTEMQs9Lvxult/tn9o29jdvbGyqluAmwtNUNuYzX4hFykOcL6eN edg+p9xjGS7o/aPf7f3yutvr9nrNhZzOUkm9GPxAk2kK47AhTgM/xi/7p+T4kHAq0nhOQ3K3JHJK SUGcHB7vsUSSksLCT2SWctz/t59f9U/1uYI6zja4K0ZeSIUsJe3/vXsC/1BM3F/Pl6T7QHiPJvmM /HePwDP4eHtRePAdOXHroevBZPLp6uZcH/r42+Xo7Pfh573vQAOpz3yWOPjB5/eBW4oEn+dfvnb2 CvqLKbjOIT3SUV+LQXyUdrCJucTP5RTYr0Q5XS0SkueBJJjEKrhYQgRLtHmYiGniSRyGD0BFsD9p GjnwvVOv000GoXtPecZBAG3BKmhQGDR3PQc5Oplc9CFnJpPR1RhjQwiWJu0Vl5Cfw/HwBvyiHAY+ fkfGHy8v20vPLgbj8fCSHALnJKFxa2EUeoJK+CNa5kAwmvsxkXNtCvUGO4ARXLLgDc3u8uhL75dX r3/+Wk+oDwYAVzOTK/DyrTIuiDUa/zG4HJ17xahLopQvfB5aZ2vqnyaD88HtgCyEH/rSPzX8DgDZ kAMfGAWCsHEifS7zzPkw+H2IMej03ZOOSw5KWppfWUQc3PYMgrejBZcyoHIxRIIMYYlL9mvKJPIh KkOyYBB4MJnyN+RF+J9k38VvGn18OJU5T0ivHv1emE6dNrpapUmOek0jHZWbK1hsqc4DWFUdmixh kjgnHYuJUF9Yu0FdUutb0iNIj/kx+9OXELWV7s6LsKM05sGOChuSAKqdpRC4GI4pgZDWQK1aU2pf HMHO9XtvNMYAwlCBs+9mOPjgktH19c3V7ZV3e3ZdimENSVS8INcMua1uL/UFKdMMEKKQ5hmoblf7 aJujNUmOek3umYomZ7/g8ggWKjBaVgYU68KPF/kzFi8RIwsjmhmgn8MglVPtQsjsCvUHtmJhoz47 q7Ot01kn/2rxziro4pZnzVQC7Dr9fiNhgyJulBVdjFcD4w87zgGCt2uwrTkU6N46F0CTnUCgjoZS jMdEguEbzABOfUmJT8oTAWwspJ8E1MiCcq5O8HJEJbpjT3PnWbloq0JnaR6HJEllnee0zEdF4K/o 1+124cwByCSASHnWJbdTJgA1Yzh7uA9F44LGARRk5A7PMC4APr/heXZPCRRtQnPhIfGTEERC8A34 MpMplAvpLOOFkK6a/jA4I7G/BELaxtqQBkhWNgRuoZj6D9QRFSmMijVWBazbZs8hJgCULQgVqDpU C6C6btHVWbEOObcbdgCoiabMUjw3FpRM/XnykyRLOPGxAKGJZAGEVtglYHNKIsaF2gLCQOiGqW5Z oBNMKSASlpZYdILtfxJEq3OIf+9jaJI05+QhSReJWifIZxzws0wnN/OXKA5Fn0PtEIKfQhq6avw+ RfY+wXq8GEEPgrS4GGZAAp0U1lMuDPoS5FkiL6hGY6tzdWlrL5fagJfFtHZwVUNdXE1uoRz1LgaT C29yMejZvN5y8Pua0xuipwac2Q7DMviUMPKW9PHvy5edzeHy4qT/LwKx4OSJYPcJQAsWXB1NnS/s q86kScBMTz1ICqcuwHp6TCCUzKicpqGAshvAZw6I5t/FBubohSy2BVW3s7+LgQZWZhD1QkW9TruB 7ADL8N/RV7ga845pS1X2/++d2W/sRDC/ixmcr8vNFKt2ZZN1wedQFqCeQrcfQAW2NORX8roJGCiW oxgdmJJ3yMEBeQbiBr6gwSxzVCP0+isIfJQ1JV1Ju1Z9O69Kp03MHrYya1vGAlPI3K5n2yBVvlaO 8iqf10lbNeQuqeZaxYfBvnq2hSe01Ktevjjcu+0TT/n8+D4FiBLTXIaAgOaCWv/vBMu9tva15XdR v4pQL+LpDNHSZojqRsRe6mx7nrSpukvZ4oU2SkmL2ZWSSLI0vKXUwGdHwz+Fr8iDgNKw5fPSiVuO +jEIlWdYrAJsr4HYKM0Tm2JrlbJkUjuExQOe5GXHBGSK6wICfIsLH8DaN0WR0bJm677JbV4gtY8T yz3IIYiOl1XFU3YHiUx9h+jtA2ldoqzOOaGqfLUZ9k2FY5b/tkOtvutYXRAXI17IONTinrrK9eg3 h6zq5qckh34r9pT9DYM+hYSy7pM2rrWeeafwo7pqg+pfba5LYuub7I1J0260G8I9tt/ewu2pPbe1 zTVvWhuF0WM7dD2An9Ckb4UmlOmoh6JUzbhm6XZPTg472JO75S3rWoFKYo8WZ0OxXoiFaFkSV1dY cKgaSKkwFG32JOCsb9ddEzrIWqfqleSHHGERjpskTY7uYIsC99EVmVJO/UgCxIc5LdsjEuScY8NU 3c4Nrkd65dnsb6Fl9iqadQ1h7XTUVTtxWjny/tz79/DmyjmIQtHwDExNhrem8y3L5Lwr5yBKoLoj y1RezPVO8Gn0xDhRvFcy0vkl6RW8XHXxXf0+kPMG8zpW2907PisIUDxsBcjO5Ud5vQqlNRhmNLGb xiZD8eoBjrC5ueEuj9zqzgo+d1xyYpFPlZBA4W37/qqpJARUaFNxi5pK1bqwPUFrYiKv4dZKQ7yD KPKrrFmgJy0SL2SiTMyi/tt85O2YXY/RqjWy4O0oxSdM12jLLPXIgjNJnfJb6Uc0mF1GO1kwNNvk U3xalrYKsrpxYmsEwGeLofBpGwsfMNhLOHxsEVO8vWPQB59gVsDKtxYzmGTXwRA+RZ40dcSgbtha yxmLytYMqm6Fhjc3VzfecPDPwWhcxblV7zvg+9AmvsqSLSm51XWoFnoOb4dgZWd9/PywGC9tv/LT hogXUP60wApQecFVpJMj9ckGV4pCEdyWG3f9qVBLBfE62NrBAHYjKIXXxq4dZRsuwhgrP1txHZ/d EbKsSIKY4QH/RIjcpUz5EWGk3XiYpURF4M36viGIUyhFigZEC6Gq1TDKeLXWusoov9WLodIThpxN l0WcroB53SvS6u37FkqFTF6Ab2ziepOFaLMqq11a12T7Z4Xf6zksA5OUz/w4XloveZtklW7Vix/L +t08ssUV633Qkot+q19QFVGifpWvOQB/vv8fUEsHCMxiPEwjCgAA8yUAAFBLAwQKAAAAAACoflFI AAAAAAAAAAAAAAAACQAQAF9fTUFDT1NYL1VYDABLe8RWS3vEVvUBFABQSwMEFAAIAAgAmH5RSAAA AAAAAAAAAAAAABMAEABfX01BQ09TWC8uX21haW4uY3BwVVgMADF7xFYve8RW9QEUAGNgFWNnYGJg 8E1MVvAPVohQgAKQGAMnEBsBcSUQg/irGYgCjiEhQVAmSMccIOZHU8KIEBdPzs/VSywoyEnVC0mt KHHNS85PycxLB0qWlqTpWlgbGpsYGZpbWpgAAFBLBwhwGo3AXQAAAKsAAABQSwECFQMUAAgACACY flFIzGI8TCMKAADzJQAACAAMAAAAAAAAAABApIEAAAAAbWFpbi5jcHBVWAgAMXvEVi97xFZQSwEC FQMKAAAAAACoflFIAAAAAAAAAAAAAAAACQAMAAAAAAAAAABA/UFpCgAAX19NQUNPU1gvVVgIAEt7 xFZLe8RWUEsBAhUDFAAIAAgAmH5RSHAajcBdAAAAqwAAABMADAAAAAAAAAAAQKSBoAoAAF9fTUFD T1NYLy5fbWFpbi5jcHBVWAgAMXvEVi97xFZQSwUGAAAAAAMAAwDSAAAATgsAAAAA --089e0160b3dc684f95052bf7b97b Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --089e0160b3dc684f95052bf7b97b-- From libssh2-devel-bounces@cool.haxx.se Wed Feb 17 15:19:11 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1HEJ6n7018213; Wed, 17 Feb 2016 15:19:10 +0100 Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01:0:0:0:22c]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1HEJ4pA018053 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 17 Feb 2016 15:19:04 +0100 Received: by mail-ob0-x22c.google.com with SMTP id gc3so15553641obb.3 for ; Wed, 17 Feb 2016 06:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7S9JWNO6dWQnIvusOny9ytV9gpWDtS9Krh4DQpiRCF0=; b=VpZKpd8C/Z5cNzEf2681DlHIBVFWfxpQ6BYNnnE8SVfzXtYTLX8ze6glboEApauhLf ANh3bpmZVzra1vmAgJBTWpC82skuejlSjrk48RBBQUu5jT2JuKu43itvJSuK5hJO+ku7 BMwczhquJ/JckX2XxHrw63yxTRya5IBKkZUEvXXApsFdAq5RfvkQAsijuOMtiorupXRq oxr8IrhcrX/lG9T/0vi5d92q0fnYewLjYzY/zplF9uBhjHixxVk8/GlG7sLvIh11hheR lKG59LB+qPLLsDkYs2ksBFJo3m2xf77+xFCla+q+OXwL7wzSBy08BgOjWrNsJuDQu5Lm kN3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=7S9JWNO6dWQnIvusOny9ytV9gpWDtS9Krh4DQpiRCF0=; b=bUJxSKpDNnadZwxjhkPFAjKCvotUIF0q3WZRRTvEGn9gP0GkwHOUaT8nplWOGnPuXz 4XAS6HBmocewfj+88lKU5wJOpMTyAZMaxn2Ran2JXPLGxxFlRz5iZODFsgE0sKIUEhYE vQnRtFEs8Qr6kPWsHKALPyoBvOiVj79ES+m3zqopBf3mmwEMhknYiyX7ccCy0L8zHHzA CPUZbyinEXZ1O2ikR5drGYh57VIgmzGDgSYyBVJL0LOR2y5rk5ZwNlxGEkn0MGZWgxp/ 4FuOIeRhpZ9C2Y88VMhsLQ3qVb35DBjz25+NoCPUh86Q+kYV+OwRd2RTzbRhq5GPmyLO yNbQ== X-Gm-Message-State: AG10YOQJYXgIbpTibuWeAPZ13Hh6iUt3kNzleI9SzP0ImQGOtmetrrSPGbnfEIFVJCHxdkkwYnAeb+Dqor1ghQ== MIME-Version: 1.0 X-Received: by 10.182.55.10 with SMTP id n10mr1372653obp.68.1455718739885; Wed, 17 Feb 2016 06:18:59 -0800 (PST) Received: by 10.76.159.229 with HTTP; Wed, 17 Feb 2016 06:18:59 -0800 (PST) In-Reply-To: References: <4D8C0CA0-14E9-4E7D-8630-335B88966649@panic.com> Date: Wed, 17 Feb 2016 16:18:59 +0200 Message-ID: Subject: Re: Memory leak on mac From: Velichko Yuriy To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============2061438186==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============2061438186== Content-Type: multipart/alternative; boundary=089e015381226247ff052bf7eee8 --089e015381226247ff052bf7eee8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In the attached example: if libssh2_session_set_blocking(session, 0); memory usage is increased. else if libssh2_session_set_blocking(session, 1); the app uses the constant amount of memory. On 17 February 2016 at 16:04, Velichko Yuriy wrote: > In the attached archive an example based on libssh2 docs: > > http://www.libssh2.org/examples/tcpip-forward.html > > In the attached code the port forwarding is implemented. In the infinity > loop we preforms port forwarding of the PostgreSQL port on the remote > computer. In the end of the loop all resources are freeing. > > But memory increases constantly. > > I think that I'm doing something wrong. Tell me please what exactly? ) > > On 16 February 2016 at 20:05, Velichko Yuriy > wrote: > >> I will create a simple example in nearest time. >> >> On 16 February 2016 at 19:52, Will Cosgrove wrote: >> >>> You=E2=80=99ll need to post an example app showing this leak; I use lib= ssh2 on >>> the Mac and have done extensive profiling and it does not leak in my us= e >>> cases. >>> >>> Will >>> >>> On Feb 16, 2016, at 9:43 AM, Velichko Yuriy >>> wrote: >>> >>> Hello! >>> >>> I have application, that among other things, checks accessibility of th= e >>> remote machine by connecting over ssh. The app immediately disconnect w= hen >>> connection is confirmed. All works fine on Mac and Windows. But on mac = the >>> app takes more and more memory (on windows is all right). The instrumen= ts >>> for XCode shows that memory is leak in function >>> >>> libssh2_default_alloc >>> >>> but I do not call this function directly anywhere. >>> >>> To release ssh handlers methods are used: >>> >>> libssh2_channel_free( ); >>> libssh2_session_disconnect( ); >>> libssh2_session_free( ); >>> >>> All of them works without errors. >>> >>> IMPOTANT NOTE: the leak occur when session works in non-blocking mode: >>> >>> libssh2_session_set_blocking( ..., 0); >>> >>> if to use >>> >>> libssh2_session_set_blocking( ..., 1); >>> >>> There is no leak. >>> >>> Tell me please what a difference. What I doing wrong? Or may be this is >>> a little bug in libssh2? >>> >>> _______________________________________________ >>> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-deve= l >>> >>> >>> >>> _______________________________________________ >>> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-deve= l >>> >>> >> >> >> -- >> =E2=80=8B=D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, = =D0=92=D0=B5=D0=BB=D0=B8=D1=87=D0=BA=D0=BE =D0=AE=D1=80=D0=B8=D0=B9. >> > > > > -- > =E2=80=8B=D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, = =D0=92=D0=B5=D0=BB=D0=B8=D1=87=D0=BA=D0=BE =D0=AE=D1=80=D0=B8=D0=B9. > --=20 =E2=80=8B=D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0= =92=D0=B5=D0=BB=D0=B8=D1=87=D0=BA=D0=BE =D0=AE=D1=80=D0=B8=D0=B9. --089e015381226247ff052bf7eee8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In the attached example:
if=C2=A0
=C2=A0libssh2_session_set_blocking(session, 0);
memory usage is increased.
else if=C2=A0
libssh2_session_set_blocking(session,=C2=A01);
the app uses the constant amount of memory.

On 17 Febru= ary 2016 at 16:04, Velichko Yuriy <velichko.yuriy@gmail.com>= wrote:
In the attache= d archive an example based on libssh2 docs:

http://www.libssh2.org/exa= mples/tcpip-forward.html
<= font face=3D"verdana, sans-serif">
In the attached code the port forwarding is implemented. In the infini= ty loop we preforms port forwarding of the PostgreSQL port on the remote co= mputer. In the end of the loop all resources are freeing.=C2=A0

But memory in= creases constantly.

I think that I'm doing something wrong. Tell me plea= se what exactly? )

On 16 February 2016 at= 20:05, Velichko Yuriy <velichko.yuriy@gmail.com> wro= te:
I will create a simple ex= ample in nearest time.

On 16 February 2016 at 19:52, Will Cosgrove <will@= panic.com> wrote:
You=E2=80=99ll need t= o post an example app showing this leak; I use libssh2 on the Mac and have = done extensive profiling and it does not leak in my use cases.
Will

On= Feb 16, 2016, at 9:43 AM, Velichko Yuriy <velichko.yuriy@gmail.com> wrote:
Hello!

I have application, that among other things, checks accessibility o= f the remote machine by connecting over ssh. The app immediately disconnect= when connection is confirmed. All works fine on Mac and Windows. But on ma= c the app takes more and more memory (on windows is all right). The instrum= ents for XCode shows that memory is leak in function=C2=A0

libssh2_d= efault_alloc

but I do not call this function directly anywhere.
To release ssh handlers methods are used:

libssh2_channel_free(= =C2=A0); =C2=A0 =C2=A0
libssh2_session_disconnect( =C2=A0);
<= div class=3D"gmail_default">libssh2_sess= ion_free( =C2=A0);

All of them works without errors.

IMPOTANT= NOTE: the leak occur when session works in non-blocking mode:
=

=
libss= h2_session_set_blocking( ..., 0);
=
if to use =C2=A0

libssh2_se= ssion_set_blocking( ..., 1);

There is no leak.

Tell me please= what a difference. What I doing wrong? Or may be this is a little bug in l= ibssh2?

_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel


_____________________________= __________________
libssh2-devel http://cool.haxx.se/cgi-bin/= mailman/listinfo/libssh2-devel



=

--
=E2=80=8B=D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0= =B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0=92=D0=B5=D0=BB=D0=B8=D1=87=D0=BA=D0=BE =D0= =AE=D1=80=D0=B8=D0=B9.



--
= =E2=80=8B=D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0= =92=D0=B5=D0=BB=D0=B8=D1=87=D0=BA=D0=BE =D0=AE=D1=80=D0=B8=D0=B9.



--
=
=E2=80=8B=D0=A1 =D1=83=D0=B2=D0=B0=D0= =B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0=92=D0=B5=D0=BB=D0=B8=D1=87=D0=BA=D0= =BE =D0=AE=D1=80=D0=B8=D0=B9.
--089e015381226247ff052bf7eee8-- --===============2061438186== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============2061438186==-- From libssh2-devel-bounces@cool.haxx.se Wed Feb 17 16:49:45 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1HFnMZk020309; Wed, 17 Feb 2016 16:49:42 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1HFnKIL020191 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 17 Feb 2016 16:49:21 +0100 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id B51E83106; Wed, 17 Feb 2016 15:49:15 +0000 (UTC) Received: from nbkamil.localnet (ovpn-204-113.brq.redhat.com [10.40.204.113]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1HFnEBe028881; Wed, 17 Feb 2016 10:49:15 -0500 From: Kamil Dudka To: Velichko Yuriy Subject: Re: Memory leak on mac Date: Wed, 17 Feb 2016 16:47:44 +0100 Message-ID: <4629591.ASNAH06Gzr@nbkamil> User-Agent: KMail/4.14.8 (Linux/4.1.15-gentoo-r1; KDE/4.14.8; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Cc: libssh2-devel@cool.haxx.se Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id u1HFnMZk020309 On Wednesday, February 17, 2016 16:04:06 Velichko Yuriy wrote: > In the attached archive an example based on libssh2 docs: > > http://www.libssh2.org/examples/tcpip-forward.html > > In the attached code the port forwarding is implemented. In the infinity > loop we preforms port forwarding of the PostgreSQL port on the remote > computer. In the end of the loop all resources are freeing. > > But memory increases constantly. > > I think that I'm doing something wrong. Tell me please what exactly? ) Your code does not seem to handle LIBSSH2_ERROR_EAGAIN coming out of libssh2_channel_free() and libssh2_session_free(). It should. Kamil _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Feb 17 19:30:15 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1HITsxa011842; Wed, 17 Feb 2016 19:30:12 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1HITp9M009306 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 17 Feb 2016 19:29:53 +0100 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 1521891FD5; Wed, 17 Feb 2016 18:29:50 +0000 (UTC) Received: from nbkamil.localnet (ovpn-204-113.brq.redhat.com [10.40.204.113]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1HITovf020763; Wed, 17 Feb 2016 13:29:50 -0500 From: Kamil Dudka To: Velichko Yuriy Subject: Re: Memory leak on mac Date: Wed, 17 Feb 2016 19:28:14 +0100 Message-ID: <6639841.NRe7g9tr1E@nbkamil> User-Agent: KMail/4.14.8 (Linux/4.1.15-gentoo-r1; KDE/4.14.8; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id u1HITp9M009306 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Cc: libssh2-devel@cool.haxx.se Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id u1HITsxa011842 On Wednesday, February 17, 2016 19:08:47 Velichko Yuriy wrote: > int res = LIBSSH2_ERROR_EAGAIN; > > while( res != 0 ) > > re = libssh2_channel_free(channel); > > > This code helps, but is it safe? Can be infinity loop here? This looks wrong to me. You need to call the library function again in case it returns LIBSSH2_ERROR_EAGAIN, but break the loop in case it returns another error code. Kamil > Maybe other solution are exist? > > On 17 February 2016 at 18:56, Velichko Yuriy > > wrote: > > ​Thanks, ​Kamil. > > Can you point me on example how to handle LIBSSH2_ERROR_EAGAIN to free > > resources properly? > > > > On 17 February 2016 at 17:47, Kamil Dudka wrote: > >> On Wednesday, February 17, 2016 16:04:06 Velichko Yuriy wrote: > >> > In the attached archive an example based on libssh2 docs: > >> > > >> > http://www.libssh2.org/examples/tcpip-forward.html > >> > > >> > In the attached code the port forwarding is implemented. In the > >> > infinity > >> > loop we preforms port forwarding of the PostgreSQL port on the remote > >> > computer. In the end of the loop all resources are freeing. > >> > > >> > But memory increases constantly. > >> > > >> > I think that I'm doing something wrong. Tell me please what exactly? ) > >> > >> Your code does not seem to handle LIBSSH2_ERROR_EAGAIN coming out > >> of libssh2_channel_free() and libssh2_session_free(). It should. > >> > >> Kamil > > > > -- > > ​С уважением, Величко Юрий. _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Feb 18 08:22:30 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1I7M7Le014382; Thu, 18 Feb 2016 08:22:26 +0100 Received: from nm10-vm2.bullet.mail.sg3.yahoo.com (nm10-vm2.bullet.mail.sg3.yahoo.com [106.10.148.225]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1I7LvQ7014173 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 18 Feb 2016 08:22:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1455780112; bh=eYyeNN3siKDywSH2JgBvTSml2K4La4IX4KSYjXdBKWQ=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=iDHEQfQ8ufZ22VFFtEWMKXYHQIfb+Mj8g/zciUEULUaFK74zZ/FfrqUmQeqHMJf8nOVIL/GQ9qj82hg2T21TjXRixW1GvFI1D3x5N8fTRQbA0kamMeAtjagemjEuf9addNEw6K0t+zDts9qqN2QqZ87uyv2tzcUeZksQrX4NLLc6rXRiMHbHDSWw3jtPQcL1DCFYJ7YK6uKIpjN31md5ufo0XTop+ZUDIoK6rg17/HxCaY8NsIICei8hIqYENKT0V7MrhZnmP7KRyBzbDg7AGhAEVIruyBjEWEHV9Oi/SyJw45+Q2iusA8QFDE11V1uGodH+D9epnGzJ9NfWgHkedg== Received: from [106.10.166.119] by nm10.bullet.mail.sg3.yahoo.com with NNFMP; 18 Feb 2016 07:21:52 -0000 Received: from [106.10.150.24] by tm8.bullet.mail.sg3.yahoo.com with NNFMP; 18 Feb 2016 07:21:52 -0000 Received: from [127.0.0.1] by omp1025.mail.sg3.yahoo.com with NNFMP; 18 Feb 2016 07:21:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 994799.27069.bm@omp1025.mail.sg3.yahoo.com X-YMail-OSG: ZX4Njr8VM1nM9pg8310CQ0UHRWeJ2vNkekYLEdeBIYcRgekTGZUADVj3IiDizXX Ys94ewabCjvENVux42Yh8fOPcE8nBdecFTSZF.wdVrHK1ekPCmTSG6bK.6jRfmZnFdjb6KMCm9Hk MGTWrQZQhg2Ua8DoMdo0gtBYt3H.ULa3TupjjKByOEFJQsZjQ642em9hQSERsOcRdsYg5UCN3ddT CU4PZj.c0ck9VehG0fFzhztR326gnC3_FZGZyd7tSynDbpfpBDtk3igMSFM.2Mjz9HzdC1AwYAXS DQOakV.uGpGwSWco8lMH4ffTyabwPP7caaX0nFLetV3RKrOXnis1.aMyiRzWzfeIVxt1dP2rbD1I VGJAOAuWAr6U_23dx8qQTcMFlfA.MJsMKlRZ_JjFfDyWthtBLVh_lRPkdSUievk9AE.p9H3kxpzn 7ozay34PtuVmVVNbdbi_uStYdtPTaOPS9hcHaKJMrokh3Zs15ySmg3_YgDSUHXytX0SuzWabK6e. F2TyLFU3QWvoKDQNytAJfkD7ozTFhPdoXdZhyTS3KA6BxlT48imtclNDf Received: by 106.10.196.177; Thu, 18 Feb 2016 07:21:51 +0000 Date: Thu, 18 Feb 2016 07:21:51 +0000 (UTC) From: suyog jadhav To: Libssh2 Development Message-ID: <315613626.4961794.1455780111216.JavaMail.yahoo@mail.yahoo.com> Subject: Regarding hmac-sha2-256 support in 1.6.0 version MIME-Version: 1.0 References: <315613626.4961794.1455780111216.JavaMail.yahoo.ref@mail.yahoo.com> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: suyog jadhav , libssh2 development Content-Type: multipart/mixed; boundary="===============1727602329==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============1727602329== Content-Type: multipart/alternative; boundary="----=_Part_4961793_1352399264.1455780111214" ------=_Part_4961793_1352399264.1455780111214 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit HI All, We have been using libssh2 from 1.2.4 version and it has been a great library. The home-page of libssh2.org mentions that hmac-sha2-256 is supported. So we are using 1.6.0 version now, but it doesn't seem to support hmac-sha2-256 as it can't connect to servers with that MAC configuration. I see following discussion on the github. https://github.com/libssh2/libssh2/issues/62#issuecomment-154999377 IS there a release planned for near future with the hmac-sha2-256 support? Regards Suyog ------=_Part_4961793_1352399264.1455780111214 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
HI All,

W= e have been using libssh2 from 1.2.4 version and it has been a great librar= y.

Th= e home-page of libssh2.org mentions that hmac-sha2-256 is supported.
So we are using 1.6.0 version now, but it doesn't seem to support hmac-sha= 2-256 as it can't connect to servers with that MAC configuration.

I = see following discussion on the github.

https://github.com/libssh2/l= ibssh2/issues/62#issuecomment-154999377


IS there a release plann= ed for near future with the hmac-sha2-256 support?

Regards
Suyog
------=_Part_4961793_1352399264.1455780111214-- --===============1727602329== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============1727602329==-- From libssh2-devel-bounces@cool.haxx.se Thu Feb 18 08:27:55 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1I7Rn5S023050; Thu, 18 Feb 2016 08:27:54 +0100 Received: from giant.haxx.se (dast@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1I7RmD6023025 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Feb 2016 08:27:48 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id u1I7Rm9a023020; Thu, 18 Feb 2016 08:27:48 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Thu, 18 Feb 2016 08:27:48 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: suyog jadhav , libssh2 development Subject: Re: Regarding hmac-sha2-256 support in 1.6.0 version In-Reply-To: <315613626.4961794.1455780111216.JavaMail.yahoo@mail.yahoo.com> Message-ID: References: <315613626.4961794.1455780111216.JavaMail.yahoo.ref@mail.yahoo.com> <315613626.4961794.1455780111216.JavaMail.yahoo@mail.yahoo.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id u1I7Rn5S023050 On Thu, 18 Feb 2016, suyog jadhav wrote: > IS there a release planned for near future with the hmac-sha2-256 support? Yes! hmac-sha2-256 support is in git and the daily snapshots since a while back and will be part of the 1.7.0 release we plan to ship on February 23. -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Feb 19 10:14:54 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1J9EPjl015231; Fri, 19 Feb 2016 10:14:50 +0100 Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1J9ENa8015227 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 19 Feb 2016 10:14:24 +0100 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id u1J9EO2A008325 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 19 Feb 2016 10:14:24 +0100 Received: from DEFTHW99ERGMSX.ww902.siemens.net (defthw99ergmsx.ww902.siemens.net [139.22.70.132]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id u1J9EOIR002999 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 19 Feb 2016 10:14:24 +0100 Received: from DEFTHW99ER4MSX.ww902.siemens.net (139.22.70.78) by DEFTHW99ERGMSX.ww902.siemens.net (139.22.70.132) with Microsoft SMTP Server (TLS) id 14.3.279.2; Fri, 19 Feb 2016 10:14:23 +0100 Received: from DEFTHW99EH2MSX.ww902.siemens.net ([169.254.12.145]) by DEFTHW99ER4MSX.ww902.siemens.net ([139.22.70.78]) with mapi id 14.03.0279.002; Fri, 19 Feb 2016 10:14:22 +0100 From: "Belau, Rene (ext)" To: libssh2 development Subject: AW: libssh2_channel_read() issue Thread-Topic: libssh2_channel_read() issue Thread-Index: AQHRaW3UtxBEFiraj0ip5LDkC1+xbZ8wJtZg////pACAATa8AA== Date: Fri, 19 Feb 2016 09:14:22 +0000 Message-ID: <16C23041BD880F48901C072C51AC6A2E02E72F81@DEFTHW99EH2MSX.ww902.siemens.net> References: <16C23041BD880F48901C072C51AC6A2E02E72E8F@DEFTHW99EH2MSX.ww902.siemens.net> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.31] MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============0798418811==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============0798418811== Content-Language: de-DE Content-Type: multipart/alternative; boundary="_000_16C23041BD880F48901C072C51AC6A2E02E72F81DEFTHW99EH2MSXw_" --_000_16C23041BD880F48901C072C51AC6A2E02E72F81DEFTHW99EH2MSXw_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW1pcnVsLA0KDQpzb3JyeSAgYnV0IHRoaXMgc291bmRzIHdlaXJkIHRvIG1lLg0KDQpBZnRl ciBjYWxsIG9mIGxpYnNzaDJfc2NwX3JlY3YoKSB5b3UgZ290IGEgaGFuZGxlIGFuZCBzYi5tb2Rl ID0gMHgwMDQwKFBPU0lYKSBvciAweDAxMDAoV0lOKSBmb3IgcmVhZCBwZXJtaXNzaW9ucz8NCg0K SWYgaXQgaXMgdHJ1ZQ0KDQphdCB0aGUgc2FtZSB1c2VjYXNlLCBhcyB5b3UgZGVzY3JpYmVkLg0K DQpMb2dnZWQgaW4gdXNlciBhbmQgZGlyZWN0b3J5IGhhdmUgcmlnaHRzLiAtPg0KDQpEcmVjdG9y eSA+PiBtZTptZSBkcnd4cnd4cnd4DQpGaWxlIGluc2lkZSA+PiBtZTptZSDigJN3LS0tLS0tLQ0K DQpNeSByZXN1bHQ6IGZvciBsaWJzc2gyKDEuNC4zICYmIDEuNS4wKSBhZnRlciAzIHRyaWVzICh0 ZXN0IHdpdGggYmxvY2tpbmcgbW9kZSBhbmQgdGVzdGVkIGFnYWluIHRocmVlIGRpZmZlcmVudCBz c2ggc2VydmVycykNCg0KMS4gICAgICBsaWJzc2gyX3NjcF9yZWN2KCkgLy9oYW5kbGUgPSBudWxs LCBzdGF0ID0gezB9LCAgbGlic3NoMl9zZXNzaW9uX2xhc3RfZXJybm8oKSAvL2Vycm9yIC0yOA0K TXkgcmVzdWx0OiBmb3IgbGlic3NoMigxLjQuMyAmJiAxLjUuMCkgYWZ0ZXIgMyB0cmllcyAodGVz dCB3aXRoIG5vbi1ibG9ja2luZyBtb2RlIGFuZCB0ZXN0ZWQgYWdhaW4gdGhyZWUgZGlmZmVyZW50 IHNzaCBzZXJ2ZXJzKQ0KDQoxLiAgICAgIGxpYnNzaDJfc2NwX3JlY3YoKSAvL2hhbmRsZSA9IG51 bGwsIHN0YXQgPSB7MH0sIGxpYnNzaDJfc2Vzc2lvbl9sYXN0X2Vycm5vKCkgLy9lcnJvciAtMzcN Cg0KMi4gICAgICBsaWJzc2gyX3NjcF9yZWN2KCkgLy9oYW5kbGUgPSBudWxsLCBzdGF0ID0gezB9 LCBsaWJzc2gyX3Nlc3Npb25fbGFzdF9lcnJubygpIC8vZXJyb3IgLTM3DQoNCjMuICAgICAgbGli c3NoMl9zY3BfcmVjdigpIC8vaGFuZGxlID0gbnVsbCwgc3RhdCA9IHswfSwgIGxpYnNzaDJfc2Vz c2lvbl9sYXN0X2Vycm5vKCkgLy9lcnJvciAtMjgNCkp1c3QgZmluZSwgaG93IGl0IHNob3VsZCBi ZS4NCg0KDQpEbyB5b3UgdXNlIGFuIG9sZGVyIHZlcnNpb24/IHlvdSBjb3VsZCBkaWcgaW50byBs aWJzc2gyIC0+IHNjcC5jIC0+IHNjcF9yZWN2IHN0YXRlIDIgb3IgMw0KDQoNClJlbmUNCg0KLS0t DQoNClZvbjogbGlic3NoMi1kZXZlbCBbbWFpbHRvOmxpYnNzaDItZGV2ZWwtYm91bmNlc0Bjb29s LmhheHguc2VdIEltIEF1ZnRyYWcgdm9uIEFtaXJ1bCBJc2xhbQ0KR2VzZW5kZXQ6IE1pdHR3b2No LCAxNy4gRmVicnVhciAyMDE2IDE0OjE0DQpBbjogbGlic3NoMiBkZXZlbG9wbWVudA0KQmV0cmVm ZjogUmU6IGxpYnNzaDJfY2hhbm5lbF9yZWFkKCkgaXNzdWUNCg0KSGkgUmVuZSwNCg0KSSBoYXZl IGNoZWNrZWQgZm9yIGxhc3QgZXJybm8gb24gYm90aCBjYXNlcyB3aGVuIGxpYnNzaDJfc2NwX3Jl Y3YoKSAmIGxpYnNzaDJfY2hhbm5lbF9yZWFkKCkgaXMgY2FsbGVkLCBsaWJzc2gyX3Nlc3Npb25f bGFzdF9lcnJubygpIHJldHVybiAwLiBUaGUgaXNzdWVzIGlzIHRoYXQgbXkgdXNlciBoYXMgYWNj ZXNzIHRvIHRoZSByZW1vdGUgZm9sZGVyLCBidXQgZG9lcyBub3QgaGF2ZSByZWFkIHBlcm1pc3Np b24gb24gdGhlIHRhcmdldCBmaWxlIHdoaWNoIGlzIGNvbnRhaW5lZCBpbiB0aGF0IGZvbGRlci4g U28gdGhlIHJldHVybiB2YWx1ZSBmcm9tIGxpYnNzaDJfY2hhbm5lbF9yZWFkKCkgaXMgYWx3YXlz IDAgYW5kIHNiLnN0X3NpemUgaXMgMS4NCg0KeW91IGNhbiBzaW11bGF0ZSBhbmQgY2hlY2sgd2hh dCB5b3UgZ2V0DQoNCk9uIFdlZCwgRmViIDE3LCAyMDE2IGF0IDQ6NTcgUE0sIEJlbGF1LCBSZW5l IChleHQpIDxiZWxhdS5yZW5lLmV4dEBzaWVtZW5zLmNvbTxtYWlsdG86YmVsYXUucmVuZS5leHRA c2llbWVucy5jb20+PiB3cm90ZToNCllvdSBuZWVkIHRvIGRvIGFuIG9wZXJhdGlvbiBhbmQgdGhl biBjaGVjayBzZXNzaW9uIGVycm9yLg0KDQpsaWJzc2gyX3NjcF9yZWN2KCkgLy9oYW5kbGUgbnVs bCwgcmV0dXJuIC0zNw0KbGlic3NoMl9zZXNzaW9uX2xhc3RfZXJybm8oKSAvL2Vycm9yIC0yOCBz Y3AgcHJvdG9jb2wgZXJyb3IgKGxpYnNzaDIgdmVyc2lvbiAxLjUuMCkgaWYgeW91IGhhdmUgbm8g cmlnaHRzIGF0IHRhcmdldCBkZXZpY2UNCg0KbGlic3NoMl9jaGFubmVsX3JlYWQoKSAvL2dvdCB3 ZSBzb21lIGJ5dGVzID8NCmxpYnNzaDJfc2Vzc2lvbl9sYXN0X2Vycm5vKCkgLy93aXRob3V0IGVy cm9yPw0KDQpsaWJzc2gyX2NoYW5uZWxfcmVhZCgpIC0+IDAgYnl0ZXMgPT4gbm8gcGF5bG9hZCwg aXQgaXMgbm90IGFuIGVycm9yIC0+IGxpYnNzaDIgdGVsbHMgdXMgaWYgaXQgaXMgZXJyb3IgISAt PiBsaWJzc2gyX3Nlc3Npb25fbGFzdF9lcnJubygpDQoNCg0KUmVuZQ0KDQpWb246IGxpYnNzaDIt ZGV2ZWwgW21haWx0bzpsaWJzc2gyLWRldmVsLWJvdW5jZXNAY29vbC5oYXh4LnNlPG1haWx0bzps aWJzc2gyLWRldmVsLWJvdW5jZXNAY29vbC5oYXh4LnNlPl0gSW0gQXVmdHJhZyB2b24gQW1pcnVs IElzbGFtDQpHZXNlbmRldDogTWl0dHdvY2gsIDE3LiBGZWJydWFyIDIwMTYgMTE6MjQNCkFuOiBs aWJzc2gyLWRldmVsQGNvb2wuaGF4eC5zZTxtYWlsdG86bGlic3NoMi1kZXZlbEBjb29sLmhheHgu c2U+DQpCZXRyZWZmOiBsaWJzc2gyX2NoYW5uZWxfcmVhZCgpIGlzc3VlDQoNCkhpIEFsbCwNCg0K SSBhbSBoYXZpbmcgYW4gaXNzdWUgd2l0aCB0aGUgbGlic3NoMl9jaGFubmVsX3JlYWQoKSBmdW5j dGlvbi4gSSBhbSB1c2luZyBpdCBpbiBibG9ja2luZyBtb2RlIHRvIGRvd25sb2FkIGZpbGVzIGZy b20gcmVtb3RlIHNlcnZlci4gTm93LCBJIGhhdmUgYW4gaW5zdGFuY2Ugd2hlcmUgdGhlIGZpbGUg SSBhbSB0cnlpbmcgdG8gZG93bmxvYWQsIEkgZG8gbm90IGhhdmUgcmVhZCBwZXJtaXNzaW9uLiBU aGlzIGlzIGNhdXNpbmcgdGhlIHJlYWQoKSBmdW5jdGlvbiB0byByZXR1cm4gMC4gSSBhbSBub3Qg c3VyZSwgaWYgSSBzaG91bGQgYnJlYWsgbXkgcmVhZCBsb29wIHdoZW4gMCBpcyByZXR1cm5lZCwg c2luY2UgdGhlIGRvY3VtZW50YXRpb24gaW1wbGllcyB3ZSBzaG91bGQgYnJlYWsgd2hlbiB0aGVy ZSBpcyBhIG5lZ2F0aXZlIHZhbHVlIHJldHVybmVkLiBJIGFtIG5vdCBpZiBicmVha2luZyBvbiAw IHdpbGwgaGF2ZSB1bnByZWRpY3RhYmxlIGJlaGF2aW9yIG9uIG90aGVyIGluc3RhbmNlcy4gbmVl ZCBoZWxwDQoNCkFsc28sIEkgY2FuIGNoZWNrIHRoZSBmaWxlIG1vZGUgd2hlbiBJIGNhbGwgbGli c3NoMl9zY3BfcmVjdigpIGZ1bmN0aW9uLCB3aGF0IHdvdWxkIGJlIHRoZSBiZXN0IHdheSB0byBj aGVjayBpZiBteSB1c2VyIGhhcyByZWFkIHBlcm1pc3Npb24/DQoNClRoYW5rIHlvdSBpbiBhZHZh bmNlLg0KDQotLQ0KDQoiRmFtZSBpcyBhIHZhcG9yOyBwb3B1bGFyaXR5IGFuIGFjY2lkZW50OyB0 aGUgb25seSBlYXJ0aGx5IGNlcnRhaW50eSBpcyBvYmxpdmlvbi4iDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpsaWJzc2gyLWRldmVsIGh0dHA6Ly9j b29sLmhheHguc2UvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL2xpYnNzaDItZGV2ZWwNCg0KDQoN Ci0tDQoNCiJGYW1lIGlzIGEgdmFwb3I7IHBvcHVsYXJpdHkgYW4gYWNjaWRlbnQ7IHRoZSBvbmx5 IGVhcnRobHkgY2VydGFpbnR5IGlzIG9ibGl2aW9uLiINCg== --_000_16C23041BD880F48901C072C51AC6A2E02E72F81DEFTHW99EH2MSXw_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRh dGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiU3ByZWNoYmxhc2VudGV4dCBaY2huIjsNCgltYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTow Y207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K c3Bhbi5TcHJlY2hibGFzZW50ZXh0WmNobg0KCXttc28tc3R5bGUtbmFtZToiU3ByZWNoYmxhc2Vu dGV4dCBaY2huIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6U3By ZWNoYmxhc2VudGV4dDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6REU7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMjANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo5ODcyNDk4 MTM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMDcx ODAwMDEyIDY3NTY3NjMxIDY3NTY3NjQxIDY3NTY3NjQzIDY3NTY3NjMxIDY3NTY3NjQxIDY3NTY3 NjQzIDY3NTY3NjMxIDY3NTY3NjQxIDY3NTY3NjQzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ dGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxw aGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6 LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBs aXN0IGwxDQoJe21zby1saXN0LWlkOjE2NjIzOTM4OTI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMDcxODAwMDEyIDY3NTY3NjMxIDY3NTY3NjQxIDY3 NTY3NjQzIDY3NTY3NjMxIDY3NTY3NjQxIDY3NTY3NjQzIDY3NTY3NjMxIDY3NTY3NjQxIDY3NTY3 NjQzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmln aHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5IaSBBbWlydWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ c29ycnkmbmJzcDsgYnV0IHRoaXMgc291bmRzIHdlaXJkIHRvIG1lLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkFmdGVyIGNhbGwgb2YNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ bGlic3NoMl9zY3BfcmVjdigpIHlvdSBnb3QgYSBoYW5kbGUgYW5kIHNiLm1vZGUgPSAweDAwNDAo UE9TSVgpIG9yIDB4MDEwMChXSU4pIGZvciByZWFkIHBlcm1pc3Npb25zPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+SWYgaXQgaXMgdHJ1ZSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmF0IHRoZSBzYW1l IHVzZWNhc2UsIGFzIHlvdSBkZXNjcmliZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpu b25lIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Mb2dnZWQgaW4gdXNlciBhbmQgZGlyZWN0b3J5IGhhdmUgcmlnaHRzLiAtJmd0OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFj ZTpub25lIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RHJlY3RvcnkgJmd0OyZndDsgbWU6bWUgZHJ3eHJ3eHJ3 eA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkZpbGUgaW5zaWRlICZndDsmZ3Q7IG1lOm1lIOKAk3ctLS0tLS0tPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0 b3NwYWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IHJlc3VsdDogZm9yIGxpYnNzaDIoMS40LjMgJmFt cDsmYW1wOyAxLjUuMCkgYWZ0ZXIgMyB0cmllcyAodGVzdCB3aXRoIGJsb2NraW5nIG1vZGUgYW5k IHRlc3RlZCBhZ2FpbiB0aHJlZSBkaWZmZXJlbnQgc3NoIHNlcnZlcnMpPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzI7dGV4dC1h dXRvc3BhY2U6bm9uZSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBsYW5nPSJFTi1VUyI+bGlic3NoMl9zY3BfcmVjdigpIC8vaGFuZGxlID0gbnVsbCwgc3Rh dCA9IHswfSwmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRl Ij5saWJzc2gyX3Nlc3Npb25fbGFzdF9lcnJubzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+KCkN Cjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+Ly9lcnJvciAtMjg8c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IHJlc3VsdDogZm9yIGxpYnNzaDIoMS40LjMgJmFt cDsmYW1wOyAxLjUuMCkgYWZ0ZXIgMyB0cmllcyAodGVzdCB3aXRoIG5vbi1ibG9ja2luZyBtb2Rl IGFuZCB0ZXN0ZWQgYWdhaW4gdGhyZWUgZGlmZmVyZW50IHNzaCBzZXJ2ZXJzKTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8zO3Rl eHQtYXV0b3NwYWNlOm5vbmUiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4t VVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+ bGlic3NoMl9zY3BfcmVjdigpIC8vaGFuZGxlID0gbnVsbCwgc3RhdCA9IHswfSwNCjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTpDb25z b2xhcztjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj5saWJzc2gyX3Nlc3Npb25fbGFzdF9l cnJubzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+KCkNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+Ly9lcnJvciAtMzc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzM7dGV4 dC1hdXRvc3BhY2U6bm9uZSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1V UyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5s aWJzc2gyX3NjcF9yZWN2KCkgLy9oYW5kbGUgPSBudWxsLCBzdGF0ID0gezB9LA0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPmxpYnNzaDJfc2Vzc2lvbl9sYXN0X2Vy cm5vPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4oKQ0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij4vL2Vycm9yIC0zNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMzt0ZXh0 LWF1dG9zcGFjZTpub25lIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIGxhbmc9IkVOLVVTIj5saWJzc2gyX3NjcF9yZWN2KCkgLy9oYW5kbGUgPSBudWxsLCBz dGF0ID0gezB9LCZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjkuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hp dGUiPmxpYnNzaDJfc2Vzc2lvbl9sYXN0X2Vycm5vPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4o KQ0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4vL2Vycm9yIC0yODxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkp1c3QgZmluZSwgaG93IGl0IHNob3VsZCBiZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5EbyB5b3UgdXNlIGFuIG9sZGVyIHZlcnNpb24/DQo8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPnlvdSBjb3VsZCBkaWcgaW50byBsaWJzc2gyIC0mZ3Q7IHNjcC5j IC0mZ3Q7IHNjcF9yZWN2IHN0YXRlIDIgb3IgMzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5S ZW5lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LS0tPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Wb246PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IGxpYnNzaDItZGV2ZWwgWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86bGlic3NoMi1kZXZlbC1ib3Vu Y2VzQGNvb2wuaGF4eC5zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1haWx0bzpsaWJz c2gyLWRldmVsLWJvdW5jZXNAY29vbC5oYXh4LnNlPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+XQ0KPGI+SW0gQXVmdHJhZyB2b24gPC9iPkFtaXJ1bCBJc2xhbTxicj4NCjxi Pkdlc2VuZGV0OjwvYj4gTWl0dHdvY2gsIDE3LiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5GZWJydWFyIDIwMTYgMTQ6MTQ8YnI+DQo8Yj5Bbjo8L2I+IGxp YnNzaDIgZGV2ZWxvcG1lbnQ8YnI+DQo8Yj5CZXRyZWZmOjwvYj4gUmU6IGxpYnNzaDJfY2hhbm5l bF9yZWFkKCkgaXNzdWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBSZW5lLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgaGF2ZSBjaGVja2VkIGZvciBsYXN0 IGVycm5vIG9uIGJvdGggY2FzZXMgd2hlbiBsaWJzc2gyX3NjcF9yZWN2KCkgJmFtcDsgbGlic3No Ml9jaGFubmVsX3JlYWQoKSBpcyBjYWxsZWQsIGxpYnNzaDJfc2Vzc2lvbl9sYXN0X2Vycm5vKCkg cmV0dXJuIDAuIFRoZSBpc3N1ZXMgaXMgdGhhdCBteSB1c2VyIGhhcyBhY2Nlc3MgdG8gdGhlIHJl bW90ZSBmb2xkZXIsIGJ1dCBkb2VzIG5vdCBoYXZlDQogcmVhZCBwZXJtaXNzaW9uIG9uIHRoZSB0 YXJnZXQgZmlsZSB3aGljaCBpcyBjb250YWluZWQgaW4gdGhhdCBmb2xkZXIuIFNvIHRoZSByZXR1 cm4gdmFsdWUgZnJvbSZuYnNwO2xpYnNzaDJfY2hhbm5lbF9yZWFkKCkgaXMgYWx3YXlzIDAgYW5k IHNiLnN0X3NpemUgaXMgMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPnlvdSBjYW4gc2ltdWxhdGUgYW5kIGNoZWNrIHdoYXQgeW91IGdldDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gV2VkLCBGZWIgMTcs IDIwMTYgYXQgNDo1NyBQTSwgQmVsYXUsIFJlbmUgKGV4dCkgJmx0Ozwvc3Bhbj48YSBocmVmPSJt YWlsdG86YmVsYXUucmVuZS5leHRAc2llbWVucy5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBs YW5nPSJFTi1VUyI+YmVsYXUucmVuZS5leHRAc2llbWVucy5jb208L3NwYW4+PC9hPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WW91IG5lZWQgdG8g ZG8gYW4gb3BlcmF0aW9uIGFuZCB0aGVuIGNoZWNrIHNlc3Npb24gZXJyb3IuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWF1dG9zcGFj ZTpub25lIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5saWJzc2gyX3NjcF9yZWN2KCkgLy9oYW5kbGUg bnVsbCwgcmV0dXJuIC0zNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6 d2hpdGUiPmxpYnNzaDJfc2Vzc2lvbl9sYXN0X2Vycm5vPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNr Ij4oKQ0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4vL2Vycm9yIC0yOCBzY3AgcHJvdG9jb2wg ZXJyb3IgKGxpYnNzaDIgdmVyc2lvbiAxLjUuMCk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+IGlmIHlvdSBoYXZlIG5vIHJpZ2h0cyBh dCB0YXJnZXQgZGV2aWNlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5s aWJzc2gyX2NoYW5uZWxfcmVhZCgpIC8vZ290IHdlIHNvbWUgYnl0ZXMgPyA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTpDb25z b2xhcztjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj5saWJzc2gyX3Nlc3Npb25fbGFzdF9l cnJubzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+KCkgLy93aXRob3V0IGVycm9yPzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPmxp YnNzaDJfY2hhbm5lbF9yZWFkKCkgLSZndDsgMCBieXRlcyA9Jmd0OyA8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6Z3JlZW47YmFja2dyb3VuZDp3aGl0ZSI+bm8gcGF5bG9hZCwgaXQgaXMgbm90IGFuIGVycm9y IC0mZ3Q7IGxpYnNzaDIgdGVsbHMgdXMgaWYgaXQgaXMgZXJyb3IgIQ0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOmdyZWVuIj4tJmd0Ow0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjkuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hp dGUiPmxpYnNzaDJfc2Vzc2lvbl9sYXN0X2Vycm5vPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4o KTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6YmxhY2siPlJlbmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Vm9uOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBsaWJzc2gyLWRldmVsIFttYWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpsaWJzc2gyLWRldmVsLWJvdW5jZXNAY29vbC5oYXh4LnNlIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmxpYnNzaDItZGV2ZWwtYm91bmNlc0Bjb29sLmhheHgu c2U8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8Yj5JbSBBdWZ0cmFn IHZvbiA8L2I+QW1pcnVsIElzbGFtPGJyPg0KPGI+R2VzZW5kZXQ6PC9iPiBNaXR0d29jaCwgMTcu IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZlYnJ1YXIg MjAxNiAxMToyNDxicj4NCjxiPkFuOjwvYj4gPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpsaWJzc2gy LWRldmVsQGNvb2wuaGF4eC5zZSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+bGlic3NoMi1kZXZlbEBjb29sLmhheHguc2U8L3NwYW4+PC9h PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGI+QmV0cmVm Zjo8L2I+IGxpYnNzaDJfY2hhbm5lbF9yZWFkKCkgaXNzdWU8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIEFsbCw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBhbSBoYXZpbmcg YW4gaXNzdWUgd2l0aCB0aGUmbmJzcDtsaWJzc2gyX2NoYW5uZWxfcmVhZCgpIGZ1bmN0aW9uLiBJ IGFtIHVzaW5nIGl0IGluIGJsb2NraW5nIG1vZGUgdG8gZG93bmxvYWQgZmlsZXMgZnJvbSByZW1v dGUgc2VydmVyLiBOb3csIEkgaGF2ZSBhbiBpbnN0YW5jZSB3aGVyZQ0KIHRoZSBmaWxlIEkgYW0g dHJ5aW5nIHRvIGRvd25sb2FkLCBJIGRvIG5vdCBoYXZlIHJlYWQgcGVybWlzc2lvbi4gVGhpcyBp cyBjYXVzaW5nIHRoZSByZWFkKCkgZnVuY3Rpb24gdG8gcmV0dXJuIDAuIEkgYW0gbm90IHN1cmUs IGlmIEkgc2hvdWxkIGJyZWFrIG15IHJlYWQgbG9vcCB3aGVuIDAgaXMgcmV0dXJuZWQsIHNpbmNl IHRoZSBkb2N1bWVudGF0aW9uIGltcGxpZXMgd2Ugc2hvdWxkIGJyZWFrIHdoZW4gdGhlcmUgaXMg YSBuZWdhdGl2ZSB2YWx1ZQ0KIHJldHVybmVkLiBJIGFtIG5vdCBpZiBicmVha2luZyBvbiAwIHdp bGwgaGF2ZSB1bnByZWRpY3RhYmxlIGJlaGF2aW9yIG9uIG90aGVyIGluc3RhbmNlcy4gbmVlZCBo ZWxwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ QWxzbywgSSBjYW4gY2hlY2sgdGhlIGZpbGUgbW9kZSB3aGVuIEkgY2FsbCZuYnNwO2xpYnNzaDJf c2NwX3JlY3YoKSBmdW5jdGlvbiwgd2hhdCB3b3VsZCBiZSB0aGUgYmVzdCB3YXkgdG8gY2hlY2sg aWYgbXkgdXNlciBoYXMgcmVhZCBwZXJtaXNzaW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rIHlvdSBpbiBhZHZhbmNlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90O0ZhbWUg aXMgYSB2YXBvcjsgcG9wdWxhcml0eSBhbiBhY2NpZGVudDsgdGhlIG9ubHkgZWFydGhseSBjZXJ0 YWludHkgaXMgb2JsaXZpb24uJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KbGlic3NoMi1kZXZlbCA8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2Nvb2wuaGF4 eC5zZS9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbGlic3NoMi1kZXZlbCIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1h bi9saXN0aW5mby9saWJzc2gyLWRldmVsPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+JnF1b3Q7RmFtZSBpcyBhIHZhcG9yOyBwb3B1bGFyaXR5IGFuIGFjY2lkZW50OyB0 aGUgb25seSBlYXJ0aGx5IGNlcnRhaW50eSBpcyBvYmxpdmlvbi4mcXVvdDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_16C23041BD880F48901C072C51AC6A2E02E72F81DEFTHW99EH2MSXw_-- --===============0798418811== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============0798418811==-- From libssh2-devel-bounces@cool.haxx.se Fri Feb 19 17:09:24 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1JG8x1i006275; Fri, 19 Feb 2016 17:09:20 +0100 Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09:0:0:0:22f]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1JG8uTV003131 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 19 Feb 2016 17:08:56 +0100 Received: by mail-wm0-x22f.google.com with SMTP id g62so83597760wme.1 for ; Fri, 19 Feb 2016 08:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmgsystemsinc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=FnsI6oc/lIpaO2nivnbETqquD5ux8WEFAdXisPxF1Ag=; b=qWw1zgbttSAs+Nh7MmpkMhwo4PIqAudquHFsLgxotX9X72jLD3Wa5ZRq5B/92ydTZx 5QiRjvz5Klm2tsDAJr5a/GtV7vuS7CfbGQYET8zBylKP3VpxfPXGjpQ58upKfg+EMfZ3 iMHqkwSrTszU70gIZR261Y09Fb4hcv3WGe8JaD7VV7wDMg4mMnHlp+PGzzZjd5ia35BU 5OxuMUw6QfVqpwx8WKVCrQhpkFjwlyAzS05g0Tc1+5CrTLyGC7O+OOY/iuiLNznSjEfJ iGgJc++VnHUXFvf5FpC39nJzdA2D/CnczFdO8fhUbKaRuKsv9caZnghGy9k9REIoAXu/ Hcwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=FnsI6oc/lIpaO2nivnbETqquD5ux8WEFAdXisPxF1Ag=; b=itFuwCInb0Ahr/JbK7kFR53io3on31BqmDpbjtGzRIcytOAgDO16TDOv4bVMv+oGvN Dwon65XP/9NBCiOln7Ch8TY/PneSfqKzph16rpE/8UdxZns/CVsDY4KbwZpksE39kCDw gC/Gi39a6wJ4hcMZ6dO1GTfr53bxTC8N4Qz8siPZiLLrhRFQNkSz+X0ww1j9Q0W0tlGC 481AybMxLaCfv4/xA5xSK15fE4t4zlJPcGjWyIR+EjZ8rm52pxfS8f1b5qbkzSmcixKQ MZy2DYj7IwIEqMzqGI6PgIt5iy5ZynsaBsxmIQxSmYbneeSA0cLdL3w55OtumMiTRfhC e7Zw== X-Gm-Message-State: AG10YORypnDxNx6QvtnZni7Dr49e9BYYzJgwfErBSXu91PReDq9hR3xcXdvNqpHmPKui/MwPDKDCFGO1W6Bejw== MIME-Version: 1.0 X-Received: by 10.194.248.200 with SMTP id yo8mr13985635wjc.38.1455898132121; Fri, 19 Feb 2016 08:08:52 -0800 (PST) Received: by 10.28.93.74 with HTTP; Fri, 19 Feb 2016 08:08:52 -0800 (PST) X-Originating-IP: [173.73.192.34] In-Reply-To: References: <56377A0C.8090103@dbyron.com> Date: Fri, 19 Feb 2016 11:08:52 -0500 Message-ID: Subject: Re: ping for release From: "George Garner (online)" To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============0764105816==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============0764105816== Content-Type: multipart/alternative; boundary=089e013d1ebafeb00e052c21b229 --089e013d1ebafeb00e052c21b229 Content-Type: text/plain; charset=UTF-8 > It turned out that only uint64_t was problematic, because we define > uint32_t to int. < I hope that you mean that you defined uint32_t to unsigned int! On Sun, Feb 14, 2016 at 5:38 PM, Alexander Lamaison wrote: > On 14 February 2016 at 20:04, Alexander Lamaison > wrote: > > On 11 February 2016 at 15:13, Daniel Stenberg wrote: > >> On Mon, 2 Nov 2015, David Byron wrote: > >> > >>> Sorry to nag, but is the repo in a good state to release? Still hoping > >>> for the large file stuff to get a little farther out in the world. > >> > >> > >> I've merged the "fix SFTP" patches from the patient Jakob Egger into > master > >> now. I _think_ we might be in a decent shape for release now. > >> > >> If you disagree, please tell us why. Also, please get the latest from > git > >> and have a go at it to help us polish out the last few quirks before we > >> ship. > > > > I've just tested the latest from master and, unfortunately, it doesn't > > compile with Visual Studio 2005. The new SFTP fix introduced uint64_t > > and uint32_t, which aren't in C90. Please hold off releasing for now. > > I've pushed a fix for the build failure, and added more versions of VS > to Appveyor so that we catch this automatically next time. It turned > out that only uint64_t was problematic, because we define uint32_t to > int. > > I've also finally resurrected my old test suite that was really good > at catching SFTP stream errors. It confirmed that commit > d754fee2f24565d8c89dc37a7f05ba1222a7bfc4 introduced data corruption, > and that it has been fixed in latest master. So I think we're good to > go for a release now. > > Alex > > -- > Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel > --089e013d1ebafeb00e052c21b229 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> It turned out that only uint64_t was problematic= , because we define
> uint32_t to int. <

I hope that = you mean that you defined uint32_t to unsigned int!

On Sun, Feb 14, 2016 at 5:38 PM= , Alexander Lamaison <swish@lammy.co.uk> wrote:
On 14 February 2016 at 20:04, Alexan= der Lamaison <swish@lammy.co.uk= > wrote:
> On 11 February 2016 at 15:13, Daniel Stenberg <daniel@haxx.se> wrote:
>> On Mon, 2 Nov 2015, David Byron wrote:
>>
>>> Sorry to nag, but is the repo in a good state to release?=C2= =A0 Still hoping
>>> for the large file stuff to get a little farther out in the wo= rld.
>>
>>
>> I've merged the "fix SFTP" patches from the patient = Jakob Egger into master
>> now. I _think_ we might be in a decent shape for release now.
>>
>> If you disagree, please tell us why. Also, please get the latest f= rom git
>> and have a go at it to help us polish out the last few quirks befo= re we
>> ship.
>
> I've just tested the latest from master and, unfortunately, it doe= sn't
> compile with Visual Studio 2005.=C2=A0 The new SFTP fix introduced uin= t64_t
> and uint32_t, which aren't in C90.=C2=A0 Please hold off releasing= for now.

I've pushed a fix for the build failure, and added more versions= of VS
to Appveyor so that we catch this automatically next time.=C2=A0 It turned<= br> out that only uint64_t was problematic, because we define uint32_t to
int.

I've also finally resurrected my old test suite that was really good at catching SFTP stream errors.=C2=A0 It confirmed that commit
d754fee2f24565d8c89dc37a7f05ba1222a7bfc4 introduced data corruption,
and that it has been fixed in latest master.=C2=A0 So I think we're goo= d to
go for a release now.

Alex

--
Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/= mailman/listinfo/libssh2-devel

--089e013d1ebafeb00e052c21b229-- --===============0764105816== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============0764105816==-- From libssh2-devel-bounces@cool.haxx.se Sat Feb 20 12:43:49 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1KBhNMo016807; Sat, 20 Feb 2016 12:43:45 +0100 Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09:0:0:0:22c]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1KBhMRq016702 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 20 Feb 2016 12:43:22 +0100 Received: by mail-wm0-x22c.google.com with SMTP id g62so104042716wme.0 for ; Sat, 20 Feb 2016 03:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=K74deVLnEUfOrEptw8+YYpSUQqdVE8EVxXpPAcenwY8=; b=X7zKr6RCYAXN0UUdbbcKcEHqUBzL5Ar4KP7FV4eyhapywgzUGnyuWHDC7lkyBPz6DZ nJRiGH95VNr+dWreRXnnG9ZGtYyG/MuxG4HvfBhQrtvSmYVAP2r/d0fe0ClTZvVz/XKT GWfEDj2UEsooMKw8rdX2I8D5CdQDsYVOAVE52aYQ4fhnTpGk4y07kFdU+gPK+2UuyPCG bzicUtsGCMowqX8N9wgp6cQbf4gh/NAmxN4P32zHy52AsGPb8rBj4h73jAvUAq+IUr/d 1XpWmAT+oGw4facPa/Mg589SmNBKk3Sql6CQBFeLWjmgVJZc2FnVCLo8xWcNfSUlFRIf 7y1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=K74deVLnEUfOrEptw8+YYpSUQqdVE8EVxXpPAcenwY8=; b=U3lkCwhRPY0+R2aT8RV6qLZl3TL7PJ5qwdaG8fpZRtBPsu8bm/ovrHR1BpEgIMBV1/ TGa/T2OZuLvcjhktrZDB5VlHHWtVUvOEZAD4VKJ9SbA4fAlZ/yZ68x2FEXH8Q4RW14Un lhWjXeYqno1jhfkcyBdXU1D8pxKJ6WaO5a2XeJ7yKMIEY9KjQ5QsH0TAeX6bMQZ0HAED d2TO2q3RXb8Uh91qSerl/OzQ5CRFcRjBbbhmHSKl4voAixk+is7oZJomMUJ1WX23RGYR eYf/5IHQoFzuArVla31ms6UJFaClJvxiGMQUeaYnhMO7xQK/2Zw34D3/s4pP0sLtlOEj FURg== X-Gm-Message-State: AG10YORNZV20idYM+UaBfuPjY8X3hOxMFtupfzPbcheoHWqowSeERNA9P3dVFGDuinAXm/IwtWm1VMyycKbZJQ== MIME-Version: 1.0 X-Received: by 10.28.60.11 with SMTP id j11mr2075633wma.99.1455968597368; Sat, 20 Feb 2016 03:43:17 -0800 (PST) Received: by 10.28.93.207 with HTTP; Sat, 20 Feb 2016 03:43:17 -0800 (PST) In-Reply-To: References: <56377A0C.8090103@dbyron.com> Date: Sat, 20 Feb 2016 11:43:17 +0000 X-Google-Sender-Auth: NKHsIm_AUTc4un89REnr7IZaYzw Message-ID: Subject: Re: ping for release From: Alexander Lamaison To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id u1KBhNMo016807 On 19 February 2016 at 16:08, George Garner (online) wrote: >> It turned out that only uint64_t was problematic, because we define >> uint32_t to int. < > > I hope that you mean that you defined uint32_t to unsigned int! Yes, indeed I did. -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Feb 22 08:45:48 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1M7jHqE008012; Mon, 22 Feb 2016 08:45:44 +0100 Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07:0:0:0:229]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1LDQnOD013358 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 21 Feb 2016 14:26:49 +0100 Received: by mail-lf0-x229.google.com with SMTP id l143so79146215lfe.2 for ; Sun, 21 Feb 2016 05:26:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=e76EDpNN0UtQiOOHTS6gkfPnJlh89ZV+MmjuAkILJDM=; b=N4QXnBtxi+9tI68d/IO+DRgOBzzDIIu5A0CwxIcI4Y36FVOwlcYj/WGvxr5pWuzOCM OM6GxDjQtOipZ2+ExGCiJxD83d2XwMd0gBgpm6oUsR1+EBjFncGYfhyuKjNQCWjFoJQW 5CI1AD3TRAgk61PRSUthqvak3GMB4FIWFtSoTh6HGKzJSUWrkgWybIc9j0sgApe0ex+r +XvhrxZgjWBiifG3IWSyrbvpvfL2yUb5qK/XxyEydiTmc5bAfK2Kr/f4iB479QOT0HQS Gnei2GNnsUorcQOUBKbX8qY+wBbRKLnq4VWbUGkQiBWXQtsTMBrbvMAN+OzEgGSXq03A sT2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=e76EDpNN0UtQiOOHTS6gkfPnJlh89ZV+MmjuAkILJDM=; b=I8OJsBqb6jauEcHeuolHPfgn8E4nU4ZlbcrvfwVDWh0y2kwv9GY2gKzPUOWbf40q6E qqzPrjFaaE+DLPZBvbu5A8Letr5x14ceAack4iXmMOGjHQSYkqVzv8AB0VrPG2L41eDC 3iBJbdhkc2Iwji8j9dYuabva4wL/v8bCAwM0TuRuLTE1HUffFky4sGL9cdvVRzemDnve nr8s+nX5ivjcIQxyaUvjgEUsSnkgF18yzll5zS1e6Szh4o3Pr9q1T49GLIlloMyUSzNg b2DKHv3V9WBVEkl1k9hLPxqco2Ukifs5qra76giWay3Y+I+bpzQ3/qGNTiYV6lByfdvI 16Sg== X-Gm-Message-State: AG10YOT6K4KBQOP3hBcu670KstQjqgC/r1X24qcq3TeXGr5/nS3fGqdNdNPplQdrrcBE66TDZ34xZEOagBLrUw== MIME-Version: 1.0 X-Received: by 10.25.19.28 with SMTP id j28mr8760312lfi.50.1456061205806; Sun, 21 Feb 2016 05:26:45 -0800 (PST) Received: by 10.25.32.140 with HTTP; Sun, 21 Feb 2016 05:26:45 -0800 (PST) In-Reply-To: <16C23041BD880F48901C072C51AC6A2E02E72F81@DEFTHW99EH2MSX.ww902.siemens.net> References: <16C23041BD880F48901C072C51AC6A2E02E72E8F@DEFTHW99EH2MSX.ww902.siemens.net> <16C23041BD880F48901C072C51AC6A2E02E72F81@DEFTHW99EH2MSX.ww902.siemens.net> Date: Sun, 21 Feb 2016 17:56:45 +0430 Message-ID: Subject: Re: libssh2_channel_read() issue From: Amirul Islam To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============0399628185==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============0399628185== Content-Type: multipart/alternative; boundary=001a11406792f184e7052c47aac7 --001a11406792f184e7052c47aac7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Rene, I have checked the sb.st_mode it returns 0x836B 68E3, I dont know if that is a valid value either. Following is the function which downloads the files. Before this is just establishing ssh connection and authentication. What did I do wrong? int scpGetFile(LIBSSH2_SESSION **session, int *sock, const struct instance *inst, const char *path, const char *filename, const char *drop) { LIBSSH2_CHANNEL *channel; struct stat fileinfo; int got =3D 0, rc, retval =3D true; char getfile[PATH_MAX], dropfile[PATH_MAX]; FILE *fp; sprintf(getfile, "%s/%s", path, filename); sprintf(dropfile, "%s/%s", drop, filename); if (!(fp =3D fopen(dropfile, "wb"))) { printlog("EROR", "%s - Cannot create file (%s) for writing.", inst->shortdesc, dropfile); return false; } if (!(channel =3D libssh2_scp_recv(*session, getfile, &fileinfo))) { printlog("EROR", "%s - Cannot create channel to download - %s", inst->shortdesc, getfile); fclose(fp); unlink(dropfile); return false; } //printlog("EROR", "%ld", fileinfo.st_mode); while (got < fileinfo.st_size) { char buffer[MAXSCPBUF]; int amount =3D MAXSCPBUF; if ((fileinfo.st_size - got) < amount) amount =3D (int) (fileinfo.st_size - got); rc =3D libssh2_channel_read(channel, buffer, amount); if (rc > 0) { fwrite(buffer, rc, 1, fp); } else if (rc < 0) { printlog("EROR", "%s - Read error from channel for %s from %s", inst->shortdesc, filename, inst->shortdesc); retval =3D false; break; } // else // { // if (libssh2_channel_eof(channel)) // { // printlog("EROR", "%s - EOF sent from channel for %s", inst->shortdesc, filename); // break; // } // printlog("EROR", "%s - Zero?"); // } got +=3D rc; } printlog("INFO", "%s - Downloaded file %s, filesize: %d", inst->shortdesc, filename, fileinfo.st_size); fclose(fp); libssh2_channel_free(channel); channel =3D NULL; if (!retval) unlink(dropfile); return retval; } On Fri, Feb 19, 2016 at 1:44 PM, Belau, Rene (ext) < belau.rene.ext@siemens.com> wrote: > Hi Amirul, > > > > sorry but this sounds weird to me. > > > > After call of libssh2_scp_recv() you got a handle and sb.mode =3D > 0x0040(POSIX) or 0x0100(WIN) for read permissions? > > > > If it is true > > > > at the same usecase, as you described. > > > > Logged in user and directory have rights. -> > > > > Drectory >> me:me drwxrwxrwx > > File inside >> me:me =E2=80=93w------- > > > > My result: for libssh2(1.4.3 && 1.5.0) after 3 tries (test with blocking > mode and tested again three different ssh servers) > > 1. libssh2_scp_recv() //handle =3D null, stat =3D {0}, > libssh2_session_last_errno() //error -28 > > My result: for libssh2(1.4.3 && 1.5.0) after 3 tries (test with > non-blocking mode and tested again three different ssh servers) > > 1. libssh2_scp_recv() //handle =3D null, stat =3D {0}, > libssh2_session_last_errno() //error -37 > > 2. libssh2_scp_recv() //handle =3D null, stat =3D {0}, > libssh2_session_last_errno() //error -37 > > 3. libssh2_scp_recv() //handle =3D null, stat =3D {0}, > libssh2_session_last_errno() //error -28 > > Just fine, how it should be. > > > > > > Do you use an older version? you could dig into libssh2 -> scp.c -> > scp_recv state 2 or 3 > > > > > > Rene > > > > --- > > > > *Von:* libssh2-devel [mailto:libssh2-devel-bounces@cool.haxx.se > ] *Im Auftrag von *Amirul Islam > *Gesendet:* Mittwoch, 17. Februar 2016 14:14 > *An:* libssh2 development > *Betreff:* Re: libssh2_channel_read() issue > > > > Hi Rene, > > > > I have checked for last errno on both cases when libssh2_scp_recv() & > libssh2_channel_read() is called, libssh2_session_last_errno() return 0. > The issues is that my user has access to the remote folder, but does not > have read permission on the target file which is contained in that folder= . > So the return value from libssh2_channel_read() is always 0 and sb.st_siz= e > is 1. > > > > you can simulate and check what you get > > > > On Wed, Feb 17, 2016 at 4:57 PM, Belau, Rene (ext) < > belau.rene.ext@siemens.com> wrote: > > You need to do an operation and then check session error. > > > > libssh2_scp_recv() //handle null, return -37 > > libssh2_session_last_errno() //error -28 scp protocol error (libssh2 > version 1.5.0) if you have no rights at target device > > > > libssh2_channel_read() //got we some bytes ? > > libssh2_session_last_errno() //without error? > > > > libssh2_channel_read() -> 0 bytes =3D> no payload, it is not an error -> > libssh2 tells us if it is error ! -> libssh2_session_last_errno() > > > > > > Rene > > > > *Von:* libssh2-devel [mailto:libssh2-devel-bounces@cool.haxx.se] *Im > Auftrag von *Amirul Islam > *Gesendet:* Mittwoch, 17. Februar 2016 11:24 > *An:* libssh2-devel@cool.haxx.se > *Betreff:* libssh2_channel_read() issue > > > > Hi All, > > > > I am having an issue with the libssh2_channel_read() function. I am using > it in blocking mode to download files from remote server. Now, I have an > instance where the file I am trying to download, I do not have read > permission. This is causing the read() function to return 0. I am not sur= e, > if I should break my read loop when 0 is returned, since the documentatio= n > implies we should break when there is a negative value returned. I am not > if breaking on 0 will have unpredictable behavior on other instances. nee= d > help > > > > Also, I can check the file mode when I call libssh2_scp_recv() function, > what would be the best way to check if my user has read permission? > > > > Thank you in advance. > > > > -- > > > > "Fame is a vapor; popularity an accident; the only earthly certainty is > oblivion." > > > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel > > > > > > -- > > > > "Fame is a vapor; popularity an accident; the only earthly certainty is > oblivion." > > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel > > --=20 "Fame is a vapor; popularity an accident; the only earthly certainty is oblivion." --001a11406792f184e7052c47aac7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Rene,

I have checked the sb.st_mode = it returns 0x836B 68E3, I dont know if that is a valid value either. Follow= ing is the function which downloads the files. Before this is just establis= hing ssh connection and authentication. What did I do wrong?

=
int scpGetFile(LIBSSH2_SESSION **session, int *sock, const = struct instance *inst, const char *path, const char *filename, const char *= drop)
{
LIBSSH2_CHANNEL *channel;
struct stat fileinfo;
int got =3D 0, rc, retval =3D true;
char getfile[PATH_MAX], dropf= ile[PATH_MAX];
FILE *fp;
sprintf(getfile,= "%s/%s", path, filename);
sprintf(dropfile, "%s/%s", drop, filename)= ;

if (!(fp =3D fopen(dropfile, "wb")))
{
printlog("EROR", "%s - Cannot creat= e file (%s) for writing.", inst->shortdesc, dropfile);
return false;
<= span class=3D"" style=3D"white-space:pre"> }

if (!(channel =3D libs= sh2_scp_recv(*session, getfile, &fileinfo)))
{
printlog("EROR", "%s - Cannot create= channel to download - %s", inst->shortdesc, getfile);
fclose(fp)= ;
unlink(drop= file);

= return false;
}

//printlog("EROR", "%ld", fileinfo.st_mode)= ;

while (got < fileinfo.st_size)
{
char buffer[MAXSCPBUF];
int amount =3D MAXSCPBUF;

<= span class=3D"" style=3D"white-space:pre"> if ((fileinfo.st_size - = got) < amount)
<= /span>amount =3D (int) (fileinfo.st_size - got);

<= span class=3D"" style=3D"white-space:pre"> rc =3D libssh2_channel_r= ead(channel, buffer, amount);

if (rc > 0)
{
fwrite(buffer, rc, 1, fp);
}
else if (rc < 0)
{
printlog("EROR", "%s - Read error fr= om channel for %s from %s", inst->shortdesc, filename, inst->sho= rtdesc);
ret= val =3D false;
break;
}
// else=C2=A0<= /div>
// {
// if (libssh2_channel_eof(channel))
// {
// printlog("EROR", "%s - EOF sent from channel for %s",= inst->shortdesc, filename);
// b= reak;
// }
// printlog("EROR", "%s - Zero?");
// }

got +=3D rc;
}
printlog(&qu= ot;INFO", "%s - Downloaded file %s, filesize: %d", inst->= shortdesc, filename, fileinfo.st_size);

fclose(fp);
libssh2_channel_free(channel);
channel =3D NULL;<= /div>

if (!retval)
unlink(dropfile);

return retval;
}

On Fri, Feb 19, 2016 at 1:4= 4 PM, Belau, Rene (ext) <belau.rene.ext@siemens.com> wrote:

Hi Amirul,

=C2= =A0

sorry=C2=A0 = but this sounds weird to me.

=C2= =A0

After call o= f libssh2_scp_recv() you got a handle and sb.mode= =3D 0x0040(POSIX) or 0x0100(WIN) for read permissions?

=C2=A0

If it is true

=C2=A0

at the same usecase, as you described.

=C2=A0

Logged in user and directory have rights. ->=

=C2=A0

Drectory >> me:me drwxrwxrwx

File inside >> me:me =E2=80=93w-------

=C2=A0

My result: for libssh2(1.4.3 &&= amp; 1.5.0) after 3 tries (test with blocking mode and tested again three d= ifferent ssh servers)

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 libssh2_scp_recv() //handl= e =3D null, stat =3D {0},=C2=A0 libssh2_session_last_errno() //error -28

My result: for libssh2(1.4.3 &&= amp; 1.5.0) after 3 tries (test with non-blocking mode and tested again thr= ee different ssh servers)<= /p>

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 libssh2_scp_recv() //handl= e =3D null, stat =3D {0}, libssh2_session_last_errno() //error -37

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 libssh2_scp_recv() //handl= e =3D null, stat =3D {0}, libssh2_session_last_errno() //error -37

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 libssh2_scp_recv() //handl= e =3D null, stat =3D {0},=C2=A0 libssh2_session_last_errno() //error -28

Just fine, how it should be.=

=C2= =A0

=C2= =A0

Do you use a= n older version? you could dig into libssh2 -> scp.c -> sc= p_recv state 2 or 3

=C2= =A0

=C2= =A0

Rene<= u>

=C2= =A0

---

=C2=A0

Von: libssh2-d= evel [mailto:libssh2-devel-bounces@cool.haxx.se] Im Auftrag von Amirul Islam
Gesendet: Mittwoch, 17. Februar 20= 16 14:14
An: libssh2 development
Betreff: Re: libssh2_channel_read() issue

=C2=A0

Hi Rene,

=C2=A0

I have checked for last errno o= n both cases when libssh2_scp_recv() & libssh2_channel_read() is called= , libssh2_session_last_errno() return 0. The issues is that my user has acc= ess to the remote folder, but does not have read permission on the target file which is contained in that folder. So t= he return value from=C2=A0libssh2_channel_read() is always 0 and sb.st_size= is 1.

=C2=A0

you can simulate and check what= you get

=C2=A0

On Wed, Feb 17, 2016 at 4:57 PM= , Belau, Rene (ext) <belau.rene.ext@siemens.com<= /a>> wrote:

You need to do an operation and the= n check session error.

=C2=A0<= u>

libssh2_scp_recv() //handle null, return -37=

libssh2_session_last_errno() //error -28 scp protocol error (libssh2 version= 1.5.0) if you have no right= s at target device

=C2=A0<= u>

libssh2_channel_read() //got we some bytes ?

libssh2_session_last_errno() //without er= ror?

=C2=A0

libssh2_channel_read() -> 0 bytes =3D> no payload, it is not an error -> libssh2 tells us i= f it is error ! -> libssh2_session_last_errno()

=C2=A0

=C2=A0

Rene

=C2=A0

Von: libssh2-d= evel [mailto:libssh2-devel-bounces@cool.haxx.se<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">] Im Auftrag von Amirul Islam
Gesendet: Mittwoch, 17. Februar 20= 16 11:24
An: libssh2-devel@cool.haxx.se
Betreff: libssh2_channel_read() issue=

=C2=A0

Hi All,

=C2=A0

I am having an issue with the= =C2=A0libssh2_channel_read() function. I am using it in blocking mode to do= wnload files from remote server. Now, I have an instance where the file I am trying to download, I do not have read permission. This is c= ausing the read() function to return 0. I am not sure, if I should break my= read loop when 0 is returned, since the documentation implies we should br= eak when there is a negative value returned. I am not if breaking on 0 will have unpredictable behavior on ot= her instances. need help

=C2=A0

Also, I can check the file mode= when I call=C2=A0libssh2_scp_recv() function, what would be the best way t= o check if my user has read permission?

=C2=A0

Thank you in advance.=

=C2=A0

--

=C2=A0

"Fame is a vapor; populari= ty an accident; the only earthly certainty is oblivion."=

=
_______________________________________________
libssh2-devel http://cool.haxx.se= /cgi-bin/mailman/listinfo/libssh2-devel<= /u>



=C2=A0

--

=C2=A0

"Fame is a vapor; populari= ty an accident; the only earthly certainty is oblivion."=


_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/= mailman/listinfo/libssh2-devel




--

"Fame is a vapo= r; popularity an accident; the only earthly certainty is oblivion."
--001a11406792f184e7052c47aac7-- --===============0399628185== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============0399628185==-- From libssh2-devel-bounces@cool.haxx.se Tue Feb 23 09:10:18 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1N89rSL004802; Tue, 23 Feb 2016 09:10:14 +0100 Received: from giant.haxx.se (dast@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1N89q0X004737 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 23 Feb 2016 09:09:52 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id u1N89qbv004734 for ; Tue, 23 Feb 2016 09:09:52 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Tue, 23 Feb 2016 09:09:52 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: the libssh2.org web site on HTTPS Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id u1N89rSL004802 Hey The libssh2.org web site is now on HTTPS. Enjoy. -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Feb 23 09:51:40 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1N8pW1A003375; Tue, 23 Feb 2016 09:51:40 +0100 Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1N8pTG0003332 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 23 Feb 2016 09:51:30 +0100 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 57AE022631; Tue, 23 Feb 2016 03:51:27 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 23 Feb 2016 03:51:27 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=SGxCp/VLj+C+qHT GSM9zXMMBJbQ=; b=bpxKgNCc6di9gRzYFlqKLbShHJQsLJZiHNu4RyMvS3JEdU2 I+Mh6y3MiuFBeTc6ye5GOQDKp234PdQP8LodSXYSSSA4xdOYwcAI04zI1N9LIyuB VA2dBANLKBlKy7i+jJMQOyuosu/pL3K3k6B+vtlV7YJc+3dmXYBnK8s4eX5I= X-Sasl-enc: JIf/suqAiYuYvZzXFgCdDwxVxl2a94p2QG2cxwfcjwZ/ 1456217487 Received: from [192.168.0.3] (cm225-232.liwest.at [81.10.225.232]) by mail.messagingengine.com (Postfix) with ESMTPA id D9369C0001B for ; Tue, 23 Feb 2016 03:51:26 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: the libssh2.org web site on HTTPS From: Jakob Egger In-Reply-To: Date: Tue, 23 Feb 2016 09:51:25 +0100 Message-Id: <0A080EAB-4273-4263-88D6-C06017281DCA@eggerapps.at> References: To: libssh2 development X-Mailer: Apple Mail (2.3112) X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id u1N8pW1A003375 Awesome! Thanks! Jakob > On 23 Feb 2016, at 09:09, Daniel Stenberg wrote: > > Hey > > The libssh2.org web site is now on HTTPS. Enjoy. > > -- > > / daniel.haxx.se > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Feb 23 14:14:22 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1NDDwHD009861; Tue, 23 Feb 2016 14:14:17 +0100 Received: from giant.haxx.se (dast@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1NDDvl5009845 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 23 Feb 2016 14:13:57 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id u1NDDvVE009840 for ; Tue, 23 Feb 2016 14:13:57 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Tue, 23 Feb 2016 14:13:57 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: [RELEASE] libssh2 1.7.0 Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1129329158-825357262-1456218721=:3343" Content-ID: X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1129329158-825357262-1456218721=:3343 Content-Type: text/plain; FORMAT=flowed; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-ID: Hi friends, I'm happy to announce libssh2 1.7.0. Pay special attention to the security advisory shipped with this relase. Download libssh2 like always from https://www.libssh2.org/ libssh2 1.7.0 This release includes the following changes: o libssh2_session_set_last_error: Add function o mac: Add support for HMAC-SHA-256 and HMAC-SHA-512 o WinCNG: support for SHA256/512 HMAC o kex: Added diffie-hellman-group-exchange-sha256 support o OS/400 crypto library QC3 support This release includes the following security advisory: o diffie_hellman_sha256: convert bytes to bits CVE-2016-0787: http://www.libssh2.org/adv_20160223.html This release includes the following bugfixes: o SFTP: Increase speed and datasize in SFTP read o openssl: make libssh2_sha1 return error code o openssl: fix memleak in _libssh2_dsa_sha1_verify() o cmake: include CMake files in the release tarballs o Fix builds with Visual Studio 2015 o hostkey.c: Fix compiling error when OPENSSL_NO_MD5 is defined o GNUmakefile: add support for LIBSSH2_LDFLAG_EXTRAS o GNUmakefile: add -m64 CFLAGS when targeting mingw64 o kex: free server host key before allocating it (again) o SCP: add libssh2_scp_recv2 to support large (> 2GB) files on windows o channel: Detect bad usage of libssh2_channel_process_startup o userauth: Fix off by one error when reading public key file o kex: removed dupe entry from libssh2_kex_methods o _libssh2_error: Support allocating the error message o hostkey: fix invalid memory access if libssh2_dsa_new fails o hostkey: align code path of ssh_rsa_init to ssh_dss_init o libssh2.pc.in: fix the output of pkg-config --libs o wincng: fixed possible memory leak in _libssh2_wincng_hash o wincng: fixed _libssh2_wincng_hash_final return value o add OpenSSL 1.1.0-pre2 compatibility o agent_disconnect_unix: unset the agent fd after closing it o sftp: stop reading when buffer is full o sftp: Send at least one read request before reading o sftp: Don't return EAGAIN if data was written to buffer o sftp: Check read packet file offset o configure: build "silent" if possible o openssl: add OpenSSL 1.1.0-pre3-dev compatibility o GNUmakefile: list system libs after user libs This release would not have looked like this without help, code, reports and advice from friends like these: Alexander Lamaison, Andreas Schneider, brian m. carlson, Daniel Stenberg, David Byron, Jakob Egger, Kamil Dudka, Marc Hoersken, Mizunashi Mana, Patrick Monnerat, Paul Howarth, Salvador Fandino, Salvador Fandiño, Salvador Fandiño, Viktor Szakats, Will Cosgrove, (16 contributors) Thanks! (and sorry if I forgot to mention someone) -- / daniel.haxx.se --1129329158-825357262-1456218721=:3343 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --1129329158-825357262-1456218721=:3343-- From libssh2-devel-bounces@cool.haxx.se Tue Feb 23 14:14:23 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1NDEL0x010063; Tue, 23 Feb 2016 14:14:22 +0100 Received: from giant.haxx.se (dast@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1NDE12G009879 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 23 Feb 2016 14:14:01 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id u1NDE1YA009875 for ; Tue, 23 Feb 2016 14:14:01 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Tue, 23 Feb 2016 14:14:01 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: [SECURITY ADVISORY] Truncated Difffie-Hellman secret length Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id u1NDEL0x010063 Truncated Difffie-Hellman secret length ======================================= Project libssh2 Security Advisory, February 23rd 2016 - [Permalink](https://www.libssh2.org/adv_20160223.html) VULNERABILITY ------------- During the SSHv2 handshake when libssh2 is to get a suitable value for 'group order' in the Diffle Hellman negotiation, it would pass in number of *bytes* to a function that expected number of *bits*. This would result in the library generating numbers using only an 8th the number of random bits than what were intended: 128 or 256 bits instead of 1023 or 2047 Using such drastically reduced amount of random bits for Diffie Hellman weakended the handshake security significantly. There are no known exploits of this flaw at this time. INFO ---- The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2016-0787 to this issue. AFFECTED VERSIONS ----------------- - Affected versions: all versions to and including 1.6.0 - Not affected versions: libssh2 >= 1.7.0 libssh2 is used by many applications, but not always advertised as such! THE SOLUTION ------------ libssh2 1.7.0 makes sure that there's a convertion done from number of bytes to number of bits when the internal `_libssh2_bn_rand` function is called. A patch for this problem is available at: https://www.libssh2.org/CVE-2016-0787.patch RECOMMENDATIONS --------------- We suggest you take one of the following actions immediately, in order of preference: A - Upgrade to libssh2 1.7.0 B - Apply the patch and rebuild libssh2 TIME LINE --------- It was first reported to the libssh2 project on February 7 2016 by Andreas Schneider. libssh2 1.7.0 was released on February 23rd 2016, coordinated with the publication of this advisory. CREDITS ------- Reported by Andreas Schneider. Thanks a lot! -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Feb 23 16:21:05 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1NFKl7n012048; Tue, 23 Feb 2016 16:21:03 +0100 Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09:0:0:0:233]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1NFKjhT011906 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 23 Feb 2016 16:20:45 +0100 Received: by mail-wm0-x233.google.com with SMTP id c200so225810142wme.0 for ; Tue, 23 Feb 2016 07:20:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmgsystemsinc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=t5RfvDfulwfOO3xrmcEZwN5QHF5/Hl46KJl816X61lY=; b=KvelvhGvIqxmBRChPm1pnyHPSDHAm33h2CgYgiqdKPcC418+PGQi8ocb/Mew7VDxs4 ii3dn3GehWVWGW6Ehu41lNntBB6qoDDbvs0OFo89qjisRC/jGgBpXz1+/uz94buzuhT4 5xzWnVWr25zJHl+iOYpCYtTI+HfjIJhT0SCKndVKxY+jeD4VDsb90FFTMbz6pQeq61Qb rGPtErUKhb7RrUEjsFzYSIDoQgyBQ2v0z7y9DCKGDr3d5zWCLrpde4NqaWCZwU8+Ir1j yj9MnIC7ZjQumQv7ZjkDMIfIV5TNt10lvsm3luastav56XD2hljwAv5MWlSBpM+gyln6 KyKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=t5RfvDfulwfOO3xrmcEZwN5QHF5/Hl46KJl816X61lY=; b=DYBy6h40t/NJjZ9vfSsOezbMOtBq4dZ33uhvgLv2kOGDtuqK5xdvEeIY0GwV86Mqrs x4/R8y0XDApgo62+2gBkvfWeJsze2v7mH5hplTPmQGtY09VU5cnmTsJ0STg5s1xATR4M 0ulIY4bLDNor94QSH29LzgX1E7DzbDGRjcn7qa+yoDB2oKTioMV+k/xKs9L030OUk9dA SofhyErMAi7AnEd/QpkvBPADSr6oJs6zIo41nW31NAaB3bbAvfLTP225isTGgdM0eQfx VED75Z6q+bEi+NpCFppuj5XIlS4vur5zCoEA4DMgFY2mConlql75KxCSnk1w9N+EXHrp cLQg== X-Gm-Message-State: AG10YORxBk3noPeqp9HYJqPj33FwGCoFvq/8nXT992mYc5ghJhshIH8g0lKmBPalTaelKdgbwcizQct5XT9oxg== MIME-Version: 1.0 X-Received: by 10.28.99.136 with SMTP id x130mr20077599wmb.12.1456240841297; Tue, 23 Feb 2016 07:20:41 -0800 (PST) Received: by 10.28.93.74 with HTTP; Tue, 23 Feb 2016 07:20:41 -0800 (PST) X-Originating-IP: [74.96.102.139] Date: Tue, 23 Feb 2016 10:20:41 -0500 Message-ID: Subject: Re: [RELEASE] libssh2 1.7.0 From: "George Garner (online)" To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============1782699041==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============1782699041== Content-Type: multipart/alternative; boundary=001a114877f80e1df8052c717e4e --001a114877f80e1df8052c717e4e Content-Type: text/plain; charset=UTF-8 What is the link to the PGP/GPG key that was used to sign the snapsot? Ideally, please put a link to this key on your main web page. --001a114877f80e1df8052c717e4e Content-Type: text/html; charset=UTF-8
What is the link to the PGP/GPG key that was used to sign the snapsot? Ideally, please put a link to this key on your main web page.
--001a114877f80e1df8052c717e4e-- --===============1782699041== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============1782699041==-- From libssh2-devel-bounces@cool.haxx.se Tue Feb 23 20:41:22 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1NJexrU006350; Tue, 23 Feb 2016 20:41:17 +0100 Received: from giant.haxx.se (dast@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1NJev1Y006271 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 23 Feb 2016 20:40:57 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id u1NJevsg006268 for ; Tue, 23 Feb 2016 20:40:57 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Tue, 23 Feb 2016 20:40:57 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: [SECURITY ADVISORY] Truncated Difffie-Hellman secret length In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id u1NJexrU006350 On Tue, 23 Feb 2016, Daniel Stenberg wrote: > A patch for this problem is available at: > > https://www.libssh2.org/CVE-2016-0787.patch Will Cosgrove pointed out to me that the patch is probably a bit too simple as it missed fixing the diffie_hellman_sha1() function. And 'yumkam' added this remark on github: https://github.com/libssh2/libssh2/commit/ca5222ea819cc5ed797860070b4c6c1aeeb28420#commitcomment-16277362 ... of which the second part I'm not really qualified to debate much, other than it doesn't match what I've been told when we got this bug reported and worked on a fix. I'll welcome further thoughts and feedback on this! -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Feb 23 22:12:12 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1NLBukB000625; Tue, 23 Feb 2016 22:12:10 +0100 Received: from mail-out.m-online.net (mail-out.m-online.net [IPv6:2001:a60:0:28:0:1:25:1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1NLBso1000591 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 23 Feb 2016 22:11:55 +0100 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3q8tNq0sPyz3hjdF for ; Tue, 23 Feb 2016 22:11:55 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 3q8tNq02qXzvh1j for ; Tue, 23 Feb 2016 22:11:54 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavisd-new, port 10024) with ESMTP id 0Wk5H0ILkaeB for ; Tue, 23 Feb 2016 22:11:53 +0100 (CET) X-Auth-Info: YT+p5/mmYiPMUUDZsAOebDG31eiuLaTF6eeezLwg3JTHtppKpGAs4IxZL0v2vG0c Received: from colibri.localdomain (ppp-93-104-107-19.dynamic.mnet-online.de [93.104.107.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA for ; Tue, 23 Feb 2016 22:11:53 +0100 (CET) Received: by colibri.localdomain (Postfix, from userid 501) id 2AED660398; Tue, 23 Feb 2016 22:11:52 +0100 (CET) Date: Tue, 23 Feb 2016 22:11:52 +0100 From: Dan Fandrich To: libssh2-devel@cool.haxx.se Subject: Re: libssh2 hangs in curl testsuite Message-ID: <20160223211152.GA9487@coneharvesters.com> Mail-Followup-To: libssh2-devel@cool.haxx.se References: <20160121080411.GA24376@coneharvesters.com> <20160206185735.GA22429@coneharvesters.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160206185735.GA22429@coneharvesters.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id u1NLBukB000625 On Sat, Feb 06, 2016 at 07:57:35PM +0100, Dan Fandrich wrote: > I looked into this and the loop is happening within gcry_mpi_powm due to an > invalid internal condition. I've brought it to the gcrypt devel mailing list. > The code calling this is new in libssh2 (commit fc4a969a) but still, gcrypt > shouldn't be hanging like this. I reported it to the libgcrypt project[1] and they quickly found the bug in libgcrypt and came up with a fix. Presumably, the fix will be in the next release (I guess ver. 1.6.6). It's a longstanding bug (that might only affect 32-bit systems) and it's only triggered in libssh2 starting with ver. 1.7.0. If someone else runs into this, try upgrading libgcrypt. [1] https://bugs.gnupg.org/gnupg/issue2256 _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Feb 24 03:41:44 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1O2fMUR013901; Wed, 24 Feb 2016 03:41:41 +0100 Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09:0:0:0:231]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1O2fJQg013846 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 24 Feb 2016 03:41:20 +0100 Received: by mail-wm0-x231.google.com with SMTP id b205so16868330wmb.1 for ; Tue, 23 Feb 2016 18:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmgsystemsinc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=K08CRmDh20gaegvFw7R52IhRToVG1z0lIuXfRFHkFuk=; b=Sl+oSpHBSBReM0ORk/d8CYKBS2pqx7O/weUtw3RpZMwCGtu/4bJK0rE78w10XRtmfv ZssAF0EcQBVSiIcHS5ksG0RRjE9F43h7Sx2uw5MxiFS6cyAW0E+HBVxYi1p1wgvDCWAy wn+Q/zNS/5wCMVSfuaCqUWhFDlXuqMK6qMmKfpAWZ6hcRk17iZ/rdALIh6dB/BeIh7df mtUovpWt7vh3ZUsJWHdV1EdSAJIj9N3o6WKPcOM/ysZfADp6KOwSf6/byna1KpcKUByP 6gKFA6CrFKPzSrGBPksmOXsfw8SoEWizwC257mT13IGv4s3HL3FU992u6B3ldHL1x5eM vmiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=K08CRmDh20gaegvFw7R52IhRToVG1z0lIuXfRFHkFuk=; b=SZe0grdDSuzXp0Vp9qxXnGjdf4LTh2tVP8qwTtHgX5EIL3HQ9b1Vj9/mQSwR1gt9Qh pvSLeovJZ7whLMLcGP2+ApiVyf7c7YRaH7d5UIRiTVWDxGI/ApY69j4VhTLdeKTbyLE4 4uwcs3BMUSoXnIh8mEhfIeTtLPc4WOuaCIjC8PYvQkG/eOhV7UZqp5fI5z7qvgPRc1HU xNvNg9LGRQSe/9SaklUJNYm3jcvmu3urQ0rB37FYlTurRk2WbH28FE3WUtRrSzvYNTFV EuZO3iJV+6emXeF2UXWctIytrjTNOyc48QJYjgTZyJKuyeuFVF7NBF2TLaoNoMv+2eGH E/SA== X-Gm-Message-State: AG10YOQ/yM1wfsp07kNLO4gSdJ1Uq61N9Sbk0YXdqdRLpKfjon+2qPQgfZP2+cNFMFb/7m4k6HnEOQxygtC1wQ== MIME-Version: 1.0 X-Received: by 10.194.24.39 with SMTP id r7mr34727528wjf.86.1456281675963; Tue, 23 Feb 2016 18:41:15 -0800 (PST) Received: by 10.28.93.74 with HTTP; Tue, 23 Feb 2016 18:41:15 -0800 (PST) X-Originating-IP: [74.96.102.139] Date: Tue, 23 Feb 2016 21:41:15 -0500 Message-ID: Subject: Re: [SECURITY ADVISORY] Truncated Difffie-Hellman secret length From: "George Garner (online)" To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============2075582749==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============2075582749== Content-Type: multipart/alternative; boundary=047d7b5d9637fd3989052c7aff1e --047d7b5d9637fd3989052c7aff1e Content-Type: text/plain; charset=UTF-8 Yes, diffie_hellman_sha1() has the same problem. Looking at the code, I see a number of other problems: 1. _libssh2_bn_ctx_new(), _libssh2_bn_init() and _libssh2_bn_init_from_bin() can fail if there are insufficient resources to allocate the _libssh2_bn_ctx and _libssh2_bn structures but you don't test the return value for NULL. One place where the error might be detected is where you call _libssh2_bn_rand, but you ignore the return value from _libssh2_bn_rand. 2. The name group_order appears to be misleading as it suggest a relationship with the Diffie-Hellman group concept. In fact, it appears to be the length of p in bytes that is read from a SSH packet. 3. Where is the p_len/group_order parameter validated? In kex_method_diffie_hellman_group_exchange_sha256_key_exchange it is converted from network byte order and accepted at face value. What happens if a malicious packet is received with a bogus value for p_len? --047d7b5d9637fd3989052c7aff1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, diffie_hellman_sha1() has the same problem.= =C2=A0 Looking at the code, I see a number of other problems:

1. _li= bssh2_bn_ctx_new(), _libssh2_bn_init() and _libssh2_bn_init_from_bin() can = fail if there are insufficient resources to allocate the _libssh2_bn_ctx an= d _libssh2_bn structures but you don't test the return value for NULL.= =C2=A0 One place where the error might be detected is where you call _libss= h2_bn_rand, but you ignore the return value from _libssh2_bn_rand.=C2=A0
2. The name group_order appears to be misleading as it suggest = a relationship with the Diffie-Hellman group=C2=A0 concept.=C2=A0 In fact, = it appears to be the length of p in bytes that is read from a SSH packet.= =C2=A0

3. Where is the p_len/group_order parameter validated?= =C2=A0 In kex_method_diffie_hellman_group_exchange_sha256_key_exchange it i= s converted from network byte order and accepted at face value.=C2=A0 What = happens if a malicious packet is received with a bogus value for p_len? =C2= =A0
--047d7b5d9637fd3989052c7aff1e-- --===============2075582749== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============2075582749==-- From libssh2-devel-bounces@cool.haxx.se Wed Feb 24 05:17:24 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1O4H69T022483; Wed, 24 Feb 2016 05:17:23 +0100 Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1O4H3bZ022314 for ; Wed, 24 Feb 2016 05:17:05 +0100 Received: from OwnerPC311012 (unknown [203.202.164.190]) (Authenticated sender: sisyphus1@optusnet.com.au) by mail104.syd.optusnet.com.au (Postfix) with ESMTPA id 5C81D423900 for ; Wed, 24 Feb 2016 15:16:51 +1100 (AEDT) Message-ID: <99E668A3CEB74C7892B3F2E26E59520B@OwnerPC311012> From: To: Subject: [1.7.0] Cannot build statically on Windows Date: Wed, 24 Feb 2016 15:16:20 +1100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0059_01D16F16.50FF3040" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=c+ZWOkJl c=1 sm=1 tr=0 a=8e8rgZJuizJfF74+JHJpGg==:117 a=8e8rgZJuizJfF74+JHJpGg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=UN5p7Z2fHh4SWQZJALwA:9 a=wPNLvfGTeEIA:10 a=0HKhtYEBDYxLM2hhN5kA:9 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" This is a multi-part message in MIME format. ------=_NextPart_000_0059_01D16F16.50FF3040 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, On Windows, doing a static build of libssh2 (against static openssl and static libz) used to be a fairly simple task. On 1.6.0, for example, it was just a matter of making slight amendments to the configure script: 1) Remove any occurrences of "-DLIBSSH2_WIN32"; 2) Append " -lgdi32" to any occurrences of "-lws2_32". Then run (in msys shell, using gcc compiler): $ ./configure --disable-shared --enable-static CPPFLAGS="-IC:/_32/msys_492/1.0/local/include -IC:/_32/msys_492/1.0/local/ssl/include" LDFLAGS="-LC:/_32/msys_492/1.0/local/lib -LC:/_32/msys_492/1.0/local/ssl/lib" --prefix=C:/_32/msys_492/1.0/local && make Works fine for 1.6.0, but not for 1.7.0. Everything is fine until we come to building the "example" programs. With 1.7.0, the first build in "example" aborts with: gcc -DHAVE_CONFIG_H -I../include -I../example -IC:/_32/msys_492/1.0/local/include -IC:/_32/msys_492/1.0/local/ssl/include -MT direct_tcpip.o -MD -MP -MF .deps/direct_tcpip.Tpo -c -o direct_tcpip.o direct_tcpip.c mv -f .deps/direct_tcpip.Tpo .deps/direct_tcpip.Po /bin/sh ../libtool --tag=CC --mode=link -LC:/_32/msys_492/1.0/local/lib -LC:/_32/msys_492/1.0/local/ssl/lib -o direct_tcpip.exe direct_tcpip.o ../src/libssh2.la -lws2_32 -lgdi32 libtool: link: gcc -o direct_tcpip.exe irect_tcpip.o -LC:/_32/msys_492/1.0/local/lib -LC:/_32/msys_492/1.0/local/ssl/lib ../src/.libs/libssh2.a -lssl -lcrypto -lz -lws2_32 -lgdi32 C:/_32/msys_492/1.0/local/lib/libcrypto.a(e_capi.o):e_capi.c:(.text+0x20f): undefined reference to `_imp__CertFreeCertificateContext@4' ..... and many more undefined references to a number of *dynamic* symbols. But with 1.6.0 the exact same commands work fine. (And it's the same shell, same compiler, same environment, same configure command, same everything). So I'm quite nonplussed as to what accounts for the 1.7.0 failure. Could it be some difference in the example/Makefile ? (Diff is attached.) Maybe it's a PEBCAK that I can't spot. It seems *very* odd that the "src" build is working fine (including the creation of the static libssh2.a), yet the building of the first "example" program wants to find *dynamic* symbols. I think I'll need some help with this. Cheers, Rob ------=_NextPart_000_0059_01D16F16.50FF3040 Content-Type: text/plain; format=flowed; name="diff_example.txt"; reply-type=original Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="diff_example.txt" --- ../libssh2-1.6.0/example/Makefile 2016-02-24 13:22:34 +1100 +++ example/Makefile 2016-02-24 12:41:26 +1100 @@ -1,7 +1,7 @@ -# Makefile.in generated by automake 1.14.1 from Makefile.am. +# Makefile.in generated by automake 1.15 from Makefile.am. # example/Makefile. Generated from Makefile.in by configure. -# Copyright (C) 1994-2013 Free Software Foundation, Inc. +# Copyright (C) 1994-2014 Free Software Foundation, Inc. # This Makefile.in is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, @@ -15,7 +15,17 @@ -am__is_gnu_make =3D test -n '$(MAKEFILE_LIST)' && test -n = '$(MAKELEVEL)' +am__is_gnu_make =3D { \ + if test -z '$(MAKELEVEL)'; then \ + false; \ + elif test -n '$(MAKE_HOST)'; then \ + true; \ + elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \ + true; \ + else \ + false; \ + fi; \ +} am__make_running_with_option =3D \ case $${target_option-} in \ ?) ;; \ @@ -91,8 +101,6 @@ $(am__EXEEXT_1) #am__append_1 =3D x11 subdir =3D example -DIST_COMMON =3D $(srcdir)/Makefile.in $(srcdir)/Makefile.am \ - $(srcdir)/libssh2_config.h.in $(top_srcdir)/depcomp ACLOCAL_M4 =3D $(top_srcdir)/aclocal.m4 am__aclocal_m4_deps =3D $(top_srcdir)/m4/autobuild.m4 \ $(top_srcdir)/m4/lib-ld.m4 $(top_srcdir)/m4/lib-link.m4 \ @@ -102,6 +110,7 @@ $(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac am__configure_deps =3D $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) = \ $(ACLOCAL_M4) +DIST_COMMON =3D $(srcdir)/Makefile.am $(am__DIST_COMMON) mkinstalldirs =3D $(install_sh) -d CONFIG_HEADER =3D $(top_builddir)/src/libssh2_config.h libssh2_config.h CONFIG_CLEAN_FILES =3D @@ -275,16 +284,18 @@ done | $(am__uniquify_input)` ETAGS =3D etags CTAGS =3D ctags +am__DIST_COMMON =3D $(srcdir)/Makefile.in $(srcdir)/libssh2_config.h.in = \ + $(top_srcdir)/depcomp DISTFILES =3D $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) -ACLOCAL =3D aclocal-1.14 +ACLOCAL =3D aclocal-1.15 ALLOCA =3D AMTAR =3D $${TAR-tar} -AM_DEFAULT_VERBOSITY =3D 1 +AM_DEFAULT_VERBOSITY =3D 0 AR =3D ar AS =3D as AUTOCONF =3D autoconf AUTOHEADER =3D autoheader -AUTOMAKE =3D automake-1.14 +AUTOMAKE =3D automake-1.15 AWK =3D gawk CC =3D gcc CCDEPMODE =3D depmode=3Dgcc3 @@ -325,7 +336,7 @@ LIBOBJS =3D LIBS =3D -lws2_32 -lgdi32 LIBSREQUIRED =3D libssl,libcrypto,zlib -LIBSSH2VER =3D 1.6.0 +LIBSSH2VER =3D 1.7.0 LIBSSL =3D C:/_32/msys_492/1.0/local/lib/libssl.a C:/_32/msys_492/1.0/local/lib/libcrypto.a LIBSSL_PREFIX =3D C:/_32/msys_492/1.0/local LIBTOOL =3D $(SHELL) $(top_builddir)/libtool @@ -364,10 +375,10 @@ SSHD =3D STRIP =3D strip VERSION =3D - -abs_builddir =3D /c/_32/comp/libssh2-1.6.0/example -abs_srcdir =3D /c/_32/comp/libssh2-1.6.0/example -abs_top_builddir =3D /c/_32/comp/libssh2-1.6.0 -abs_top_srcdir =3D /c/_32/comp/libssh2-1.6.0 +abs_builddir =3D /c/_32/comp/libssh2-1.7.0/example +abs_srcdir =3D /c/_32/comp/libssh2-1.7.0/example +abs_top_builddir =3D /c/_32/comp/libssh2-1.7.0 +abs_top_srcdir =3D /c/_32/comp/libssh2-1.7.0 ac_ct_AR =3D ar ac_ct_CC =3D gcc ac_ct_DUMPBIN =3D @@ -396,7 +407,7 @@ htmldir =3D ${docdir} includedir =3D ${prefix}/include infodir =3D ${datarootdir}/info -install_sh =3D ${SHELL} /c/_32/comp/libssh2-1.6.0/install-sh +install_sh =3D ${SHELL} /c/_32/comp/libssh2-1.7.0/install-sh libdir =3D ${exec_prefix}/lib libexecdir =3D ${exec_prefix}/libexec localedir =3D ${datarootdir}/locale @@ -408,6 +419,7 @@ prefix =3D C:/_32/msys_492/1.0/local program_transform_name =3D s,x,x, psdir =3D ${docdir} +runstatedir =3D ${localstatedir}/run sbindir =3D ${exec_prefix}/sbin sharedstatedir =3D ${prefix}/com srcdir =3D . @@ -417,7 +429,7 @@ top_builddir =3D .. top_srcdir =3D .. AUTOMAKE_OPTIONS =3D foreign nostdinc -EXTRA_DIST =3D libssh2_config.h.in +EXTRA_DIST =3D libssh2_config.h.in libssh2_config_cmake.h.in = CMakeLists.txt AM_CPPFLAGS =3D -I$(top_srcdir)/include -I$(top_builddir)/example LDADD =3D $(top_builddir)/src/libssh2.la all: libssh2_config.h @@ -437,7 +449,6 @@ echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign example/Makefile'; \ $(am__cd) $(top_srcdir) && \ $(AUTOMAKE) --foreign example/Makefile -.PRECIOUS: Makefile Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status @case '$?' in \ *config.status*) \ @@ -828,6 +839,8 @@ mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \ tags tags-am uninstall uninstall-am +.PRECIOUS: Makefile + # Tell versions [3.59,3.63) of GNU make to not export all variables. # Otherwise a system limit (for SysV at least) may be exceeded. ------=_NextPart_000_0059_01D16F16.50FF3040 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== ------=_NextPart_000_0059_01D16F16.50FF3040-- From libssh2-devel-bounces@cool.haxx.se Thu Feb 25 06:13:47 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1P5DMjQ006937; Thu, 25 Feb 2016 06:13:45 +0100 Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1P5DJaY000897 for ; Thu, 25 Feb 2016 06:13:20 +0100 Received: from OwnerPC311012 (unknown [203.202.164.190]) (Authenticated sender: sisyphus1@optusnet.com.au) by mail108.syd.optusnet.com.au (Postfix) with ESMTPA id 57C521A5AFA for ; Thu, 25 Feb 2016 16:13:07 +1100 (AEDT) Message-ID: <9757A2ABDFC349129B489F0DEECDA569@OwnerPC311012> From: To: References: <99E668A3CEB74C7892B3F2E26E59520B@OwnerPC311012> In-Reply-To: <99E668A3CEB74C7892B3F2E26E59520B@OwnerPC311012> Subject: Re: [1.7.0] Cannot build statically on Windows Date: Thu, 25 Feb 2016 16:12:24 +1100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=EfU1O6SC c=1 sm=1 tr=0 a=8e8rgZJuizJfF74+JHJpGg==:117 a=8e8rgZJuizJfF74+JHJpGg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=8nJEP1OIZ-IA:10 a=PO7r1zJSAAAA:8 a=RLSjlpDb6Lt57RzWNQUA:9 a=wPNLvfGTeEIA:10 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id u1P5DMjQ006937 -----Original Message----- From: sisyphus1@optusnet.com.au Sent: Wednesday, February 24, 2016 3:16 PM To: libssh2-devel@cool.haxx.se Subject: [1.7.0] Cannot build statically on Windows > Maybe it's a PEBCAK that I can't spot. Yeah, it was pretty much a PEBCAK. For 1.6.0 or earlier it's sufficient, in the configure script to change: LIBS="$LIBS -lws2_32" to LIBS="$LIBS -lws2_32 -lgdi32" but, for 1.7.0, it needs to become LIBS="$LIBS -lws2_32 -lgdi32 -lcrypt32" Stupidly (and I mean *really* stupidly), I was thinking that those unresolved references would be resolved by the shared openssl libraries - but, of course, they are resolved by the crypt32 system library and it's just a matter of linking to that library. All good - sorry for the noise. Cheers, Rob _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Feb 25 10:08:13 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1P97pB6014117; Thu, 25 Feb 2016 10:08:10 +0100 Received: from foo.stuge.se (foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1P97npD014035 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 25 Feb 2016 10:07:50 +0100 Received: (qmail 1002 invoked by uid 1000); 25 Feb 2016 09:06:53 -0000 Date: Thu, 25 Feb 2016 09:06:53 +0000 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: [1.7.0] Cannot build statically on Windows Message-ID: <20160225090653.GF29002@foo.stuge.se> References: <99E668A3CEB74C7892B3F2E26E59520B@OwnerPC311012> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <99E668A3CEB74C7892B3F2E26E59520B@OwnerPC311012> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id u1P97pB6014117 sisyphus1@optusnet.com.au wrote: > On Windows, doing a static build of libssh2 (against static openssl > and static libz) used to be a fairly simple task. Why not build libssh2 against WinCNG instead of OpenSSL? > With 1.7.0, the first build in "example" aborts with: .. > C:/_32/msys_492/1.0/local/lib/libcrypto.a(e_capi.o):e_capi.c:(.text+0x20f): > undefined reference to `_imp__CertFreeCertificateContext@4' So the above says that C:/_32/msys_492/1.0/local/lib/libcrypto.a (part of OpenSSL) is looking for an import library symbol for the CertFreeCertificateContext function. Import libraries look like static libraries (filenames end with .a or .lib) but they are much smaller in size than the actual library file, because they do not contain the code. They just contain a little bit of code to load the actual shared library (DLL) at runtime. At least with MSVC, this is how shared libraries are linked. > So I'm quite nonplussed as to what accounts for the 1.7.0 failure. I'm unclear why 1.6 is any different, but oh well. > It seems *very* odd that the "src" build is working fine (including > the creation of the static libssh2.a), yet the building of the first > "example" program wants to find *dynamic* symbols. This actually makes a lot of sense. The error happens when a program is trying to link against libssh2, not when libssh2 itself is built. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Feb 25 16:14:46 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1PFERP7004231; Thu, 25 Feb 2016 16:14:43 +0100 Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09:0:0:0:231]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1PFEQUS004168 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 25 Feb 2016 16:14:26 +0100 Received: by mail-wm0-x231.google.com with SMTP id a4so31962792wme.1 for ; Thu, 25 Feb 2016 07:14:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmgsystemsinc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=fl86b267gpFdDKT0qRjeFCr8aA2DJAg3Bv32oA7uKMQ=; b=IXJQ1U94TnnjOUuUZXKnRJBRAwRD0848/qukxCog3Q4wfvKTDpZgdC8x1m372Dx8bQ +olt09qG7DMmrVDlsnnIJplhPxyBWCTwms0bj+QA2krLJ+IAw8YlTKEh/z7izPrTJ2AQ UpbQ1twtjdxBmmFD/GcDYKLFb62sKjyJeCCISsFZJoMTXfXA/vqe68NQ62JwKD2Flybf Z/rSH4FfWPIIH8NFnI3NUbrFRBJuqBV8TMfzuecTpceOvTBVLbuLfpGYORvwPh6HDn3I wbNWmeIjJhBQAcTOhvAked4yIc0cVcMcL7igRXz8aqGqK/z2YftOgt7WkBTuTsEa+97K 4BOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=fl86b267gpFdDKT0qRjeFCr8aA2DJAg3Bv32oA7uKMQ=; b=JjSo2jzwzdz6Q4PigyT7or3A3p/U6YgskqPAWhLv3WkyKoyybKefGG15/LAO3eg+h/ Sd9VfedBg48XiNXuBmX76AvBfs+jwdOcT8IMXbfYpj3fOU9t864TsS2MWQxtD6GYUlHC 6iplcrC0a4/PlkSy2vsHhxt5scgH9I34Z/rYEhtISQuVPG0R+29XOnxm0s8S0s+6uBMi 6+gFqN6qKtz0LOEy9DdXpcDOs0Nr64zNFoF48bqJfGgh3BjyfApfJx69n8MENcwOJhiF F6p3yOrwl8PtSPheQrgkGBz0qA1vSPHNaBF99ZM5VreExNHjwYfgP9lml3+hQKnnWhEc JsyA== X-Gm-Message-State: AG10YORlTM92U4WARgkNc2sf8W2EtA0E2sFhiLMxbTFXoJwWHkUr/ECcWhA3VyUqGHHqXoOLOWlkt03wgiIYmA== MIME-Version: 1.0 X-Received: by 10.28.4.134 with SMTP id 128mr3940610wme.96.1456413261747; Thu, 25 Feb 2016 07:14:21 -0800 (PST) Received: by 10.28.93.74 with HTTP; Thu, 25 Feb 2016 07:14:21 -0800 (PST) X-Originating-IP: [173.73.193.2] Date: Thu, 25 Feb 2016 10:14:21 -0500 Message-ID: Subject: Re: [SECURITY ADVISORY] Truncated Difffie-Hellman secret length From: "George Garner (online)" To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============0752278048==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============0752278048== Content-Type: multipart/alternative; boundary=001a1141e75e1d1e12052c99a3e3 --001a1141e75e1d1e12052c99a3e3 Content-Type: text/plain; charset=UTF-8 Delving a little further into the code, it would appear that you are only using the macro _libssh2_bn_rand in the two locations that need to be fixed so you could simply change the definition of _libssh2_bn_rand and revert the previous patch. - #define _libssh2_bn_rand(bn, bits, top, bottom) BN_rand(bn, bits, top, bottom) + #define _libssh2_bn_rand(bn, bytes * 8 -1, top, bottom) BN_rand(bn, bits, top, bottom) This would also allow simplification of the algorithm on Windows because BCryptGenRandom expects the length in bytes and you would no longer need to convert from bits to bytes using ceil(). Because you are always subtracting 1 from the number of bytes x 8, the number of bits will always be odd. --001a1141e75e1d1e12052c99a3e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Delving a little further into the code, it would appe= ar that you are only using the macro _libssh2_bn_rand in the two locations = that need to be fixed so you could simply change the definition of _libssh2= _bn_rand and revert the previous patch.

- #define _libssh2_bn_rand(b= n, bits, top, bottom) BN_rand(bn, bits, top, bottom)
+ #define _libssh2_= bn_rand(bn, bytes * 8 -1, top, bottom) BN_rand(bn, bits, top, bottom)
This would also allow simplification of the algorithm on Windows be= cause BCryptGenRandom expects the length in bytes and you would no longer n= eed to convert from bits to bytes using ceil().=C2=A0 Because you are alway= s subtracting 1 from the number of bytes x 8, the number of bits will alway= s be odd.
--001a1141e75e1d1e12052c99a3e3-- --===============0752278048== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============0752278048==-- From libssh2-devel-bounces@cool.haxx.se Fri Feb 26 16:45:36 2016 Return-Path: Received: from www.haxx.se (list@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTP id u1QFjAht032438; Fri, 26 Feb 2016 16:45:33 +0100 Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u1QFj8QF032400 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 26 Feb 2016 16:45:08 +0100 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aZKZm-0000cH-Rh for libssh2-devel@cool.haxx.se; Fri, 26 Feb 2016 16:45:06 +0100 Received: from ppp37-190-56-35.pppoe.spdop.ru ([37.190.56.35]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Feb 2016 16:45:06 +0100 Received: from yumkam by ppp37-190-56-35.pppoe.spdop.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Feb 2016 16:45:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: libssh2-devel@cool.haxx.se From: yumkam@gmail.com (Yuriy M. Kaminskiy) Subject: [PATCH][WIP][v2] Re: [SECURITY ADVISORY] Truncated Difffie-Hellman secret length Date: Thu, 25 Feb 2016 03:10:23 +0300 Lines: 991 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ppp37-190-56-35.pppoe.spdop.ru User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) Cancel-Lock: sha1:jGsOHm8P1Zxrd8SUeJ1YaNkYLic= X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.20 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --=-=-= Content-Type: text/plain "George Garner (online)" writes: [...] > 3. Where is the p_len/group_order parameter validated? In > kex_method_diffie_hellman_group_exchange_sha256_key_exchange it is > converted from network byte order and accepted at face value. What > happens if a malicious packet is received with a bogus value for > p_len? Maybe I miss something, but it looks like this defect (blindly trust various 32-bit length that was sent remote side and don't verify if it fits buffer) is *everywhere* in libssh2. I've sent some patches for kex.c via gh pull request, but quickly discovered it is much worse. Very WIP (and incomplete) patch for *other* files is attached; unfortunately, in most cases, I have no idea how such errors should be handled within libssh2, don't know libssh2 code base well enough, so I give up at this. Note that in early connection setup "malicious server" is not required, "malicious MITM" can insert broken packets as well. In general, please re-review all `grep ntoh -r src/`, in many cases surrounding code looks problematic in one way or other. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=libssh2-check-length.v2.patch --- Changelog: v2: fixed obvious errors Note: This is still NOT COMPLETE work, all XXX comment must be reviewed and acted upon. src/agent.c | 32 ++++++++-------- src/channel.c | 10 ++++- src/hostkey.c | 19 +++++++-- src/kex.c | 43 +++++++++++---------- src/packet.c | 45 +++++++++++++++++----- src/publickey.c | 117 +++++++++++++++++++++++++++++++++++++++++++------------- src/session.c | 2 + src/sftp.c | 42 ++++++++++++++++---- src/sftp.h | 1 + src/userauth.c | 32 ++++++++++++++++ 10 files changed, 260 insertions(+), 83 deletions(-) diff --git a/src/agent.c b/src/agent.c index c2ba422..255b63d 100644 --- a/src/agent.c +++ b/src/agent.c @@ -449,12 +449,12 @@ agent_sign(LIBSSH2_SESSION *session, unsigned char **sig, size_t *sig_len, goto error; } method_len = _libssh2_ntohu32(s); - s += 4; - len -= method_len; - if (len < 0) { + if (method_len < 0 || len < method_len) { rc = LIBSSH2_ERROR_AGENT_PROTOCOL; goto error; } + s += 4; + len -= method_len; s += method_len; /* Read the signature */ @@ -464,12 +464,12 @@ agent_sign(LIBSSH2_SESSION *session, unsigned char **sig, size_t *sig_len, goto error; } *sig_len = _libssh2_ntohu32(s); - s += 4; - len -= *sig_len; - if (len < 0) { + if ((size_t)len < *sig_len) { rc = LIBSSH2_ERROR_AGENT_PROTOCOL; goto error; } + len -= *sig_len; + s += 4; *sig = LIBSSH2_ALLOC(session, *sig_len); if (!*sig) { @@ -558,15 +558,15 @@ agent_list_identities(LIBSSH2_AGENT *agent) goto error; } identity->external.blob_len = _libssh2_ntohu32(s); - s += 4; - - /* Read the blob */ - len -= identity->external.blob_len; - if (len < 0) { + if ((size_t)len < identity->external.blob_len) { rc = LIBSSH2_ERROR_AGENT_PROTOCOL; LIBSSH2_FREE(agent->session, identity); goto error; } + s += 4; + + /* Read the blob */ + len -= identity->external.blob_len; identity->external.blob = LIBSSH2_ALLOC(agent->session, identity->external.blob_len); @@ -587,16 +587,16 @@ agent_list_identities(LIBSSH2_AGENT *agent) goto error; } comment_len = _libssh2_ntohu32(s); - s += 4; - - /* Read the comment */ - len -= comment_len; - if (len < 0) { + if (comment_len < 0 || len < comment_len) { rc = LIBSSH2_ERROR_AGENT_PROTOCOL; LIBSSH2_FREE(agent->session, identity->external.blob); LIBSSH2_FREE(agent->session, identity); goto error; } + s += 4; + + /* Read the comment */ + len -= comment_len; identity->external.comment = LIBSSH2_ALLOC(agent->session, comment_len + 1); diff --git a/src/channel.c b/src/channel.c index 32d914d..38572be 100644 --- a/src/channel.c +++ b/src/channel.c @@ -225,6 +225,7 @@ _libssh2_channel_open(LIBSSH2_SESSION * session, const char *channel_type, } if (session->open_state == libssh2_NB_state_sent) { + unsigned char *end; rc = _libssh2_packet_requirev(session, reply_codes, &session->open_data, &session->open_data_len, 1, @@ -238,7 +239,11 @@ _libssh2_channel_open(LIBSSH2_SESSION * session, const char *channel_type, goto channel_error; } + end = session->open_data + session->open_data_len; + if (session->open_data[0] == SSH_MSG_CHANNEL_OPEN_CONFIRMATION) { + if (13+4 > (end - session->open_data)) + goto channel_error; session->open_channel->remote.id = _libssh2_ntohu32(session->open_data + 5); session->open_channel->local.window_size = @@ -265,7 +270,8 @@ _libssh2_channel_open(LIBSSH2_SESSION * session, const char *channel_type, return session->open_channel; } - if (session->open_data[0] == SSH_MSG_CHANNEL_OPEN_FAILURE) { + if (session->open_data[0] == SSH_MSG_CHANNEL_OPEN_FAILURE && + 4 <= (end - (session->open_data + 5))) { unsigned int reason_code = _libssh2_ntohu32(session->open_data + 5); switch (reason_code) { case SSH_OPEN_ADMINISTRATIVELY_PROHIBITED: @@ -1399,6 +1405,7 @@ _libssh2_channel_flush(LIBSSH2_CHANNEL *channel, int streamid) if (((packet_type == SSH_MSG_CHANNEL_DATA) || (packet_type == SSH_MSG_CHANNEL_EXTENDED_DATA)) + && packet->data_len >= 5 + (packet_type == SSH_MSG_CHANNEL_EXTENDED_DATA ? 4 : 0) && (_libssh2_ntohu32(packet->data + 1) == channel->local.id)) { /* It's our channel at least */ long packet_stream_id = @@ -1418,6 +1425,7 @@ _libssh2_channel_flush(LIBSSH2_CHANNEL *channel, int streamid) bytes_to_flush, packet_stream_id, channel->local.id, channel->remote.id); + /* XXX assert(packet->data_len >= 13); XXX */ /* It's one of the streams we wanted to flush */ channel->flush_refund_bytes += packet->data_len - 13; channel->flush_flush_bytes += bytes_to_flush; diff --git a/src/hostkey.c b/src/hostkey.c index 2a0a8f9..7b780e2 100644 --- a/src/hostkey.c +++ b/src/hostkey.c @@ -66,31 +66,42 @@ hostkey_method_ssh_rsa_init(LIBSSH2_SESSION * session, libssh2_rsa_ctx *rsactx; const unsigned char *s, *e, *n; unsigned long len, e_len, n_len; + const unsigned char *end = hostkey_data + hostkey_data_len; int ret; - (void) hostkey_data_len; - if (*abstract) { hostkey_method_ssh_rsa_dtor(session, abstract); *abstract = NULL; } s = hostkey_data; + if (4 > end - s) + return -1; len = _libssh2_ntohu32(s); s += 4; + if (len > (size_t)(end - s)) + return -1; if (len != 7 || strncmp((char *) s, "ssh-rsa", 7) != 0) { return -1; } - s += 7; + s += len; + if (4 > end - s) + return -1; e_len = _libssh2_ntohu32(s); s += 4; + if (e_len > (size_t)(end - s)) + return -1; e = s; s += e_len; + if (4 > end - s) + return -1; n_len = _libssh2_ntohu32(s); s += 4; + if (n_len > (size_t)(end - s)) + return -1; n = s; ret = _libssh2_rsa_new(&rsactx, e, e_len, n, n_len, NULL, 0, @@ -181,6 +192,8 @@ hostkey_method_ssh_rsa_sig_verify(LIBSSH2_SESSION * session, (void) session; /* Skip past keyname_len(4) + keyname(7){"ssh-rsa"} + signature_len(4) */ + if (15 > sig_len) + return -1; sig += 15; sig_len -= 15; return _libssh2_rsa_sha1_verify(rsactx, sig, sig_len, m, m_len); diff --git a/src/kex.c b/src/kex.c index 40dbeab..2381d52 100644 --- a/src/kex.c +++ b/src/kex.c @@ -2463,21 +2463,20 @@ static int kex_agree_comp(LIBSSH2_SESSION *session, * within the given packet. */ static int kex_string_pair(unsigned char **sp, /* parsing position */ - unsigned char *data, /* start pointer to packet */ - size_t data_len, /* size of total packet */ + unsigned char *end, /* end of packet */ size_t *lenp, /* length of the string */ unsigned char **strp) /* pointer to string start */ { unsigned char *s = *sp; - *lenp = _libssh2_ntohu32(s); - /* the length of the string must fit within the current pointer and the - end of the packet */ - if (*lenp > (data_len - (s - data) -4)) + if (4 > end - s) return 1; - *strp = s + 4; - s += 4 + *lenp; - + *lenp = _libssh2_ntohu32(s); + s += 4; + if (*lenp > (size_t)(end - s)) + return 1; + *strp = s; + s += *lenp; *sp = s; return 0; } @@ -2493,6 +2492,10 @@ static int kex_agree_methods(LIBSSH2_SESSION * session, unsigned char *data, size_t kex_len, hostkey_len, crypt_cs_len, crypt_sc_len, comp_cs_len; size_t comp_sc_len, mac_cs_len, mac_sc_len; unsigned char *s = data; + unsigned char *end = data + data_len; + + if (1 + 16 > end - s) + return -1; /* Skip packet_type, we know it already */ s++; @@ -2501,21 +2504,24 @@ static int kex_agree_methods(LIBSSH2_SESSION * session, unsigned char *data, s += 16; /* Locate each string */ - if(kex_string_pair(&s, data, data_len, &kex_len, &kex)) + if(kex_string_pair(&s, end, &kex_len, &kex)) + return -1; + if(kex_string_pair(&s, end, &hostkey_len, &hostkey)) return -1; - if(kex_string_pair(&s, data, data_len, &hostkey_len, &hostkey)) + if(kex_string_pair(&s, end, &crypt_cs_len, &crypt_cs)) return -1; - if(kex_string_pair(&s, data, data_len, &crypt_cs_len, &crypt_cs)) + if(kex_string_pair(&s, end, &crypt_sc_len, &crypt_sc)) return -1; - if(kex_string_pair(&s, data, data_len, &crypt_sc_len, &crypt_sc)) + if(kex_string_pair(&s, end, &mac_cs_len, &mac_cs)) return -1; - if(kex_string_pair(&s, data, data_len, &mac_cs_len, &mac_cs)) + if(kex_string_pair(&s, end, &mac_sc_len, &mac_sc)) return -1; - if(kex_string_pair(&s, data, data_len, &mac_sc_len, &mac_sc)) + if(kex_string_pair(&s, end, &comp_cs_len, &comp_cs)) return -1; - if(kex_string_pair(&s, data, data_len, &comp_cs_len, &comp_cs)) + if(kex_string_pair(&s, end, &comp_sc_len, &comp_sc)) return -1; - if(kex_string_pair(&s, data, data_len, &comp_sc_len, &comp_sc)) + + if (1 > end - s) return -1; /* If the server sent an optimistic packet, assume that it guessed wrong. @@ -2524,9 +2530,6 @@ static int kex_agree_methods(LIBSSH2_SESSION * session, unsigned char *data, session->burn_optimistic_kexinit = *(s++); /* Next uint32 in packet is all zeros (reserved) */ - if (data_len < (unsigned) (s - data)) - return -1; /* short packet */ - if (kex_agree_kex_hostkey(session, kex, kex_len, hostkey, hostkey_len)) { return -1; } diff --git a/src/packet.c b/src/packet.c index 5f1feb8..3659daa 100644 --- a/src/packet.c +++ b/src/packet.c @@ -85,10 +85,12 @@ packet_queue_listener(LIBSSH2_SESSION * session, unsigned char *data, char failure_code = SSH_OPEN_ADMINISTRATIVELY_PROHIBITED; int rc; - (void) datalen; - if (listen_state->state == libssh2_NB_state_idle) { unsigned char *s = data + (sizeof("forwarded-tcpip") - 1) + 5; + unsigned char *end = data + datalen; + if (4*4 > (end - s)) { + return 0; /* XXX ??? XXX */ + } listen_state->sender_channel = _libssh2_ntohu32(s); s += 4; @@ -99,15 +101,27 @@ packet_queue_listener(LIBSSH2_SESSION * session, unsigned char *data, listen_state->host_len = _libssh2_ntohu32(s); s += 4; + if (listen_state->host_len > (size_t)(end - s)) { + return 0; /* XXX ??? XXX */ + } listen_state->host = s; s += listen_state->host_len; + if (4*2 > (end - s)) { + return 0; /* XXX ??? XXX */ + } listen_state->port = _libssh2_ntohu32(s); s += 4; listen_state->shost_len = _libssh2_ntohu32(s); s += 4; + if (listen_state->shost_len > (size_t)(end - s)) { + return 0; /* XXX ??? XXX */ + } listen_state->shost = s; s += listen_state->shost_len; + if (4 > (end - s)) { + return 0; /* XXX ??? XXX */ + } listen_state->sport = _libssh2_ntohu32(s); _libssh2_debug(session, LIBSSH2_TRACE_CONN, @@ -271,10 +285,12 @@ packet_x11_open(LIBSSH2_SESSION * session, unsigned char *data, LIBSSH2_CHANNEL *channel = x11open_state->channel; int rc; - (void) datalen; - if (x11open_state->state == libssh2_NB_state_idle) { unsigned char *s = data + (sizeof("x11") - 1) + 5; + unsigned char *end = data + datalen; + if (4*4 > (end - s)) { + return 0; /* XXX ??? XXX */ + } x11open_state->sender_channel = _libssh2_ntohu32(s); s += 4; x11open_state->initial_window_size = _libssh2_ntohu32(s); @@ -283,8 +299,14 @@ packet_x11_open(LIBSSH2_SESSION * session, unsigned char *data, s += 4; x11open_state->shost_len = _libssh2_ntohu32(s); s += 4; + if (x11open_state->shost_len > (size_t)(end - s)) { + return 0; /* XXX ??? XXX */ + } x11open_state->shost = s; s += x11open_state->shost_len; + if (4 > (end - s)) { + return 0; /* XXX ??? XXX */ + } x11open_state->sport = _libssh2_ntohu32(s); _libssh2_debug(session, LIBSSH2_TRACE_CONN, @@ -807,22 +829,26 @@ _libssh2_packet_add(LIBSSH2_SESSION * session, unsigned char *data, else if (len == sizeof("exit-signal") - 1 && !memcmp("exit-signal", data + 9, sizeof("exit-signal") - 1)) { + unsigned char *end = data + datalen; + unsigned char *s = data + 9 + sizeof("exit-signal"); /* command terminated due to signal */ if(datalen >= 20) channelp = _libssh2_channel_locate(session, channel); - if (channelp) { + if (channelp && end - s >= 4) { /* set signal name (without SIG prefix) */ - uint32_t namelen = - _libssh2_ntohu32(data + 9 + sizeof("exit-signal")); + uint32_t namelen = _libssh2_ntohu32(s); + s += 4; + if (namelen > (size_t)(end - s)) + /* XXX ??? XXX */; + else { channelp->exit_signal = LIBSSH2_ALLOC(session, namelen + 1); if (!channelp->exit_signal) rc = _libssh2_error(session, LIBSSH2_ERROR_ALLOC, "memory for signal name"); else { - memcpy(channelp->exit_signal, - data + 13 + sizeof("exit_signal"), namelen); + memcpy(channelp->exit_signal, s, namelen); channelp->exit_signal[namelen] = '\0'; /* TODO: save error message and language tag */ _libssh2_debug(session, LIBSSH2_TRACE_CONN, @@ -832,6 +858,7 @@ _libssh2_packet_add(LIBSSH2_SESSION * session, unsigned char *data, channelp->local.id, channelp->remote.id); } + } } } diff --git a/src/publickey.c b/src/publickey.c index bfee0a8..d19efb7 100644 --- a/src/publickey.c +++ b/src/publickey.c @@ -247,6 +247,7 @@ publickey_response_success(LIBSSH2_PUBLICKEY * pkey) switch (response) { case LIBSSH2_PUBLICKEY_RESPONSE_STATUS: /* Error, or processing complete */ + if (data_len >= 4) { unsigned long status = _libssh2_ntohu32(s); @@ -258,6 +259,7 @@ publickey_response_success(LIBSSH2_PUBLICKEY * pkey) publickey_status_error(pkey, session, status); return -1; } + /* fallthru */ default: LIBSSH2_FREE(session, data); if (response < 0) { @@ -403,6 +405,7 @@ static LIBSSH2_PUBLICKEY *publickey_init(LIBSSH2_SESSION *session) if (session->pkeyInit_state == libssh2_NB_state_sent3) { while (1) { unsigned char *s; + unsigned char *end; rc = publickey_packet_receive(session->pkeyInit_pkey, &session->pkeyInit_data, &session->pkeyInit_data_len); @@ -419,6 +422,7 @@ static LIBSSH2_PUBLICKEY *publickey_init(LIBSSH2_SESSION *session) } s = session->pkeyInit_data; + end = session->pkeyInit_data + session->pkeyInit_data_len; if ((response = publickey_response_id(&s, session->pkeyInit_data_len)) < 0) { _libssh2_error(session, LIBSSH2_ERROR_PUBLICKEY_PROTOCOL, @@ -432,19 +436,33 @@ static LIBSSH2_PUBLICKEY *publickey_init(LIBSSH2_SESSION *session) { unsigned long status, descr_len, lang_len; - status = _libssh2_ntohu32(s); - s += 4; - descr_len = _libssh2_ntohu32(s); - s += 4; - /* description starts here */ - s += descr_len; - lang_len = _libssh2_ntohu32(s); - s += 4; - /* lang starts here */ - s += lang_len; - - if (s > - session->pkeyInit_data + session->pkeyInit_data_len) { + if (4*2 > end - s) + s = NULL; + else { + status = _libssh2_ntohu32(s); + s += 4; + descr_len = _libssh2_ntohu32(s); + s += 4; + /* description starts here */ + if (descr_len > (size_t)(end - s)) + s = NULL; + else { + s += descr_len; + if (4 > end - s) + s = NULL; + else { + lang_len = _libssh2_ntohu32(s); + s += 4; + /* lang starts here */ + if (lang_len > (size_t)(end - s)) + s = NULL; + else + s += lang_len; + } + } + } + + if (s == NULL) { _libssh2_error(session, LIBSSH2_ERROR_PUBLICKEY_PROTOCOL, "Malformed publickey subsystem packet"); @@ -810,6 +828,7 @@ libssh2_publickey_list_fetch(LIBSSH2_PUBLICKEY * pkey, unsigned long *num_keys, } while (1) { + unsigned char *end; rc = publickey_packet_receive(pkey, &pkey->listFetch_data, &pkey->listFetch_data_len); if (rc == LIBSSH2_ERROR_EAGAIN) { @@ -822,6 +841,7 @@ libssh2_publickey_list_fetch(LIBSSH2_PUBLICKEY * pkey, unsigned long *num_keys, } pkey->listFetch_s = pkey->listFetch_data; + end = pkey->listFetch_data + pkey->listFetch_data_len; if ((response = publickey_response_id(&pkey->listFetch_s, pkey->listFetch_data_len)) < 0) { @@ -836,19 +856,34 @@ libssh2_publickey_list_fetch(LIBSSH2_PUBLICKEY * pkey, unsigned long *num_keys, { unsigned long status, descr_len, lang_len; - status = _libssh2_ntohu32(pkey->listFetch_s); - pkey->listFetch_s += 4; - descr_len = _libssh2_ntohu32(pkey->listFetch_s); - pkey->listFetch_s += 4; - /* description starts at pkey->listFetch_s */ - pkey->listFetch_s += descr_len; - lang_len = _libssh2_ntohu32(pkey->listFetch_s); - pkey->listFetch_s += 4; - /* lang starts at pkey->listFetch_s */ - pkey->listFetch_s += lang_len; - - if (pkey->listFetch_s > - pkey->listFetch_data + pkey->listFetch_data_len) { + if (4*2 > end - pkey->listFetch_s) + pkey->listFetch_s = NULL; + else { + status = _libssh2_ntohu32(pkey->listFetch_s); + pkey->listFetch_s += 4; + descr_len = _libssh2_ntohu32(pkey->listFetch_s); + pkey->listFetch_s += 4; + if (descr_len > (size_t)(end - pkey->listFetch_s)) + pkey->listFetch_s = NULL; + else { + /* description starts at pkey->listFetch_s */ + pkey->listFetch_s += descr_len; + if (4 > end - pkey->listFetch_s) + pkey->listFetch_s = NULL; + else { + lang_len = _libssh2_ntohu32(pkey->listFetch_s); + pkey->listFetch_s += 4; + if (lang_len > (size_t)(end - pkey->listFetch_s)) + pkey->listFetch_s = NULL; + else { + /* lang starts at pkey->listFetch_s */ + pkey->listFetch_s += lang_len; + } + } + } + } + + if (pkey->listFetch_s == NULL) { _libssh2_error(session, LIBSSH2_ERROR_PUBLICKEY_PROTOCOL, "Malformed publickey subsystem packet"); goto err_exit; @@ -887,8 +922,12 @@ libssh2_publickey_list_fetch(LIBSSH2_PUBLICKEY * pkey, unsigned long *num_keys, if (pkey->version == 1) { unsigned long comment_len; + if (4 > end - pkey->listFetch_s) + goto err_exit; comment_len = _libssh2_ntohu32(pkey->listFetch_s); pkey->listFetch_s += 4; + if (comment_len > (size_t)(end - pkey->listFetch_s)) + goto err_exit; if (comment_len) { list[keys].num_attrs = 1; list[keys].attrs = @@ -911,24 +950,42 @@ libssh2_publickey_list_fetch(LIBSSH2_PUBLICKEY * pkey, unsigned long *num_keys, list[keys].num_attrs = 0; list[keys].attrs = NULL; } + if (4 > end - pkey->listFetch_s) + goto err_exit; list[keys].name_len = _libssh2_ntohu32(pkey->listFetch_s); pkey->listFetch_s += 4; + if (list[keys].name_len > (size_t)(end - pkey->listFetch_s)) + goto err_exit; list[keys].name = pkey->listFetch_s; pkey->listFetch_s += list[keys].name_len; + if (4 > end - pkey->listFetch_s) + goto err_exit; list[keys].blob_len = _libssh2_ntohu32(pkey->listFetch_s); pkey->listFetch_s += 4; + if (list[keys].blob_len > (size_t)(end - pkey->listFetch_s)) + goto err_exit; list[keys].blob = pkey->listFetch_s; pkey->listFetch_s += list[keys].blob_len; } else { /* Version == 2 */ + if (4 > end - pkey->listFetch_s) + goto err_exit; list[keys].name_len = _libssh2_ntohu32(pkey->listFetch_s); pkey->listFetch_s += 4; + if (list[keys].name_len > (size_t)(end - pkey->listFetch_s)) + goto err_exit; list[keys].name = pkey->listFetch_s; pkey->listFetch_s += list[keys].name_len; + if (4 > end - pkey->listFetch_s) + goto err_exit; list[keys].blob_len = _libssh2_ntohu32(pkey->listFetch_s); pkey->listFetch_s += 4; + if (list[keys].blob_len > (size_t)(end - pkey->listFetch_s)) + goto err_exit; list[keys].blob = pkey->listFetch_s; pkey->listFetch_s += list[keys].blob_len; + if (4 > end - pkey->listFetch_s) + goto err_exit; list[keys].num_attrs = _libssh2_ntohu32(pkey->listFetch_s); pkey->listFetch_s += 4; if (list[keys].num_attrs) { @@ -943,14 +1000,22 @@ libssh2_publickey_list_fetch(LIBSSH2_PUBLICKEY * pkey, unsigned long *num_keys, goto err_exit; } for(i = 0; i < list[keys].num_attrs; i++) { + if (4 > end - pkey->listFetch_s) + goto err_exit; list[keys].attrs[i].name_len = _libssh2_ntohu32(pkey->listFetch_s); pkey->listFetch_s += 4; + if (list[keys].attrs[i].name_len > (size_t)(end - pkey->listFetch_s)) + goto err_exit; list[keys].attrs[i].name = (char *) pkey->listFetch_s; pkey->listFetch_s += list[keys].attrs[i].name_len; + if (4 > end - pkey->listFetch_s) + goto err_exit; list[keys].attrs[i].value_len = _libssh2_ntohu32(pkey->listFetch_s); pkey->listFetch_s += 4; + if (list[keys].attrs[i].value_len > (size_t)(end - pkey->listFetch_s)) + goto err_exit; list[keys].attrs[i].value = (char *) pkey->listFetch_s; pkey->listFetch_s += list[keys].attrs[i].value_len; diff --git a/src/session.c b/src/session.c index 06e61dd..ba1bad5 100644 --- a/src/session.c +++ b/src/session.c @@ -763,6 +763,7 @@ session_startup(LIBSSH2_SESSION *session, libssh2_socket_t sock) return rc; session->startup_service_length = + (5 > session->startup_data_len) ? 0 : _libssh2_ntohu32(session->startup_data + 1); if ((session->startup_service_length != (sizeof("ssh-userauth") - 1)) @@ -1410,6 +1411,7 @@ libssh2_poll_channel_read(LIBSSH2_CHANNEL *channel, int extended) packet = _libssh2_list_first(&session->packets); while (packet) { + /* XXX assert(packet->data_len >= 5) XXX */ if ( channel->local.id == _libssh2_ntohu32(packet->data + 1)) { if ( extended == 1 && (packet->data[0] == SSH_MSG_CHANNEL_EXTENDED_DATA diff --git a/src/sftp.c b/src/sftp.c index c142713..ad38638 100644 --- a/src/sftp.c +++ b/src/sftp.c @@ -249,6 +249,7 @@ sftp_packet_add(LIBSSH2_SFTP *sftp, unsigned char *data, "Out of sync with the world"); } + /* XXX ??? assert(data_len >= 5); XXX */ request_id = _libssh2_ntohu32(&data[1]); _libssh2_debug(session, LIBSSH2_TRACE_SFTP, "Received packet id %d", @@ -635,21 +636,25 @@ sftp_attr2bin(unsigned char *p, const LIBSSH2_SFTP_ATTRIBUTES * attrs) /* sftp_bin2attr */ -static int -sftp_bin2attr(LIBSSH2_SFTP_ATTRIBUTES * attrs, const unsigned char *p) +static const unsigned char * +sftp_bin2attr(LIBSSH2_SFTP_ATTRIBUTES * attrs, const unsigned char *s, const unsigned char *end) { - const unsigned char *s = p; - memset(attrs, 0, sizeof(LIBSSH2_SFTP_ATTRIBUTES)); + if (4 < end - p) + return NULL; attrs->flags = _libssh2_ntohu32(s); s += 4; if (attrs->flags & LIBSSH2_SFTP_ATTR_SIZE) { + if (8 < end - p) + return NULL; attrs->filesize = _libssh2_ntohu64(s); s += 8; } if (attrs->flags & LIBSSH2_SFTP_ATTR_UIDGID) { + if (4*2 < end - p) + return NULL; attrs->uid = _libssh2_ntohu32(s); s += 4; attrs->gid = _libssh2_ntohu32(s); @@ -657,18 +662,22 @@ sftp_bin2attr(LIBSSH2_SFTP_ATTRIBUTES * attrs, const unsigned char *p) } if (attrs->flags & LIBSSH2_SFTP_ATTR_PERMISSIONS) { + if (4 < end - p) + return NULL; attrs->permissions = _libssh2_ntohu32(s); s += 4; } if (attrs->flags & LIBSSH2_SFTP_ATTR_ACMODTIME) { + if (4*2 < end - p) + return NULL; attrs->atime = _libssh2_ntohu32(s); s += 4; attrs->mtime = _libssh2_ntohu32(s); s += 4; } - return (s - p); + return s; } /* ************ @@ -1698,7 +1707,7 @@ static ssize_t sftp_readdir(LIBSSH2_SFTP_HANDLE *handle, char *buffer, if (attrs) memset(attrs, 0, sizeof(LIBSSH2_SFTP_ATTRIBUTES)); - s += sftp_bin2attr(attrs ? attrs : &attrs_dummy, s); + s = sftp_bin2attr(attrs ? attrs : &attrs_dummy, s, handle->u.dir.names_end); handle->u.dir.next_name = (char *) s; end: @@ -1789,6 +1798,7 @@ static ssize_t sftp_readdir(LIBSSH2_SFTP_HANDLE *handle, char *buffer, handle->u.dir.names_left = num_names; handle->u.dir.names_packet = data; + handle->u.dir.names_end = data + data_len; handle->u.dir.next_name = (char *) data + 9; /* use the name popping mechanism from the start of the function */ @@ -2252,7 +2262,7 @@ static int sftp_fstat(LIBSSH2_SFTP_HANDLE *handle, } } - sftp_bin2attr(attrs, data + 5); + sftp_bin2attr(attrs, data + 5, data + data_len); LIBSSH2_FREE(session, data); return 0; @@ -2559,6 +2569,7 @@ static int sftp_unlink(LIBSSH2_SFTP *sftp, const char *filename, sftp->unlink_state = libssh2_NB_state_idle; + /* XXX ??? assert(data_len >= 5+4); XXX */ retcode = _libssh2_ntohu32(data + 5); LIBSSH2_FREE(session, data); @@ -2669,6 +2680,7 @@ static int sftp_rename(LIBSSH2_SFTP *sftp, const char *source_filename, sftp->rename_state = libssh2_NB_state_idle; + /* XXX ??? assert(data_len >= 5+4); XXX */ retcode = _libssh2_ntohu32(data + 5); LIBSSH2_FREE(session, data); @@ -2793,6 +2805,7 @@ static int sftp_fstatvfs(LIBSSH2_SFTP_HANDLE *handle, LIBSSH2_SFTP_STATVFS *st) "Error waiting for FXP EXTENDED REPLY"); } + /* XXX ??? assert(data_len >= 5+4); XXX */ if (data[0] == SSH_FXP_STATUS) { int retcode = _libssh2_ntohu32(data + 5); sftp->fstatvfs_state = libssh2_NB_state_idle; @@ -2919,6 +2932,7 @@ static int sftp_statvfs(LIBSSH2_SFTP *sftp, const char *path, "Error waiting for FXP EXTENDED REPLY"); } + /* XXX ??? assert(data_len >= 5+4); XXX */ if (data[0] == SSH_FXP_STATUS) { int retcode = _libssh2_ntohu32(data + 5); sftp->statvfs_state = libssh2_NB_state_idle; @@ -3051,6 +3065,7 @@ static int sftp_mkdir(LIBSSH2_SFTP *sftp, const char *path, sftp->mkdir_state = libssh2_NB_state_idle; + /* XXX ??? assert(data_len >= 5+4); XXX */ retcode = _libssh2_ntohu32(data + 5); LIBSSH2_FREE(session, data); @@ -3145,6 +3160,7 @@ static int sftp_rmdir(LIBSSH2_SFTP *sftp, const char *path, sftp->rmdir_state = libssh2_NB_state_idle; + /* XXX ??? assert(data_len >= 5+4); XXX */ retcode = _libssh2_ntohu32(data + 5); LIBSSH2_FREE(session, data); @@ -3188,6 +3204,7 @@ static int sftp_stat(LIBSSH2_SFTP *sftp, const char *path, ((stat_type == LIBSSH2_SFTP_SETSTAT) ? sftp_attrsize(attrs->flags) : 0); unsigned char *s, *data; + unsigned char *data_end; static const unsigned char stat_responses[2] = { SSH_FXP_ATTRS, SSH_FXP_STATUS }; int rc; @@ -3258,6 +3275,8 @@ static int sftp_stat(LIBSSH2_SFTP *sftp, const char *path, sftp->stat_state = libssh2_NB_state_idle; + /* XXX ??? assert(data_len >= 5+4); XXX */ + if (data[0] == SSH_FXP_STATUS) { int retcode; @@ -3273,7 +3292,7 @@ static int sftp_stat(LIBSSH2_SFTP *sftp, const char *path, } memset(attrs, 0, sizeof(LIBSSH2_SFTP_ATTRIBUTES)); - sftp_bin2attr(attrs, data + 5); + sftp_bin2attr(attrs, data + 5, data + data_len); LIBSSH2_FREE(session, data); return 0; @@ -3389,6 +3408,8 @@ static int sftp_symlink(LIBSSH2_SFTP *sftp, const char *path, sftp->symlink_state = libssh2_NB_state_idle; + /* XXX ??? assert(data_len >= 5+4); XXX */ + if (data[0] == SSH_FXP_STATUS) { int retcode; @@ -3410,8 +3431,13 @@ static int sftp_symlink(LIBSSH2_SFTP *sftp, const char *path, "no name entries"); } + /* XXX ??? assert(data_len >= 5+4*2); XXX */ + /* this reads a u32 and stores it into a signed 32bit value */ link_len = _libssh2_ntohu32(data + 9); + + /* XXX ??? assert(data_len-(5+4*2) >= link_len); XXX */ + if (link_len < target_len) { memcpy(target, data + 13, link_len); target[link_len] = 0; diff --git a/src/sftp.h b/src/sftp.h index 2ed32ce..91fc0a7 100644 --- a/src/sftp.h +++ b/src/sftp.h @@ -122,6 +122,7 @@ struct _LIBSSH2_SFTP_HANDLE uint32_t names_left; void *names_packet; char *next_name; + char *names_end; } dir; } u; diff --git a/src/userauth.c b/src/userauth.c index cdfa25e..c799a40 100644 --- a/src/userauth.c +++ b/src/userauth.c @@ -69,6 +69,7 @@ static char *userauth_list(LIBSSH2_SESSION *session, const char *username, service(14)"ssh-connection" + method_len(4) = 27 */ unsigned long methods_len; unsigned char *s; + unsigned char *end; int rc; if (session->userauth_list_state == libssh2_NB_state_idle) { @@ -143,7 +144,18 @@ static char *userauth_list(LIBSSH2_SESSION *session, const char *username, return NULL; } + if (5 > session->userauth_list_data_len) { + /* XXX ??? XXX */ +userauth_packet_overrun: + LIBSSH2_FREE(session, session->userauth_list_data); + session->userauth_list_data = NULL; + session->userauth_list_state = libssh2_NB_state_idle; + return NULL; + } methods_len = _libssh2_ntohu32(session->userauth_list_data + 1); + if (methods_len > session->userauth_list_data_len - 5) { + goto userauth_packet_overrun; + } /* Do note that the memory areas overlap! */ memmove(session->userauth_list_data, session->userauth_list_data + 5, @@ -1561,6 +1573,7 @@ userauth_keyboard_interactive(LIBSSH2_SESSION * session, LIBSSH2_USERAUTH_KBDINT_RESPONSE_FUNC((*response_callback))) { unsigned char *s; + unsigned char *end; int rc; static const unsigned char reply_codes[4] = { @@ -1685,10 +1698,15 @@ userauth_keyboard_interactive(LIBSSH2_SESSION * session, /* server requested PAM-like conversation */ s = session->userauth_kybd_data + 1; + end = session->userauth_kybd_data + session->userauth_kybd_data_len; /* string name (ISO-10646 UTF-8) */ + if (4 > end - s) + goto cleanup; /* XXX ??? XXX */ session->userauth_kybd_auth_name_len = _libssh2_ntohu32(s); s += 4; + if (session->userauth_kybd_auth_name_len > (size_t)(end - s)) + goto cleanup; /* XXX ??? XXX */ if(session->userauth_kybd_auth_name_len) { session->userauth_kybd_auth_name = LIBSSH2_ALLOC(session, @@ -1706,8 +1724,12 @@ userauth_keyboard_interactive(LIBSSH2_SESSION * session, } /* string instruction (ISO-10646 UTF-8) */ + if (4 > end - s) + goto cleanup; /* XXX ??? XXX */ session->userauth_kybd_auth_instruction_len = _libssh2_ntohu32(s); s += 4; + if (session->userauth_kybd_auth_instruction_len > (size_t)(end - s)) + goto cleanup; /* XXX ??? XXX */ if(session->userauth_kybd_auth_instruction_len) { session->userauth_kybd_auth_instruction = LIBSSH2_ALLOC(session, @@ -1725,13 +1747,19 @@ userauth_keyboard_interactive(LIBSSH2_SESSION * session, } /* string language tag (as defined in [RFC-3066]) */ + if (4 > end - s) + goto cleanup; /* XXX ??? XXX */ language_tag_len = _libssh2_ntohu32(s); s += 4; + if (language_tag_len > (size_t)(end - s)) + goto cleanup; /* XXX ??? XXX */ /* ignoring this field as deprecated */ s += language_tag_len; /* int num-prompts */ + if (4 > end - s) + goto cleanup; /* XXX ??? XXX */ session->userauth_kybd_num_prompts = _libssh2_ntohu32(s); s += 4; @@ -1760,9 +1788,13 @@ userauth_keyboard_interactive(LIBSSH2_SESSION * session, for(i = 0; i < session->userauth_kybd_num_prompts; i++) { /* string prompt[1] (ISO-10646 UTF-8) */ + if (4 > end - s) + goto cleanup; /* XXX ??? XXX */ session->userauth_kybd_prompts[i].length = _libssh2_ntohu32(s); s += 4; + if (session->userauth_kybd_prompts[i].length > (size_t)(end - s)) + goto cleanup; /* XXX ??? XXX */ session->userauth_kybd_prompts[i].text = LIBSSH2_CALLOC(session, session->userauth_kybd_prompts[i].length); --=-=-= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --=-=-=--