Коллеги, есть ли причины, по которым не стоит собирать релизную версию серверного приложения 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 оказались вне этого каталога.

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

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

AVK>Как это поможет на продакшене?
В двух словах — это просто переход на другой технологический уровень.

Если нужно разобрать дапм, ты берешь его и разбираешь, и все просто работает. Ты не думаешь о том как бы посмотреть исходники, где взять бинари, и к какой же версии черт побери это относится.
Нужен удаленный дебаг или профайл — запускаешь и он просто работает.

Как перейти с IDE 20 летней давности на что-то современное.

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

R>Если нужно разобрать дапм, ты берешь его и разбираешь, и все просто работает. Ты не думаешь о том как бы посмотреть исходники, где взять бинари, и к какой же версии черт побери это относится.

Это все понятно, но это не про продакшен, а про машину разработчика. Вопрос же был в другом.

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

AVK>Это все понятно, но это не про продакшен, а про машину разработчика. Вопрос же был в другом.

Про машину разработчика + dump debug. С 2010й студии емнип работает. Завести, чтоб оно работало — то ещё удовольствие, правда.

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

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

Поставляем одновременно релизные и дебажные либы с PDB.
Иногда у разработчиков-клиентов что-то падает через "слоёный пирог" прямых/обратных вызовов в своём коде через третьесторонний. Удобней в таких случаях для отладки иметь полный стек.

AVK>Это все понятно, но это не про продакшен, а про машину разработчика. Вопрос же был в другом.
Затем что для корректной работы профайлеров нужно восстанавливать callstack, а там FPO, stackalloc, зоопарк calling conventions и слои managed/unmanaged/wow64
Некоторые ***ки конечно делают вид что у них этого всего нет, или что нарубив код на дотнете это можно просто проигнорировать, но на то они и ****ки, и стек у них вечно разваливается

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

P>Как поступаете вы?
Оставляю. Всегда делаем систему логов при получении любого исключения в котором лежит стэктрейс и время сборки приложения.

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

AVK>>Это все понятно, но это не про продакшен, а про машину разработчика. Вопрос же был в другом.
R>Затем что для корректной работы профайлеров нужно восстанавливать callstack

Ты профайлеры на продакшене запускаешь?

AVK>Ты профайлеры на продакшене запускаешь?
Почему нет, только так можно анализировать реальную нагрузку.

AVK>Ты профайлеры на продакшене запускаешь?
Да, когда не получается изолировать, или когда это проще и есть возможность

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

AVK>>Ты профайлеры на продакшене запускаешь?
Tom>Почему нет, только так можно анализировать реальную нагрузку.

Потому что вряд ли пользователи порадуются, когда все резко стало тормозить и глючить. Хотя, конечно, продакшен бывает разный.

AVK>Потому что вряд ли пользователи порадуются, когда все резко стало тормозить и глючить. Хотя, конечно, продакшен бывает разный.
О как, странно но пользователи StackOverflow не жалуются
Ну и в догонку, совсем непонятно с какого перепугу вдруг всё должно резко тормозить и уж тем более глючить.
Особенно в sampling режиме

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

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

I second that. Кастомеру не нужны PDB в дистрибутиве, ему плевать, поэтому включать их в релизный билд просто не имеет смысла ( из-за раздутия последнего ). А вот когда этот кастомер придёт с дампом, они очень даже кстати. Настройка symbol server — дело от силы пары часов, так что за отмазу не прокатит.

Мои две копейки.

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

M>I second that. Кастомеру не нужны PDB в дистрибутиве, ему плевать, поэтому включать их в релизный билд просто не имеет смысла ( из-за раздутия последнего ). А вот когда этот кастомер придёт с дампом, они очень даже кстати. Настройка symbol server — дело от силы пары часов, так что за отмазу не прокатит.

Не всегда можно снять дамп, особенно если проблема плавающая. А вот номера строк и названия файлов в логах очень даже небесполезны.