Коллеги, есть ли причины, по которым не стоит собирать релизную версию серверного приложения c PDB-файлами?
Чему они мешают, какие опасности они таят, если их всё-таки собрать и разместить в каталоге приложения в продуктиве?

Как поступаете вы?

P>Коллеги, есть ли причины, по которым не стоит собирать релизную версию серверного приложения c PDB-файлами?
P>Чему они мешают, какие опасности они таят, если их всё-таки собрать и разместить в каталоге приложения в продуктиве?

P>Как поступаете вы?
Только размер дистрибутива, но это не причина, всегда собираем только с PDB и ставим их на сервер

Здравствуйте, Tom, Вы писали:

P>>Коллеги, есть ли причины, по которым не стоит собирать релизную версию серверного приложения c PDB-файлами?
P>>Чему они мешают, какие опасности они таят, если их всё-таки собрать и разместить в каталоге приложения в продуктиве?

P>>Как поступаете вы?
Tom>Только размер дистрибутива, но это не причина, всегда собираем только с PDB и ставим их на сервер

У нас приложение серверное... никакого дистрибутива не готовим,
готовим набор файлов для развёртывания в продуктив и развёртываем. Никому наружу не отдаём.

Чем нам могут помешать PDB-файлы?

Вариант-догадка: ... безопасность? ...

P>У нас приложение серверное... никакого дистрибутива не готовим,
P>готовим набор файлов для развёртывания в продуктив и развёртываем. Никому наружу не отдаём.
Что бы файлы на сервере развернуть они туда должны как то попасть. Вот размер этого архива, nuget пакета или msi инсталяции, Docker имиджа (нужное подчеркнуть) и будет увеличен

P>Чем нам могут помешать PDB-файлы?
Ничем

P>Вариант-догадка: ... безопасность? ...
Если ваши серверные бинарники утекут то и без PDB они великолепно декомпилируются.
Решарпер вон умеет из коробки генерить PDB и декомпилировать сборки.

Здравствуйте, Pek2014, Вы писали:

P>Вариант-догадка: ... безопасность? ...

Информация из PDB-файлов потенциально может помочь атакующему оптимизировать процесс поиска уязвимостей для атаки (если он найдёт способ их получить, конечно). Но в целом, безопасность приложения должна обеспечиваться исходя из предположения о доступности атакующему всех исходников приложения и наличие или отсутствие PDB в развёрнутой версии приложения на неё влиять не должно.

Здравствуйте, Pek2014, Вы писали:

P>У нас приложение серверное... никакого дистрибутива не готовим,
P>готовим набор файлов для развёртывания в продуктив и развёртываем. Никому наружу не отдаём.
Тем не менее, размер это первое о чём приходится задумываться. А если ещё есть нативные зависимости — то размеры PDB сильно поболее. Например, всякие chromium-based проекты будут иметь pdb файл более 1Гб. Такой точно замахаешься деплоить.

P>Чем нам могут помешать PDB-файлы?
P>Вариант-догадка: ... безопасность? ...

Коллективный разум подсказывает, что в дотнете — по сути ничем, т.к. код в самих сборках достаточно просто декомпилируется.

Если хочется имён файлов и строк — тогда ложите pdb.

PS: Но, имхо, это показатель недостаточной обработки ошибок в самом коде, или отсутствие внятных сообщений об ошибках или наличие супер длинных методов. Плюс если у вас несколько инсталляций у которых есть рассинхрон в версиях — эти ссылки на файлы/строки необходимо правильно читать.

UPD: А ещё эти номера строк на async/await в каких-то ситуациях нагло врут.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Информация из PDB-файлов потенциально может помочь атакующему оптимизировать
Мы же в дотнете тут: не проще ли использовать код самих сборок?

Здравствуйте, Mystic Artifact, Вы писали:
MA>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Информация из PDB-файлов потенциально может помочь атакующему оптимизировать
MA> Мы же в дотнете тут: не проще ли использовать код самих сборок?

Ну, если он сможет добраться до файлов со сборками, то конечно проще. Например, если в приложении есть уязвимость к чтению произвольного файла. Но вполне возможна ситуация, когда PDB достать проще, чем DLL (например, если в веб-сервере запрещена обработка прямых запросов к DLL, но не запрещена для PDB).

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Ну, если он сможет добраться до файлов со сборками, то конечно проще. Например, если в приложении есть уязвимость к чтению произвольного файла. Но вполне возможна ситуация, когда PDB достать проще, чем DLL (например, если в веб-сервере запрещена обработка прямых запросов к DLL, но не запрещена для PDB).

Ну да, о очевидном и не подумал.

В How Many Secrets Do .NET PDB Files Really Contain? утверждается, что там только имена файлов / номера строк и имена локальных переменных, в отличие от нативных.
Впрочем, если упор делается именно на безопасность — тогда проще не делать никакой разницы и никогда их не распространять.

Здравствуйте, Pek2014, Вы писали:

P>Коллеги, есть ли причины, по которым не стоит собирать релизную версию серверного приложения c PDB-файлами?
P>Чему они мешают, какие опасности они таят, если их всё-таки собрать и разместить в каталоге приложения в продуктиве?
Я бы размышлял от обратного: а зачем они там нужны? Всегда проще отвечать на вопрос "зачем делать", чем "почему не нужно делать".

P>Как поступаете вы?
Релизные PDB на боевой сервер не деплоим, храним отдельно на случай отладки.
За последние 5-7 лет не понадобились не разу.

P>>Коллеги, есть ли причины, по которым не стоит собирать релизную версию серверного приложения c PDB-файлами?
P>>Чему они мешают, какие опасности они таят, если их всё-таки собрать и разместить в каталоге приложения в продуктиве?
V>Я бы размышлял от обратного: а зачем они там нужны?
Кэп, что бы видеть номера строк.

Здравствуйте, vmpire, Вы писали:

V>Я бы размышлял от обратного: а зачем они там нужны? Всегда проще отвечать на вопрос "зачем делать", чем "почему не нужно делать".

Имена файлов и номера строк помогают.

Имена файлов тоже бывают совсем небесполезны. Они показываются с абсолютными путями.
Если вы билдите разные билды в разные папки, то в имени файла (в его пути) вы получаете
ещё и номера билдов сборок. Что тоже может помочь найти проблему (найти сборки из несовместимых билдов).

P>>Как поступаете вы?
V>Релизные PDB на боевой сервер не деплоим, храним отдельно на случай отладки.
V>За последние 5-7 лет не понадобились не разу.

Странно... PDB часто помогают именно обойтись без отладки,
говоря точно в какой строчке какого файла произошла проблема.

Здравствуйте, Tom, Вы писали:

P>>>Коллеги, есть ли причины, по которым не стоит собирать релизную версию серверного приложения c PDB-файлами?
P>>>Чему они мешают, какие опасности они таят, если их всё-таки собрать и разместить в каталоге приложения в продуктиве?
V>>Я бы размышлял от обратного: а зачем они там нужны?
Tom>Кэп, что бы видеть номера строк.
Согласен, хотя не так часто эта информация необходима. Имя метода видно и так, а по виду исключения часто можно и строку быстро найти.
Конечно, это всё зависит от проекта. У нас методы короткие, так чтро номера строк пригодились бы пару раз в год.
С другой стороны, и вреда в pdb файлах особого нет.

Здравствуйте, Pek2014, Вы писали:

V>>Я бы размышлял от обратного: а зачем они там нужны? Всегда проще отвечать на вопрос "зачем делать", чем "почему не нужно делать".

P>Странно... PDB часто помогают именно обойтись без отладки,
P>говоря точно в какой строчке какого файла произошла проблема.
Файл можно определить и так, по имени метода.
Строчка — да, иногда может помочь. Но насколько часто — зависит от кода.

Правильно — всегда собирать с PDB, иметь symbol server & source server. И PDB и бинари класть в symbol server
Нужно имеенно все сразу, иначе толку не будет.

Здравствуйте, Pek2014, Вы писали:

P>Коллеги, есть ли причины, по которым не стоит собирать релизную версию серверного приложения c PDB-файлами?

Размер. PDB здорово его раздувают.

P>Чему они мешают, какие опасности они таят, если их всё-таки собрать и разместить в каталоге приложения в продуктиве?

Кроме размера, насколько я знаю, больше особых проблем с ними нет.

P>Как поступаете вы?

Обычно оставляю.

Здравствуйте, rm822, Вы писали:

R>Правильно — всегда собирать с PDB, иметь symbol server & source server. И PDB и бинари класть в symbol server

Как это поможет на продакшене?

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Но вполне возможна ситуация, когда PDB достать проще, чем DLL (например, если в веб-сервере запрещена обработка прямых запросов к DLL, но не запрещена для PDB).

Ты с таким реально сталкивался, или просто теоретически?

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, rm822, Вы писали:

R>>Правильно — всегда собирать с PDB, иметь symbol server & source server. И PDB и бинари класть в symbol server

AVK>Как это поможет на продакшене?

мне помогало несколько раз, когда получал краш от модуля к IIS, приятно же сразу увидеть, что и где упало, со стеком но дело такое, если есть своя система сбора крашев, то может и не надо, но например кто через WER их получает, очень полезно, но я таких пару только видел — вроде как партнером Microsoft надо быть для использования WER через MS, не уверен что сейчас так.

Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Но вполне возможна ситуация, когда PDB достать проще, чем DLL (например, если в веб-сервере запрещена обработка прямых запросов к DLL, но не запрещена для PDB).
AVK>Ты с таким реально сталкивался, или просто теоретически?

Нет, это только мои грязные фантазии на тему В IIS/ASP.NET надо сильно постараться, чтобы можно было что-то скачать из /bin или чтобы PDB оказались вне этого каталога.