'wget' used by packager has trouble downloading certain files from GitHub (like TinyMCE)

+1 on this, we saw this error on Hotsauce, even after deleting all releases and trying to create a couple new ones, none of our releases are getting built (although strangely this error hasn't popped up again, the releases just never get built).

--no-cache is used when drush make is executed, I don't think it is caching.

Internally, drush tries to execute something like

bash-3.2$ wget -v --timeout=30 -O /dev/null https://github.com/downloads/tinymce/tinymce/tinymce_3.5.8.zip
--2014-07-18 19:43:03--  https://github.com/downloads/tinymce/tinymce/tinymce_3.5.8.zip
Resolving github.com (github.com)... 192.30.252.130
Connecting to github.com (github.com)|192.30.252.130|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://cloud.github.com/downloads/tinymce/tinymce/tinymce_3.5.8.zip [following]
--2014-07-18 19:43:04--  https://cloud.github.com/downloads/tinymce/tinymce/tinymce_3.5.8.zip
Resolving cloud.github.com (cloud.github.com)... 54.230.70.141, 54.230.71.145, 54.240.188.239, ...
Connecting to cloud.github.com (cloud.github.com)|54.230.70.141|:443... connected.
OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Unable to establish SSL connection.

Not being able to establish an SSL connection is the problem.

Both curl and wget can't complete the SSL handshake on util and git7site. They can on stagingwww1. Some package(s) for the OS need to be updated.

I put in a support request to GitHub support in case util.drupal.org accidentally got blocked on their end.

curl -vLk https://github.com/downloads/tinymce/tinymce/tinymce_3.5.8.zip > /dev/null

After the redirect, it returns:

* Issue another request to this URL: 'https://cloud.github.com/downloads/tinymce/tinymce/tinymce_3.5.8.zip'
* About to connect() to cloud.github.com port 443 (#1)
100   134  100   134    0     0      8      0  0:00:16  0:00:15  0:00:01     8connected
* Connected to cloud.github.com (54.230.69.66) port 443 (#1)
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
* Closing connection #1

curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
} [data not shown]

Since -k should tell curl to allow the certificate to go unchecked, and this still doesn't download the file, I'm thinking being blocked is a possibility.

Short summary: It looks like the GitHub has a misconfigured AWS CloudFront.

Longer Summary: The AWS CloudFront that GitHub is using isn't properly handling
the secure port and so openssl chokes on it

For this instance trying to download
https://github.com/downloads/tinymce/tinymce/tinymce_3.5.8.zip

redirects to
https://cloud.github.com/downloads/tinymce/tinymce/tinymce_3.5.8.zip

which is a CNAME to
https://d24z2fz21y4fag.cloudfront.net

Checking the SSL port with

openssl s_client -connect cloud.github.com:443
or
openssl s_client -connect d24z2fz21y4fag.cloudfront.net:443

yeilds

CONNECTED(00000003)
140647768274576:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:762:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 320 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

For a baseline I looked at github.com and a random CloudFront instance provided by AWS itself

openssl s_client -connect github.com:443
openssl s_client -connect d34xub3ut0ooib.cloudfront.net:443

which worked properly

Newer versions of openssl give the error, but newer wget/curl seem to at least get past the error.

@dsnopek, while we are debugging this issue with cloud.github.com, SNI, and our versions of wget, openssl and curl, could you switch the URL for tinymce to http://download.moxiecode.com/tinymce/tinymce_3.5.8.zip ?

This is a workaround, but will at least work until @isntall can find a resolution with github's support people.

Awesome! Glad to see the issue has been isolated and that a workaround exists in the meantime!

Thanks,
I had this problem, but i am using 'wget' for now.

FWIW, this has also hit the aGov distro...

https://www.drupal.org/node/2248207#comment-9032027

all of the GitHub whitelist entries (that don't have licensing issues) have been updated to allow https, http, or git use of github.com and both http and https use of raw.githubusercontent.com and codeload.github.com.

I'm marking this specific issues as fixed since it's as fixed as we can get within the Whitelist project. While https access to github.com urls like https://github.com/downloads/tinymce/tinymce/tinymce_3.5.8.zip or https://raw.github.com/mustangostang/spyc/master/Spyc.php may continue to be problematic, developers should be moving to https://codeload.github.com/tinymce/tinymce/zip/3.5.8 or https://raw.githubusercontent.com/mustangostang/spyc/master/Spyc.php which both work.

cloud.github.com (aliased to d24z2fz21y4fag.cloudfront.net) is using the standard SNI-based SSL, not the (excruciatingly expensive) dedicated IP SSL mode. It works perfectly for me:

openssl s_client -connect d24z2fz21y4fag.cloudfront.net:443 -servername "cloud.github.com"

(Note that s_client only sends a SNI if explicitly asked.)

So do we have a version of wget installed that doesn't actually support SNI properly?

In short yes.

That box is CentOS 5 and without build an custom openssl and wget, SNI is a stopper.

I talked this over with basic and isntall, but neglected to update this issue. What we will do is move packaging from util to jenkins1. This makes a lot of sense for various infrastructure reasons and gets this running on a CentOS 6 box.

The one thing we need to do is resolve #1028950: Fix packaging scripts to checkout from sane/stable Git URLs instead of hard-coding the local filesystem. The rest of the work is relatively straightforward, and some QA.

QA will be a lot easier for me if the issue summary has a list of failing release node URLs. I'll be triggering packaging on them to make sure they work.

Moving this back to Infra, since I realized #1028950: Fix packaging scripts to checkout from sane/stable Git URLs instead of hard-coding the local filesystem exists to track the drupalorg code change.

#1028950: Fix packaging scripts to checkout from sane/stable Git URLs instead of hard-coding the local filesystem is now deployed and working well. I found a second blocker to moving packaging, #1268120: Use the project packaging checkout to create dependencies instead of checking out the code

#1268120: Use the project packaging checkout to create dependencies instead of checking out the code is actually not an issue, so I'm moving forward with testing this. I'll be repackaging affected releases on jenkins1 to test everything out.

I repackaged panopoly 7.x-1.7 https://www.drupal.org/node/2304621. The unable to download error disappeared, but -dev modules have drifted enough that 3 patches no longer apply. I'll need to find a release which is currently failing because of only this to really test it out.

After testing repackaging drupalorg and a few other distros, I moved all packaging over to jenkins1.