SVN exploit

[kika]

По-моему в этой истории самое интересное - не сам эксплойт (он-то как раз довольно скучен, в смысле hack value) а тот факт, что в такой массе (крупных!) компаний совершенно отсутствует понятие релиз-менеджмента. Делают просто svn co в корень сайта и понеслось.
Фактическая statelessность HTTP протокола сыграла с индустрией злую шутку in da long run.

Comments

[xfyre.livejournal.com]

я тебе по большому секрету скажу, что даже там, где понятие релиз-менеджмента присутствует, процедура выкатывания релиза как раз таки и заключается в svn co в корень сайта. там где работать умеют чуть лучше - умеют вместо co делать export.

меня намного больше удивило, что такому количеству админов неочевидно обязательное наличие в конфигурации Deny from all на все что матчится с CVS|\.svn

[rblaze.livejournal.com]

Это совершенно необязательно. Ничего матчащегося с CVS/svn и вообще не предназначеного для выдачи клиенту/интерпретации в дереве просто не должно быть. На всякие deny рано или поздно обязательно найдется эксплойт с достаточно мощной резьбой.

[dmzlj.livejournal.com]

если это пэхэпэ сайт, то там уже лежат исходники.

[kika.livejournal.com]

Илья, ты чего? checkout - это операция создания РАБОЧЕЙ КОПИИ! Какая в жопу рабочая копия в корне сервера?
Даже в нашей микрокомпании выкатывание чего-либо на боевые машины делается RPMом. Хотя конечно я понимаю, что такие релиз-менеджеры в spec добавят не список файлов для релиза, а корневую директорию проекта, их наверное и RPM не спасет.

[xfyre.livejournal.com]

да меня-то зачем агитировать, мне это как раз очевидно. freebsd package manager можно так же использовать.

мне интересно - более человеческого для юниксов ничего не придумали? помимо rpm и pkg_add? и так чтоб везде работало?

[anatolix.livejournal.com]

Не вижу трагедии особой в co. В Яндексе например верстка именно так и выкладывается. Из отдельного репозитария специально для верстки. Ничего секретного там нет. Если у тебя развесистая верстка, то co лучше т.к. выкладывает 2 изменившихся файла, а не все дерево. Опять же в случае если какой-нибудь #удак с рутом файлик поправит прямо на сервере это будет видно при следующей выкатке. Ну подумаешь хакеры утащат makefile который 10 css-ов в один склеивает.

Все программы у нас естественно выкладываются тоже собранные - в *.deb или бинарник хотя бы.

[kika.livejournal.com]

Ничего секретного там нет.

Пока нет.

Если у тебя развесистая верстка, то co лучше т.к. выкладывает 2 изменившихся файла, а не все дерево.

rsync *.rpm делает тоже самое и даже лучше. Он может выложить 2 изменившихся байта :-) И я в этом месте не понял - Яндекс экономит на трафике?

Опять же в случае если какой-нибудь #удак с рутом файлик поправит прямо на сервере это будет видно при следующей выкатке.

rpm -V

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

[anatolix.livejournal.com]

(не в ту ветку в первый раз написал)

Почему пока - что секретного может быть в коде который пользователю весь отдается?

rsync rpm тебе только rpm скачает - его же еще ставить надо, что все файлы перепишет. Плюс rpm гзипованный - там нифига не 2 байта меняются при смене одного файла.

Яндекс экономит на времени раскладки релиза. Если тебе нужно выкатить верстку на 300 морд, чтобы чтобы они все не были одновременно в ауте это может занять некоторое время.

[kika.livejournal.com]

Почему пока - что секретного может быть в коде который пользователю весь отдается?

Там могут быть скрипты, в них пароли, структура базы или любая другая информация, напрямую юзеру не отдающаяся. Суть релиз менеджмента тут заключается не в наличии как такового RPM'а, а в том что возникает формализованная стадия формирования выходного продукта и в процессе разработки возникает стадия согласования "вот это мы отдаем на морду, а это нет".
Duct tape programmer по Джоэлу не только работает изолентой, но он еще и избыточно умный, что позволяет ему срезать углы. В Яндексе это не так - изолента есть, но при этом остаются .svn директории. Моя точка зрения заключается в том, что не надо применять изоленту там, где под рукой есть термоусадка и тепловой пистолет. Углы делятся на те, которые имеет смысл срезать и те, выигрыша от срезания которых практически нет.

Яндекс экономит на времени раскладки релиза. Если тебе нужно выкатить верстку на 300 морд

I feel being played. Релиз менеджмент в данном случае заключается в установке 301-ой морды, на которую накатываются релизы и с которой все клонируется на 300 боевых морд по расписанию rsync'ом, unison'ом or чем-нибудь еще.

[itman.livejournal.com]

Да-да-да... какой красивый метод инсталляции. Я писаю кипятком.

[anatolix.livejournal.com]

Да ладно... если бы ты знал или умел что-то лучше...

[dil.livejournal.com]

может, всё-таки up, а не co?

[anatolix.livejournal.com]

да конечно.

[itman.livejournal.com]

Кстати, по теме. Еще бы, это ведь так дорого и муторно. Нужно фиксировать релиз, нужно делать бинарники и прогнять их через QA. А так вжик и готово! Сколько времени экономится, блин!

[lionet.livejournal.com]

Если я посоветую курить про разные бранчи, в том числе бранч для оттестированного, прогнанного через QA кода, меня пошлют ведь, да?

[itman.livejournal.com]

Ты скажи, неужели ты все, что лежит в репозитории вываливаешь на сервер? И бинарники ты тоже кладешь в репозиторий?

[lionet.livejournal.com]

1. Нет, не всё, что в репозитории. Только то, что в релиз-бранче.
2. Нет, бинарники не кладу.

[itman.livejournal.com]

То есть ты хочешь сказать, что сначала делаешь специальный бранч, куда копируешь только то, что нужно?

[mikedin.livejournal.com]

а вот тут уже я не очень понял :)

если с вываливанием мне еще понятно, то не объясните что плохого в выкладывании бинарников в репозиторий?
у нас в свое время было именно так. да, репозитории были большие, но собрать второй раз давний спец-релиз так, чтобы подхватились отладочные символы при отладке, как показала практика, не получалось.

если что - это был msvc, но что-то мне подсказывает, что дело не в нем...

[itman.livejournal.com]

В аду за это жарить точно не будут. Репозиторий просто для этого не предназначен. Репозиторий он для ведения системы версий, сравнения исходников разных версий, итд... А если чекаут нужно по сети делать, а там гиги этих бинарников?
Релиз один раз сложили и до свидания. Это можно и без репозитория сделать. Сложить в любой каталог, который бэкапится. Разделив по версиям предварительно.

[dmzlj.livejournal.com]

А если нет бинарников? Поломали то апачистов-пхп-шников в первую очередь. Потому как такой там подход и настройки сервера по-умолчанию.

[itman.livejournal.com]

Совсем-совсем нет бинарников?

[gorinevski.livejournal.com]

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

Это даже не про релиз-менеджмент, а про билд-менеджмент и деплоймент. Говно не должно попадать куда попало в принципе. Для этого можно разным пользоваться, не суть.

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

[kika.livejournal.com]

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

[gorinevski.livejournal.com]

Подумаешь, бином Ньютона :) Админ должен был знать, как деплоят и что .svn всюду. Т.к. деплоить должны через него.