Наш третий GitLab Саммит, прошел на этот раз в Остине, штат Техас, и мы выпустили наш 54-й релиз 22-го числа, несмотря на воскресенье. GitLab 8.8 готов к работе с улучшенным GitLab CI, повышенной производительностью, удобными шаблонами и многим другим.
Самой ценной персоной (MVP) этого месяца является Мэтт Оукс, за вклад в работу по скрытию текстового файла различий, по-умолчанию на ветке с .gitattributes.
Спасибо Мэтт!
В самом начале 2010 года Vincent Driessen пишет отличную статью A successful Git branching model. Для понимания того, о чем пойдет речь дальше, со статьей нужно, конечно же, познакомиться. А для тех, кому сложен язык оригинальной статьи, на хабре есть её отличный перевод.
С этого момента описанная модель ветвления GitFlow, начинает, что называется, расходиться по миру. Её берут на вооружение многие команды. Авторы пишут много статей об успешном её использовании. Она получает поддержку в большинстве инструментов, которые используют разработчики:
Кажется, что модель идеальна. Быть может так оно и есть, если у вас небольшая команда, неизменяемый скоуп релизов, высокая культура работы с VCS. Тогда, действительно, GitFlow может и удовлетворит все ваши потребности. Но, к сожалению, описанные условия подходят не всем командам и не всем проектам. К слову, найти статьи, в которых бы авторы описывали проблемы этой модели не так уж и просто даже в 2016 году. Но как мы все знаем, серебряной пули нет, а, значит, и в этой модели всё хорошо далеко не для всех.
Фонд свободного программного обеспечения (FSF) и проект GNU опубликовали результаты проверки четырёх сервисов для хостинга кода на соответствие этическим принципам GNU — прежде всего, это соблюдение конфиденциальности и свободы информации.
Проверялись сервисы Savannah, Gitlab, Github и Sourceforge.
В итоге, каждый сервис получал одну из следующих оценок:
F — неприемлем для хостинга.
C — соответствует всем базовым критериям, приемлем для хостинга.
Читать полностью »
С ростом компании меняются люди и проекты. Не так давно в блоге GitHub появилась интересная статья, в которой автор рассказывает, как делать, а как лучше не делать Pull Request’ы. Перевод, традиционно, спрятан под катом.
Доброго времени суток.
Я работаю Ruby разработчиком в стремительно растущей IT-компании. И вот однажды нами было принято стратегическое решение смены сервиса для работы с Git. Всех, кому интересно, прошу под кат.
Исследователь информационной безопасности Лаел Целлье (Laël Cellier) обнаружил две критические уязвимости в клиенте и серверной части Git (CVE-2016-2324 и CVE‑2016‑2315).
Воспользовавшись ими, злоумышленники могут осуществлять удаленное выполнение кода. Для этого необходимо создать репозиторий с деревом файлов с очень длинными названиями, а затем отправить «пуш» на удаленный уязвимый сервер или позволить уязвимому клиенту осуществить «пулл».Читать полностью »
Так сложилось, что для ведения проекта не хватало обычного GitHub или GitBucket. Оснавная причина в хранении и контроле версий больших бинанрых файлов psd, 3dsmax и других. На самом деле вариантов решения масса, можно например было использовать Облачный диск или git Large Files System, представленный GitHub. Но взвесив все плюсы и минусы разных подходов к организации, мы пришли к связке GitLab + redmine.
Я не думаю, что есть смысл описывать продукты, я лишь приведу основные достоинства, которые подтолкнули нас на этот выбор.
Основные плюсы GitLab:
Также оба проекта Open Source.
Читать полностью »
При эксплуатации системы GitLab CE на своем предприятии (имеющему большую филиальную структуру), была обнаружена уязвимость, которая может привести к получению полного доступа к аккаунту любого пользователя системы администраторами филиалов предприятия.
Проблема выявлена в подсистеме LDAP-аутентификации пользователей. Дело в том, что основной сущностью, с использованием которой происходит авторизация в GitLab является E-Mail пользователя. Однако при входе пользователей в GitLab с использованием LDAP процесс аутентификации/авторизации происходит следующим образом:
.
В результате, например, «нехороший» системный администратор «филиала A», может используя свои полномочия, к примеру в Active Directory, создать в своем OU «Филиал А» любого пользователя (например hackuser) и записать в его LDAP-атрибут MAIL адрес электронной почты пользователя любого другого филиала, на который даже не распространяются полномочия этого администратора. После этого «нехороший» администратор «Филиала А» может авторизоваться пользователем hackuser в системе GitLab, при этом в результате авторизации будет получен полный доступ к аккаунту пользователя, имеющего адрес электронной почты установленный «нехорошим» администратором для hackuser.
Читать полностью »
Доброго времени суток. У меня есть маленький подручный сервер, который используется как git сервер для показа клиенту проекта и т.д. Сервер работает на операционной системе Slackware v.13.1.0, семейства linux. Почему не Debian или Ubuntu — так исторически сложилось. Для просмотра git репозиториев я использовал cgit. Недавно возникла необходимость начать использовать GitLab. Если интересно — добро пожаловать под кат.
Читать полностью »
14 июня (суббота) 2014 — пройдет крупнейшая конференция по Ruby, PHP, Python,JavaScript, Android
62 доклада от авторов языков, баз данных и экспертов в WEB-разработке!
Впервые в России нам удалось собрать авторов MySQL, PostgreSQL, Percona Server, Sphinx, Tarantool в отдельном потоке DevConf::Storage — по сути это отдельная конференция по современным БД.
Поток Ruby насыщен актуальными темами, который обязан знать каждый Ruby-разработчик
