profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/vszakats/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

curl/curl-for-win 406

Reproducible curl binaries for Windows

vszakats/hb 58

Harbour fork (from https://github.com/harbour/core) + updates & fixes = 3.4

vszakats/curl 0

A command line tool and library for transferring data with URL syntax, supporting HTTP, HTTPS, FTP, FTPS, GOPHER, TFTP, SCP, SFTP, SMB, TELNET, DICT, LDAP, LDAPS, FILE, IMAP, SMTP, POP3, RTSP and RTMP. libcurl offers a myriad of powerful features

vszakats/curl-www 0

The curl and libcurl website contents

vszakats/MINGW-packages 0

Package scripts for MinGW-w64 targets to build under MSYS2.

vszakats/pixelfed 0

Photo Sharing. For Everyone.

delete branch vszakats/curl-www

delete branch : babielsvg

delete time in an hour

push eventcurl/curl-www

Viktor Szakats

commit sha 5cc7958d9880aaff86fb061b50804a14f07e0a77

sponsors: replace Babiel logo with SVG

view details

Viktor Szakats

commit sha c984fa03f38a01f2c6eec82eb3a6b0f1ff44ffe5

sponsors: embed Babiel SVG & add dynamic style for light/dark modes

view details

push time in an hour

PR merged curl/curl-www

sponsors: replace Babiel logo with SVG
+21 -2

4 comments

3 changed files

vszakats

pr closed time in an hour

pull request commentcurl/curl-www

sponsors: replace Babiel logo with SVG

Ok, let's go with it then!

vszakats

comment created time in an hour

push eventvszakats/curl-www

Viktor Szakats

commit sha 6ffad6721391e81e6a5c76f1eb5cccaefec65e73

sponsors: replace Babiel logo with SVG

view details

Viktor Szakats

commit sha 4cd7e19a4afe29f3992ae477e092067f2bab613a

sponsors: embed Babiel SVG & add dynamic style for light/dark modes

view details

push time in an hour

pull request commentcurl/curl-www

sponsors: replace Babiel logo with SVG

Light mode (both methods): Screen Shot 2021-09-16 at 18 37 01 Dark mode with external SVG: Screen Shot 2021-09-16 at 18 37 48 Dark mode with embedded SVG: Screen Shot 2021-09-16 at 18 36 54

vszakats

comment created time in 3 hours

pull request commentcurl/curl-www

sponsors: replace Babiel logo with SVG

With the second commit, the SVG will be embedded into sponsors.html (via an #include) and will automatically adapt its color depending on dark/light mode browser setting. This is done using a small embedded stylesheet in the SVG code.

Plus some tweaks to sync hover behaviour with light mode and external images.

vszakats

comment created time in 3 hours

pull request commentcurl/curl

Fix version checking in Windows (proper backwards and forwards compatible version checking)

It's not though. It's a real bug that happens in real-life. You can shrug your shoulders and say it doesn't matter. But you shrugging your shoulders doesn't mean the problem doesn't exist.

Do you need to be offensive? I'm not shrugging any shoulders and I understand the problem. Also spent probably too much time around manifests and Windows version detection. What I'm saying it's not the job of a single linked library to solve the Windows manifest problem. I also deem the problem not grave enough to merit breaking compatibility, all builds, and talking directly to the kernel. This is a matter of opinion. Nor can libcurl fully solve this for any app. This is a fact.

If the libcurl DLL manifest doesn't solve the problem for user apps (which can be and it's a valid point, though I'm also linking statically so never tried), it extends the scope of the use-case.

Huh? Unless curl is dropping support for SChannel I don't see this as a relevant suggestion. This accurate version detection > PR (or a variation of it) is a prerequisite for us doing the work to add Schannel TLS 1.3 support to curl.

It's an option, not a suggestion.

it will have to be added to every apps' build systems that happen to link libcurl statically. No, that's not how it works. On Windows if you link the dll or static lib with another lib and the end-program will inherit those > links. On Unix it's different... but we're not talking about unix.

Did you try? Have you considered other C compilers besides MSVC?

There is no concept of inherinting static library requirements when using the toolchains I mentioned above. It's an MSVC-specific feature.

wyattoday

comment created time in 4 hours

PR opened curl/curl-www

sponsors: replace Babiel logo with SVG
+21 -2

0 comment

3 changed files

pr created time in 4 hours

PR closed curl/curl-www

sponsors: replace Babiel logo with SVG
+21 -2

1 comment

3 changed files

vszakats

pr closed time in 4 hours

create barnchvszakats/curl-www

branch : babielsvg

created branch time in 4 hours

delete branch vszakats/curl-www

delete branch : baibelsvg

delete time in 4 hours

push eventvszakats/curl-www

Viktor Szakats

commit sha 3c5aaa692107b6d8204e0a1f3f0c77f5852d6b77

embed svg and add dynamic styling for light/dark modes

view details

push time in 4 hours

push eventvszakats/curl-www

Viktor Szakats

commit sha 708ca8b8abab66e86bb70f5fff0228063f789498

sponsorts: replace Babiel logo with SVG

view details

push time in 4 hours

push eventvszakats/curl-www

Viktor Szakats

commit sha f6da141b5959ad55b59b5549920ad6620c7144bf

sponsorts: replace Babiel logo with SVG

view details

push time in 4 hours

pull request commentcurl/curl-www

sponsorts: replace Baibel logo with SVG

The logo is on the too-dark side on dark background. There is a fix for this, but it needs embedding the SVG inside the HTML.

vszakats

comment created time in 4 hours

CommitCommentEvent

push eventvszakats/curl-www

Viktor Szakats

commit sha 3912c141f32d2a9fd085a34508fd825e046d9181

sponsorts: replace Baibel logo with SVG

view details

push time in 4 hours

PR opened curl/curl-www

sponsorts: replace Baibel logo with SVG version
+1 -1

0 comment

2 changed files

pr created time in 4 hours

create barnchvszakats/curl-www

branch : baibelsvg

created branch time in 4 hours

fork vszakats/curl-www

The curl and libcurl website contents

https://curl.se/

fork in 4 hours

CommitCommentEvent

pull request commentcurl/curl

Fix version checking in Windows (proper backwards and forwards compatible version checking)

Yes, I know. I feel like we're talking past eachother. For MS compilers the #pragma is used for simplicity's sake. For non-MS compilers on Windows, I've already added the correct linker flag to the configure.

What I'm saying is that this flag not only needs to be added to all the different build systems in the curl project itself (there is also CMake and Makefile.m32), it will have to be added to every apps' build systems that happen to link libcurl statically. So this effectively replaces the optional manifest with a new mandatory linker option in these cases.

For ALPN it's necessary.

This is a matter of opinion, but I feel it doesn't look like libcurl's job to fix (static libcurl + SChannel) depedent apps where a manifest was not added. If it was forgotten or left out on purpose, libcurl would behave unexpectedly compared to other components linked to the app, or compared to how it should behave with the manifest linked (or not linked). IOW if someone is leaving out the manifest it's not a libcurl problem, but a problem for all other code linked to that app. Working this around in libcurl alone will not fix that app. Not disputing that mistakes can be made here and manifests are a notorously weird system indeed, but it's been around for quite some time and for better or worse, everyone building Windows binaries need to live with them. There is also the option to use libcurl DLL which has its own manifest and will behave accordingly. Another option is to use an alternate TLS-backend, which don't suffer from feature-detection woes as SChannel.

The other issue is fixing this by making direct kernel calls from userspace code.

If others feel this justified as a fix for this specific use-case, I'd strongly vote to implement this in a non-breaking and portable (across C compilers) way using a dynamic call and fallback to official/existing detection code as necessary. Also I think it'd be necessary to avoid adding compile-time WINVER and _WIN32_WINNT checks to make the binary output as unified as possible, regardless of compiler or SDK version.

wyattoday

comment created time in 6 hours

pull request commentcurl/curl

Fix version checking in Windows (proper backwards and forwards compatible version checking)

Not in Microsoft compilers (just double-checked to confirm). And if MingW maintains any sort of compatibility with Microsoft compilers on Windows, then not there either.

In MSVC that #pragma is the equivalent to the -lntdll linker option. Maybe Pelles C supports it, but others not so much. MinGW + LLVM says this: warning: unknown pragma ignored [-Wunknown-pragmas], GCC: warning: ignoring '#pragma comment ' [-Wunknown-pragmas].

wyattoday

comment created time in 8 hours

CommitCommentEvent

pull request commentcurl/curl

Fix version checking in Windows (proper backwards and forwards compatible version checking)

This patch adds -lntdll linker option and #pragma comment(lib, "ntdll.lib") (which #pragma only works with MSVC), meaning the resulting binaries will have a new entry referencing this DLL (at the moment this DLL is indirectly referenced by Win32 API DLLs). After this patch, any app linking libcurl will have to also add -lntdll, otherwise they will get a linker error similar to this: undefined reference to __imp_RtlGetVersion'.

On Windows when referencing APIs that may or may not be available at runtime, the standard method is to retrieve their address at runtime and gracefully fall back to a compatible code path when that API is not available.

If this call is necessary, I would not worry about the performance of the two extra API calls to retrieve the handle of the DLL than retrieve the function's address. If this causes a performance issue, the pointer can be saved and re-used from then on, e.g. in the Wine detection code and whereever else it is (will be) needed. It is also good practice to minimize redundant (and non-portable) code.

So, we don't yet know how this will work in a non-broken, final release? It seems a bit odd (though probably not unprecedented) that SChannel TLS 1.3 support would require version detection (especially a non-official method) and explicit detection/enabling work (or registry tweak even!). Windows Server 2008 SP2/R2 required registry tweaks to enable TLS 1.2, so it wouldn't be unprecedented, though in such case this is an OS-level issue and once enable there, SChannel automatically used it. That link says that TLS 1.3 is automatically enabled in Windows 2022.

wyattoday

comment created time in 9 hours

pull request commentcurl/curl

Fix version checking in Windows (proper backwards and forwards compatible version checking)

NTDLL is definitely something new, but linking against it statically is not a best solution. This, instead of requiring apps to include a manifest (which is the recommended/expected way to deal with this), will force all applications to link against NTDLL and break their compatibility requirements (and their build scripts) in the process. I think it is not ideal if a 3rd-party library like libcurl imposes such requirements/limitations on apps that wants to link it.

Version detection was made extremely messy in Windows, no doubt about that, but usually it's best to accept whatever mess was produced by the vendor than trying to actively fight it.

Is it known already that it's required in upcoming SChannel to actively detect TLS 1.3 to be able to use it? Does it need to be explicitly enabled on new systems to use it? Can SChannel be told to use it using flags, which flags will be ignored on OS versions that don't support it?

wyattoday

comment created time in 11 hours

pull request commentmsys2/MINGW-packages

URL upgrades/updates/fixups

Though its unlikely the tests will ever pass for this one, the current issue is :: File /var/cache/pacman/pkg/mingw-w64-x86_64-libtiff-4.3.0-6-any.pkg.tar.zst is corrupted (invalid or corrupted package (checksum))., which seems unrelated to this PR. libtiff was upgraded to HTTPS, but that source tarball is the exact same as the HTTP one and both match the included SHA256.

vszakats

comment created time in a day

pull request commentcurl/curl

Fix version checking in Windows (proper backwards and forwards compatible version checking)

The dynamic call needs to be done a single time (on the first call) then store the result in memory. ntdll.dll is always linked indirectly via necessary Win32 API DLLs (and loaded on any booted Windows system anyway), so there is no need to load anything extra. Plus this new method would replace a bunch of official version-detection calls. Also ntdll.dll is already used dynamically to detect Wine.

Overall it feels a little uneasy to use an undocumented kernel call to detect versions behind the back of the manifest, just to cover the rare case when someone gets it wrong or forgets it. E.g. the mingw/cygwin toolchain has been adding a default manifest automatically for many years.

For TLS 1.3 and other new features, targeted feature detection would seem more fitting. If this is no doable here, the dynamic option would keep curl compatible and I believe performance optimizations can be done once the new detection works as expected.

wyattoday

comment created time in a day

pull request commentcurl/curl

Fix version checking in Windows (proper backwards and forwards compatible version checking)

Is there a reason why RtlGetVersion() is linked and called statically, instead of calling it via GetModuleHandle() / GetProcAddress() dynamically? With the latter method it wouldn't be necessary to break compatibility to make this new version detection scheme work.

wyattoday

comment created time in a day