ручная работа(без Composer)

[arturf]

Чтобы не тянуть зависимости композером из "недоверенных" источников, можно склонировать публичные репозитории в какую-то свою закрытую среду (приватные репозитории гитхаба или локальные решения а-ля Gitlab), после чего проаудировать их с целью поиска каких-либо уязвимостей; и потом уже можно настроить проектный composer.json на использование своих версий библиотек.

Переход на новые версии библиотек будет, конечно, менее удобным (нужно будет поддерживать локальные репозитории в актуальном состоянии), но будет больше контроля над кодом, если это критично с точки зрения безопасности.

Автоматизация обновления зависимостей будет особенно полезной, если над проектом работает много людей, а также при использовании CI-серверов удобно использовать композер в сценариях сборки для получения работающего приложения, при этом нет необходимости вместе с кодом проекта держать условно статичный код библиотек, который меняется относительно редко (или вообще никогда, если версии прописаны строго).

[3ton]

Много лет назад, когда я учился на факультете радиоаппаратостроения, нас научили одной простой истине - чем больше элементов содержит конструкция и чем они сложнее - тем меньше надежность самой конструкции.
Для примера лампочка или резистор - имеют один из высоких коэффициентов надежности в отличии от транзистора или тем более микросхемы. Поэтому я и в программировании пытаюсь сделать так чтоб мой код зависел от как можно меньшего кол-ва элементов тем более не нужных мне. А работа порядка 8 лет системным администратором в крупных компаниях с серьезными требованиями к безопасности научили что баги обычно могут вылезти там где их совсем не ожидаешь.

Сегодня прочитал статью(http://habrahabr.ru/post/245745/) про композер и понял что именно такого действия от него я и остерегался, но не факт что его поведение не может вылиться и в более опасный результат.

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

[lynicidn]

>Много лет назад, когда я учился на факультете радиоаппаратостроения, нас научили одной простой истине - чем больше элементов содержит конструкция и чем они сложнее - тем меньше надежность самой конструкции.
Явный сторонник системды

[zelenin]

Много лет назад, когда я учился на факультете радиоаппаратостроения, нас научили одной простой истине - чем больше элементов содержит конструкция и чем они сложнее - тем меньше надежность самой конструкции.
Для примера лампочка или резистор - имеют один из высоких коэффициентов надежности в отличии от транзистора или тем более микросхемы. Поэтому я и в программировании пытаюсь сделать так чтоб мой код зависел от как можно меньшего кол-ва элементов тем более не нужных мне. А работа порядка 8 лет системным администратором в крупных компаниях с серьезными требованиями к безопасности научили что баги обычно могут вылезти там где их совсем не ожидаешь.

Сегодня прочитал статью(http://habrahabr.ru/post/245745/) про композер и понял что именно такого действия от него я и остерегался, но не факт что его поведение не может вылиться и в более опасный результат.

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

могу посоветовать обходится и без yii, раз уж приводите такие некорректные сравнения.
проект без композера - это не проект с дополнительынм элементом и без. Это копать траншею простым устройством (лопата) или устройством из мотора, микросхем и прочих форсунок (экскаватор), которое может сломаться.

[zelenin]

Сегодня прочитал статью(http://habrahabr.ru/post/245745/) про композер и понял что именно такого действия от него я и остерегался, но не факт что его поведение не может вылиться и в более опасный результат.

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

[3ton]

Почему это проблема композера, если он выполняет свою работу - обновляет пакет?

Проблема как раз в том что композер может мне подсунуть совсем не тот пакет. Эта вероятность есть и ее никто не исключает.

могу посоветовать обходится и без yii

спасибо за стоящий совет ))))

[chungachguk]

Сегодня прочитал статью(http://habrahabr.ru/post/245745/) про композер и понял что именно такого действия от него я и остерегался, но не факт что его поведение не может вылиться и в более опасный результат.

Статья занимательная, но интересно какой в реальности прок от этой "уязвимости"? Если есть репозиторий приватный, на ресурсе композера выложили репозиторий с таким же названием, с которого композер и обновился. Но в итоге основной код не отработает, так как нужно же заранее знать под какой репозиторий делать фейковый, знать его структуру и с чего начнётся исполнение кода.

Если имеется ввиду раздел composer.json

Код: Выделить всё

"scripts": {
        "post-create-project-cmd": [
            "yii\\composer\\Installer::postCreateProject"
        ]
    },
 

то здесь ( https://github.com/composer/composer/bl ... scripts.md ) вроде как сказано, что запускаются они только из основного composer.json

Может я что-то не так понял?

[zelenin]

Почему это проблема композера, если он выполняет свою работу - обновляет пакет?

Проблема как раз в том что композер может мне подсунуть совсем не тот пакет. Эта вероятность есть и ее никто не исключает.

как не тот? у пакета есть идентификатор - название. Если вы подключаете два репозитория пакетов, есть вероятность, что название неуникально. Вы же как разработчик должны это учесть. Это не проблема композера.

[zelenin]

Статья занимательная, но интересно какой в реальности прок от этой "уязвимости"? Если есть репозиторий приватный, на ресурсе композера выложили репозиторий с таким же названием, с которого композер и обновился. Но в итоге основной код не отработает, так как нужно же заранее знать под какой репозиторий делать фейковый, знать его структуру и с чего начнётся исполнение кода.

тут как раз все понятно. Бывший разработчик проекта, зная как используется их приватный проект, может создать фейковый пакет с учетом того, что где нужно допилить.

Но как это может быть проблемой разработчика? если я создам у себя в приватном репозитории пакет yiisoft/yii2 версии 0.0.1, то конечно установится версия 2.0.1 из packagist. Разве это проблема композера?
Либо отрубай packagist, либо задавай уникальное название (хотя, как выше написал, от знакомого с кухней разработчика, уникальное имя не спасет)

[Kane:)]

...
Интересует возможность собрать приложение ручками, не готовыми решениями через Composer, а именно так как это делалось в первой версии: мы делаем скелет приложения, размещаем папку с нужной версией фреймворка в нужном нам месте, ссылаемся на него из index.php и у нас все работает.
...

Как выше и советовали, в таком случае вам нужно ставить вопрос о выборе другого фреймворка для вашего проекта, так как с такими требованиями явно не к Yii2. Зачем ломать инструмент который не для ваших задач вместо того, чтобы просто взять тот что вам нужен?

[zelenin]

Как выше и советовали, в таком случае вам нужно ставить вопрос о выборе другого фреймворка для вашего проекта, так как с такими требованиями явно не к Yii2. Зачем ломать инструмент который не для ваших задач вместо того, чтобы просто взять тот что вам нужен?

я не советовал выбрать другой фреймворк. я советовал взять инструмент с меньшим количеством деталей под копотом - голый php.
Любой современный фреймворк работает с композером.

[lynicidn]

первую версию можно

[zelenin]

первую версию можно

и вторую тоже. не в этом дело.

[Ekstazi]

Странная тема вышла. yii2 можно успешно применять и без composer. С большими усилиями, но я не понимаю зачем. Правильно сказали - чем больше элементов - тем ненадежней система. Composer берет на себя роль по установке пакетов и их контролю. Ненадежность приходит когда у тебя много сторонних пакетов и расширений. И каждое необходимо обновлять регулярно (+ подключить один раз в extensions.php и следить за ним регулярно). composer может и не идеален (не для меня), но это отличный инструмент, который можно легко заточить под свои нужды (например, прикрутить satis).

[zelenin]

Странная тема вышла. yii2 можно успешно применять и без composer. С большими усилиями, но я не понимаю зачем. Правильно сказали - чем больше элементов - тем ненадежней система. Composer берет на себя роль по установке пакетов и их контролю. Ненадежность приходит когда у тебя много сторонних пакетов и расширений. И каждое необходимо обновлять регулярно (+ подключить один раз в extensions.php и следить за ним регулярно). composer может и не идеален (не для меня), но это отличный инструмент, который можно легко заточить под свои нужды (например, прикрутить satis).

хороший коммент. Резюмирую: композер добавляет надежности, там, где надежности становится меньше с увеличением вручную установленных пакетов. А не наоборот, как писал 3ton.

[samdark]

Просто за сторонним кодом надо смотреть. А как этот сторонний код затягивается в проект — руками или же набором composer update в консольке, не так важно. Не посмотрели код — сами виноваты.

[lynicidn]

композер.жсон едакое оглавление установленных пакетов и их версий, другого быть не может или composer update для актуализации

[chungachguk]

композер.жсон едакое оглавление установленных пакетов и их версий, другого быть не может или composer update для актуализации

не, тут уже переживаем что может

[GeX]

Такс, насколько я понял принцип, то проект использует автолоад от композера, ок, нормально, пусть будет. Теперь момент. У меня есть библиотека, самопальная, самописная, несколько функций, скелеты классов и т.д., короче этакая надстроечка (у меня там была своя удобная мне надстройка для дебага в файл, аналог Zend_Registry, скелет под класс гидратора и т.д.). В yii1.1 я это дело подключал экстеншеном и прекрасно с ним работал. Ок. Если что-то нужно было дописать - дописывал непосредственно в папке экстеншена проекта, то есть эта штука совершенно не имела своего личного репозитария, нигде не лежала, жила себе тихо-мирно внутри проекта.

Теперь ситуация - композер. Я понимаю что в эту же библиотеку я могу добавить composer.phar, запаковать архивом и подключить или как пак, или как артефакт, оно себе встанет в vendors, пропишется в autoload и будет всё хорошо.

Но например у меня либа лежит в vendors/gex/liba. Можно ли композеру сказать что исходный репозитарий это vendors/gex/liba ? Чтобы он при composer install и composer update себе мозг не сломал? Можно ли править содержимое vendors/gex/liba так, чтобы оно не потёрлось при composer install или composer update?

[chungachguk]

Но например у меня либа лежит в vendors/gex/liba. Можно ли композеру сказать что исходный репозитарий это vendors/gex/liba ? Чтобы он при composer install и composer update себе мозг не сломал? Можно ли править содержимое vendors/gex/liba так, чтобы оно не потёрлось при composer install или composer update?

Можно. в GII при генерации расширения, в конце появляется подсказка как реализовать установку пакета локально.