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

FDS>·>Если тебя заботит безопасность, то ты должен как-то верифицировать, что запускаемое это ровно то, что было скомпилировано и проверено компилятором.
FDS>Это уже вопрос рантайма. Причём может решаться частично организационными методами.
Вряд ли... Хотя если проект из одного человека, то может и сработать.

>>Программист. Когда пишет код, он должен точно знать что ему надо для выполнения данного функционала. Аудитор этот списочек будет проверять.
FDS>Нет. Так дело не пойдёт.
FDS>Как раз в том-то и дело, что не аудитор должен проверять, а компилятор.
На каком основании компилятор будет принимать решение, что некая функция с неким именем calculateHash может или не может писать в файлы?

FDS>·>Система типов может только лишь проверить, что типы не нарушаются, иногда тип может быть выведен автоматически. Но решать что какая функция может, а что не может придётся программисту.
FDS>Да. Но здесь всё просто. По умолчанию, никакая функция ничего не может. Программист должен просто сказать, что функция может.
FDS>Важно то, чтобы можно было эти все функции отследить.
Так в итоге в сколько-либо сложном проекте у тебя дойдёт до того, что программист будет говорить что все функции могут всё.

FDS>·>Поэтому выделяют API, модули, библиотеки и т.п., чтобы уменьшить attack surface. Но это вопрос проектирования конкретного приложения, а не ЯП.
FDS>Это вопрос именно ЯП, к сожалению. Потому что я должен иметь возможность ограничить доступ к API.
FDS>Даже если второй программист, допустим, злонамеренный. Ну или меня, не знаю, загипнотизировали
Так практически любой ЯП это уже умеет. Если в файле не написано "import java.io.*" то io никакого в данном файле быть не может (рефлексию не считаем, её можно явно оключить, как правило).

FDS>·>По большому счёту сборщик мусора единственное самое надёжное место для обнуления памяти.
FDS>Да. Верно. Либо сборщик мусора, либо счётчик ссылок,
Счётчик ссылок это тривиальный вариант реализации сборщика мусора.

FDS>либо специализированная система выделения памяти.
Тут проблема не в выделении, а в освобождении. Т.к. именно при освобождении надо занулять.

FDS>·>А что если процесс записал в память секрет, и тут же крешнулся или был убит? Перезаписать будет банально некому. Так что гарантировать ты никак такое не сможешь.
FDS>В данном случае предполагается гарантия при правильной работе программы, хотя бы.
FDS>При неправильной ничто никогда не гарантирует.
Ну тогда просто — при завершении процесса занулить всю память. Интуиция подсказывает, что такое API должно предоставляться операционкой. А то утечёт что-нибудь в своп-файл, сработает какая-нибудь дефрагментация и нифига не занулится.

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

FDS>·>Если тебя заботит безопасность, то ты должен как-то верифицировать, что запускаемое это ровно то, что было скомпилировано и проверено компилятором.
FDS>Это уже вопрос рантайма. Причём может решаться частично организационными методами.
Вряд ли... Хотя если проект из одного человека, то может и сработать.

>>Программист. Когда пишет код, он должен точно знать что ему надо для выполнения данного функционала. Аудитор этот списочек будет проверять.
FDS>Нет. Так дело не пойдёт.
FDS>Как раз в том-то и дело, что не аудитор должен проверять, а компилятор.
На каком основании компилятор будет принимать решение, что некая функция с неким именем calculateHash может или не может писать в файлы?

FDS>·>Система типов может только лишь проверить, что типы не нарушаются, иногда тип может быть выведен автоматически. Но решать что какая функция может, а что не может придётся программисту.
FDS>Да. Но здесь всё просто. По умолчанию, никакая функция ничего не может. Программист должен просто сказать, что функция может.
FDS>Важно то, чтобы можно было эти все функции отследить.
Так в итоге в сколько-либо сложном проекте у тебя дойдёт до того, что программист будет говорить что все функции могут всё.

FDS>·>Поэтому выделяют API, модули, библиотеки и т.п., чтобы уменьшить attack surface. Но это вопрос проектирования конкретного приложения, а не ЯП.
FDS>Это вопрос именно ЯП, к сожалению. Потому что я должен иметь возможность ограничить доступ к API.
FDS>Даже если второй программист, допустим, злонамеренный. Ну или меня, не знаю, загипнотизировали
Так практически любой ЯП это уже умеет. Если в файле не написано "import java.io.*" то io никакого в данном файле быть не может. Немного сложнее, но элементарно делается. Динамическую подгрузку кода не считаем, её можно явно оключить, как правило.

FDS>·>По большому счёту сборщик мусора единственное самое надёжное место для обнуления памяти.
FDS>Да. Верно. Либо сборщик мусора, либо счётчик ссылок,
Счётчик ссылок это тривиальный вариант реализации сборщика мусора.

FDS>либо специализированная система выделения памяти.
Тут проблема не в выделении, а в освобождении. Т.к. именно при освобождении надо занулять.

FDS>·>А что если процесс записал в память секрет, и тут же крешнулся или был убит? Перезаписать будет банально некому. Так что гарантировать ты никак такое не сможешь.
FDS>В данном случае предполагается гарантия при правильной работе программы, хотя бы.
FDS>При неправильной ничто никогда не гарантирует.
Ну тогда просто — при завершении процесса занулить всю память. Интуиция подсказывает, что такое API должно предоставляться операционкой. А то утечёт что-нибудь в своп-файл, сработает какая-нибудь дефрагментация и нифига не занулится.