В корректирующих обновлениях платформы для организации совместной разработки GitLab 15.3.1, 15.2.3 и 15.1.5 устранена критическая уязвимость (CVE-2022-2884), позволяющая аутентифицированному пользователю, имеющему доступ к API для импорта данных из GitHub, удалённо выполнить код на сервере. Подробности эксплуатации пока не приводятся. Уязвимость выявлена исследователем безопасности в рамках действующей на HackerOne программы выплаты вознаграждений за выявление уязвимостей...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57672
[Удобство]\/[Безопасность]Хе. Чаша [Удобство] снова в приоритете.
опять ты
Где там удобство, диффы убого как в соснольке отображаются, когда во всех нормальных IDE графически.
покажи как надо
Открой idea, netbeans или smartgit - там как надо.
Не про удобство, вангую, эта история, а про деманд. Уж насколько подборка фич вызывает удивление, настолько писали не систему, а - откуда ветер подует, так и выйдет.А уж остальное приложилось т.к. иначе ну совсем нельзя.
То чувство, когда товарищи Гитлабовцы хотели удалять код из-за простоя...
Начинайте с себя!
Их главный предпочел коммитить в твиттер.
Тише, тише, а то ещё и эту ерунду туда притащат, вместо чего-то полезного.
Оно все также жрет памяти как прожорливая корова?
У тебя что там, пентиум 1 с 256 мб озу?
Это неважно. Важно то, что оно жрет память. Софт значит неоптимизирован
Манипуляция для дурачков.
Скажи что софт не оптимизирован - и создается впечатление что существует некая оптимизация которая позволит не жрать память...
Берете софт 20 летней давности и радуетесь "оптимизации" благодаря которой он "не жрет память".
Правда оно ничего не умеет. но разве это важно :) ?
> Берете софт 20 летней давности и радуетесь "оптимизации" благодаря которой он "не жрет память". Правда оно ничего не умеет. но разве это важно :) ?Если софт "20 летней давности" попытаются сегодня написать с нуля тем же "ничего не умеет" функционалом, потреблять он будет в разы больше. Нет, конечно, есть разработчики, которые таки предпринимают попытки в оптимизации, и даже получают сносный результат, но в среднем по больнице ситуация явно будет не в пользу софтостроителей наших дней.
Манипуляция для дурачков.
Выкидываешь Руби и берешь любой нормальный язык программирования и жор сразу же прекращается.
Манипуляция для дурачков.
Банишь анонимов и читаешь только нормальных комментаторов и в диалоге появляется смысл.
Манипуляция для дурачков.
Посылаешь нахер ыы читаешь нормально опеннетик.
"Ты мне так безразличен что я тебе обязательно отвечу" :)
Ну продолжай.. Продолжай.. :)
Откуда там у пентиумов 1 256 мб озу было? На 16MB win95/98 гоняли, 32 мб это уже почти буржуинство - win nt можно было относительно сносно гонять.
> Оно все также жрет памяти как прожорливая корова?У меня есть инсталляция, где я затюнил его нормально работать на:
- 2x CPU (Xeon / Cascadelake)
- 3 GiB RAM (+1 GiB swap)
- 25 GiB HDDЭто без раннеров, метрик-алёртов-графаны, с урезанным до одного потока веб-сервером, двумя потоками планировщика, стораджем для артефактов/регистри и бэкапами в s3. Память в среднем забита на 80%, своп на 65%; Диск забит на 35%, LA в районе 0.2. Работает шустро.
конфиг будет? ато пока только слова
> конфиг будет? ато пока только словаДа пожалуйста:
puma['worker_processes'] = 0
sidekiq['concurrency'] = 2
postgresql['shared_buffers'] = '256MB'
grafana['enable'] = false
prometheus_monitoring['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = falseДобавьте это в конец /etc/gitlab/gitlab.rb и будете наблюдать описанный мной результат.
а база на этом же серваке?
> а база на этом же серваке?Да. Можно вынести отдельно, сэкономит примерно 300 мб рамы. До 2 гб потребление не доведёт, так что с учётом того, что при заказе машин у провайдера память обычно квантуется по гигабайту, смысла в этом не вижу.
Вообще я не понимаю, что тут комментаторов удивляет. По официальной доке гитлабу нужно 4 гига рамы + 2 гига свопа, я затюнил его до 3 гигов рамы + 1 гига свопа, банально отключив лишний функционал и понизив количество потоков основных сервисов. Не рокет саенс.
А до тебя не доходит что сам факт того что надо что-то тюнить и есть доказательство жора.Почему gitea с drone столько не жрут?
> Почему gitea с drone столько не жрут?Потому что у них разная аудитория с разными целями. Гитлаб -- это коробочный продукт, который после установки сразу обеспечивает весь заявленный функционал. Гитея же -- это конструктор, где после установки вы подключаете нужный функционал по кусочкам самостоятельно.
> А до тебя не доходит что сам факт того что надо что-то тюнить и есть доказательство жора.
По той же логике, recommends в пакетах debian-а -- это тоже "доказательство жора" тогда. =)
Смотрите:
- Вот мы возьмём дефолтные настройки APT, и поставим evince. Очень много зависимостей прилетит, займёт много места. Зато сразу всё работает. Это -- подход GitLab.
- Или возьмём да отключим в APT установку Recommends. Поставим тот же самый evince. Места заняло мало, но он сможет работать только с dvi-файлами. А у вас в коллекции djvu и pdf. Придётся отдельно ставить пакеты с плагинами для них. А потом вы вдруг скачали epub. И опять что-то ставить надо. А потом вам друг скинул fb2. И по-новой. Это -- подход Gitea.На самом деле вполне очевидно, что это эти два подхода суть не более чем трейдофф между удобством и затратами.
--
У меня вот в дефиците время, а не ресурсы. Поэтому мой выбор очевиден. А какой подход больше устраивает вас -- решайте сами. Я лишь показал, что гитлаб может жрать меньше заявленного вендором. Достаточно ли этого для вас -- мне не ведомо, да и в общем-то безразлично.
> что сам факт того что надо что-то тюнить и есть доказательство жора.отключение неиспользуемого функционала - не тюнинг, и не жор, банальная экономия ресурса. Жор был бы тогда, когда отключив функционал, испытывал бы недостаток ресурсов. Тюнинг там только в процессных лимитах как я понял, но и с базой не ясно, что тюнил, что отрубил.
Тюнинг и жор. Зачем тогда всё это по-умолчанию то гитлаб включает?
> Тюнинг и жор. Зачем тогда всё это по-умолчанию то гитлаб включает?вот, отсюда надо взять 4Гб как утверждают гитлабовцы, завести систему из коробки не отключая ничего и проверить, жор будет или нет. Но как мне кажется в 4ГБ не в ходит ресурсы бд.
>> Тюнинг и жор. Зачем тогда всё это по-умолчанию то гитлаб включает?Так удобнее.
> надо взять 4Гб как утверждают гитлабовцы, завести систему из коробки
> не отключая ничего и проверить, жор будет или нет.Есть почти такая машина: 8 гигов рамы, 4 гига свопа. Конфигурация дефолтная: всё на одной машине. Во время пиковой нагрузки потребление 4.1 гигов рамы и почти 1 гиг свопа. С сервером одновременно работают ~70 пользователей, порядка 15 одновременных пайплайнов (раннеры, естественно, на отдельных тачках).
> По официальной доке гитлабу нужно 4 гига рамы + 2 гига свопа, я затюнил его до 3 гигов рамы + 1 гига свопа, банально отключив лишний функционал и понизив количество потоков основных сервисов.для одного проекта достаточно с максимальным числом пользователей не больше 5:)
> своп
> Работает шустро.Ты шутник или лжец?
Прикинь, не везде нужна быстрая память
Пример есть?
Я нашел еще одну уязвимость в gitlab. Она называется Git. В связи с этим имею 2 вопроса:
1. Когда устранят найденное мной безобразие?
2. Как я могу получить свое вознаграждение?
> отключить "GitHub"Интересное предложение.
Самое верное. И забыть про эти костыли.
Но ты конечно уже написал замену и естесственно выложил код? Линк же вот прям сейчас дашь да?
Не удивлен, что в этом мега комбаине будет уязвимость.