Possible unsigned DLL files?

[GregPlowman]

Within our corporate environment (Windows) we have received alerts from anti-malware software (Cortex) regarding suspicious DLL files.

libodbccr-2.dll
libboost_system.dll
libboost_date_time.dll

The report indicates these files are not signed, which contributed to their detection as potential security concerns.

My questions are:

• Are the DLL files indeed unsigned?
• If so, is this intended?

libodbccr-2.dll is used in unixODBC_jll
ODBC -> unixODBC_jll

libboost_system.dll and libboost_date_time.dll are used in boost_jll
SCIP -> SCIP_jll -> boost_jll
SCIP -> SCIP_PaPILO_jll -> boost_jll

Output from versioninfo()

Julia Version 1.11.3
Commit d63adeda50 (2025-01-21 19:42 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: 64 × AMD Ryzen Threadripper PRO 5975WX 32-Cores
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, znver3)

[giordano]

• Are the DLL files indeed unsigned?

Yes.

If so, is this intended?

Yes, for lack of anyone interested in setting up an automated process to sign anything for Windows. We do that for macOS already, but it's very simple, I personally have no idea how that'd work for Windows, nor any interest, so if that's something really desired then someone particularly motivated would need to come up with a practical plan of actions and implement it.

[evetion]

... how that'd work for Windows, nor any interest, so if that's something really desired then someone particularly motivated would need to come up with a practical plan of actions and implement it.

No interest here to implement it, but these are the required steps in a nutshell:

• Get a new code-signing certificate or re-use the mac one if possible
• Get signtool.exe from the Windows SDK
• Sign all libraries/execs using signtool.exe.

[giordano]

or re-use the mac one if possible

We don't have any certificate for macOS.

Get signtool.exe from the Windows SDK

We don't have any Windows SDK.

Sign all libraries/execs using signtool.exe.

We can't run Windows executables.

[ViralBShah]

Is this something one could potentially run through wine?

[giordano]

That'd address only the last point.

[ViralBShah]

I imagine getting a certificate is annoying but not hard. But the other two points are hard - getting Windows SDK, just to get signtool.exe and then run Wine. Just wanted to understand the steps. Thanks.

[barche]

There is also this, eliminating the need to run a windows exe: https://github.com/mtrojnar/osslsigncode

[giordano]

That looks very interesting (and the page mentions that Wine wouldn't work), thanks! But need to resolve the problem with the certificate and figuring out the infrastructure stuff (how to sign the files on Yggdrasil in a safe way). We don't have any certificate for macOS, just running ldid does the trick, that simplifies a lot our work.

[ViralBShah]

I believe @DilumAluthge or @staticfloat might be able to point to our certificates we sign our windows binaries with. The part about getting it done in a safe way is probably the part that needs work.

[ViralBShah]

Do any other open source ecosystems sign their DLLs? @GregPlowman Does Conda do this - any insights on how you deal with other ecosystems would be valuable.

[staticfloat]

In my opinion, it's not really feasible or useful to try and codesign everything for Windows. Microsoft doesn't require it, and while certain antivirus vendors may use it as a mark against a file, I'm not aware of any opensource ecosystem similar to ours that signs things like this (for instance, the .dll files in numpy from PyPI are not signed).

The purpose of a code signature is that the owner of the signature is vouching for the safety of a particular .dll, and if malicious .dll's are found signed with a certain key, that key can be revoked and nobody trusts those files anymore. Given our current practices with Yggdrasil, if a bad actor wanted to get a trojan merged under some obscure name I think it would not be too difficult to do (we're certainly not vetting the entire codebase of every project added to Yggdrasil) and having our own signature tied to everything coming out of Yggdrasil means we're basically running a code-signing-as-a-service platform, with all the associated issues that entails.

This is in sharp contrast to Julia itself where we do claim ultimate responsibility over it and every .dll that ships with it, and we do pay much more attention to the code going in to Julia itself (And even its dependencies).

Finally, the macOS signing we do is not the same kind of signing that we're talking about here. Most of the time when people talk about code signing on macOS you must create a developer certificate with Apple and the same kinds of issues I mention above come into play. However macOS 12+ has a hard requirement that all binary objects be signed by something in order to be loadable at all. To allow for things such as gcc -o test test.c && ./test to work, therefore, the linker embeds a signature into the binary that is called an "ad-hoc signature". It's a signature that doesn't have any associated certificate, it purely ensures integrity of the file itself. This is what we do for Yggdrasil, and it has none of the problems mentioned above. We do the full code signing with our own developer certificate for Julia and its dependencies on macOS, just like we do for Windows.

In summary, I don't think we should do this.

[GregPlowman]

Do any other open source ecosystems sign their DLLs? @GregPlowman Does Conda do this - any insights on how you deal with other ecosystems would be valuable.

I'm an end user, so I can't comment directly, except to say that our environment is generally restrictive. I have asked for a response from our corporate IT security.

The explanation from staticfloat seems to make sense to me. I have passed that on to the security team as well.