The rationale: bd2c77f4c2 (commitcomment-21229420)
> If you absolutely want to disable secure transport I think it'd be a
> better choice to use the http:// protocol instead, making the
> insecurity unambiguously visible in logs/screen output. (Not sure if
> GitLab supports it, but the first two does I think.)
Regular downloads of packages are verified by checksums, so
--no-check-certificate doesn't compromise the build system,
but the checksums themselves are often updated with update-checksum-%
which in turn calls the regular package download mechanism, so there
is a possibility of downloading and sealing a poisoned file.
On the one hand, old systems may still rely on --no-check-certificate,
so it is not nice to completely disable it for regular downloads.
However keeping this option enabled for backup servers only is enough
to support such systems because of the fallback mechanism.
On the other hand, download from a backup doesn't make sense while
updating a package, because the package is definetely not in the backup yet.
So --no-check-certificate is now enabled only for backup servers
and backup servers are disabled while updating packages.
See https://github.com/mxe/mxe/pull/1694#issuecomment-285324739
- move cmake configuration from mxe-conf to cmake-conf
- replace `echo` with templates for readability and maintenance
- allow packages to set other dep files
- set CMAKE_POLICY_DEFAULT_CMPNNNN in wrapper since
`cmake_minimum_required` or `cmake_policy` can't be set in
toolchain (closes#971)
The update expectedly leads to static linking failure of the qtbase
test program. Rolling back until the problem can be solved.
This reverts commit d6992ec3cf.
Boris Nagaev
Pavel Vatagin
Tony Theodore
MXEBot as Travis CI
Viktor Szakats
Mark Brand