Dapper.dll has internal PDB
sherlock1982 opened this issue · 5 comments
Describe the bug
Dapper.dll contains internal PDB symbols. Our deliverables scanner (ReversingLabs) flags Dapper.dll because it contains PDB inside.
To Reproduce
Execute (from Microsoft C++ toolset):
dumpbin /HEADERS Dapper.dll
You will see in Debug Directories extra section spgo
Expected and actual behavior
We believe that PDB files should not be distributed even inside 3rdParty libraries. Though they can be in Nuget package of course. We have a project of approx ~600 DLLs and onyl 4 of them has PDB inside.
OK, genuine question: why is it flagging it? Why is it considering this a problem? AFAIK there's nothing wrong with including symbols, and compared to not shipping symbols at all: it is definitely a good thing.
"because {some random tool flags it}" isn't an answer by itself; I want to know why it is flagging it
As for if we did something here: we could perhaps switch to snupkg (https://learn.microsoft.com/nuget/create-packages/symbol-packages-snupkg); thoughts @NickCraver ?
The reason is simple: what if a developer forgot to remove debug symbols and now evil hackers can easier explore the code providing they do not have the sources.
This is very valid for the files I compile myself. Because I do not distribute my source code and don't want anyone to anyhow reverse engineer it.
I understand this is kinda less important for 3rdParty OpenSource libs which is Dapper.
But in general if my client scans my project and finds Dapper.pdb I will need to explain that it is "3rdParty OpenSource"
I just checked and out of my overall 768 dlls only 4 has PDB's inside.
You can freely close it of course. In general this is not a big deal but I wanted to know your opinion on this.
The reason is simple: what if a developer forgot to remove debug symbols and now evil hackers can easier explore the code providing they do not have the sources.
The source that is literally publicly available on GitHub?
But in general if my client scans my project and finds Dapper.pdb I will need to explain that it is "3rdParty OpenSource"
You could just add a build step that deletes the file.
I am happy to have the conversation about what the most appropriate way of shipping symbols is - and that answer may well have changed over time (for example, the .snupkg approach is a new replacement for .symbols.nupkg), so it is possible that we should update our approach. That's fine! It just changes how we frame things:
Check what the current expected approach is for shipping symbols, and adopt if necessary, to be a good library author and community citizen.
is different to
Stop embedding symbols because of a security problem.
or even
Stop embedding symbols because of a perception problem with clients not knowing what is/isn't a risk.
We very intentionally deploy symbols in the main package so people get detailed stack traces in production, but you are of course free to delete it or exclude even utilizing it from the package by changing MSBuild properties about which file types get copied as a global solution.
To put this another way: we could switch to embedded symbols inside the .dll and have all the same concepts and the scanner wouldn't care, but that has memory implications, so we do not.
Well I can't delete Dapper.dll cause I need it.
And I don't think there's an (easy) way to strip embedded PDB from Dapper.dll.
And even if there's a way I won't strip it because Dapper.dll is a also a "well-known" file with a certain checksum.
Modifying it means another level of trust here.
Ok I will close but just keep it in mind ) Maybe you will change it in the future
Note it's not a security problem per se (cause it's OpenSource). But it is unusual nowadays and might cause extra questions from endusers. Neigher Google nor Microsoft has it embedded. Overall I would consider a professional app the one that doesn't have any PDB's inside without the need to analyze if it's open source or not (because what if I compiled Dapper.dll myself).
Anyway thanks for the explanation!