В реализации команды "go get (https://golang.org/pkg/cmd/go/internal/get/)", предоставляемой штатным интерфейсом командой строки для языка Go и используемой для загрузки пакетов и связанных с ними зависимоcтей, выявлено несколько уязвимостей (https://seclists.org/oss-sec/2018/q4/254), позволяющих выполнить код при обработке специально оформленных пакетов, подготовленных злоумышленниками. Проблемы устранены в корректирующих выпусках Go 1.11.3 и 1.10.6.
Первая уязвимость (https://golang.org/issue/29230.) (CVE-2018-16873 (https://security-tracker.debian.org/tracker/CVE-2018-16873)) проявляется при выполнении команды "go get -u" и прямом импорте модулей в режиме GOPATH. Атака сводится к созданию в модуле импортируемых путей, заканчивающихся на "/.git", которые воспринимаются при вызове "go get -u" как корень репозитория с последующим выполнением в нём команд git. Выполнение кода организуется через размещение вредоносных команд в прикреплённом к репозиторию файле конфигурации git;
Вторая уязвимость (https://golang.org/issue/29231) (CVE-2018-16874 (https://security-tracker.debian.org/tracker/CVE-2018-16874)) позволяет при выполнении команды
"go get" выйти за пределы определённого для модуля корневого пути, через манипуляцию с фигурными скобками в импортируемых путях. Проблема проявляется только в режиме GOPATH и не затрагивает появившийся в Go 1.11 (https://www.opennet.ru/opennews/art.shtml?num=49183) экспериментальный режим модулей (https://golang.org/cmd/go/#hdr-Module_aware_go_get). При помощи данной уязвимости атакующий может перезаписать произвольные файл в ФС, насколько это позволяют текущие полномочия.URL: https://seclists.org/oss-sec/2018/q4/254
Новость: https://www.opennet.ru/opennews/art.shtml?num=49787
1.11.3 ломает go get. Но уже есть 1.11.4, в котором обещали исправить go get.
Вот что происходит, когда смешивают систему сборки и пакетный менеджер.
maven
Им собирают, как правило, то, что ни с какими нормальными пакетными менеджерами не дружит и дружить не должно - либо ынтырпрайзный софт либо андроидный, и там и там подход "всё своё тащу с собой, за обновлениями идите к разработчику, и хрен вам а не самостоятельное обновление зависимостей". Плюс монструозное и детальное поисание всего и вся, на что готов сильно не каждый.С Go этот подход попытались протащить туда, где пакетные менеджеры есть, да ещё обеспечить удобство работы с пакаджами. А оно так не работает - либо ты описываешь всё детально и имеешь простыни либо делегируешь задачу тому, для чего она первоочередная - как установка пакетов для дистрибутива/пакетного менеджера. А подход "сделаем впридачу к языку, и чтобы оно было всё волшебно и удобно" не взлетает - угу, начиная с того самого leftpad.
> Им собирают, как правило, то, что ни с какими нормальными пакетными менеджерами не дружит и дружить не должноВот это, кстати, конкретнейшая проблема. Надо Михаила спросить про текущее состояние интеграции с языковыми пакетными менеджерами. В Альте была движуха год назад, но, кажется, воз и ныне там.
Посмотрел список рассылки - интересная идея от manowar@altlinux.org - плагины к apt.Но, в любом случае, там не проведён анализ экосистем языков. Так что прокакие-то телодвижения говорить ещё очень рано.
Единственная нормальная интеграция - использовать системный пакетный менеджер. Потому что когда сразу 5 программ делают одно и то же по смыслу, результатом становится закономерный бардак и потеря контроля над процессом.А у хипстоты с новоязами к тому же есть большие проблемы с пониманием азов безопасности.
Там сложный сисадминско-административный вопрос: как наладить взаимодействие с языковыми репозитариями так, чтобы тратить как можно меньше времени и делать это минимально чeрeзжoпнo.
С каких пор он стал "пакетным менеджером"?
> Вот что происходит, когда смешивают систему сборки и пакетный менеджерНе-не!
Это происходит когда думают что ЯП заменит безопасность.
> Это происходит когда думают что ЯП заменит безопасность.Кроме Вас так никто не думает. Да и Вы так не думаете. На (условно)безопасном языке всегда можно написать небезопасные алгоритмы, небезопасную логику. Но овно на вентилятор надо вбросить, верно, братец-аноним?
Вот на это овно, братец, половину и ловят при раскрутке платформы.
Та было с го, дотнетом, жабой,..
Это уже потом "ну вы же не думали, что..".
А не ты ли, братец, этот вентилятор раскручивал? За мзду малую, а? :D
> Это уже потом "ну вы же не думали, что..".До Вас не дошло, братец. В отличие от Вас, все сразу понимали и знали, где "грабли зарыты" в "безопасных языках". Всем (кроме Вас) изначально было понятно, что если в "безопасном языке" в программном блоке перед "бесконечным циклом" Вы выделите гиг памяти под массив, обработаете его, не "обнулите" ссылку, а в последующем цикле он Вам уже нафиг не нужен (мало ли, Вам только хэш нужен был от массива) - то получите аналог "утечки памяти". Но Вас ведь надо носом в такое тыкать?
> Всем (кроме Вас)хорэ врать! Тут народ только этим и занимается. В любой новости об уязвимостях в проектах на С/С++.
И "прозревает" (прям как вы сейчас) во всех остальных.
Начиная с аксакала Айзена. :D
Объясните кратко, какие профиты даст переход с 1.9 на 1.11.4?
>появившийся в Go 1.11 экспериментальный режим модулей
Новые SIMD инструкции и как обычно GC был сильно оптимизирован.
исправление уязвимостей и багов с версии 1.9 до 1.11?
А я то думаю, почему половина софта на GO в контейнерах собирается... Знали, видимо.
Нет. Просто неосиляторы.
Ну ниче, с go mod теперь не нужно осваивать bash и способы установки GO_PATH, теперь можно и вылазить с контейнеров и билдить всесь go-внософт на хост системе.
s/с контейнеров/из контейнеров/
граммарнаци негодуэ
GO_PATH это шо таке?
Сам-то видимо осилил по-сложнее "Ehlo world" написать
Проверил, ваш сниппет не работает :(
А есть ещё отсталые которые собирают не в контейнерах? Печаль...
s в слове docker stands for 'S'security, ага. И в rkt/lxc тоже, если что. Собирайте-собирайте.На самом деле, разумеется, это делают для того, чтобы не выгребать потом тонны мусора из своего home, и чтоб еще и запускалось не только там же где этот home есть.
>и чтоб еще и запускалось не только там же где этот home есть.Скомпилированному файлу накакать на home...
Т-с-с-с-
А говорили что такое только на C или PHP может быть, а Go — безопасный, хм.
Безопасный ЯП это что-то интересное... это как безопасный секс?
Тоже самое про Rust говорят. С нетерпением жду когда у фанатиков подгорит от найденых уязвимостей. Oh, wait, они уже есть! Любой низкоуровневый код без дериктивы unsafe не работает.
Не могу говорить за всех фанатиков, но я, как один из них, абсолютно нормально отношусь к уязвимостях, находимым в моём языке / его экосистеме. Это, конечно, не офигеть как хорошо, но и смертельно; доказумо идеальный код в реальном мире писать невозможно, и руст, конечно же, не исключение.
Идеальный код exist :)> echo 'Hello world';
согласен идеальный вариант. не подкопаешься.или на питоне: print('Hello World')
на С:
main()
{
printf("Hello World\n");}
пишем все. кто на чем. хочу на дельфях глянуть)))
Вы правда хотите чтобы все отсюда:https://esolangs.org/wiki/Hello_world_program_in_esoteric_la...
попало сюда ?
О мой мозг! :)
Это восхитительно!
Monkeys
1 RIGHT
1 RIGHT
1 RIGHT
1 RIGHT
1 RIGHT
1 RIGHT
1 DOWN
1 DOWN
1 LEFT
1 LEFT
2 LEFT
2 UP
2 RIGHT
2 LEFT
2 DOWN
2 UP
2 RIGHT
2 LEFT
2 DOWN
2 RIGHT
2 BOND
1 YELL
1 LEFT
1 LEFT
1 UP
1 UP
1 LEFT
1 LEFT
1 UP
1 UP
1 LEFT
1 DOWN
1 DOWN
1 LEFT
1 UP
1 UP
1 LEFT
1 DOWN
1 DOWN
1 RIGHT
1 DOWN
1 LEFT
1 TEACH
1 DOWN
1 RIGHT
1 UP
1 UP
1 UP
1 RIGHT
1 DOWN
1 DOWN
1 DOWN
1 DOWN
1 UP
1 RIGHT
1 RIGHT
1 DOWN
1 DOWN
1 TEACH
4 YELL
1 RIGHT
1 RIGHT
1 DOWN
1 DOWN
1 DOWN
1 LEFT
1 YELL
1 YELL
1 LEFT
1 LEFT
1 LEFT
2 LEFT
2 DOWN
2 RIGHT
2 UP
2 UP
2 LEFT
2 LEFT
2 LEFT
2 DOWN
2 DOWN
2 DOWN
2 RIGHT
2 RIGHT
2 RIGHT
2 RIGHT
2 UP
2 UP
2 UP
2 LEFT
2 LEFT
2 DOWN
2 RIGHT
2 YELL
3 YELL
1 YELL
1 RIGHT
1 RIGHT
1 RIGHT
1 YELL
4 DOWN
4 TEACH
4 DOWN
4 DOWN
4 DOWN
4 DOWN
4 DOWN
2 RIGHT
6 LEFT
6 DOWN
6 RIGHT
6 UP
6 UP
6 LEFT
6 DOWN
6 RIGHT
6 YELL
4 YELL
2 YELL
> согласен идеальный вариант. не подкопаешься.
% echo "Hello" >> /dev/full
echo: write error: no space left on device
>или на питоне: print('Hello World')
% python -c "print 'helllo'" >>/dev/full
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
;-)
>> согласен идеальный вариант. не подкопаешься.
>
> % echo "Hello" >> /dev/full
> echo: write error: no space left on device
>
>>или на питоне: print('Hello World')Вот правда, как в жизни, была нормальная программа, пришли, доработали и пипец, а ведь в начале все работало...
и не говори . кто их просил в /dev отправлять)))
> Это, конечно, не офигеть как хорошо, но и смертельноДолго завис на этой фразе
> А говорили что такое только на C или PHP может быть, а Go — безопасный, хм.Вы неверно услышали, что говорили. Или не уловили суть данных двух уязвимостей. На безопасном языке можно запросто написать небезопасный алгоритм. А вот по невнимательности обратиться к освобожденной области памяти в C легче чем в Go.
Ну нормально, и этим пришла очередь по граблям походить... Закономерный этап.
а может sysvinit на rust переписать?
rustinit? ох уж эти любители суперегероев от корпораций))))
sysrust, тогда уж.
sysirust, тогда уж.