wireguard-windows, branch v0.3.2

version: bump

2020-11-27T14:10:54Z

Signed-off-by: Jason A. Donenfeld

build: bump wintun to 0.9.2

2020-11-27T14:05:27Z

Signed-off-by: Jason A. Donenfeld

fetcher: make malleability checks work on big endian

2020-11-27T13:16:25Z

Doesn't matter for us, but still probably a good idea. This has also been reported upstream. Signed-off-by: Jason A. Donenfeld

fetcher: use sha512 from bcrypt

2020-11-27T12:44:52Z

Saves 4k in the binary. Signed-off-by: Jason A. Donenfeld

winipcfg: cleanup netsh error reporting

2020-11-27T12:36:25Z

Signed-off-by: Jason A. Donenfeld

conf: separate out migration and print errors

2020-11-27T12:15:38Z

Signed-off-by: Jason A. Donenfeld

main: restrict dll search path

2020-11-27T12:15:38Z

Signed-off-by: Jason A. Donenfeld

go-patches: force PIE mode on arm

2020-11-27T12:15:38Z

Signed-off-by: Jason A. Donenfeld

mod: bump

2020-11-27T12:15:38Z

Signed-off-by: Jason A. Donenfeld

fetcher: delay load anything with transitive dependencies outside of knowndlls

2020-11-27T11:50:53Z

It looks like advapi32.dll loads cryptbase.dll because RtlGenRandom is forwarded to it, and cryptbase.dll isn't in knowndlls. So, even though we haven't done anything wrong by importing advapi32.dll statically, the surprising forwarding behavior means that this is a disaster. At the same time, some UI-related system modules wind up calling loadlibraryex with default arguments, so again, even though linking to things like user32.dll and such statically is fine, microsoft is doing the wrong thing inside of them. Work around the first issue by loading advapi32.dll (and others, just for good measure) delayed, and work around the latter by gimping the dll search path. Reported-by: Stefan Kanthak Signed-off-by: Jason A. Donenfeld