The included `premake5.exe` is broken
Trying to build this project:
https://github.com/SpartanJ/eepp
premake5.exe failed to fetch SDL2:
premake5 gmake --windows-mingw-build
Downloading: https://www.libsdl.org/release/SDL2-devel-2.32.8-mingw.zip
Failed to download: https://www.libsdl.org/release/SDL2-devel-2.32.8-mingw.zip res: SSL peer certificate or SSH remote key was not OK
server verification failed: certificate signer not trusted. (CAfile: none CRLfile: none)
Looks more like a libcurl issue not being able to verify the certificate issuer.
To be investigated further.
More likely that the certs are not included so there is nothing for it to verify against.
The official premake5.exe from premake-5.0.0-beta7-windows.zip is a statically linked binary with no external dependencies:
$ ldd ./premake5
ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ffc7b7c0000)
ntdll.dll => /c/Windows/SysWOW64/ntdll.dll (0x77b10000)
wow64.dll => /c/Windows/SYSTEM32/wow64.dll (0x77ab0000)
wow64win.dll => /c/Windows/system32/wow64win.dll (0x77a40000)
wow64cpu.dll => /c/Windows/system32/wow64cpu.dll (0x77b00000)
Ah, it's also a 32 bit program:
$ file ./premake5
./premake5: PE32 executable for MS Windows 6.00 (console), Intel i386, 5 sections
I can't imagine if it can have such a small binary size if it links with libcurl. This is confirmed by running listpedeps on it. The program only uses the Windows API. So, it must be possible to configure premake-core this way.
This the the mingw-w64-ucrt-x86_64-premake package:
$ ldd /ucrt64/bin/premake5
ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ffc7b7c0000)
KERNEL32.DLL => /c/Windows/system32/KERNEL32.DLL (0x7ffc7ada0000)
KERNELBASE.dll => /c/Windows/system32/KERNELBASE.dll (0x7ffc78bc0000)
ADVAPI32.dll => /c/Windows/system32/ADVAPI32.dll (0x7ffc797c0000)
bcrypt.dll => /c/Windows/SYSTEM32/bcrypt.dll (0x7ffc783d0000)
CRYPT32.dll => /c/Windows/system32/CRYPT32.dll (0x7ffc789e0000)
api-ms-win-crt-convert-l1-1-0.dll => /c/Windows/SYSTEM32/api-ms-win-crt-convert-l1-1-0.dll (0x7ffc73eb0000)
api-ms-win-crt-environment-l1-1-0.dll => /c/Windows/SYSTEM32/api-ms-win-crt-environment-l1-1-0.dll (0x7ffc73e50000)
api-ms-win-crt-filesystem-l1-1-0.dll => /c/Windows/SYSTEM32/api-ms-win-crt-filesystem-l1-1-0.dll (0x7ffc73e70000)
api-ms-win-crt-heap-l1-1-0.dll => /c/Windows/SYSTEM32/api-ms-win-crt-heap-l1-1-0.dll (0x7ffc73ed0000)
api-ms-win-crt-locale-l1-1-0.dll => /c/Windows/SYSTEM32/api-ms-win-crt-locale-l1-1-0.dll (0x7ffc73ea0000)
api-ms-win-crt-math-l1-1-0.dll => /c/Windows/SYSTEM32/api-ms-win-crt-math-l1-1-0.dll (0x7ffc73e40000)
api-ms-win-crt-private-l1-1-0.dll => /c/Windows/SYSTEM32/api-ms-win-crt-private-l1-1-0.dll (0x7ffc6f470000)
api-ms-win-crt-runtime-l1-1-0.dll => /c/Windows/SYSTEM32/api-ms-win-crt-runtime-l1-1-0.dll (0x7ffc74090000)
api-ms-win-crt-stdio-l1-1-0.dll => /c/Windows/SYSTEM32/api-ms-win-crt-stdio-l1-1-0.dll (0x7ffc73ec0000)
api-ms-win-crt-string-l1-1-0.dll => /c/Windows/SYSTEM32/api-ms-win-crt-string-l1-1-0.dll (0x7ffc73ee0000)
api-ms-win-crt-time-l1-1-0.dll => /c/Windows/SYSTEM32/api-ms-win-crt-time-l1-1-0.dll (0x7ffc73e80000)
api-ms-win-crt-utility-l1-1-0.dll => /c/Windows/SYSTEM32/api-ms-win-crt-utility-l1-1-0.dll (0x7ffc73e90000)
ole32.dll => /c/Windows/system32/ole32.dll (0x7ffc7afb0000)
VERSION.dll => /c/Windows/SYSTEM32/VERSION.dll (0x7ffc6e920000)
WS2_32.dll => /c/Windows/system32/WS2_32.dll (0x7ffc7b370000)
msvcrt.dll => /c/Windows/system32/msvcrt.dll (0x7ffc78ea0000)
sechost.dll => /c/Windows/SYSTEM32/sechost.dll (0x7ffc795f0000)
RPCRT4.dll => /c/Windows/system32/RPCRT4.dll (0x7ffc793b0000)
MSASN1.dll => /c/Windows/system32/MSASN1.dll (0x7ffc789c0000)
combase.dll => /c/Windows/SYSTEM32/combase.dll (0x7ffc7b150000)
GDI32.dll => /c/Windows/system32/GDI32.dll (0x7ffc7b3d0000)
USER32.dll => /c/Windows/system32/USER32.dll (0x7ffc791c0000)
NSI.dll => /c/Windows/system32/NSI.dll (0x7ffc7b7b0000)
ucrtbase.DLL => /c/Windows/SYSTEM32/ucrtbase.DLL (0x7ffc6ada0000)
Yeah, the same as the official build. Only the Windows API. No libcurl.
More likely that the certs are not included so there is nothing for it to verify against.
@brechtsanders I think this conjecture of @Curculigo is a possibility.
I believe so too, though I think it would be better root certs stored in the OS should be used.
Somehow libcurl (or one of its dependencies like gnutls) isn't doing this.
Because they are not designed to do this. They always use their own certs. You have to include these certs.