Здравствуйте, ·, Вы писали:
·>Если тебя заботит безопасность, то ты должен как-то верифицировать, что запускаемое это ровно то, что было скомпилировано и проверено компилятором.
Это уже вопрос рантайма. Причём может решаться частично организационными методами.
>Программист. Когда пишет код, он должен точно знать что ему надо для выполнения данного функционала. Аудитор этот списочек будет проверять.
Нет. Так дело не пойдёт.
Как раз в том-то и дело, что не аудитор должен проверять, а компилятор.
·>Система типов может только лишь проверить, что типы не нарушаются, иногда тип может быть выведен автоматически. Но решать что какая функция может, а что не может придётся программисту.
Да. Но здесь всё просто. По умолчанию, никакая функция ничего не может. Программист должен просто сказать, что функция может.
Важно то, чтобы можно было эти все функции отследить.
·>Поэтому выделяют API, модули, библиотеки и т.п., чтобы уменьшить attack surface. Но это вопрос проектирования конкретного приложения, а не ЯП.
Это вопрос именно ЯП, к сожалению. Потому что я должен иметь возможность ограничить доступ к API.
Даже если второй программист, допустим, злонамеренный. Ну или меня, не знаю, загипнотизировали
·>Можно взять какой-нибудь существующий и допилить.
Обычно проще написать самому. Слишком технологии разные. Ну или Cosmos брать.
·>По большому счёту сборщик мусора единственное самое надёжное место для обнуления памяти.
Да. Верно. Либо сборщик мусора, либо счётчик ссылок, либо специализированная система выделения памяти.
> Ясное дело, что ценой будет падение производительности... поэтому так не делают, но думаю допилить сущетсвующий будет не сложно. Лучший компромисс это когда программист явно помечает секретные данные в коде чтобы они чистились явно. Если чистить всё и всегда — будет тормозить.
В данном случае все данные предполагаются секретными.
·>А что если процесс записал в память секрет, и тут же крешнулся или был убит? Перезаписать будет банально некому. Так что гарантировать ты никак такое не сможешь.
В данном случае предполагается гарантия при правильной работе программы, хотя бы.
При неправильной ничто никогда не гарантирует.
