PHP фреймворки
- Автор темы dmitryssh
- Дата начала
Вопрос очень интересный.
Только он намного сложнее и шире, чем название темы (это вообще предмет для отдельной новой темы) ... потому как PHP сам по себе - это лохотрон для WEB-самоделкиных, но вопрос в той же мере относится ко всем "взрослым" инструментам программирования:
- вот сертифицировали вы все конечные IT продукты...
- а как быть с собственными разработками, скажем на компилирующих языках ... C / C++ / Go - но там к вашему продукту прикомпоновываются динамически библиотеки, libc.so - в самом простейшем случае всегда ... + 2 десятка, возможно, ещё DLL - как быть с сертификацией такой собственной разработки?
- но и чисто компилирующих языков осталось за последние 20 лет ... практически 3: всё те же C / C++ / Go - из 100-150 активно используемых языков разработки; а как быть с остальными? с Java которой вашим проектам нужна виртуальная машина JVM? с Python которому нужна исполняющая система Python? ... и ещё 2 десятка активно используемых в разработке языков : Perl, Lua, Tcl/Tk, Scala, JavaScript, Ruby, Swift, Rust, Kotlin, Scheme, Ocaml, Hakell, Erlang,...
Жёстко зарегулированные условия сертификации в отношении применяемых инструментов разработки может отбросить отечественных разработчиков на уровень каменного века ... на уровень Cobol, Fortran, Pascal ...
С другой стороны, сертификации могли бы подлежать только конечные представленные IT продукты ... но здесь всё становится очень зависимо от ... "убедительности"
фирмы-разработчика.
Только он намного сложнее и шире, чем название темы (это вообще предмет для отдельной новой темы) ... потому как PHP сам по себе - это лохотрон для WEB-самоделкиных, но вопрос в той же мере относится ко всем "взрослым" инструментам программирования:
- вот сертифицировали вы все конечные IT продукты...
- а как быть с собственными разработками, скажем на компилирующих языках ... C / C++ / Go - но там к вашему продукту прикомпоновываются динамически библиотеки, libc.so - в самом простейшем случае всегда ... + 2 десятка, возможно, ещё DLL - как быть с сертификацией такой собственной разработки?
- но и чисто компилирующих языков осталось за последние 20 лет ... практически 3: всё те же C / C++ / Go - из 100-150 активно используемых языков разработки; а как быть с остальными? с Java которой вашим проектам нужна виртуальная машина JVM? с Python которому нужна исполняющая система Python? ... и ещё 2 десятка активно используемых в разработке языков : Perl, Lua, Tcl/Tk, Scala, JavaScript, Ruby, Swift, Rust, Kotlin, Scheme, Ocaml, Hakell, Erlang,...
Жёстко зарегулированные условия сертификации в отношении применяемых инструментов разработки может отбросить отечественных разработчиков на уровень каменного века ... на уровень Cobol, Fortran, Pascal ...
С другой стороны, сертификации могли бы подлежать только конечные представленные IT продукты ... но здесь всё становится очень зависимо от ... "убедительности"
фирмы-разработчика.
Последнее редактирование:
Ну и используйте... PHP у вас в AL SE есть (в репозиториях на дисках):
Сам ваш собственный исходный программный код никакой сертификации не подлежит и не требует...
Код:
olej@astra:~$ aptitude show php
Пакет: php
Версия: 1:7.0+49
Состояние: не установлен
Приоритет: необязательный
Раздел: php
Сопровождающий: Debian PHP Maintainers <pkg-php-maint@lists.alioth.debian.org>
Архитектура: all
Размер в распакованном виде: 12,3 k
Зависит: php7.0
Предоставляется: php7.0 (7.0.27-0+deb9u1)
Описание: server-side, HTML-embedded scripting language (default)
PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is
especially suited for web development and can be embedded into HTML.
This package is a dependency package, which depends on Debian's default PHP version (currently 7.0).Программный код - это текстовый документ.
Вы когда пишете карандашом письмо на деревню маме - требуете для него сертификацию безопасности? ... того что там написано ...
P.S. А bash скрипты тоже сертифицировать станем?
Как-то вся эта история с сертификацией своей оборотной стороной начинает напоминать идиотизм...
Вы когда пишете карандашом письмо на деревню маме - требуете для него сертификацию безопасности? ... того что там написано ...
P.S. А bash скрипты тоже сертифицировать станем?
Как-то вся эта история с сертификацией своей оборотной стороной начинает напоминать идиотизм...
Последнее редактирование:
Вот из состава репозитрия AL SE 1.6 на 2-х дисках:
Код:
olej@astra:~$ aptitude search php-symfony | wc -l
62
Код:
olej@astra:~$ aptitude search zend
p php-zend-code - Zend Framework - Code component
p php-zend-eventmanager - Zend Framework - EventManager component
v php-zendframework-zend-code -
v php-zendframework-zend-eventmanager -
Последнее редактирование:
to _Denis_
Коротко:
На всякий случай: для разработки под Astra Linux Special Edition недостаточно скачать откуда-то "диск разработчика" и что-то лепить. Тем более под серьезные системы, а не на "поиграться". Как минимум, потому что оный диск покупается, а не качается с торрентов, ага...
to Olej
И вылезайте уже из саркофага 90х-2000х, а то подобная позиция перестает забавлять...
Коротко:
- Сертификации подвергается конечный программный продукт. Исходный код, если он предоставляется разработчиком, проверяется, однако не во всех случаях и далеко не всегда в полной мере...
- Сертификация инфобеза в РФ бывает разная. По линии МО РФ, по линии ФСТЭК России, по линии ФСБ России и т.д. Требования различаются, зато Astra сама по себе и софт для нее соответственно может "проходить" по любой из этих линий...
- Сертификация инфобеза в РФ бывает разная (второй раз, ага). Имеются: сертификация софта как СЗИ и сертификация прикладного софта, не претендующего на защиту информации, исключительно по контролю недекларированных возможностей (для применения в АС с обработкой гостайны и некоторых ИС с высоким уровнем/классом защищенности). По линии ФСТЭК России это свойство прописано либо в Профиле защиты под конкретный тип СЗИ, либо в общих правилах ОУД (оценочный уровень доверия) с недавних пор...
- Инструменты разработчика (фреймворки, среды разработки, поддержка языков) - с ними много нюансов. В общих чертах, инструменты не сертифицируются, но для защищенной разработки требуются конкретные версии + доп. ограничения по инфраструктуре, в которой проводится разработка. И, важно, требуются сертифицированные (если существуют) средства проверки (анализа, аудита) конечного софта (исходного кода)...
- Подключаемые библиотеки и зависимости разрабатываемого софта в большинстве случаев должны быть из состава той среды обработки, в которой будет использоваться софт. В части случаев также требуется предоставление исходного кода зависимостей до пятого колена. Надо смотреть по ситуации...
На всякий случай: для разработки под Astra Linux Special Edition недостаточно скачать откуда-то "диск разработчика" и что-то лепить. Тем более под серьезные системы, а не на "поиграться". Как минимум, потому что оный диск покупается, а не качается с торрентов, ага...
to Olej
- PHP в современном мире именно что инструмент разработчика, причем в части случаев незаменимый. Точка зрения про web-поделки не выдерживает критики, потому что web сейчас - основное направление. Плохо это или хорошо - не важно, это данность. Или вы разработку любого web-проекта на чистом Си от и до фигачить предлагаете? И кто тогда застрял в каменном веке, а?
- Внезапно, но скрипты проходят проверку при использовании в составе СЗИ и в защищенных АС вообще. Потому что по смыслу инфобеза ничем не отличаются от скомпиллированного кода...
- Текущие условия сертификации никого никуда не отбрасывают. Сложностей добавляют, да, схема разработки аналогична "общедоступным" системам...
И вылезайте уже из саркофага 90х-2000х, а то подобная позиция перестает забавлять...