How would we go about verifing this library?

dpc commented 5 years ago

As a part of effort of cargo crev, I wanted to review winapi-i686-pc-windows-gnu, and it turned out it's a 52MB of binary libraries. I realize that they are probably good reason for this, but how should I go about making sure there are no rootkits, viruses etc. in there?

retep998 commented 5 years ago

You can build them yourself from the .def files. I'm not sure how good MinGW is at reproducible builds, but if you want to work on making them reproducible, have at it.

Ideally though, we'd just have https://github.com/rust-lang/rfcs/pull/2627 and I wouldn't need those import libraries.

MaulingMonkey commented 5 years ago

I poked at this some (under the mistaken impression binaries were used in *-msvc builds too) and discovered the .a files might have incorrect ordinals in the 0.3 branch based on the differences in .idata$6 described bellow. Not sure how problematic that is.

What follows is mostly a description of how to generate and diff the binaries reasonably. I have not done an exhaustive check against all binaries - could be automated more, but I haven't. I also haven't checked that e.g. I list everything important using objdump (I probably haven't), making mingw output reproducable builds would probably be a saner approach anyways.

Stuff used:

MinGW installed per rust-lang 's instructions:
A MSYS2 MinGW 64-bit console
0.3 branch (by accident - 0.3.7 specifically)
A script to rebuild everything: https://github.com/MaulingMonkey/winapi-rs/commit/387a0af15ede50c8066d2a84a6c7b5e2cb423e5e (would it be useful to get this checked into winapi-rs? I can send a PR for https://github.com/retep998/winapi-rs/compare/0.3...MaulingMonkey:script-recreate-binaries if so.)
Resulting binaries do differ some. Resulting *.a files can be extracted with ar, 7-zip, or anything else that speaks this archive format.

Archive Differences

Modified timestamps differ
Object filenames are semi-random (d(random)(t|h|s\d{5}).o)

Archive\1.txt Differences

First two symbols are based on absolute paths used with dlltool.
Filenames don't match
Otherwise, libwinapi_xinput.a\1.txt seems identical between runs (same symbols, same ordering)

Example:

dkxcbt.o    __C__Users_Peter_Code_winapi_rs_x86_64_lib_libwinapi_xinput_a_iname
dkxcbh.o    _head_C__Users_Peter_Code_winapi_rs_x86_64_lib_libwinapi_xinput_a
dkxcbs00007.o    XInputSetState
dkxcbs00007.o    __imp_XInputSetState
dkxcbs00006.o    XInputGetState
dkxcbs00006.o    __imp_XInputGetState
dkxcbs00005.o    XInputGetKeystroke
dkxcbs00005.o    __imp_XInputGetKeystroke
dkxcbs00004.o    XInputGetCapabilities
dkxcbs00004.o    __imp_XInputGetCapabilities
dkxcbs00003.o    XInputGetBatteryInformation
dkxcbs00003.o    __imp_XInputGetBatteryInformation
dkxcbs00002.o    XInputGetAudioDeviceIds
dkxcbs00002.o    __imp_XInputGetAudioDeviceIds
dkxcbs00001.o    XInputEnable
dkxcbs00001.o    __imp_XInputEnable
dkxcbs00000.o    DllMain
dkxcbs00000.o    __imp_DllMain

Archive\*.o Differences

We can use objdump -s *.o and other flags to inspect differences. First 0000 is the file offset.
.idata$6 section differs!

From the 0.3 branch:

dkxcbs00007.o:     file format pe-x86-64
...
Contents of section .idata$6:
0000 07005849 6e707574 53657453 74617465  ..XInputSetState
0010 0000                                 ..

The first two bytes of .idata$6, 0700..., rise numerically, matching the file for all of libwinapi_xinput.a's numbered .o files.

From locally rebuilt archives:
```
daims00007.o:     file format pe-x86-64
...
Contents of section .idata$6:
0000 03005849 6e707574 53657453 74617465  ..XInputSetState
0010 0000         
```
The first two bytes of .idata$6, 0300..., match the ordinal in the .def files (e.g. XInputSetState @3 from xinput.def:10), for all of libwinapi_xinput.a's numbered .o files.

MaulingMonkey commented 5 years ago

Yep, .idata$6 is supposed to contain ordinals: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=binutils/dlltool.c;hb=HEAD#l228

retep998 / winapi-rs