Разработчики инструментария непрерывной интеграции Jenkins (http://www.jenkins-ci.org) предупредили (https://jenkins.io/blog/2016/11/12/addressing-remote-vulnera.../) о выходе 16 ноября корректирующего релиза, в котором будет устранена опасная уязвимость (https://groups.google.com/forum/#!msg/jenkinsci-advisories/-...), позволяющая удалённому атакующему без прохождения аутентификации выполнить свой код на сервере. Суть уязвимости в том, что через передачу сериализированных Java-объектов в Jenkins CLI можно добиться обращения к LDAP-серверу атакующего. Ответ от LDAP-сервера может содержать сериализированный код, который будет выполнен в обход механизмов защиты.
В качестве временной меры защиты до выхода обновления всем администраторам публичных серверов Jenkins рекомендуется временно заблокировать интерфейс CLI, воспользовавшись скриптом (https://github.com/jenkinsci-cert/SECURITY-218/blob/master/c...), опубликованным (https://github.com/jenkinsci-cert/SECURITY-218) для временной защиты от прошлогодней критической уязвимости. Скрипт следует запустить через меню Manage Jenkins в секции Script Console, после чего добавить в автозапуск ($JENKINS_HOME/init.groovy.d/cli-shutdown.groovy) до применения обновления с устранением уязвимости. Другим временным способом защиты является блокировка доступа к страницам "/cli" на стороне http-сервера.URL: http://seclists.org/oss-sec/2016/q4/412
Новость: http://www.opennet.me/opennews/art.shtml?num=45485
Пф.... https://hackage.haskell.org/package/sproxy
Слава богу у нас теперь гитхаб и гитлаб есть.
и что же из них умеет собирать код?
GitLab вроде умеет.
Сколько юзали чудо жабье у себя в конторе, столько плевались. Утешали себя тем, что альтернативы ещё хуже. А потом поставили себе GitLab и с удивлением обнаружили, что в нём есть чудесный CI. И всё у нас стало хорошо.
Шило на мыло, было чудо жабье, стало чудо-руби, оперативы жрать меньше не стало
Гитлаб неиллюзорно жручий до памяти, это правда. Для нашей конторы аж целый гиг пришлось ему выделить. Но память жрётся только на основном сервере, а на билд-нодах запущен только маленький демон на Go. https://gitlab.com/gitlab-org/gitlab-ci-multi-runner В отличие от сабжа, у которого жабий слейв часто отжирает больше, чем сам билд.
> гиг пришлось ему выделить. Но память жрётся только на основном сервере,
> а на билд-нодах запущен только маленький демон на Go.Им не хватает фичреквеста "а теперь перепишите и все остальное нормально" :)
Ай, это не то место, где это важно. Если бы на каждой билд-ноде столько жрало, это была бы проблема. А на один сервер гиг выделить - это что же за контора такая, где это вообще может быть проблемой, стоящей хоть минуты обсуждения? Та, которая дырокол в аренду берет?
Иди в дупу!
Если вы там здрасти мир! строгаете то да. А я летом обновил сервак с 8GB до 16GB и всё равно не скажу что летает :(
omnibus от GitLab, всё на SSD-ях.
Drone-CI вроде не жрет.
Увы, для очень непростых конфигураций, где один джоб запускает второй, передавая друг другу артефакты, а тот – третий, при этом матричный, оно не подходит от слова "совсем".
> Увы, для очень непростых конфигураций, где один джоб запускает второй, передавая друг другу артефактыВсё это есть в гитлабе. Матриц вот и правда нет.
> Ответ от LDAP-сервера может содержать сериализированный код,
> который будет выполнен в обход механизмов защиты.Значит, говорите, в пруду утка, в утке яйцо, в яйце жаба, в жабе LDAP, а в LDAP-е код... ух нифига себе сказочку завернули.
> А потом поставили себе GitLab и с удивлением обнаружили, что в нём есть чудесный CI. И всё у нас стало хорошопо сравнению с Jenkins еще мало что умеет, но активно развивается. Так глядишь и через пару тройку лет, можно будет заменить.
Сначала пусть руби рельсы
> Сначала пусть руби рельсыВыпилят
Нереально. :( Это будет новый - другой продугд :(