jquery / codeorigin.jquery.com

jQuery CDN

jQuery CDN

Add new assets

To publish a new release, project maintainers should commit new assets to the cdn/ directory and push to the main branch. The jQuery CDN (code.jquery.com) and releases site (releases.jquery.com) will both automatically rebuild.

WordPress build

This repository is also used to update the asset catalog at https://releases.jquery.com/, which is an auto-generated WordPress site.

To preview changes for a jquery-wp-content instance, follow the workflow instructions from our documentation on contributing to jQuery Foundation web sites.

codeorigin.jquery.com's Issues

code.jquery.com produces different script tag based on how it is accessed

If you go to https://code.jquery.com and request a script tag, it will load the script over https.

<script src="https://code.jquery.com/jquery-3.4.1.min.js" integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous"></script>

However, if you just navigate to the website via the address bar or google, you will get the HTTP website instead (http://code.jquery.com). This version of the website produces incorrect code that points to HTTP website. This is completely non-obvious to the developer and leads to jQuery not being loaded properly over HTTPS.

Please fix this so both versions of the website provide script links that point to https://code.jquery.com

Still having issues with code.jquery.com (lacks IPv6 support)

Originally reported at #51 and jquery/jquery.com#51.

The jQuery CDN code.jquery.com lacks IPv6 addresses and thus resources from it can't be received using IPv6.

As @mgol said, I'm also sorry to post it here guys, but still there doesn't seem to be any place to report issues related to code.jquery.com.

Below some traceroutes and curl calls that may help to identify the real issue.

lrcarvalho@kalabria-2:~$ curl -6 https://code.jquery.com/jquery-3.4.1.min.js -I
HTTP/1.1 403 Forbidden
Date: Wed, 11 Sep 2019 12:31:10 GMT
Connection: close
Accept-Ranges: bytes
Cache-Control: max-age=10
Content-Length: 0
X-HW: 1568205070.dop054.sp3.t,1568205070.cds036.sp3.shn,1568205070.cds036.sp3.c

lrcarvalho@kalabria-2:~$ curl -6 https://code.jquery.com -v --trace-time
09:33:04.316010 * Rebuilt URL to: https://code.jquery.com/
09:33:04.320430 *   Trying 2001:4de0:ac18::1:a:1a...
09:33:04.320462 * TCP_NODELAY set
09:33:04.345722 * Connected to code.jquery.com (2001:4de0:ac18::1:a:1a) port 443 (#0)
09:33:04.345866 * ALPN, offering h2
09:33:04.345901 * ALPN, offering http/1.1
09:33:04.345975 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
09:33:04.350264 * successfully set certificate verify locations:
09:33:04.350288 *   CAfile: /etc/ssl/cert.pem
  CApath: none
09:33:04.350371 * TLSv1.2 (OUT), TLS handshake, Client hello (1):
09:33:04.378452 * TLSv1.2 (IN), TLS handshake, Server hello (2):
09:33:04.380605 * TLSv1.2 (IN), TLS handshake, Certificate (11):
09:33:04.381982 * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
09:33:04.382153 * TLSv1.2 (IN), TLS handshake, Server finished (14):
09:33:04.382961 * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
09:33:04.383004 * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
09:33:04.383071 * TLSv1.2 (OUT), TLS handshake, Finished (20):
09:33:04.410728 * TLSv1.2 (IN), TLS change cipher, Client hello (1):
09:33:04.410860 * TLSv1.2 (IN), TLS handshake, Finished (20):
09:33:04.411066 * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
09:33:04.411104 * ALPN, server did not agree to a protocol
09:33:04.411140 * Server certificate:
09:33:04.411188 *  subject: OU=Domain Control Validated; OU=PositiveSSL Multi-Domain; CN=jquery.org
09:33:04.411251 *  start date: Oct 17 00:00:00 2018 GMT
09:33:04.411296 *  expire date: Oct 16 23:59:59 2020 GMT
09:33:04.411487 *  subjectAltName: host "code.jquery.com" matched cert's "code.jquery.com"
09:33:04.411661 *  issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Domain Validation Secure Server CA
09:33:04.411726 *  SSL certificate verify ok.
09:33:04.412120 > GET / HTTP/1.1
09:33:04.412120 > Host: code.jquery.com
09:33:04.412120 > User-Agent: curl/7.54.0
09:33:04.412120 > Accept: */*
09:33:04.412120 >
09:33:04.438844 < HTTP/1.1 403 Forbidden
09:33:04.438908 < Date: Wed, 11 Sep 2019 12:33:04 GMT
09:33:04.438950 < Connection: close
09:33:04.438990 < Accept-Ranges: bytes
09:33:04.439071 < Cache-Control: max-age=10
09:33:04.439135 < Content-Length: 0
09:33:04.439193 < X-HW: 1568205184.dop054.sp3.t,1568205184.cds038.sp3.shn,1568205184.cds038.sp3.c
09:33:04.439234 <
09:33:04.439498 * Closing connection 0
09:33:04.440027 * TLSv1.2 (OUT), TLS alert, Client hello (1):

lrcarvalho@kalabria-2:~$ traceroute6 code.jquery.com
traceroute6: Warning: cds.s5x3j6q5.hwcdn.net has multiple addresses; using 2001:4de0:ac18::1:a:1a
traceroute6 to cds.s5x3j6q5.hwcdn.net (2001:4de0:ac18::1:a:1a) from 2804:d51:4b01:5d00:d0c5:73b7:8707:5fae, 64 hops max, 12 byte packets
 1  2804:d51:222:15c::1  3.549 ms  1.285 ms  1.015 ms
 2  * * *
 3  * * *
 4  * * *
...

SSL certificate revoked

I'm getting an SSL error when visiting code.jquery.com over https. Apparently "There are issues with the site's certificate chain". Tested on both Chrome and Safari on OSX. Does this mean all websites using the jquery CDN over https are broken? That wouldn't be good...

Update: I have no issues when visiting on iOS Safari, strange.

Copy to clipboard button don't work

Returns just url of current page ( code.jquery.com ).

OS: Window 10
Browser: Chrome 73

301 Redirect Loop due to unknown CDN nodes

Hello everybody, hope you are doing great
This is Arturo Baldo on behalf of AS 262187.
I am experiencing a loop of 301 redirects since 2 weeks ago, i spoke to stackpath/highwinds cdn and they say it could be a misconfiguration at jQuery's end
Is there anything we can do to help in order to fix it?

Add link to >=3.x slim builds on https://code.jquery.com/ homepage

Right now, it shows:

jQuery Core 3.0.0 - uncompressed, minified

Perhaps we could do:

jQuery Core 3.0.0 - uncompressed, minified, slim

Listing refreshes on deploy not fully working

I just deployed a change to jquery-wp-content which affects all pages on codeorigin, but only the UI and QUnit listing pages updated.

https://code.jquery.com can't be opened. 打不开网站

https://code.jquery.com/jquery-3.3.1.min.js 打不开 ,有什么地域限制吗？

Add support for SRI

As a CDN provider it will soon become good practice to provide integrities.
See:
jsdelivr/jsdelivr#6029
cdnjs/cdnjs#4599

For all static assets that never change can integrities be added?

I'm here to help if anything is needed.

SLv3.0 vulnerabilities and handshake problems...":SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure"

First of all: Why should you disable sslv3 (and tlsv1.0 which is outdated too): http://disablessl3.com/

For "old" server which are ignoring the threats tied to sslv3, we designed an exception list containing server which are allowed to communicate in "sslv3.0" and "tlsv1.0".
For most of these server the communication works fine.
But the communication to the "jquery.com" fails with the following error: "SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure".

Reasons found in the internet trying to explain this error are for example:
DNS - problems: But we can access the "http"-pages without any problem. So it does not look like a dns-problem...
"Destination Site does not like the cipher": We are using a "selfsigned key" build on our private PKI (http://blog.techstacks.com/2010/03/3-common-causes-of-unknown-ssl-protocol-errors-with-curl.html) so you must see somthing in the server-logs if this is the problem... This error is often referred to as an problem in the usage of curl. Since we use an appliance we do not know whether curl is implemented and used or not.
Following https://curl.haxx.se/mail/archive-2014-11/0030.html the only way to deal with the problem ist to switch off sslv3.0 ...

Support pre-releases for jQuery UI

The files for jQuery UI. 1.11.0-beta.1 aren't getting listed on http://code.jquery.com/ui/

The deploy fails with this stacktrace:

/Users/jza/dev/codeorigin.jquery.com/node_modules/grunt/lib/util/task.js:352
          throw e;
                ^
TypeError: Cannot read property 'version' of undefined
    at Object.<anonymous> (/Users/jza/dev/codeorigin.jquery.com/grunt.js:284:36)
    at program1 (eval at <anonymous> (/Users/jza/dev/codeorigin.jquery.com/node_modules/handlebars/lib/handlebars/compiler/compiler.js:579:23), <anonymous>:15:92)
    at program (/Users/jza/dev/codeorigin.jquery.com/node_modules/handlebars/lib/handlebars/runtime.js:77:14)
    at Object.<anonymous> (/Users/jza/dev/codeorigin.jquery.com/node_modules/handlebars/lib/handlebars/base.js:116:21)
    at Object.eval (eval at <anonymous> (/Users/jza/dev/codeorigin.jquery.com/node_modules/handlebars/lib/handlebars/compiler/compiler.js:579:23), <anonymous>:64:25)
    at /Users/jza/dev/codeorigin.jquery.com/node_modules/handlebars/lib/handlebars/runtime.js:38:33
    at /Users/jza/dev/codeorigin.jquery.com/node_modules/handlebars/lib/handlebars/compiler/compiler.js:1294:21
    at Object.<anonymous> (/Users/jza/dev/codeorigin.jquery.com/grunt.js:336:62)
    at Object.thisTask.fn (/Users/jza/dev/codeorigin.jquery.com/node_modules/grunt/lib/grunt/task.js:58:16)
    at Task.<anonymous> (/Users/jza/dev/codeorigin.jquery.com/node_modules/grunt/lib/util/task.js:343:36)

The first entry in the ui array of the data passed to the template looks like this: { major: '1.11', latestStable: undefined, all: [Object] }. The template then tries to render something using the latestStable property, which is undefined, so it has no version property, leading to the exception above.

When looking into fixing this issue I ran into a different issue: How should pre-releases show up, if at all, on http://code.jquery.com/ui/ ? Even if I wrap the output for latestRelease in a conditional, the beta.1 is currently not a "Previous Release".

I'm going ahead with publishing the beta anyway, since this isn't a blocker (the blog post will link to the files as well).

Mixed content

code.jquery.com has mixed content with some URLs going to http - Corey asked us to file a ticket.

got "certificate has expired"

We got during bower install.

curl same error.

$curl https://code.jquery.com/
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.
HTTPS-proxy has similar options --proxy-cacert and --proxy-insecure.

But no error when certificate with goole chrome
Why???

jQuery CDN - Bug Bounty - Vulnerabilities WebApplicationAssessment

Over this site jQuery CDN https://94.31.29.54/ I detected the below vulnerabilities, my objective is that you see this issue as Bug Bounty and give an reward for this, thanks.

Asset IP Address	Service Port	Vulnerability  Test Result Code	Vulnerability ID	Vulnerability CVE IDs	Vulnerability  Severity Level	Vulnerability Title
94.31.29.54	443	vv	http-php-obsolete		10	Obsolete Version of PHP
94.31.29.54	0	vv	wordpress-obsolete		10	Obsolete Version of WordPress
94.31.29.54	0	vv	wordpress-cve-2017-14723	CVE-2017-14723	8	Wordpress: CVE-2017-14723: $wpdb->prepare() can create unexpected and unsafe queries leading to potential SQL injection
94.31.29.54	0	vv	wordpress-cve-2017-5611	CVE-2017-5611	8	Wordpress: CVE-2017-5611: 'WP_Query' is vulnerable to SQL injection when passing unsafe data
94.31.29.54	443	vv	php-cve-2015-1351	CVE-2015-1351	8	PHP Vulnerability: CVE-2015-1351
94.31.29.54	0	vv	wordpress-cve-2017-16510	CVE-2017-16510	8	Wordpress: CVE-2017-16510: $wpdb->prepare() can create unexpected and unsafe queries leading to potential SQL injection
94.31.29.54	443	ve	certificate-common-name-mismatch		7	X.509 Certificate Subject CN Does Not Match the Entity Name
94.31.29.54	0	vv	wordpress-cve-2017-9064	CVE-2017-9064	7	Wordpress: CVE-2017-9064: Cross-Site Request Forgery (CRSF) vulnerability in the filesystem credentials dialog
94.31.29.54	0	vv	wordpress-cve-2017-5489	CVE-2017-5489	7	Wordpress: CVE-2017-5489: Cross-site request forgery (CSRF) bypass via uploading a Flash file
94.31.29.54	0	vv	wordpress-cve-2016-7169	CVE-2016-7169	7	Wordpress: CVE-2016-7169: Directory Traversal Vulnerability in the upgrade package uploader
94.31.29.54	0	vv	wordpress-cve-2017-17091	CVE-2017-17091	7	Wordpress: CVE-2017-17091: wp-admin/user-new.php allows remote attackers to bypass intended access restrictions
94.31.29.54	0	vv	wordpress-cve-2017-5492	CVE-2017-5492	7	Wordpress: CVE-2017-5492: Cross-site request forgery (CSRF) in the accessibility mode of widget editing
94.31.29.54	0	vv	wordpress-cve-2017-6815	CVE-2017-6815	6	Wordpress: CVE-2017-6815: Control characters can trick redirect URL validation
94.31.29.54	0	vv	wordpress-cve-2016-6896	CVE-2016-6896	6	Wordpress: CVE-2016-6896: Directory Traversal Vulnerability in the wp_ajax_update_plugin function of 'wp-admin/includes/ajax-actions.php'
94.31.29.54	0	vv	wordpress-cve-2016-5839	CVE-2016-5839	5	Wordpress: CVE-2016-5839: 'sanitize_file_name' protection bypass via unspecified vectors
94.31.29.54	0	vv	wordpress-cve-2016-5835	CVE-2016-5835	5	Wordpress: CVE-2016-5835: Information Disclosure Vulnerability allowing remote attackers to obtain sensitive revision-history information
94.31.29.54	0	vv	wordpress-cve-2017-5610	CVE-2017-5610	5	Wordpress: CVE-2017-5610: User interface for assigning taxonomy terms in Press This is shown to users who do not have permissions to use it
94.31.29.54	0	vv	wordpress-cve-2017-14725	CVE-2017-14725	5	Wordpress: CVE-2017-14725: An open redirect was discovered on the user and term edit screens
94.31.29.54	0	vv	wordpress-cve-2017-9062	CVE-2017-9062	5	Wordpress: CVE-2017-9062: Improper handling of post meta data values in the XML-RPC
94.31.29.54	0	vv	wordpress-cve-2017-9065	CVE-2017-9065	5	Wordpress: CVE-2017-9065: Lack of capability checks for post meta data in the XML-RPC API
94.31.29.54	0	vv	wordpress-cve-2018-6389	CVE-2018-6389	5	Wordpress: CVE-2018-6389: Application Denial of Service (DoS)
94.31.29.54	0	vv	wordpress-cve-2017-14719	CVE-2017-14719	5	Wordpress: CVE-2017-14719: A path traversal vulnerability was discovered in the file unzipping code
94.31.29.54	0	vv	wordpress-cve-2017-9066	CVE-2017-9066	5	Wordpress: CVE-2017-9066: Insufficient redirect validation in the HTTP class, leading to SSRF.
94.31.29.54	0	vv	wordpress-cve-2016-5838	CVE-2016-5838	5	Wordpress: CVE-2016-5838: Password-change restriction bypass via stolen cookie
94.31.29.54	0	vv	wordpress-cve-2016-5836	CVE-2016-5836	5	Wordpress: CVE-2016-5836: Potential Denial of Service (DoS) attack vectors via oEmbed protocol implementation
94.31.29.54	0	vv	wordpress-cve-2017-5487	CVE-2017-5487	5	Wordpress: CVE-2017-5487: REST API exposed user data for all users who had authored a post of a public post type
94.31.29.54	0	vv	wordpress-cve-2017-5493	CVE-2017-5493	5	Wordpress: CVE-2017-5493: Weak cryptographic security for Multisite activation key
94.31.29.54	0	vv	wordpress-cve-2012-6707	CVE-2012-6707	5	Wordpress: CVE-2012-6707: A vulnerability due to weak MD5-based password hashing algorithm
94.31.29.54	0	vv	wordpress-cve-2017-14722	CVE-2017-14722	5	Wordpress: CVE-2017-14722: A path traversal vulnerability was discovered in the customizer
94.31.29.54	0	vv	wordpress-cve-2016-5837	CVE-2016-5837	5	Wordpress: CVE-2016-5837: Unauthorized category removal from a post
94.31.29.54	0	vv	wordpress-cve-2016-5832	CVE-2016-5832	5	Wordpress: CVE-2016-5832: Redirect bypass in the customizer
94.31.29.54	0	vv	wordpress-cve-2017-5491	CVE-2017-5491	5	Wordpress: CVE-2017-5491: Post via email checks mail.example.com if default settings aren't changed
94.31.29.54	0	vv	wordpress-cve-2017-8295	CVE-2017-8295	4	Wordpress: CVE-2017-8295: Potential Unauthorized Password Reset
94.31.29.54	0	vv	wordpress-cve-2017-14720	CVE-2017-14720	4	Wordpress: CVE-2017-14720: A cross-site scripting (XSS) vulnerability was discovered in template names
94.31.29.54	0	vv	wordpress-cve-2017-14718	CVE-2017-14718	4	Wordpress: CVE-2017-14718: A cross-site scripting (XSS) vulnerability was discovered in the link modal
94.31.29.54	0	vv	wordpress-cve-2017-17093	CVE-2017-17093	4	Wordpress: CVE-2017-17093: wp-includes/general-template.php allows attackers to conduct XSS attacks
94.31.29.54	0	vv	wordpress-cve-2016-7168	CVE-2016-7168	4	Wordpress: CVE-2016-7168: Cross-Site Scripting (XSS) Vulnerability in the media_handle_upload function in 'wp-admin/includes/media.php'
94.31.29.54	0	vv	wordpress-cve-2018-5776	CVE-2018-5776	4	Wordpress: CVE-2018-5776: WordPress before 4.9.2 has XSS in the Flash fallback files in MediaElement (under wp-includes/js/mediaelement)
94.31.29.54	0	vv	wordpress-cve-2017-14721	CVE-2017-14721	4	Wordpress: CVE-2017-14721: A cross-site scripting (XSS) vulnerability was discovered in the plugin editor
94.31.29.54	0	vv	wordpress-cve-2017-9063	CVE-2017-9063	4	Wordpress: CVE-2017-9063: Cross-Site Scripting (XSS) vulnerability related to the Customizer
94.31.29.54	0	vv	wordpress-cve-2017-17092	CVE-2017-17092	4	Wordpress: CVE-2017-17092: wp-includes/functions.php allows remote attackers to conduct XSS attacks
94.31.29.54	0	vv	wordpress-cve-2017-17094	CVE-2017-17094	4	Wordpress: CVE-2017-17094: wp-includes/feed.php allows attackers to conduct XSS attacks
94.31.29.54	0	vv	wordpress-cve-2017-5488	CVE-2017-5488	4	Wordpress: CVE-2017-5488: Cross-Site Scripting (XSS) Vulnerability via the plugin name or version header on 'update-core.php'
94.31.29.54	0	vv	wordpress-cve-2017-6814	CVE-2017-6814	4	Wordpress: CVE-2017-6814: Cross-Site Scripting (XSS) Vulnerability via media file metadata
94.31.29.54	443	ve	ssl-cve-2011-3389-beast	CVE-2011-3389	4	TLS/SSL Server is enabling the BEAST attack
94.31.29.54	0	vv	wordpress-cve-2017-14724	CVE-2017-14724	4	Wordpress: CVE-2017-14724: A cross-site scripting (XSS) vulnerability was discovered in the oEmbed discovery
94.31.29.54	0	vv	wordpress-cve-2017-14726	CVE-2017-14726	4	Wordpress: CVE-2017-14726: A cross-site scripting (XSS) vulnerability was discovered in the visual editor
94.31.29.54	0	vv	wordpress-cve-2016-5834	CVE-2016-5834	4	Wordpress: CVE-2016-5834: Cross-Site Scripting (XSS) Vulnerability in the wp_get_attachment_link function in 'wp-includes/post-template.php'
94.31.29.54	0	vv	wordpress-cve-2016-5833	CVE-2016-5833	4	Wordpress: CVE-2016-5833: Cross-Site Scripting (XSS) Vulnerability in the column_title function in 'wp-admin/includes/class-wp-media-list-table.php'
94.31.29.54	0	vv	wordpress-cve-2016-6897	CVE-2016-6897	4	Wordpress: CVE-2016-6897: Cross-site request forgery (CSRF) in the wp_ajax_update_plugin function of 'wp-admin/includes/ajax-actions.php'
94.31.29.54	0	vv	wordpress-cve-2017-5612	CVE-2017-5612	4	Wordpress: CVE-2017-5612: Cross-Site Scripting (XSS) Vulnerability in the posts list table
94.31.29.54	0	vv	wordpress-cve-2017-6817	CVE-2017-6817	4	Wordpress: CVE-2017-6817: Cross-Site Scripting (XSS) Vulnerability via video URL in YouTube Embeds
94.31.29.54	0	vv	wordpress-cve-2017-6816	CVE-2017-6816	4	Wordpress: CVE-2017-6816: Unintended files can be deleted by administrators using the plugin deletion functionality
94.31.29.54	443	ve	tlsv1_0-enabled		4	TLS Server Supports TLS version 1.0
94.31.29.54	0	vv	wordpress-cve-2017-9061	CVE-2017-9061	4	Wordpress: CVE-2017-9061: Cross-Site Scripting (XSS) vulnerability when attempting to upload very large files
94.31.29.54	0	vv	wordpress-cve-2017-5490	CVE-2017-5490	4	Wordpress: CVE-2017-5490: Cross-Site Scripting (XSS) Vulnerability via theme name fallback
94.31.29.54	0	vv	wordpress-cve-2017-6819	CVE-2017-6819	4	Wordpress: CVE-2017-6819: Cross-site request forgery (CSRF) in Press This leading to excessive use of server resources
94.31.29.54	0	vv	wordpress-cve-2017-6818	CVE-2017-6818	4	Wordpress: CVE-2017-6818: Cross-Site Scripting (XSS) Vulnerability via taxonomy term names
94.31.29.54	443	ve	ssl-static-key-ciphers		3	TLS/SSL Server Supports The Use of Static Key Ciphers
94.31.29.54	443	vp	ssl-cbc-ciphers	CVE-2013-0169	3	TLS/SSL Timing Side-Channel Attacks, aka the "Lucky Thirteen" Attack
94.31.29.54	0	vv	wordpress-cve-2016-9263	CVE-2016-9263	3	Wordpress: CVE-2016-9263: A cross-domain Flash injection vulnerability found in flashmediaelement.swf
94.31.29.54	443	ve	tlsv1_1-enabled		3	TLS Server Supports TLS version 1.1
94.31.29.54	0	ve	generic-icmp-timestamp	CVE-1999-0524	1	ICMP timestamp response

code.jquery.com lacks IPv6 support

Originally reported by @tambry in jquery/jquery.com#178.

The jQuery CDN code.jquery.com lacks IPv6 addresses and thus resources from it can't be received using IPv6.

The CDN seems to be served by StackPath (previously Highwinds), which has recently gotten IPv6 support, so this should be fixable. For reference, BootstrapCDN also uses StackPath, and they recently enabled IPv6 for their CDN endpoint (stackpath.bootstrapcdn.com).

PS
Apologies if this is the wrong place to report this, but there doesn't seem to be any place to report issues related to code.jquery.com.

ui-git and ui-1-9-git fight for theme images

We need to move the 1-9 git build to it's own directory so it doesn't compete with the standard git build for the images directory.

Consider asserting a `Cross-Origin-Resource-Policy`?

Hey folks! Hopefully this is a reasonable repository for requests like this one. :)

Cross-Origin-Resource-Policy (CORP) is an HTTP response header that asserts a scope in which a given resource is allowed to be embedded. Today, the default for all resources is to allow cross-site loads, which unfortunately creates the conditions for side-channel attacks via Spectre, et al. With this background, browser vendors are interested in changing this default generally in the long-term, and in the short-term will allow developers to require explicit opt-in via Cross-Origin-Embedder-Policy. This opt-in will be a prerequisite for some particularly interesting APIs like SharedArrayBuffer.

To support this migration, it would be ideal if y'all could begin adding this assertion explicitly to resources that are expected to be used by various sites out there on the internet (e.g. by sending a Cross-Origin-Resource-Policy: cross-origin header). This should be a no-op in the status quo, and will ensure that y'all aren't blocking developers from opting-into Cross-Origin-Embedder-Policy (and therefore exciting new APIs).

If there's any more context I can give you about this set of features, I'd be happy to chat!

Enable HSTS to tell browsers to prefer HTTPS for code.jquery.com

This would solve:

• #55
• jquery/demos.jquerymobile.com#19

Sub steps:

• Set Strict-Transport-Security: max-age=106384710; includeSubDomains; preload in our Nginx backend configuration as a header on our main content domains. Taking care to apply this both to responses generated via WordPress for pages on api.jquery.com and code.jquery.com, as well as static files served from codeorigin.jquery.com.
• Submit jquery.com to https://hstspreload.org/

Redirect to HTTPS, or lock CORS to HTTPS only

A full forced redirect to HTTPS should have no negative impact on browsers accessing code.jquery.com through a <script> tag. An HSTS header would further protect visitors to sites that embed an insecure code.jquery.com link.

Alternatively, I can see that CORS has just recently been enabled for resources on code.jquery.com. Safari does break on attempts to redirect CORS URLs from HTTP to HTTPS, even if both endpoints have CORS headers enabled.

Before the jQuery CDN develops much of a user base for its CORS support, the most immediate helpful thing to avoid making it difficult for the CDN to force a redirect in the future would be to only provide CORS support for HTTPS requests. This would at least prevent the situation from deterioriating while the jQuery CDN evaluates a full switch to HTTPS and HSTS.

Grunt 0.4.x

Why is this on 0.3.x ?

Reload listing pages on deploy

When we deploy, the listing pages should be automatically reloaded. We have so few pages that we can just reload all on every deploy instead of trying to be smart and only reloading the ones that actually changed.

Remove the unversioned jQuery map file

See jquery/jquery#2899

One of the root or intermediate certificates has expired (3 days ago).

https://www.sslshopper.com/ssl-checker.html#hostname=https://code.jquery.com reports an error.

And

https://sectigostore.com/ssl-tools/ssl-checker.php does not.

https://forum.jquery.com/topic/certificate-chain-issue reported it to the forum.

Offer HTTP/2

Resources from the jquery CDN are only loaded over HTTP/1.1

Add 3.0 to http://code.jquery.com/jquery/

3.0 will need to be added to this page when 3.0 final is released.

Note that links to http://code.jquery.com/jquery-git2.js redirects to 3.0-pre.

301 Redirect Loop due to unknown CDN nodes (*-latest files)

The url https://code.jquery.com/jquery-latest.min.js isn't working due to a redirect loop.

I'm trying to reach the url from Uruguay, South America. Any browser is giving the next problem:
This page isn’t working
code.jquery.com redirected you too many times.
Try clearing your cookies.
ERR_TOO_MANY_REDIRECTS

Wordpress version

Apparently needs to be updated:

http://sitecheck.sucuri.net/results/code.jquery.com

Provide a JSON file for all versions

There should be a JSON file generated on every update which lists all the versions using semver and points to the appropriate files. This should exist for all projects.

Remove submodules

There is a submodule for the NetDNA php code, we should just import the external so I don't have to change the puppet scripts to do git submodule update --init

cc @aulvi

Purge not working as expected

The QUnit git build hasn't updated in a while (since version 2.6.3-pre) which corresponds to when the CDN API changed and the purge endpoint was updated.

According to this Jenkins log, the file should have been updated successfully, but you can see here that the version is still out-of-date (should be version 2.8.1-pre).

cc @Krinkle

QUnit versions not updating

The latest version of QUnit listed on http://code.jquery.com/ is out-of-date. Additionally, the QUnit page does not list all published versions.

Seems like maybe the build for the website is no longer running correctly?

Increase gzip compression level

I have tested the latest jQuery version at code.jquery.com using Gzip and Brotli Compression Level Estimator and there is room for improvement:

Please increase the gzip compression level from 1 to at least 6 and enable brotli compression method. Thanks.

code.jquery.com use a TLS/SSL certificate no more valid

The root certificate authority has expired at 30 may 2020

https://www.ssllabs.com/ssltest/analyze.html?d=code.jquery.com&s=2001%3a4de0%3aac19%3a0%3a0%3a1%3ab%3a1b&latest

code.jquery.com has mismatched cert

The code.jquery.com site is serving up a cert for hwcdn.net.

code.jquery.com uses an invalid security certificate.

The certificate is only valid for the following names: *.ssl.hwcdn.net, ssl.hwcdn.net Error code: SSL_ERROR_BAD_CERT_DOMAIN

Obviously this breaks any site including one of the CDN scripts as the browser will not load it.

jQuery Latest broken on CDN

http://code.jquery.com/jquery-latest.min.js
http://code.jquery.com/jquery-latest.js

Give both 502 Bad Gateway breaking a lot of pages, although they should be included as they are in https://github.com/jquery/codeorigin.jquery.com/tree/master/cdn ? Maybe a bad sync to the CDN ?

( I understand you are fading out the support for jquery latest, but since it's the most 'popular' quick implementation due to articles like http://stackoverflow.com/questions/441412/is-there-a-link-to-the-latest-jquery-library-on-google-apis I assume this might be a malfunction )

Enable SRI for QUnit releases

It seems to be limited to jQuery core releases currently.

Provide Brotli compression

Split from #38.

I have tested the latest jQuery version at code.jquery.com using Gzip and Brotli Compression Level Estimator and there is room for improvement:

https://code.jquery.com/ is down

https://code.jquery.com/ fails to load. http://code.jquery.com/ loads except for the HTTPS resources it tries to request.

Not a local network issue, I've verified with multiple people at different locations and they too cannot reach the HTTPS site.

Redirect to https

I'm not sure if this is the right place to report this, but:

http://code.jquery.com/

don't redirect to https and links are just paths so they are also http (so if you use copy link in context menu you will get http link).

Maybe everything should be redirected to https including the file links.

Accept-Encoding values not treated as case-insensitive (i.e. GZIP vs gzip)

Migrated from jquery/jquery#4162

From @gibson042:

Issue confirmed. Content coding values (which are the contents of Accept-Encoding) are case-insensitive per RFC 7231, but code.jquery.com sends a response with no encoding in response to Accept-Encoding: GZIP (or other variants that are not all lowercase), and—here's the issue—lies about that lack of encoding by also including Content-Encoding: gzip.

Transcripts, with ### comments added.

no Accept-Encoding

$ curl -sv http://code.jquery.com/jquery-2.2.4.min.js | head -c 10 | xxd
*   Trying 205.185.208.52...
* Connected to code.jquery.com (205.185.208.52) port 80 (#0)
> GET /jquery-2.2.4.min.js HTTP/1.1
> Host: code.jquery.com
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Fri, 31 Aug 2018 14:04:40 GMT
< Connection: Keep-Alive
< Accept-Ranges: bytes
< Content-Length: 85578 ### unencoded size: 85578
< Content-Type: application/javascript; charset=utf-8
< Last-Modified: Fri, 20 May 2016 17:24:41 GMT
< Server: nginx
< ETag: W/"573f4859-14e4a"
< Cache-Control: max-age=315360000
< Cache-Control: public
< Access-Control-Allow-Origin: *
< Vary: Accept-Encoding
< X-HW: 1535724280.dop013.ny3.t,1535724280.cds046.ny3.c
< 
{ [1460 bytes data]
00000000: 2f2a 2120 6a51 7565 7279                 /*! jQuery ### unencoded response
* Failed writing body (892 != 16384)
* Closing connection 0

no Accept-Encoding: gzip

$ curl -sv -H 'Accept-Encoding: gzip' http://code.jquery.com/jquery-2.2.4.min.js | head -c 10 | xxd
*   Trying 205.185.208.52...
* Connected to code.jquery.com (205.185.208.52) port 80 (#0)
> GET /jquery-2.2.4.min.js HTTP/1.1
> Host: code.jquery.com
> User-Agent: curl/7.47.0
> Accept: */*
> Accept-Encoding: gzip ### request for gzipped response
> 
< HTTP/1.1 200 OK
< Date: Fri, 31 Aug 2018 14:10:51 GMT
< Connection: Keep-Alive
< Accept-Ranges: bytes
< Content-Encoding: gzip ### response is claimed to be gzipped
< Content-Length: 34834 ### compressed size: 34834
< Content-Type: application/javascript; charset=utf-8
< Last-Modified: Fri, 20 May 2016 17:24:41 GMT
< Server: nginx
< ETag: W/"573f4859-14e4a"
< Cache-Control: max-age=315360000
< Access-Control-Allow-Origin: *
< Vary: Accept-Encoding
< X-HW: 1535724651.dop012.ny3.t,1535724651.cds046.ny3.c
< 
{ [1460 bytes data]
00000000: 1f8b 0800 0000 0000 0003                 .......... ### response appears gzipped, cf. https://tools.ietf.org/html/rfc1952#page-6
* Failed writing body (1500 != 9899)
* Closing connection 0

no Accept-Encoding: GZIP

$ curl -sv -H 'Accept-Encoding: GZIP' http://code.jquery.com/jquery-2.2.4.min.js | head -c 10 | xxd
*   Trying 205.185.208.52...
* Connected to code.jquery.com (205.185.208.52) port 80 (#0)
> GET /jquery-2.2.4.min.js HTTP/1.1
> Host: code.jquery.com
> User-Agent: curl/7.47.0
> Accept: */*
> Accept-Encoding: GZIP ### unusual request for gzipped response
> 
< HTTP/1.1 200 OK
< Date: Fri, 31 Aug 2018 14:14:50 GMT
< Connection: Keep-Alive
< Accept-Ranges: bytes
< Content-Encoding: gzip ### response is claimed to be gzipped
< Content-Length: 85578 ### …but the size is as big as an unencoded response :\
< Content-Type: application/javascript; charset=utf-8
< Last-Modified: Fri, 20 May 2016 17:24:41 GMT
< Server: nginx
< ETag: W/"573f4859-14e4a"
< Cache-Control: max-age=315360000
< Access-Control-Allow-Origin: *
< Vary: Accept-Encoding
< X-HW: 1535724890.dop004.ny3.t,1535724890.cds046.ny3.c
< 
{ [1460 bytes data]
00000000: 2f2a 2120 6a51 7565 7279                 /*! jQuery ### non-gzipped! >:(
* Failed writing body (2068 != 16384)
* Closing connection 0

Domain code.jquery not working

Dears,

Why the URL http://code.jquery.com/jquery-x.x.x not working

jquery 3.2.1.slim.min.js breaks ajax load function definition

When referencing http://code.jquery.com/jquery-3.2.1.slim.min.js I get an error about undefined .load() function. Referencing http://code.jquery.com/jquery-3.2.1.min.js instead fixes the issue.

$(document).ready(function() { $('#test').load('doesntmatter'); });

Uncaught TypeError: $(...).load is not a function

StackOverflow question showing minimal example.

Update NetDNA Rest Service

We should update to the latest version from https://github.com/netdna/netdnarws-php.

jQuery CDN - Bug Bounty - Vulnerabilities WebApplicationAssessment

Over this site jQuery CDN https://94.31.29.54/ I detected the below vulnerabilities, my objective is that you see this issue as Bug Bounty and give me an reward for this, thanks.

Asset IP Address	Service Port	Vulnerability  Test Result Code	Vulnerability ID	Vulnerability CVE IDs	Vulnerability  Severity Level	Vulnerability Title
94.31.29.54	443	vv	http-php-obsolete		10	Obsolete Version of PHP
94.31.29.54	0	vv	wordpress-obsolete		10	Obsolete Version of WordPress
94.31.29.54	0	vv	wordpress-cve-2017-14723	CVE-2017-14723	8	Wordpress: CVE-2017-14723: $wpdb->prepare() can create unexpected and unsafe queries leading to potential SQL injection
94.31.29.54	0	vv	wordpress-cve-2017-5611	CVE-2017-5611	8	Wordpress: CVE-2017-5611: 'WP_Query' is vulnerable to SQL injection when passing unsafe data
94.31.29.54	443	vv	php-cve-2015-1351	CVE-2015-1351	8	PHP Vulnerability: CVE-2015-1351
94.31.29.54	0	vv	wordpress-cve-2017-16510	CVE-2017-16510	8	Wordpress: CVE-2017-16510: $wpdb->prepare() can create unexpected and unsafe queries leading to potential SQL injection
94.31.29.54	443	ve	certificate-common-name-mismatch		7	X.509 Certificate Subject CN Does Not Match the Entity Name
94.31.29.54	0	vv	wordpress-cve-2017-9064	CVE-2017-9064	7	Wordpress: CVE-2017-9064: Cross-Site Request Forgery (CRSF) vulnerability in the filesystem credentials dialog
94.31.29.54	0	vv	wordpress-cve-2017-5489	CVE-2017-5489	7	Wordpress: CVE-2017-5489: Cross-site request forgery (CSRF) bypass via uploading a Flash file
94.31.29.54	0	vv	wordpress-cve-2016-7169	CVE-2016-7169	7	Wordpress: CVE-2016-7169: Directory Traversal Vulnerability in the upgrade package uploader
94.31.29.54	0	vv	wordpress-cve-2017-17091	CVE-2017-17091	7	Wordpress: CVE-2017-17091: wp-admin/user-new.php allows remote attackers to bypass intended access restrictions
94.31.29.54	0	vv	wordpress-cve-2017-5492	CVE-2017-5492	7	Wordpress: CVE-2017-5492: Cross-site request forgery (CSRF) in the accessibility mode of widget editing
94.31.29.54	0	vv	wordpress-cve-2017-6815	CVE-2017-6815	6	Wordpress: CVE-2017-6815: Control characters can trick redirect URL validation
94.31.29.54	0	vv	wordpress-cve-2016-6896	CVE-2016-6896	6	Wordpress: CVE-2016-6896: Directory Traversal Vulnerability in the wp_ajax_update_plugin function of 'wp-admin/includes/ajax-actions.php'
94.31.29.54	0	vv	wordpress-cve-2016-5839	CVE-2016-5839	5	Wordpress: CVE-2016-5839: 'sanitize_file_name' protection bypass via unspecified vectors
94.31.29.54	0	vv	wordpress-cve-2016-5835	CVE-2016-5835	5	Wordpress: CVE-2016-5835: Information Disclosure Vulnerability allowing remote attackers to obtain sensitive revision-history information
94.31.29.54	0	vv	wordpress-cve-2017-5610	CVE-2017-5610	5	Wordpress: CVE-2017-5610: User interface for assigning taxonomy terms in Press This is shown to users who do not have permissions to use it
94.31.29.54	0	vv	wordpress-cve-2017-14725	CVE-2017-14725	5	Wordpress: CVE-2017-14725: An open redirect was discovered on the user and term edit screens
94.31.29.54	0	vv	wordpress-cve-2017-9062	CVE-2017-9062	5	Wordpress: CVE-2017-9062: Improper handling of post meta data values in the XML-RPC
94.31.29.54	0	vv	wordpress-cve-2017-9065	CVE-2017-9065	5	Wordpress: CVE-2017-9065: Lack of capability checks for post meta data in the XML-RPC API
94.31.29.54	0	vv	wordpress-cve-2018-6389	CVE-2018-6389	5	Wordpress: CVE-2018-6389: Application Denial of Service (DoS)
94.31.29.54	0	vv	wordpress-cve-2017-14719	CVE-2017-14719	5	Wordpress: CVE-2017-14719: A path traversal vulnerability was discovered in the file unzipping code
94.31.29.54	0	vv	wordpress-cve-2017-9066	CVE-2017-9066	5	Wordpress: CVE-2017-9066: Insufficient redirect validation in the HTTP class, leading to SSRF.
94.31.29.54	0	vv	wordpress-cve-2016-5838	CVE-2016-5838	5	Wordpress: CVE-2016-5838: Password-change restriction bypass via stolen cookie
94.31.29.54	0	vv	wordpress-cve-2016-5836	CVE-2016-5836	5	Wordpress: CVE-2016-5836: Potential Denial of Service (DoS) attack vectors via oEmbed protocol implementation
94.31.29.54	0	vv	wordpress-cve-2017-5487	CVE-2017-5487	5	Wordpress: CVE-2017-5487: REST API exposed user data for all users who had authored a post of a public post type
94.31.29.54	0	vv	wordpress-cve-2017-5493	CVE-2017-5493	5	Wordpress: CVE-2017-5493: Weak cryptographic security for Multisite activation key
94.31.29.54	0	vv	wordpress-cve-2012-6707	CVE-2012-6707	5	Wordpress: CVE-2012-6707: A vulnerability due to weak MD5-based password hashing algorithm
94.31.29.54	0	vv	wordpress-cve-2017-14722	CVE-2017-14722	5	Wordpress: CVE-2017-14722: A path traversal vulnerability was discovered in the customizer
94.31.29.54	0	vv	wordpress-cve-2016-5837	CVE-2016-5837	5	Wordpress: CVE-2016-5837: Unauthorized category removal from a post
94.31.29.54	0	vv	wordpress-cve-2016-5832	CVE-2016-5832	5	Wordpress: CVE-2016-5832: Redirect bypass in the customizer
94.31.29.54	0	vv	wordpress-cve-2017-5491	CVE-2017-5491	5	Wordpress: CVE-2017-5491: Post via email checks mail.example.com if default settings aren't changed
94.31.29.54	0	vv	wordpress-cve-2017-8295	CVE-2017-8295	4	Wordpress: CVE-2017-8295: Potential Unauthorized Password Reset
94.31.29.54	0	vv	wordpress-cve-2017-14720	CVE-2017-14720	4	Wordpress: CVE-2017-14720: A cross-site scripting (XSS) vulnerability was discovered in template names
94.31.29.54	0	vv	wordpress-cve-2017-14718	CVE-2017-14718	4	Wordpress: CVE-2017-14718: A cross-site scripting (XSS) vulnerability was discovered in the link modal
94.31.29.54	0	vv	wordpress-cve-2017-17093	CVE-2017-17093	4	Wordpress: CVE-2017-17093: wp-includes/general-template.php allows attackers to conduct XSS attacks
94.31.29.54	0	vv	wordpress-cve-2016-7168	CVE-2016-7168	4	Wordpress: CVE-2016-7168: Cross-Site Scripting (XSS) Vulnerability in the media_handle_upload function in 'wp-admin/includes/media.php'
94.31.29.54	0	vv	wordpress-cve-2018-5776	CVE-2018-5776	4	Wordpress: CVE-2018-5776: WordPress before 4.9.2 has XSS in the Flash fallback files in MediaElement (under wp-includes/js/mediaelement)
94.31.29.54	0	vv	wordpress-cve-2017-14721	CVE-2017-14721	4	Wordpress: CVE-2017-14721: A cross-site scripting (XSS) vulnerability was discovered in the plugin editor
94.31.29.54	0	vv	wordpress-cve-2017-9063	CVE-2017-9063	4	Wordpress: CVE-2017-9063: Cross-Site Scripting (XSS) vulnerability related to the Customizer
94.31.29.54	0	vv	wordpress-cve-2017-17092	CVE-2017-17092	4	Wordpress: CVE-2017-17092: wp-includes/functions.php allows remote attackers to conduct XSS attacks
94.31.29.54	0	vv	wordpress-cve-2017-17094	CVE-2017-17094	4	Wordpress: CVE-2017-17094: wp-includes/feed.php allows attackers to conduct XSS attacks
94.31.29.54	0	vv	wordpress-cve-2017-5488	CVE-2017-5488	4	Wordpress: CVE-2017-5488: Cross-Site Scripting (XSS) Vulnerability via the plugin name or version header on 'update-core.php'
94.31.29.54	0	vv	wordpress-cve-2017-6814	CVE-2017-6814	4	Wordpress: CVE-2017-6814: Cross-Site Scripting (XSS) Vulnerability via media file metadata
94.31.29.54	443	ve	ssl-cve-2011-3389-beast	CVE-2011-3389	4	TLS/SSL Server is enabling the BEAST attack
94.31.29.54	0	vv	wordpress-cve-2017-14724	CVE-2017-14724	4	Wordpress: CVE-2017-14724: A cross-site scripting (XSS) vulnerability was discovered in the oEmbed discovery
94.31.29.54	0	vv	wordpress-cve-2017-14726	CVE-2017-14726	4	Wordpress: CVE-2017-14726: A cross-site scripting (XSS) vulnerability was discovered in the visual editor
94.31.29.54	0	vv	wordpress-cve-2016-5834	CVE-2016-5834	4	Wordpress: CVE-2016-5834: Cross-Site Scripting (XSS) Vulnerability in the wp_get_attachment_link function in 'wp-includes/post-template.php'
94.31.29.54	0	vv	wordpress-cve-2016-5833	CVE-2016-5833	4	Wordpress: CVE-2016-5833: Cross-Site Scripting (XSS) Vulnerability in the column_title function in 'wp-admin/includes/class-wp-media-list-table.php'
94.31.29.54	0	vv	wordpress-cve-2016-6897	CVE-2016-6897	4	Wordpress: CVE-2016-6897: Cross-site request forgery (CSRF) in the wp_ajax_update_plugin function of 'wp-admin/includes/ajax-actions.php'
94.31.29.54	0	vv	wordpress-cve-2017-5612	CVE-2017-5612	4	Wordpress: CVE-2017-5612: Cross-Site Scripting (XSS) Vulnerability in the posts list table
94.31.29.54	0	vv	wordpress-cve-2017-6817	CVE-2017-6817	4	Wordpress: CVE-2017-6817: Cross-Site Scripting (XSS) Vulnerability via video URL in YouTube Embeds
94.31.29.54	0	vv	wordpress-cve-2017-6816	CVE-2017-6816	4	Wordpress: CVE-2017-6816: Unintended files can be deleted by administrators using the plugin deletion functionality
94.31.29.54	443	ve	tlsv1_0-enabled		4	TLS Server Supports TLS version 1.0
94.31.29.54	0	vv	wordpress-cve-2017-9061	CVE-2017-9061	4	Wordpress: CVE-2017-9061: Cross-Site Scripting (XSS) vulnerability when attempting to upload very large files
94.31.29.54	0	vv	wordpress-cve-2017-5490	CVE-2017-5490	4	Wordpress: CVE-2017-5490: Cross-Site Scripting (XSS) Vulnerability via theme name fallback
94.31.29.54	0	vv	wordpress-cve-2017-6819	CVE-2017-6819	4	Wordpress: CVE-2017-6819: Cross-site request forgery (CSRF) in Press This leading to excessive use of server resources
94.31.29.54	0	vv	wordpress-cve-2017-6818	CVE-2017-6818	4	Wordpress: CVE-2017-6818: Cross-Site Scripting (XSS) Vulnerability via taxonomy term names
94.31.29.54	443	ve	ssl-static-key-ciphers		3	TLS/SSL Server Supports The Use of Static Key Ciphers
94.31.29.54	443	vp	ssl-cbc-ciphers	CVE-2013-0169	3	TLS/SSL Timing Side-Channel Attacks, aka the "Lucky Thirteen" Attack
94.31.29.54	0	vv	wordpress-cve-2016-9263	CVE-2016-9263	3	Wordpress: CVE-2016-9263: A cross-domain Flash injection vulnerability found in flashmediaelement.swf
94.31.29.54	443	ve	tlsv1_1-enabled		3	TLS Server Supports TLS version 1.1
94.31.29.54	0	ve	generic-icmp-timestamp	CVE-1999-0524	1	ICMP timestamp response

I tried to upload in PDF format the report, but appear this error: Something went really wrong, and we can’t process that file.

I put the vulnerabilities directly in the issue.

Add SRI hashes to Git

Given that addition of files is done through Git, perhaps the build step that creates the SRI information should also be committed to Git - instead of happening during deployment?

That would provide more confidence, transparency and verifiability for these values.

Copy theme images for UI git build

SSL Issue

There appears to be an SSL issue with the code.jquery.com site.

Your connection is not private
Attackers might be trying to steal your information from code.jquery.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID

Fortify Issue : https://github.com/jquery/codeorigin.jquery.com/blob/master/cdn/jquery-3.2.1.min.js line 2 (Insecure Randomness)

Fortify Issue : https://github.com/jquery/codeorigin.jquery.com/blob/master/cdn/jquery-3.2.1.min.js line 2 (Insecure Randomness)

Make sure the minified file is, in fact, minified

Hey guys,

Look at this url: http://code.jquery.com/jquery-migrate-3.0.1.min.js
At the end it says ".min", but the file isn't minified.

http://code.jquery.com/jquery-latest.min.js is not latest

http://code.jquery.com/jquery-latest.min.js "v1.10.2"
v1.11 was released 2 months ago. That is if "latest" was supposed to work to mean "latest v1 branch".

Workaround: (I believe these are scripted, so as long as someone makes the right folder name, aliases will work).
http://cdn.jsdelivr.net/jquery/1/jquery.min.js //newest v1.*
http://cdn.jsdelivr.net/jquery/2/jquery.min.js //newest v2.*

Long-term workaround: Perhaps let jsDelivr, be the "official" CDN? It is basically MaxCDN (that you're already using) + CloudFlare (that drives CDNJS) + a few extra POPs. In a month or so there will be a semi-automated upload system also.

Thanks for all the work you all do!