Опубликованы (https://groups.google.com/forum/m/#!topic/golang-nuts/sHfMg4...) корректирующие выпуски языка программирования Go 1.8.4 и 1.9.1 (https://golang.org), в которых устранены две проблемы с безопасностью:
- Возможность (https://github.com/golang/go/issues/22125) запуска стороннего кода при выполнении операций "go get" или "go get -d" над пакетами, размещёнными в специально оформленных вложенных репозиториях. Атакующий может разместить в репозитории Subversion (или другой системе управления версиями, отличной от Git), срез "git checkout", включающий набор хуков (.git/hooks/). При обработке такого репозитория указанные во вложенном Git-репозитории скрипты-обработчики будут выполнены на стороне клиента;- В пакете smtp устранена (https://github.com/golang/go/issues/22134) проблема, которая могла использоваться для перехвата паролей в открытом виде в результате MITM-атаки из-за применения метода PLAIN auth для незашифрованных соединений, если удалённый сервер заявляет о поддержке данного метода аутентификации. В новой версии действие PLAIN auth ограничено только TLS-сеансами и обращением к localhost.
URL: https://groups.google.com/forum/m/#!topic/golang-nuts/sHfMg4...
Новость: http://www.opennet.me/opennews/art.shtml?num=47332
Наверное, правильней говорить "обновление интерперетатора языка", ибо сам язык не претерпел изменений ведь, верно?
он компилируемый. один из фиксов -- в стандартной smtp-библиотеке (оторвали plain, если нет tls и не localhost), второй -- в своего рода пакетном менеджере go get.
Интерпретируемый / компилируемый, какая разница? Язык это одно, а стандартная библиотека - это другое.Если в glibc найдётся уязвимость, мы будем кричать про новый релиз языка с++? Или все таки следующего стандарта подождем?
Одна из особенностей "языка go" (в контексте заголовка - так его везде в энторнэтах и используют "язык go", "go lang") - это не просто отдельный компилятор + отдельная стандартная библиотека, оно "в одном флаконе", причем собирать и использовать его можно не только из /bin | /usr/local | /opt / etc, а откуда угодно - хоть из $HOME, да хоть из /tmp (причем очень просто - достаточно задать помимо $GOPATH еще и $GOROOT - что удобно в CI, когда можно на сборочных агентах при сборке без возможности пользования контейнеров/виртуализации иметь одновременно сразу несколько версий). А glibc - это "всего лишь" библиотека... (Про С++ вы наверно пошутили, подразумевая libstdc++/libc++?...)
эммм.. я реально не понимаю.с++ тоже можно "собирать и использовать не только из /bin | /usr/local | /opt / etc, а откуда угодно - хоть из $HOME, да хоть из /tmp"
и даже задавать ни чего не нужно, главное что бы не было noexecкстати, тот же stdc++ идет из компилятора.
У многих ЯП нет четкого разделения на спецификацию и реализацию. Корректирующий выпуск perl, ruby или python тоже может выйти без каких-либо изменений в спецификации, но с исправлениями/улучшениями в core модулях или утилитах. И говорит будут про обновление языка perl/ruby/python, так как там спецификация и ее эталонная(а то и единственная) реализация неразрывно связаны. Go относится к таким ЯП.А есть ЯП вроде C, С++ и javascript, которые отличаются тем, что спецификации сами по себе, а реализации сами по себе. И для них нормальна ситуация, когда ни одна из реализаций не является полноценной, но вместе с тем содержит не входящие в спецификацию фичи. Вот для них про изменение в стандарте и изменение в какой-либо из реализаций говорят отдельно. А в случае с libc еще хуже, у нее своя независимая разработка и множественные не очень совместимые реализации, про которые тоже пишут отдельно, а не говорят об обновлении языка С.