Как стать автором
Обновить
0
0

Пользователь

Отправить сообщение

Недавно представитель ИСП РАН говорил, что они вместе с ФСТЭК готовят ГОСТ по безопасному компилятору C/C++.

Особое очарование мандатному контролю (или управлению, кому как больше нравится) доступа придает необходимость работы с информацией различных грифов. Особенно, когда нужно такую информацию вносить в систему или наоборот, выдавать. Поскольку клиентская программа (хоть толстый, хоть тонкий клиент) работает на конкретном уровне сеанса — например, С — ввод данных НС в этом случае весьма затруднён, поскольку требует преобразования меток перед записью (например, в БД), что в общем случае является нетривиальной задачей. Альтернативный путь — поочередная работа пользователя в разных сеансах, в соответствии с грифом данных, которые он планирует вводить. А разные сеансы — это, на минуточку, перелогинивание пользователя и повторный запуск программы. Ну или в лучшем случае, переключение в соседнюю консоль (заранее открытую и с запущенной программой). И хорошо, если вводимые данные разных грифов не связаны между собой. Но обычно то оно не так — классическая задача ведения несекретных перечней объектов с секретными характеристиками типа объектов делает процесс ввода данных достаточно фееричным. А ведь ещё можно вспомнить не менее типовую задачу формирования отчётов, которые, в зависимости от данных, могут иметь разный гриф. И генерировать их проходится либо из разных сеансов, либо, опять же, со сменой меток на ходу. А в этом случае добавляет радостей автоматическая маркировка выдаваемых на печать документов, которой обычно фиолетово, секретный или несекретный файл ты отправляешь на печать из секретного сеанса. В общем, на практике проблем там гораздо больше, чем упоминает автор; впрочем, он же обещал продолжение, будет интересно почитать.

Да вот только правило говорит нам, что следует всегда использовать default. Я и указываю на излишнюю догматичность и даже вредность этого правила для случая enum.

В случае, если enum содержит, например, пару десятков значений, а реально полезны (как-то обрабатываются) из них в конкретном switch штук пять — перечисление всех возможных значений в switch вряд ли можно назвать чистым и читаемым кодом. Указание только обрабатываемых значений и обработка по default, по мне, выглядят куда более читабельными.

Конечно, всё, что пришло извне, должно подвергаться проверке. Только при чём тут default?

Как я понял, речь о том, что значение переменной в памяти может измениться/побиться, причём может получиться совершенно произвольное значение, не соответствующее ни одному из используемых в enum (т.е. при использовании enum со значениями 1, 2, 3 переменная может оказаться равной, скажем, 23). В таком случае наличие case со всеми значениями enum и без default в конце не приведёт к срабатыванию ни одного case (значение-то совсем кривое). И вот тут default с «аварийной» обработкой будет очень кстати.
Поэтому лично я обеими руками за default всегда и везде.

По мне, вопрос насколько неоднозначный. С одной стороны — такое взаимодействие даёт крайне положительный эффект. Когда клиент пару раз выскажет программисту своё "фи" по результатам его работы, эти результаты в дальнейшем часто становятся заметно лучше. С другой стороны — такая ситуация говорит, вроде бы, про некачественную работу менеджера, который недостаточно проконтролировал результат. Истина же, как водится, где-то посередине — т.к. никакие ТЗ, критерии приемки, методики испытаний не покроют абсолютно всех деталей задачи, и место оголтелому креативу или циничному пофигизму всегда найдется.
В-общем, я — за такие общение, хотя бы иногда.

Не очень понятна клиентская и околоклиентская сторона. Судя по описанию, клиенты всегда обращаются к лидеру (дилеру, как предлагает свайп, что, в принципе, тоже подходит :) ). Спрашивается, чем оно обеспечивается — клиенты узнают про нового лидера, или предполагается использование редиректора на лидера? Но и редиректор тоже должен узнавать про изменения, а об этом в статье не сказано.
Если же клиенты будут обращаться к разным серверам, включая бывших лидеров — тут совсем зоопарк может получиться.
Опять же, смущает пример (который хороший пример, но с трагическим началом), где лог фолловера содержит запись, отсутствующую у лидера. Откуда-то она же там появилась? А в результате оказывается затёрта.
В общем, с работой клиентов надо поразбираться.

Не согласен с требованием выносить режим в заголовок абзаца, при этом теряется исходная идея task-топика, то есть подхода «от задачи». Режим же здесь — средство выполнения задачи, он вторичен. Другое дело, что определен он в самом деле не сильно явно — тут согласен. Если уж используется термин «режим Coherence» — так и определен он должен быть именно в таком виде.
Ну и маленькая реплика от нормоконтроля: «Чтобы переключиться из режима „Окно“ в Coherence...» — всё же стоит использовать одинаковые подходы в именовании режимов — либо везде в кавычках, либо везде без них.
А может кто-нибудь объяснить, в чем практический смысл использования урезанного размера PDU (из п.1.2), например, «L2 Data или IP packet len»? Могу понять это на уровне, скажем, шлюза с разной физикой по разные стороны, где полный объем трафика получается разным м разных сторон; а вот применительно к, например, ethernet-маршрутизатору как-то непонятно, зачем такое делать.
Насколько я понимаю, здесь главная проблема у пользователей была в том, что непонятно, как добиться выполнения требования. В случае с классическими вариантами, типа использования спецсимволов и т.п. ясно, что делать. А вот что нужно сделать, чтобы пароль имел нужный уровень энтропии — и для продвинутого в плане безопасности пользователя может быть не очевидно, а уж для далёкого от этих вопросов обычного человека, ни разу не математика, — однозначно темный лес. Мое мнение — если очень хочется гарантировать высокую стойкость паролей — генерируйте их сами. Хотя куча пользователей за это спасибо не скажет :)
Помимо боевых систем, для МО разрабатывается куча другого софта, имеющего на порядок большие перспективы применения в других областях. Лично меня тут больше беспокоит вопрос засвечивания уязвимостей в коде. А учитывая, что многие системы там вполне себе успешно работают и через 20 лет после разработки, этот вопрос может стать реальной проблемой.
до того, как запросить создание трансляции, Vuze заставил маршрутизатор перечислить все имеющиеся Port Forwarding'и. Для чего это было сделано, я могу лишь догадываться
Могу предположить, это для того, чтобы не создавать уже существующий (не закрытый ранее — например, из-за грохнувшегося приложения) проброс. Тут, правда, возникает вопрос — что лучше, пытаться повторно использовать потенциально чужой проброс или захламлять маршрутизатор всё новыми пробросами.
Тут сразу возникает вопрос, можно ли будет отвечать на ещё не одобренные комментарии. Если нет — ветка обсуждения по определению зависает, возможно, до 3-х дней; если да — что делать с «дочерними» комментариями в случае неодобрения — удалять? Так вроде их не за что. Оставлять висящими в воздухе? Тоже не выйдет.
В общем, в первом случае удобства немного, а во втором ещё и куча проблем. Скорее всего, оно того не стоит.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность