Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQBD9-0000DE-0t for buildfarm-members@arkaria.postgresql.org; Sun, 08 Jan 2017 11:00:27 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cQBD8-00051d-6m for buildfarm-members@arkaria.postgresql.org; Sun, 08 Jan 2017 11:00:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cQBD5-0004ye-7u for buildfarm-members@postgresql.org; Sun, 08 Jan 2017 11:00:23 +0000 Received: from mail-it0-x231.google.com ([2607:f8b0:4001:c0b::231]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cQBD0-0007OJ-Mh for buildfarm-members@postgresql.org; Sun, 08 Jan 2017 11:00:22 +0000 Received: by mail-it0-x231.google.com with SMTP id c7so5150954itd.1 for ; Sun, 08 Jan 2017 03:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ux4Ai95f4IZGWi/1qWrINqx2WTDeo7/T1drUfLYvcMU=; b=Q3ncIhyE5U8m0goQG5U6+HerFlq4ax07v8M6yHxrkYmnNtFC/vKmUXcu+RvMFfg8kM khSpm4x2Cz8O0q11YP4pTz6Sd5OX96W/Wusvj2F+hElbGkRUr2fXJskl8RJYI9GGFf4w eN8YAq9w/C//ai0v76BRXQ1AcXTYXTjT3jZWsG0VmAKD3zwYUMFDJ6eYbmkdZtQOaUc5 ycraZdBzeWR8DCk1ecqJGLbaJZhXxhKb6OHCU0Gss8aCWB4GaP4gIy2MzQPCnl+mEjky EoVNRwiAOB91oIMGSrnJG7RMFSR/811ShrynYo8aME8Ec2KoD1n9pNC840ebvsskQIBX Mz8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ux4Ai95f4IZGWi/1qWrINqx2WTDeo7/T1drUfLYvcMU=; b=FjjvEyNmNGK9M3qFyryZUKdKvn6l81Azbl+09J0GmX1R/S1icbrzuqiMveeb7wCABw 5b5JxLlgp8ORVzYls/s6/bLfGFBTf5ZfVTsbKogfw8gLLMm5LCe1ia/HI9lqxQU9dkxJ 0h7A63itfDOcFaYUAnFUB/VPKlY2RQZYK6Aaq5r0PrzL6tvngazncqBNlnA61Rj41L38 7JAL6zbXQf7jrCi1gCvORnnkqxcZpBExxCc2gwgeYKdTPbim4dN0R+iKk3JRWWabVk/z R4Srj2SZ19Zj/Rj8HxFD/rE+E0oRb7Bt5fTwjyc9mUDFKa0FS1KIzSiuspVgFnmx7fTe TR2g== X-Gm-Message-State: AIkVDXKxfbTOUAzpcSG8k/NFUK9w/nErEmr25URbfbawQDYyjp6KJeXu2wr/EtyzvF5s3AC6hXRPD2KNpM3xiw== X-Received: by 10.36.54.8 with SMTP id l8mr5496039itl.113.1483873216547; Sun, 08 Jan 2017 03:00:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.224.198 with HTTP; Sun, 8 Jan 2017 03:00:15 -0800 (PST) In-Reply-To: References: <89d566b4-58fb-c1e9-97ef-46d4d915b86c@dunslane.net> <20170107215523.GA294152@tornado.leadboat.com> <96080bc2-086f-c47f-6cee-b7f00a9bcd38@2ndQuadrant.com> <3104.1483834327@sss.pgh.pa.us> From: Dave Page Date: Sun, 8 Jan 2017 11:00:15 +0000 Message-ID: Subject: Re: Moving to HTTPS To: Andrew Dunstan Cc: Tom Lane , "buildfarm-members@postgresql.org" , "buildfarm-admins@postgresql.org" Content-Type: multipart/alternative; boundary=001a1144e1b4f6e1cd05459327c8 X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: buildfarm-members Precedence: bulk Sender: buildfarm-members-owner@postgresql.org --001a1144e1b4f6e1cd05459327c8 Content-Type: text/plain; charset=UTF-8 On Sunday, January 8, 2017, Andrew Dunstan wrote: > > > On 01/07/2017 07:12 PM, Tom Lane wrote: > >> Andrew Dunstan writes: >> >>> Yeah, you're right. Or perhaps even more simply we could do: >>> perl -MLWP::Simple -e 'print qq{BAD\n} unless head(q{ >>> https://www.postgresql.org});' >>> >> Hmm, so that reports BAD on all four of my buildfarm critters :-(. >> >> On longfin, which is running a current macOS release, "cpan install >> LWP::Protocol::https" seems to be enough to fix it; but on the other >> three, I get various flavors of failure. It looks like the root cause is >> that the versions of the relevant modules that are currently available >> from CPAN assume newer versions of OpenSSL and/or other Perl modules than >> these machines have installed. >> >> I could embark on a massive update binge, but that would sort of defeat >> the purpose of testing against old Perl versions. Thoughts? >> > I get the same on the machine hosting casteroides and protociurus: -bash-3.00$ /opt/csw/bin/perl -MLWP::Simple -e 'print qq{BAD\n} unless head(q{https://www.postgresql.org});' BAD installing LWP::Protocol::https failed miserably with both Sun Studio and GCC :-( > Ugh. I was afraid of something like that. We might need to look at > providing a proxy or something. > That would kinda defeat the point of us trying to secure everything :-( -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company --001a1144e1b4f6e1cd05459327c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sunday, January 8, 2017, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote:=


On 01/07/2017 07:12 PM, Tom Lane wrote:
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
Yeah, you're right. Or perhaps even more simply we could do:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 perl -MLWP::Simple -e 'print qq{BAD\n} unle= ss head(q{https://= www.postgresql.org});'
Hmm, so that reports BAD on all four of my buildfarm critters :-(.

On longfin, which is running a current macOS release, "cpan install LWP::Protocol::https" seems to be enough to fix it; but on the other three, I get various flavors of failure.=C2=A0 It looks like the root cause= is
that the versions of the relevant modules that are currently available
from CPAN assume newer versions of OpenSSL and/or other Perl modules than these machines have installed.

I could embark on a massive update binge, but that would sort of defeat
the purpose of testing against old Perl versions.=C2=A0 Thoughts?

I get the same on the machine hosti= ng casteroides and protociurus:

-bash-3.00$ /= opt/csw/bin/perl -MLWP::Simple -e 'print qq{BAD\n} unless head(q{https://www.postgresql.org});'
BAD

installing LWP::Protocol::https f= ailed miserably with both Sun Studio and GCC :-(
=C2=A0
Ugh. I was afraid of something like that. We might need to look at providin= g a proxy or something.

That would kind= a defeat the point of us trying to secure everything :-(=C2=A0

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

Ent= erpriseDB UK: htt= p://www.enterprisedb.com
The Enterprise PostgreSQL Company

--001a1144e1b4f6e1cd05459327c8--