MINGW-packages: GnuTLS still not working properly?

@revelator Don’t really get the mintty talk for MinGW. The whole apparent MSYS2 axiom, that everything for windows should work inside a somewhat dubious posix emulator kind of make my head spin like “wait… what?”. Trying to make everything work like that will always break somewhere - and for MinGW it should way sooner break in mintty and not on the desktop, IMO. MinGW64 mintty support probably isn’t something a lot of users need or would even understand. Besides, there’s a native MSYS2 version of gnutls - just use that in mintty. Just saying…

sorry havent had time to look further into it yet, first i got sick now and now my old developer machine finally bit the dust after 12 years of faithfull service (had to happen someday) but it had a good run. So the last few days i been installing new hardware and now i have to recreate my build environment before i can give it another go… i hope to be up and running again soon though.

New upstream tickets: https://gitlab.com/gnutls/gnutls/-/issues/1449 https://gitlab.com/gnutls/gnutls/-/issues/1450

sure but give me sec, got pneumonia :S so im not totally upto speed (sleeping most of the time and coughing my lungs up yuck).

This fixes GnuTLS for me, the cli interface now connects reliably so I am posting this for review and confirmation by others.

The big problem was indeed the certificate store. You really need to be using the right one and the default WIndows store doesn’t seem to work correctly for MinGW. And pulling individual files from p11-kit seemed like a clever old school way of doing things but is also wrong. TLDR; I think we need to change PKGCONFIG to add the following configuration(x2) line at the very least:

--with-default-trust-store-pkcs11="pkcs11:"

It works on most Linux distros and seems to work for MinGW too. My cli connections are very reliable now. To prove this to myself I also no longer need the TLS-1.3 work-round I posted earlier. Just change to p11-kit as the default store and everything else just works!

The second part of the problem we caused ourselves by reversing an upstream patch that probably shouldn’t be reversed. I changed common.h back to it’s original state before the chunk reversal and it solved the remaining cli issues for me. Anyone want to try it out? Afterwards maybe @Biswa96 depending on confirmation you might want to call off the dogs upstream… It was all us apparently just faulty packaging and lack of actual testing.

PS pidgin still doesn’t work right but with cli working perfectly I’m starting to believe there’s an implementation/configuration issue I’ll keep looking. But with finally working gnutls tools I think we can eliminate that dependency from the equation…

I’m not sure how that could be correct if you are using MSYS2-project defaults. Here is my recommended path for MinGW64 users who chose the MSYS2 distro:

Path=X:\B;X:\B\bin;X:\MSYS2\mingw64\bin;X:\MSYS2\mingw64\libexec;X:\MSYS2\mingw64\x86_64-w64-mingw32\bin;X:\MSYS2\usr\bin;C:\Program Files (x86)\Common…

Some explanation:

1. All paths are REAL paths. Win32 doesn’t properly support softlinks, nodelinks or anything else posix.
2. MSYS is positioned BEHIND MinGW, so MinGW always gets priority. Per my very good discussion with @revelator many moons ago, the art is always in properly understanding the mix of MInGW and MSYS.
3. “X:\B” is a master batchfile folder. I recommend every programmer have one, and only batchfile scripts with TOP PRIORITY should be placed there.

Not just for you but since the topic came up I think it’s time to share…

Edit: I decided to very edit that copy-and-paste of my actual path to remove the Kotlin-Java, Enrgyplus, etc as it could (unbelievably but true) cause confusion. Sorry for the edited version isn’t precisely real but it will help other readers focus on the point here…