* Update to OpenSSL 1.1.1 -
mingw-w64-openssl 1.1.1 - upgrade to latest version - This will break stuff compiled with stuff compiled with older versions of OpenSSL
mingw-w64-nghttp2 - 1l33l0 - rebuild for new OpenSSL version
mingw-w64-curl - 7.61.1 - rebuild with new openssl version
* This is a COMPATABILITY package that should only contain relevant config, engine .DLL's, and the standard old .DLL's.
This should NOT contain any development stuff because we want to use the new OpenSSL 1.1.1. I only provided this for compatability.
openssl-compat - 1.0.2p - UNew package
* OpenSSL 1.1.1 - revisions:
- relocation patch from https://github.com/MSP-Greg/ruby-makepkg-mingw/tree/master/mingw-w64-openssl-1.1.1
- encorporate some things from https://github.com/MSP-Greg/ruby-makepkg-mingw/tree/master/mingw-w64-openssl-1.1.1 PKGBUILD file
- enable rc5 since the patent expired
- added a patch to fix socket issue I discussed as well as added __USE_MINGW_ANSI_STDIO
- incidentily, I have built the package out of source with success for both Win32 and Win64.
Removeopenssl-compat package - it is not desired
* curl: ensure that the correct ca-bundle.crt is used for HTTPS proxies
There are actually two separate settings for the ca-bundle.crt file: one
to validate HTTPS servers, and one to validate HTTPS proxies. We forgot
the proxies.
This is a port of the fix for
https://github.com/git-for-windows/git/issues/1493
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* curl: increase pkgrel
We just fixed the long-standing issue where cURL would not find the
certificate bundle when trying to validate HTTPS *proxies*'
certificates.
Let's increase the pkgrel in preparation for a new build.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* curl: modify patches in preparation for cURL v7.57.0
While at it, squash them into one, because there is really no good
reason to apply a patch that uses the executable path for anchoring the
relocation first, only to immediately modify it to use the dll path
instead.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* curl: new version v7.57.0
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In both the openssl and gnutls variants. MultiSSL has
been introduced in curl 7.56.0 and allows multiple
SSL backends to be linked at the same time. It's then
possible to select between them at runtime.
Ref: https://curl.haxx.se/libcurl/c/curl_global_sslset.html
Ref: 1328f69d53
Also fix quote in --with-nghttp2= option.
Packages built with WinSSL or GnuTLS have -winssl or -gnutls
suffixes respectively. The packages conflict with each other,
so only one cURL variant can be installed at a time.
This required a backport of a fix that already made it into cURL's
master branch for a build error discovered only after 7.53.0 was
released.
While at it, I just regenerated the patch files for easier future
adjustments (of course, the easiest would be to just maintain these
patches in a long-running Git branch instead of patch files, but that
is too much to hope for).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* upgrade some broken packages
* correct some broken urls/checksums
* use secure urls where possible
* update PKGBUILD templates
* remove line-ending whitespace
* minor typos/fixes
Remaining md5sums either didn't download or
didn't pass checksum tests.
Currently, cURL uses the path to the current executable to figure out
where the certificates are. This works as long as all executables are in
/mingw64/bin/ (or /mingw32/bin/).
However, the entire point of having a DLL with a linkable .dll.a is to
be able to use it in executables that other people build. For example,
if an .exe lives in %HOME%\bin, the path used by our libcurl to look up
the certificates is all wrong.
Same problem with Git for Windows: its executables are hidden away from
the user, in the /mingw64/libexec/git-core/ directory. So the path to
the certificates is all wrong again.
So let's just use the path to the *cURL library* instead of the path to
the current .exe. This requires Win32 API available in Windows XP & 2003
and later, well within the Windows versions supported by Cygwin (and
therefore MSys2).
Reported by David Ebbo.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
