Исправления безопасности в языке Go

Билдь на GCC/LLVM LTO, профилииуй, используй sync.Pool. Go работает медлено только в кривых руках. Goawk (скомпилированный стандартными средствами) по некоторым тестам превосходит gawk.

когда я начинал он был популярным

4.2 лютейнее же, на питоне «быстрее» не бывает

Что, правда зуб даёшь? :)

Ну тады придётся извлекать...

https://www.nexedi.com/NXD-Blog.Multicore.Python.HTTP.Server

Ты че шаблоны рвёшь людям? Тут в головах аксиома, что питон мега тормозной, прям как черепаха в квадрате, некоторые особо одаренные верят, что даже bash быстрее. А всё почему? Потому, что питон скриптота, а скрипты у них по определению не могут быть быстрее компилируемого статически типизированного кода, иначе зачем они тогда учат Go/Rust/Java?

Компилируемый питон это как рэперы в думе. Желание присосаться к трендам есть, а желания менять систему нет. Прямо hip-hop для php

Ололо, ты ещё RPython и сишные биндинги мне покажи. Допустим быстро, ок. Только при чём здесь собственно питон?

А что собсна не так? Cython - язык со статической типизацией, транслируется в сишечку, скорость - приблизительно в 2 раза медленнее C. При этом полностью совместим с тем, что сейчас написано на питоне. Если хочется кроссплатформенность как у Java - есть PyPy, который генерирует байт-код, сравнимый по скорости с жабой. Но он совместим только с версией 3.5 и не все там работает, также проблемы с оффтопиком (слава богу не наоборот).

Мне вот просто делать нечего было и я гонял тесты всего этого. Кстати PyPy в режиме интерпретации не во всех местах обогнал LuaJIT.

Исходники бенчмарков есть, а вот зайдешь на сайтик - а там инфа трехлетней давности, поэтому самому надо :D

We wrapped LWAN with Cython into a Python module. The end result is not pure Python code and contains C

ну и, при чем тут питон? Биндинги для сишной либы можно написать и на Go, а тот факт, что Go медленнее C, вообще-то никем никогда не отрицался

А что собсна не так? Cython - язык со статической типизацией

А что так? Паскаль тоже язык со статической типизацией. Дьявол в деталях. А деталей там мама не горюй. Возьми любой современный ЯП. Там тебе и пакетный менеджер и системы сборки и поддержка IDE и прочие околоязыковые инструменты. Плюс сам язык: ты сравниваешь типизированную нашлепку поверх питона с ЯП, которые изначально создавались как статически тпизированные. Естественно первый проиграет по всем пунктам

Призываю всех жертв маркетинга переходить на crystal - та же тема, только на базе нормального скриптового языка (ruby). С полной поддержкой его божественного синтаксиса.

И это в то время как мажорный релиз пыха выходит на лоре мини-новостью.

мажорный релиз пыха это скорее повод воскликнуть «да когда же оно сдохнет!», чем писать об этом большие новости :(

Потому, что питон скриптота, а скрипты у них по определению не могут быть быстрее компилируемого статически типизированного кода, иначе

Иначе это обертки вокруг сишных либ, а не скрипты. Питон (в широком смысле) на 90% состоит из таких оберток. Поэтому все быстро, до тех пор пока быдлокодер не начинает фигачить реализации алгоритмов с быдлокодерской сложностью на самом питоне. Тогда все резко превращается в тыкву, и мы получаем дичайшие непредсказуемые тормоза и жор в самых неожиданных местах.

Точнее, скрипты это и есть дерганье готовых компонентов. И пока на недоязычке пишут только скрипты, все нормально. Как только кодеры поверят в мантру про «язык общего назначения», начинаются проблемы.

А не так собственно вот в этих фразах с https://www.nexedi.com/NXD-Blog.Multicore.Python.HTTP.Server:

However, all experiments we are aware that rely on Cython for system programming fail short in at least two ways:

1. as soon as some Python code is invoked (as opposed to pure Cython cdef code), performance degrades by one or two orders of magnitude;

2. benchmarks are most of the time provided for single core execution only, which is somehow unfair considering Golang's ability to scale up on multiple cores.

The first issue is related to Python's Global Interpreter Lock (GIL) and its highly dynamic nature. It will probably never change much. In a nutshell, the GIL prevents many forms of parallelism in Python and it can also degrade performance.

То есть авторы сами признают, что только в синтетических лабораторных тестах в «вакууме» иногда и бывает быстро.

ИМХО. не программист на go, но насколько я знаю их систему сборки, выкачивается из git репозиториев и собирается всё, что указано в зависимостях. И даже у примтивных проектов дерево зависимостей идёт на десяток реп. В такой ситуации компрометация любого репозитория приводит к глобальной жопе.

Так вот, знатоки, внимание вопрос. В чём прикол залепить в дуршлаге одну из дырок, если безопасность экосистемы golang на уровне «TODO: security» ?

А другие пакетные менеджеры при ЯП работают как-то иначе?

А чем в данном случае будет отличаться любой $LANGNAME?

Хоть питон, хоть жабаскрипт, хоть ржавый — везде при компрометации зависимости будет один и тот же исход.

Да дело даже не в пакетном менеджере. Если репозиторий скомпрометирован, то там не только скрипты сборки могут подменить, но и сам непосредственно код.

даже у примтивных проектов дерево зависимостей идёт на десяток реп

не путаешь с js?

Не претендую на объективность, взгляд с дивана

Отличие в 2 вещах

1) в golang подтягивание и сборка зависимостей автоматическая. Не нужно включать мозги и смотреть что там собирается ( и этой возможностью воспользуются 99% разработчиков, т.к. либо «дедлайн на прошлой неделе, от кофе уже тошнит, а тестировщики нашли 2 критических бага», либо «дедлайн на прошлой неделе, я ещё не дочитал go в комиксах для начинающих, а на стековерфлоу мой топик заминусили» . серьёзно, у разработчиков совсем другие задачи). тогда как для python необходимость установки модуля vasyan.pwnd из репы на гитхабе вызвала бы лёгкое удивление ( хм, а почему не из pypi? и почему в моём дистрибутиве нет пакета? ).

2) в golang сборка по умолчанию статическая. Т.е. в п.1. подтягиваются не хэдеры и не среда разработки/тестирования, и именно код, который будет непосредственно включен в результат сборки. А размер собранного файла - десятки мегабайт. Не вижу возможности узнать, что в этом огромном чёрном ящике в форме деревянного коня

Нет, я понимаю что оба пункта ( автоматическая загрузка и статическая сборка ) дают огромные преимущества. Но не вижу, как они вяжутся с безопасностью

Если кто-нибудь объяснит, буду благодарен

Если у тебя дырявая библиотека, то дыра во всех приложениях её использующих. Обновлением библиотек занимается конечный пользователь. А приложением - разработчик, который всё проверяет. Ну и какой-нибудь пресловутый

LD_LIBRARY_PATH=/exploits/

Количество проектов на Go растет в геометрической прогрессии

смешно.

``` Геометри́ческая прогре́ссия — последовательность чисел , в которой каждое последующее число, начиная со второго, получается из предыдущего умножением его на определённое число q ```

похоже, в случае с go, имеем q == 1 :)))

А для сборки сейчас появился vgo (бета) и есть аналогичные сторонние средства. Которые автоматически подтягивают зависимости и чекают их на конкретный коммит. А там уже SHA1.

Если у тебя дырявая библиотека, то дыра во всех приложениях её использующих

Да. Но хотя бы есть способ узнать, что они используют библиотеку / модуль

Обновлением библиотек занимается конечный пользователь. А приложением - разработчик, который всё проверяет

Если заменить пользователя на мейнтейнера дистрибутива, а разработчика оставить, ситуация немного меняется

Меня именно это и напрягает - теперь о безопасности обязан думать разработчик, и ему же предоставили возможность о безопасности не думать

Проекты растут как грибы. Потому что на Go можно просто программировать, не отвлекаясь на всё остальное. Это чертовски удобно. И чертовски экономит время.

похоже, в случае с go, имеем q == 1 :)))

Не, их действительно всё больше. Хоть новости почитай, если не используешь

Из самого очевидного - docker и всё, что с ним связано. Актуальные системы мониторинга ( prometheus, influx stack ) и всё, что с ними связано.

на Go можно просто программировать, не отвлекаясь на всё остальное

а потом пожинать плоды «просто программирования». это можно на любом языке делать. таких «двелоперов» пруд-пруди.

Лол, тебе знание make/cmake помогает? Да ты свят.

Да ситуация с Полкитом позволяет доверять мэйнтейнеру больше, чем разработчику (нет).

Речь не о доверии. Даже если забыть, что у разработчика на первом месте обычно другие задачи

Вот прошла сборка в пустом окружении. Релиз отправлен на тестирование, новая сборка будет в новом пустом окружении. Результатом сборки является бинарник весом в 50 мегабайт. Какие есть способы обнаружить, что в него при сборке вкомпилили код из одного лишнего репозитория?

Синтаксис в рубях блевотный, питонический вариант я бы ещё понял, но вот это — абсолбтное нинужно.

Недавно «модули» появились.

pypi

Его типа скомпрометировать нельзя? Там переодически малварь находят.

На внешние сервисы впринципе нельзя полагаться по-хорошему, нужно держать свои зеркала.

Caddy

Не безопасен. В него встроена телеметрия. Которая включена по дефолту. И автор сервера не хочет её удалять.

Зачем ты отрицаешь объективную реальность и выдумываешь альтернативную?

crystal

Как у него с безопасностью ? Можно как в голанге собрать бинарник полностью без сторонних зависимостей, при этом не встраивая в себя чужие бинарные библиотеки написанные на других языках программирования (c/c++) ?

Которая включена по дефолту

4.2, при загрузке готового бинарника с официального сайта галочка телеметрии по-дефолту снята. Не знаю точно, оно собрано вообще без телеметрии или просто с выключенной телеметренией, но так или иначе, она выключена. И никто тебе не мешает собрать самому без неё, в Go сбока абсолютно безгеморная.

Его типа скомпрометировать нельзя? Там переодически малварь находят.

Можно. Но я не об этом.

Смотри, сломали репу разработчика puper.parser для python. Через месяц обнаружили, начали устранять последствия. На лоре новость: «скомпрометирован python модуль puper.parser» . Разработчик ПО, использующего puper.parser: «хм... pip list | grep puper ... твою ж инкапсуляцию, меня поимели». Пользователь: «хм... dpkg -L | grep puper .... мейнейнеры, руки из жопы!11 ». Мейнейнер: «хм... pip list | grep puper .... вот блин, надо устранять последствия»

Сломали репу разработчика модуля go gitgub.com/kumar/parsehz, добавили импорт лишней репы и инициализацию. буквально 2 строки. Через месяц обнаружили, начали устранять последствия. На лоре новость: «скомпрометирована go библиотека ( или как там они называются? ). Разработчик: „хм. первый раз слышу о таком модуле“ . А в коде import radja/request, а в том уже import kumar/parsehz. Пользователь: „ну и как мне это проверить?“. Мейнтейнеры: „твою ж инкапсуляцию. и как мне это проверить?“

Проверить коммит хэш перед сборкой используя специальные утилиты. Для Linux, кстати, можно и разделяемые библиотеки делать с Go, довольно давно. Но это ничего не меняет.

Проверить коммит хэш перед сборкой используя специальные утилиты

Спасибо, не знал. Через пару месяцев планирую почитать про golang подробнее, пригодится.

А если сборка уже прошла? 50 мегабайт бинарник, ВМ для сборки пересоздана из шаблона при очередном релизе

Вообще, для чего-то более менее устойчивого обычно пихают зависимости в vendor либо используют специальные утилиты типа Go modules, dep и так далее у которых прописан конкретный тэг или коммит хэш. Если этот коммит скопроментирован - то это фиаско, потому что разработчик пихну его в релиз. Если после этого коммита, то проблемы нету вообще.

при чём здесь собственно питон?

Код на питоне написан? На нём самом. Так в чём же дело?

го лососнул тунца - вот в чём дело. А ты остался без зуба.

Вон snap, например, написан на Go для Ubuntu, там и мэйнтейнеры, и автоматическая сборка. Они используют утилиту govendor, и в списке зависимлстей прописаны все хэши https://github.com/snapcore/snapd/blob/master/vendor/vendor.json

Согласен, я был неправ. В golang безопасности уделено достаточно внимания

Но ведь уже вкорячили версионирование и никто не мешает закрепить зависимости на конкретных версииях.

Код на питоне написан?

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

Не нужно включать мозги и смотреть что там собирается ( и этой возможностью воспользуются 99% разработчиков, т.к. либо «дедлайн на прошлой неделе, от кофе уже тошнит, а тестировщики нашли 2 критических бага», либо «дедлайн на прошлой неделе, я ещё не дочитал go в комиксах для начинающих, а на стековерфлоу мой топик заминусили» .

не надо винить 99% разработчиков. они делают то что от них требуют - то есть сделать быстро и что бы гуй был красивым. с безопасностью 99% тупорылого мынеджерья разбираться никогда не будет да они и не в состоянии даже если о чудо захотят это сделать. вот и пусть наслаждаются результатами своего менеджмента потом. захочешь сделать по хорошему тебя пошлют нахрен, оставят без оплаты и напишут негативный отзыв что на целых 2 дня дольше сдал. так что подумаешь в следущий раз пять раз по поводу того а стоит ли стараться, пусть лучше менеджеров имеют хакеры потом чем они разработчика сейчас.

не надо винить 99% разработчиков. они делают то что от них требуют - то есть сделать быстро и что бы гуй был красивым.

И не думал. Чуть дальше процитированного куска - «серьёзно, у разработчиков совсем другие задачи»

при загрузке готового бинарника

При чём тут бинарник ? Это личный бинарник автора собранный по его личному способу.

В исходном коде по дефолту включена телеметрия. https://github.com/mholt/caddy/blob/master/caddy/caddymain/run.go

А указывать в исходном коде по дефолту включение телеметрии это зашквар. Не секьюрно.