Опубликованы корректирующие обновления платформы для организации совместной разработки - GitLab 17.1.1, 17.0.3, 16.11.5, 16.10.8, 16.9.9, 16.8.8, 16.7.8 и 16.6.8, в которых устранены 14 уязвимостей. Одной из проблем (СVE-2024-5655), которая проявляется начиная с выпуска GitLab 15.8, присвоен критический уровень опасности. Уязвимость позволяет запустить работы в конвейере непрерывной интеграции (pipeline jobs) под произвольным пользователем. Выполнение своей работы в контексте другого пользователя позволяет атакующему получить доступ к внутренним репозиториям и закрытым проектам этого пользователя...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61445
Ну все переписываем с руби на го.
Точно на го?
Ну в следующей итерации будет с го на си, а потом с си на раст. Это нормально)))
influxdb переписывали с си на го, щас на раст.
> Точно на го?Можно на Java или производных (kotlin). Выбор языков для бэкенда, если сходу исключить эшельбе-пашальбе-похапе, весьма невелик.
Ссылка на собстна сам CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2024-5655
Речь же про user gitlab а не user воркера, где выполняется сборка ?
А то первый мой вопрос после прочтения заголовка,
"Блин да как они находят такие лазейки ? "
А у меня блин как эта компания с корнями из СНГ так умудряется вставить лазейку что её находят.
Они не лазейку ставят. Это действительно ошибки, стимулированные культурой разработки.Например, при работе с регулярками у них был один недоделанный вариант, потом стал другой неполный.
Т.е. они в угоду запроса на фичи пилят туда, куда деньги тянут, а остальное и остальные страдают.
Всегда был продукт без нужной гибкости, без нужного, но с удобным интерфейсом для хомячков. Увы: интефейс Ок, внутренности не к делу.
> Всегда был продукт без нужной гибкости, без нужного, но с удобным интерфейсом для хомячков.Что за бред?
> они в угоду запроса на фичи пилят туда, куда деньги тянут, а остальное и остальные страдают.
Такое ощущение что вы вообще не знаете что такое приоретизация задач.
Если что-то нужно 1% аудитории, а что-то 99%, то буду делать второе.
За исключением тех случаев, когда этот 1% даст больше профита. Но как видим - нет))> без нужной гибкости, без нужного
Какой гибкости? Нужное кому? Полутора зapoтaм?
> но с удобным интерфейсом для хомячков
Интерфейс должен быть удобен для большинства.
И если меньшинству хочется прдлтся с TUI или чем-то подобным - то это их дело.
> Интерфейс должен быть удобен для большинства.Это не всегда работает. Может быть множество мелких групп, у каждой свои запросы к интерфейсу, и для каждой есть блокирующий запрос, который не позволяет им пользоваться продуктом. Таким образом, может оказаться, что ориентируясь на "большинство" ты игнорируешь большинство. Что хуже, ты будешь слышать преимущественно голоса тех, кто уже пользуется твоим продуктом, а это значит что ты будешь заниматься фичами, которые не столь критичны (люди ведь пользуются продуктом несмотря на отсутствие этих фичей, так?), в ущерб фичам, которые для кого-то критичны настолько, что он даже не рассматривает возможность пользоваться твоим продуктом.
Прогибаться под юзверей и делать как они просят -- это та самая дорога в ад, которая была выстлана благими намерениями. Даже если тебе при этом кажется, что ты максимизируешь прибыль. Максимизация краткосрочная, в долгосрочной перспективе тебя ждёт вытеснение в какую-то узкую нишку, а со временем и схлопывание этой нишки, потому что конкуренты, кто работал над тем, чтобы как можно больше клиентов привлечь, могут предоставить твоим пользователям всё то же, что и ты, плюс ещё сверху ништяков.
Это та самая причина, почему методы статистических исследований должны преподаваться в любом ВУЗе. В частности в этом курсе должна разбираться Against Prediction, поскольку эта книга в принципе нацелена на разбор тех граблей, на которые можно наступить если свою деятельность направлять статистикой.
> который не позволяет им пользоваться продуктомЗначит это не пользователи, а только потенциальные пользователи.
И вот далеко не факт, что исправив их "блокирующий запрос" они начнут пользоваться продуктом, а не начнут докидывать хотелки. Мы же не хотим "прогибаться под юзверей"))> люди ведь пользуются продуктом несмотря на отсутствие этих фичей, так?
Так. Но потом кто-то это сделает и они перейдут к нему.
> Прогибаться под юзверей и делать как они просят -- это та самая дорога в ад, которая была выстлана благими намерениями.
Должен быть баланс.
- Если ты будешь забивать на текущую аудиторию - ты ее потеряешь.
- Если ты будешь игнорить запросы потенциальных пользователей - то не будешь привлекать новую аудиторию. Вопрос насколько эти пользователи потенциальные, а не просто мимокрокодилы - оставим за скобками.
- Если ты начнешь удовлетворять всяких маргинальные хотелки - то ты погрязнешь в сложности поддержки, потому что тянуть N интерфейсов или M реализаций фичей, особенно если они не атомарные, а влияют друг на друга, тот еще адок. Ты получишь напр. +0,1% новых юзеров и потеряешь 1% старых, потому что ты перенаправил ресурсы на неприоритетное направление. А текущим юзерам ждать надоело.Приходится искать какое-то парето-оптимальное решение.
> потому что конкуренты, кто работал над тем, чтобы как можно больше клиентов привлечь
Которые в такой же ситуации как и ты. У них точно также ограниченные ресурсы. И им также нужно приоритизировать задачи.
И пока они буду удовлетворять хотелки меньшинств - я реализую хотелки большинства и уже получу от них профит в виде максимального охвата аудитории/рынка. А вот потом уже имея ресурсы буду закрывать другие хотелки.
А у них ресурсов будет меньше просто потому что меньшинство на то и меньшинство.
> Приходится искать какое-то парето-оптимальное решение.Да, на основании анализа хотелок всей потенциальной клиентуры, с учётом того, что там у конкурентов происходит, и всё это дело выливается в какую-то сложную стратегию, включающую как активные элементы так и реактивные.
Но я о другом, что если стратегия сводится к удовлетворению потребностей тех, кто уже у тебя, то это провальная стратегия.
> А у них ресурсов будет меньше просто потому что меньшинство на то и меньшинство.
Да, у github'а, например, будет меньше ресурсов, потому что майкрософт будет же жидиться как может, так?
Ты видимо не интересовался тем, как всякие Uber'ы уничтожали уже сложившиеся таксопарки, работая себе в убыток на деньги инвесторов, да? Или основные претензии к Китаю от США, по поводу электромобилей в том, что Китай субсидирует все эти разработки, и китайский автопром имеет возможность продавать конечную продукцию по ценам ниже себестоимости.
Или любимое на опеннете противостояние ff и chrome: chrome разрабатывается гуглом, как вспомогательный инструмент для того, чтобы контролировать web и рынок рекламы, и mozilla может хоть как там мухой на стекле выёживаться, она всегда будет аутсайдером. И дело вовсе не в количестве пользователей, количество пользователей это в частности результат политики гугла, который, например, последовательно ломает свои сервисы для ff, который предустанавливает хром на мобилах.
Не надо полагаться на то, что все в равных условиях, мир не справедлив, и об этом не надо забывать никогда.
Я вообще не понимаю, как можно сравнивать "10 юзеров попросили фичу А" и "100 юзеров попросили фичу Б"! Дело-то ВООБЩЕ НЕ В ЦИФРАХ! В первую очередь разраб должен думать о самих фичах и их перспективности, а не сколько хомячков её просят. Может так статься, что он вообще напишет фичу "Ц", которая будет объединением А и Б + что-то перспективное. Никогда нельзя идти на поводу у статистики - сначала думать, а только потом решать, что именно надо написать.
Если что-то нужно 1% аудитории, а что-то 99%, и этот 1% платит, а те 99% - нет, то буду делать то, что нужно 1%.
Эм... там именно так и написано:
"За исключением тех случаев, когда этот 1% даст больше профита."
А если 99% тоже будут платить, но меньше чем 1%, то тоже сделают, возможно как эксклюзив для 1%.
> Если что-то нужно 1% аудитории, а что-то 99%, и этот 1% платит,
> а те 99% - нет, то буду делать то, что нужно 1%.Давай стразу договоримся считать юзеров (даже потенциальных) тех кто деньги платит.
Остальные - это просто нахлебники с небольшим процентов конвертации (в некоторых отраслях 5% считается манной небесной)
Извини, но "use" - это "пользоваться", а не "платить".
> они в угоду запроса на фичи пилят туда, куда деньги тянут, а остальное и остальные страдают.Так если не будет
фич -> не будет денег
не будет денег -> не будет разработки
(вообще какой либо, то что так полтора ўасяна напрограммят не считается)
не будет разработки -> пострадают все
не будет дворца -> не будет дворца (с)
Вот что происходит, когда доверяешь свою репу каким-то некомпетентным ребятам.
А не серьезной компании типа гитхаба.
И сколько людей поверили мантрам и пошли хранить код к бракоделам?
Надеюсь это станет для них уроком.
Что то на рубях, что это. А значит, культура разработки соответствующая (индусы либо румыны пинают полуразложившееся легаси с традиционными песнями и плясками), и дыр плюс-минус столько же.
> серьезной компании типа гитхабаТак толсто, что аж тонко. Зачот.
Хм... относительно недавно была новость за сентябрь 2023
"Критическая уязвимость в GitLab, позволяющая запустить pipeline-работы под другим пользователем"
opennet.ru/opennews/art.shtml?num=59782И тут опять /_-
Они вообще ничему не учатся?
У них просто нет времени точить пилу, всё время уходит на пиление
> подстановка JavaScript-кода (XSS) в примечаниях к коммитамзачем запускать примечания? это же просто текст!
В рамках HTML можно запустить любой элемент страницы (при недостаточно хорошем экранировании).
Так ведь раннер запускается не от рута, а значит не может сменить пользователя на произвольного в общем случае.
Ой, блин, щас глянул: от рута =)
не думаю, что это вообще связаноскорее всего пострадали только шареные ранеры, суть в том, из под какого юзера ты код забрать можешь, а не локальный юзер на билд сервере