История изменений

Разработчики должны отслеживать уязвимости в библиотеках, которые они используют. Если кто-то написал программу, а она ломает всё и вся, то никто не будет этой программой пользоваться. Это вопрос жизни этой программы. Нельзя полагаться на то, что кто-то где-то будет обновлять библиотеки. Ментейнеры дистрибутива вообще могут, в теории, забить на это или не знать.

На деле это так не работает. Я рассмотрел вариант, когда линковка происходит статически, но сами библиотеки находятся в отдельных пакетах. То есть разработчик приложения не знает, с какой именно версией библиотеки будет собрано его приложение (это самая частая ситуация). Если же рассматривать вариант, о котором ты пишешь, когда разработчик приложения сам поставляет все зависимости (например мозилла так делает без дебиановского патча), то всё становится гораздо хуже. Тогда при обнаружении дыры в библиотеке уже разработчики приложения должны пересобрать ту же версию приложения с обновлённой библиотекой. Но они этого обычно не делают, в лучшем случае говорят, возьмите новую версию приложения, но это рушит идею стабильности релиза, потому что новая версия приложения неизбежно несёт проблемы с совместимостью и новые неизвестные баги. Да, для каких-то отдельных приложений такой подход приемлем, но как стандартная практика для всех приложений - нет. Ну, либо надо отказываться от идеи стабильных протестированных релизов дистрибутивов с обновлениями безопасности, а это совсем плохо. Поэтому, например, разработчики Дебиана изменяют код Мозиллы, чтобы она зависила от системных библиотек, а не от тех что таскает за собой.

2. А разве библиотеки которые в зависимостях не занимают место на диске или в ОЗУ?

В этом и суть разделяемых библиотек, вместо того чтобы копироваться в каждом приложении (если 1000 приложений, то x1000 на диске, x1000 в памяти), они занимают один раз место на диске и в памяти.

3. В куче зависимостей гораздо проще что-то подменить (спрятать), чем один бинарь контрольную сумму которого можно отслеживать или использовать инструмент вроде afick.

Контрольную сумму можно посчитать и для библиотек. Здесь разницы нет.

Разработчики должны отслеживать уязвимости в библиотеках, которые они используют. Если кто-то написал программу, а она ломает всё и вся, то никто не будет этой программой пользоваться. Это вопрос жизни этой программы. Нельзя полагаться на то, что кто-то где-то будет обновлять библиотеки. Ментейнеры дистрибутива вообще могут, в теории, забить на это или не знать.

На деле это так не работает. Я рассмотрел вариант, когда линковка происходит статически, но сами библиотеки находятся в отдельных пакетах. То есть разработчик приложения не знает, с какой именно версией библиотеки будет собрано его приложение (это самая частая ситуация). Если же рассматривать вариант, о котором ты пишешь, когда разработчик приложения сам поставляет все зависимости (например мозилла так делает без дебиановского патча), то всё становится гораздо хуже. Тогда при обнаружении дыры в библиотеке уже разработчики приложения должны пересобрать ту же версию приложения с обновлённой библиотекой. Но они этого обычно не делают, в лучшем случае просто говорят, возьмите полностью новую версию приложения, но это рушит идею стабильности релиза, потому что новая версия приложения неизбежно несёт проблемы с совместимостью и новые неизвестные баги. Да, для каких-то отдельных приложений такой подход приемлем, но как стандартная практика для всех приложений - нет. Ну, либо надо отказываться от идеи стабильных протестированных релизов дистрибутивов с обновлениями безопасности, а это совсем плохо. Поэтому, например, разработчики Дебиана изменяют код Мозиллы, чтобы она зависила от системных библиотек, а не от тех что таскает за собой.

2. А разве библиотеки которые в зависимостях не занимают место на диске или в ОЗУ?

В этом и суть разделяемых библиотек, вместо того чтобы копироваться в каждом приложении (если 1000 приложений, то x1000 на диске, x1000 в памяти), они занимают один раз место на диске и в памяти.

3. В куче зависимостей гораздо проще что-то подменить (спрятать), чем один бинарь контрольную сумму которого можно отслеживать или использовать инструмент вроде afick.

Контрольную сумму можно посчитать и для библиотек. Здесь разницы нет.

Разработчики должны отслеживать уязвимости в библиотеках, которые они используют. Если кто-то написал программу, а она ломает всё и вся, то никто не будет этой программой пользоваться. Это вопрос жизни этой программы. Нельзя полагаться на то, что кто-то где-то будет обновлять библиотеки. Ментейнеры дистрибутива вообще могут, в теории, забить на это или не знать.

На деле это так не работает. Я рассмотрел вариант, когда линковка происходит статически, но сами библиотеки находятся в отдельных пакетах. То есть разработчик приложения не знает, с какой именно версией библиотеки будет собрано его приложение (это самая частая ситуация). Если же рассматривать вариант, о котором ты пишешь, когда разработчик приложения сам поставляет все зависимости (например мозилла так делает без дебиановского патча), то всё становится гораздо хуже. Тогда при обнаружении дыры в библиотеке уже разработчики приложения должны выпустить новую версию приложения с обновлённой библиотекой (а остальной код оставить неизменным). Но они этого обычно не делают, в лучшем случае просто говорят, возьмите полностью новую версию приложения, но это рушит идею стабильности релиза, потому что новая версия приложения неизбежно несёт проблемы с совместимостью и новые неизвестные баги. Да, для каких-то отдельных приложений такой подход приемлем, но как стандартная практика для всех приложений - нет. Ну, либо надо отказываться от идеи стабильных протестированных релизов дистрибутивов с обновлениями безопасности, а это совсем плохо. Поэтому, например, разработчики Дебиана изменяют код Мозиллы, чтобы она зависила от системных библиотек, а не от тех что таскает за собой.

2. А разве библиотеки которые в зависимостях не занимают место на диске или в ОЗУ?

В этом и суть разделяемых библиотек, вместо того чтобы копироваться в каждом приложении (если 1000 приложений, то x1000 на диске, x1000 в памяти), они занимают один раз место на диске и в памяти.

3. В куче зависимостей гораздо проще что-то подменить (спрятать), чем один бинарь контрольную сумму которого можно отслеживать или использовать инструмент вроде afick.

Контрольную сумму можно посчитать и для библиотек. Здесь разницы нет.

Разработчики должны отслеживать уязвимости в библиотеках, которые они используют. Если кто-то написал программу, а она ломает всё и вся, то никто не будет этой программой пользоваться. Это вопрос жизни этой программы. Нельзя полагаться на то, что кто-то где-то будет обновлять библиотеки. Ментейнеры дистрибутива вообще могут, в теории, забить на это или не знать.

На деле это так не работает. Я рассмотрел вариант, когда линковка происходит статически, но сами библиотеки находятся в отдельных пакетах. То есть разработчик приложения не знает, с какой именно версией библиотеки будет собрано его приложение (это самая частая ситуация). Если же рассматривать вариант, о котором ты пишешь, когда разработчик приложения сам поставляет все зависимости (например мозилла так делает без дебиановского патча), то всё становится гораздо хуже. Тогда при обнаружении дыры в библиотеке уже разработчики приложения должны выпустить новую версию приложения с обновлённой библиотекой (а остальной код оставить неизменным). Но они этого обычно не делают, в лучшем случае просто говорят, возьмите полностью новую версию приложения, но это рушит полностью идею стабильности релиза, потому что новая версия приложения неизбежно несёт проблемы с совместимостью и новые неизвестные баги. Да, для каких-то отдельных приложений такой подход приемлем, но как стандартная практика для всех приложений - нет. Ну, либо надо отказываться от идеи стабильных протестированных релизов дистрибутивов с обновлениями безопасности, а это совсем плохо. Поэтому, например, разработчики Дебиана изменяют код Мозиллы, чтобы она зависила от системных библиотек, а не от тех что таскает за собой.

2. А разве библиотеки которые в зависимостях не занимают место на диске или в ОЗУ?

В этом и суть разделяемых библиотек, вместо того чтобы копироваться в каждом приложении (если 1000 приложений, то x1000 на диске, x1000 в памяти), они занимают один раз место на диске и в памяти.

3. В куче зависимостей гораздо проще что-то подменить (спрятать), чем один бинарь контрольную сумму которого можно отслеживать или использовать инструмент вроде afick.

Контрольную сумму можно посчитать и для библиотек. Здесь разницы нет.

Разработчики должны отслеживать уязвимости в библиотеках, которые они используют. Если кто-то написал программу, а она ломает всё и вся, то никто не будет этой программой пользоваться. Это вопрос жизни этой программы. Нельзя полагаться на то, что кто-то где-то будет обновлять библиотеки. Ментейнеры дистрибутива вообще могут, в теории, забить на это или не знать.

На деле это так не работает. Я рассмотрел вариант, когда линковка происходит статически, но сами библиотеки находятся в отдельных пакетах. То есть разработчик приложения не знает, с какой именно версией библиотеки будет собрано его приложение (это самая частая ситуация). Если же рассматривать вариант, о котором ты пишешь, когда разработчик приложения сам поставляет все зависимости (например мозилла так делает без дебиановского патча), то всё становится гораздо хуже. Тогда при обнаружении дыры в библиотеке уже разработчики приложения должны выпустить новую версию приложения с обновлённой библиотекой (а остальной код оставить неизменным). Но они этого обычно не делают, в лучшем случае просто говорят, возьмите новую версию приложения, но это рушит полностью идею стабильности релиза, потому что новая версия приложения неизбежно несёт проблемы с совместимостью и новые неизвестные баги. Да, для каких-то отдельных приложений такой подход приемлем, но как стандартная практика для всех приложений - нет. Ну, либо надо отказываться от идеи стабильных протестированных релизов дистрибутивов с обновлениями безопасности, а это совсем плохо. Поэтому, например, разработчики Дебиана изменяют код Мозиллы, чтобы она зависила от системных библиотек, а не от тех что таскает за собой.

2. А разве библиотеки которые в зависимостях не занимают место на диске или в ОЗУ?

В этом и суть разделяемых библиотек, вместо того чтобы копироваться в каждом приложении (если 1000 приложений, то x1000 на диске, x1000 в памяти), они занимают один раз место на диске и в памяти.

3. В куче зависимостей гораздо проще что-то подменить (спрятать), чем один бинарь контрольную сумму которого можно отслеживать или использовать инструмент вроде afick.

Контрольную сумму можно посчитать и для библиотек. Здесь разницы нет.

Разработчики должны отслеживать уязвимости в библиотеках, которые они используют. Если кто-то написал программу, а она ломает всё и вся, то никто не будет этой программой пользоваться. Это вопрос жизни этой программы. Нельзя полагаться на то, что кто-то где-то будет обновлять библиотеки. Ментейнеры дистрибутива вообще могут, в теории, забить на это или не знать.

На деле это так не работает. Я рассмотрел вариант, когда линковка происходит статически, но сами библиотеки находятся в отдельных пакетах. То есть разработчик приложения не знает, с какой именно версией библиотеки будет собрано его приложение (это самая частая ситуация). Если же рассматривать вариант, о котором ты пишешь, когда разработчик приложения сам поставляет все зависимости (например мозилла так делает без дебиановского патча), то всё становится гораздо хуже. Тогда при обнаружении дыры в библиотеке уже разработчики приложения должны выпустить новую версию приложения с обновлённой библиотекой (а остальной код оставить неизменным). Но они этого обычно не делают, в лучшем случае просто говорят, возьмите новую версию приложения, но это рушит полностью идею стабильности релиза, потому что новая версия приложения неизбежно несёт проблемы с совместимостью и новые неизвестные баги. Да, для каких-то отдельных приложений такой подход приемлем, но как стандартная практика для всех приложений - нет. Ну, либо надо отказываться от идеи стабильных протестированных релизов дистрибутивов с обновлениями безопасности, а это совсем плохо. Поэтому, например, разработчики Дебиана изменяют код мозиллы, чтобы она зависила от системных библиотек, а не от тех что таскает за собой.

2. А разве библиотеки которые в зависимостях не занимают место на диске или в ОЗУ?

В этом и суть разделяемых библиотек, вместо того чтобы копироваться в каждом приложении (если 1000 приложений, то x1000 на диске, x1000 в памяти), они занимают один раз место на диске и в памяти.

3. В куче зависимостей гораздо проще что-то подменить (спрятать), чем один бинарь контрольную сумму которого можно отслеживать или использовать инструмент вроде afick.

Контрольную сумму можно посчитать и для библиотек. Здесь разницы нет.

Разработчики должны отслеживать уязвимости в библиотеках, которые они используют. Если кто-то написал программу, а она ломает всё и вся, то никто не будет этой программой пользоваться. Это вопрос жизни этой программы. Нельзя полагаться на то, что кто-то где-то будет обновлять библиотеки. Ментейнеры дистрибутива вообще могут, в теории, забить на это или не знать.

На деле это так не работает. Я рассмотрел вариант, когда линковка происходит статически, но сами библиотеки находятся в отдельных пакетах. То есть разработчик приложения не знает, с какой именно версией библиотеки будет собрано его приложение (это самая частая ситуация). Если же рассматривать вариант, о котором ты пишешь, когда разработчик приложения сам поставляет все зависимости (например мозилла так делает без дебиановского патча), то всё становится гораздо хуже. Тогда при обнаружении дыры в библиотеке уже разработчики приложения должны выпустить новую версию приложения с обновлённой библиотекой (а остальной код оставить неизменным). Но они этого обычно не делают, в лучшем случае просто говорят, возьмите новую версию приложения, но это рушит полностью идею стабильности релиза, потому что новая версия приложения неизбежно несёт проблемы с совместимостью и новые неизвестные баги. Да, для каких-то отдельных приложений такой подход приемлем, но как стандартная практика для всех приложений - нет. Ну, либо надо отказываться от идеи стабильных протестированных релизов дистрибутивов с обновлениями безопасности, а это совсем плохо.

2. А разве библиотеки которые в зависимостях не занимают место на диске или в ОЗУ?

В этом и суть разделяемых библиотек, вместо того чтобы копироваться в каждом приложении (если 1000 приложений, то x1000 на диске, x1000 в памяти), они занимают один раз место на диске и в памяти.

3. В куче зависимостей гораздо проще что-то подменить (спрятать), чем один бинарь контрольную сумму которого можно отслеживать или использовать инструмент вроде afick.

Контрольную сумму можно посчитать и для библиотек. Здесь разницы нет.

Разработчики должны отслеживать уязвимости в библиотеках, которые они используют. Если кто-то написал программу, а она ломает всё и вся, то никто не будет этой программой пользоваться. Это вопрос жизни этой программы. Нельзя полагаться на то, что кто-то где-то будет обновлять библиотеки. Ментейнеры дистрибутива вообще могут, в теории, забить на это или не знать.

На деле это так не работает. Я рассмотрел вариант, когда линковка происходит статически, но сами библиотеки находятся в отдельных пакетах. То есть разработчик приложения не знает, с какой именно версией библиотеки будет собрано его приложение (это самая частая ситуация). Если же рассматривать вариант, о котором ты пишешь, когда разработчик приложения сам поставляет все зависимости (например мозилла так делает без дебиановского патча), то всё становится гораздо хуже. Тогда при обнаружении дыры в библиотеке уже разработчики приложения должны выпустить новую версию приложения с обновлённой библиотекой (а остальной код оставить неизменным). Но они этого обычно не делают, в лучшем случае просто говорят, возьмите новую версию приложения, но это рушит полностью идею стабильности релиза, потому что новая версия приложения неизбежно несёт проблемы с совместимостью и новые неизвестные баги. Да, для каких-то отдельных приложений такой подход приемлем, но как стандартная практика для всех приложений - нет. Ну, либо надо отказываться от идеи стабильных протестированных релизов с обновлениями безопасности, а это совсем плохо.

2. А разве библиотеки которые в зависимостях не занимают место на диске или в ОЗУ?

В этом и суть разделяемых библиотек, вместо того чтобы копироваться в каждом приложении (если 1000 приложений, то x1000 на диске, x1000 в памяти), они занимают один раз место на диске и в памяти.

3. В куче зависимостей гораздо проще что-то подменить (спрятать), чем один бинарь контрольную сумму которого можно отслеживать или использовать инструмент вроде afick.

Контрольную сумму можно посчитать и для библиотек. Здесь разницы нет.

Разработчики должны отслеживать уязвимости в библиотеках, которые они используют. Если кто-то написал программу, а она ломает всё и вся, то никто не будет этой программой пользоваться. Это вопрос жизни этой программы. Нельзя полагаться на то, что кто-то где-то будет обновлять библиотеки. Ментейнеры дистрибутива вообще могут, в теории, забить на это или не знать.

На деле это так не работает. Я рассмотрел вариант, когда линковка происходит статически, но сами библиотеки находятся в отдельных пакетах. То есть разработчик приложения не знает, с какой именно версией библиотеки будет собрано его приложение (это самая частая ситуация). Если же рассматривать вариант, о котором ты пишешь, когда разработчик приложения сам поставляет все зависимости (например мозилла так делает без дебиановского патча), то всё становится гораздо хуже. Тогда при обнаружении дыры в библиотеке уже разработчики приложения должны выпустить новую версию приложения с обновлённой библиотекой (а остальной код оставить неизменным). Но они этого обычно не делают, в лучшем случае просто говорят, возьмите новую версию приложения, но это рушит полностью идею стабильности релиза, потому что новая версия приложения неизбежно несёт проблемы с совместимостью и новые неизвестные баги. Да, для каких-то отдельных приложений такой подход приемлем, но как стандартная практика для всех приложений - нет. Ну, либо надо отказываться от стабильных протестированных релизов с обновлениями безопасности, а это совсем плохо.

2. А разве библиотеки которые в зависимостях не занимают место на диске или в ОЗУ?

В этом и суть разделяемых библиотек, вместо того чтобы копироваться в каждом приложении (если 1000 приложений, то x1000 на диске, x1000 в памяти), они занимают один раз место на диске и в памяти.

3. В куче зависимостей гораздо проще что-то подменить (спрятать), чем один бинарь контрольную сумму которого можно отслеживать или использовать инструмент вроде afick.

Контрольную сумму можно посчитать и для библиотек. Здесь разницы нет.

Разработчики должны отслеживать уязвимости в библиотеках, которые они используют. Если кто-то написал программу, а она ломает всё и вся, то никто не будет этой программой пользоваться. Это вопрос жизни этой программы. Нельзя полагаться на то, что кто-то где-то будет обновлять библиотеки. Ментейнеры дистрибутива вообще могут, в теории, забить на это или не знать.

На деле это так не работает. Я рассмотрел вариант, когда линковка происходит статически, но сами библиотеки находятся в отдельных пакетах. То есть разработчик приложения не знает, с какой именно версией библиотеки будет собрано его приложение (это самая частая ситуация). Если же рассматривать вариант, о котором ты пишешь, когда разработчик приложения сам поставляет все зависимости (например мозилла так делает без дебиановского патча), то всё становится гораздо хуже. Тогда при обнаружении дыры в библиотеке уже разработчики приложения должны выпустить новую версию приложения с обновлённой библиотекой (а остальной код оставить неизменным). Но они этого обычно не делают, в лучшем случае просто говорят, возьмите новую версию приложения, но это рушит полностью идею стабильности релиза, потому что новая версия приложения неизбежно несёт проблемы с совместимостью и новые неизвестные баги. Да, для каких-то отдельных приложений такой подход приемлем, но как стандартная практика для всех приложений - нет.

2. А разве библиотеки которые в зависимостях не занимают место на диске или в ОЗУ?

В этом и суть разделяемых библиотек, вместо того чтобы копироваться в каждом приложении (если 1000 приложений, то x1000 на диске, x1000 в памяти), они занимают один раз место на диске и в памяти.

3. В куче зависимостей гораздо проще что-то подменить (спрятать), чем один бинарь контрольную сумму которого можно отслеживать или использовать инструмент вроде afick.

Контрольную сумму можно посчитать и для библиотек. Здесь разницы нет.

Разработчики должны отслеживать уязвимости в библиотеках, которые они используют. Если кто-то написал программу, а она ломает всё и вся, то никто не будет этой программой пользоваться. Это вопрос жизни этой программы. Нельзя полагаться на то, что кто-то где-то будет обновлять библиотеки. Ментейнеры дистрибутива вообще могут, в теории, забить на это или не знать.

На деле это так не работает. Я рассмотрел вариант, когда линковка происходит статически, но сами библиотеки находятся в отдельных пакетах. То есть разработчик приложения не знает, с какой именно версией библиотеки будет собрано его приложение (это самая частая ситуация). Если же рассматривать вариант, о котором ты пишешь, когда разработчик приложения сам поставляет все зависимости (например мозилла так делает без дебиановского патча), то всё становится гораздо хуже. Тогда при обнаружении дыры в библиотеке уже разработчики приложения должны выпустить новую версию приложения с обновлённой библиотекой. Но они этого обычно не делают, в лучшем случае просто говорят, возьмите новую версию приложения, но это рушит полностью идею стабильности релиза, потому что новая версия приложения неизбежно несёт проблемы с совместимостью и новые неизвестные баги. Да, для каких-то отдельных приложений такой подход приемлем, но как стандартная практика для всех приложений - нет.

2. А разве библиотеки которые в зависимостях не занимают место на диске или в ОЗУ?

В этом и суть разделяемых библиотек, вместо того чтобы копироваться в каждом приложении (если 1000 приложений, то x1000 на диске, x1000 в памяти), они занимают один раз место на диске и в памяти.

3. В куче зависимостей гораздо проще что-то подменить (спрятать), чем один бинарь контрольную сумму которого можно отслеживать или использовать инструмент вроде afick.

Контрольную сумму можно посчитать и для библиотек. Здесь разницы нет.