﻿# 1000 глаз, которые не хотят проверять код открытых проектов

Есть такой миф, что открытое программное обеспечение более качественное и безопасное, чем закрытое\. Много раз это обоснованно ставилось под сомнение\. Существует примеры, когда в открытом коде находили эпичные уязвимости, которые скрывались от разработчиков и пользователей долгие годы\. Я считаю, что качество проекта зависит от того, как руководители разработки построили процесс и какие методологии/инструменты используются, а не от того, открыт или закрыт проект\.

![0900_1000_eyes_ru/image1.png](https://import.viva64.com/docx/blog/0900_1000_eyes_ru/image1.png)

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

Как разработчик PVS\-Studio, нашедший несколько тысяч [ошибок](https://pvs-studio.ru/ru/blog/examples/) в открытых проектах, я очень скептически к этому отношусь\. Во\-первых, я сомневаюсь, что так уж часто кто\-то из этих абстрактных сторонних людей на самом деле ищет ошибки и уязвимости\. Во\-вторых, будучи как раз этим редким человеком, я могу утверждать, что разработчикам часто до балды эти старания\. То есть самим разработчикам может быть неинтересно качество и надёжность их проектов\. Им интересны новые фичи или что\-то ещё, а не потенциальные проблемы и дефекты безопасности\.

Множество раз мои сообщения про найденные ошибки игнорировались или откладывались в дальний ящик авторами открытых проектов\. Хочется proof'ов? Пожалуйста\.  Сегодня у меня как раз есть красивый жирный пример\.

Меня cподвигло написать эту мини\-заметку неожиданное письмо от багтрекера проекта Samba\. Я сначала даже не понял, что это за письмо такое\. Оказывается, добрались до ошибок, отписанных мной ещё 9 лет назад\! 

![0900_1000_eyes_ru/image2.png](https://import.viva64.com/docx/blog/0900_1000_eyes_ru/image2.png)

Девять лет всем всё равно, что в проекте баги\. Девять лет всем всё равно, что в проекте присутствуют старые версии библиотек с потенциальными уязвимостями типа [CWE\-14](https://cwe.mitre.org/data/definitions/14.html)\. Да, собственно, и сейчас, пока я пишу эти строки, в коде присутствуют всё те же опасные вызовы _memset_\. Например, здесь:

```cpp
static void
md_result(MD_CTX * ctx, unsigned char *dst)
{
  SHA256_CTX tmp;

  memcpy(&tmp, ctx, sizeof(*ctx));
  SHA256_Final(dst, &tmp);
  memset(&tmp, 0, sizeof(tmp));
}
```

Или здесь:

```cpp
static void
calc(struct md2 *m, const void *v)
{
  unsigned char x[48], L;
  const unsigned char *p = v;
  int i, j, t;

  ....
  memcpy(m->state, x, 16);
  memset(x, 0, sizeof(x));
}
```

Вызовы этих _memset_ компилятор удалит, и приватные данные будут продолжать находиться в памяти\. Если вы далеки от этой темы, то разобраться, что к чему, поможет статья "[Безопасная очистка приватных данных](https://pvs-studio.ru/ru/blog/posts/cpp/0388/)"\.

Возможно, конкретно эти баги и дефекты безопасности никакой реальной беды и угрозы не представляют\. Дело в другом\. Разработчикам проекта всё равно\. И сторонним разработчикам всё равно\. Никто не берёт и не исправляет хотя бы те баги, которые можно взять и найти с помощью PVS\-Studio\. И даже уже найденные баги не торопятся исправлять\.

Бомбанул\. Стало полегче\. Спасибо, кто выслушал :\)\. Буду ссылаться на эту заметку, когда кто\-то вновь заведёт шарманку на тему того, что открытый код безопаснее\.