https://opennet.dev/openforum/vsluhforumID3/112424.html Опубликованы (https://groups.google.com/forum/m/#!topic/golang-nuts/sHfMg4gZNps) корректирующие выпуски языка программирования Go 1.8.4 и 1.9.1 (https://golang.org), в которых устранены две проблемы с безопасностью:<br><br><br>- Возможность (https://github.com/golang/go/issues/22125) запуска стороннего кода при выполнении операций "go get" или "go get -d" над пакетами, размещёнными в специально оформленных вложенных репозиториях. Атакующий может разместить в репозитории Subversion (или другой системе управления версиями, отличной от Git), срез "git checkout", включающий набор хуков (.git/hooks/). При обработке такого репозитория указанные во вложенном Git-репозитории скрипты-обработчики будут выполнены на стороне клиента;<br><br>- В пакете smtp устранена (https://github.com/golang/go/issues/22134) проблема, которая могла использоваться для перехвата паролей в открытом виде в результате MITM-атаки из-за применения метода PLAIN auth для незашифрованных соединений, если удалённый сервер заявляет о поддержке данного https://opennet.dev/openforum/vsluhforumID3/112424.html#6 Fri, 06 Oct 2017 07:14:09 GMT эммм.. я реально не понимаю.<br><br>с++ тоже можно "собирать и использовать не только из /bin &#124; /usr/local &#124; /opt / etc, а откуда угодно - хоть из $HOME, да хоть из /tmp"<br>и даже задавать ни чего не нужно, главное что бы не было noexec<br><br>кстати, тот же stdc++ идет из компилятора.<br> https://opennet.dev/openforum/vsluhforumID3/112424.html#5 Thu, 05 Oct 2017 22:02:33 GMT У многих ЯП нет четкого разделения на спецификацию и реализацию. Корректирующий выпуск perl, ruby или python тоже может выйти без каких-либо изменений в спецификации, но с исправлениями/улучшениями в core модулях или утилитах. И говорит будут про обновление языка perl/ruby/python, так как там спецификация и ее эталонная(а то и единственная) реализация неразрывно связаны. Go относится к таким ЯП. <br><br>А есть ЯП вроде C, С++ и javascript, которые отличаются тем, что спецификации сами по себе, а реализации сами по себе. И для них нормальна ситуация, когда ни одна из реализаций не является полноценной, но вместе с тем содержит не входящие в спецификацию фичи. Вот для них про изменение в стандарте и изменение в какой-либо из реализаций говорят отдельно. А в случае с libc еще хуже, у нее своя независимая разработка и множественные не очень совместимые реализации, про которые тоже пишут отдельно, а не говорят об обновлении языка С. <br> https://opennet.dev/openforum/vsluhforumID3/112424.html#4 Thu, 05 Oct 2017 20:38:14 GMT Одна из особенностей "языка go" (в контексте заголовка - так его везде в энторнэтах и используют "язык go", "go lang") - это не просто отдельный компилятор + отдельная стандартная библиотека, оно "в одном флаконе", причем собирать и использовать его можно не только из /bin &#124; /usr/local &#124; /opt / etc, а откуда угодно - хоть из $HOME, да хоть из /tmp (причем очень просто - достаточно задать помимо $GOPATH еще и $GOROOT - что удобно в CI, когда можно на сборочных агентах при сборке без возможности пользования контейнеров/виртуализации иметь одновременно сразу несколько версий). А glibc - это "всего лишь" библиотека... (Про С++ вы наверно пошутили, подразумевая libstdc++/libc++?...)<br> https://opennet.dev/openforum/vsluhforumID3/112424.html#3 Thu, 05 Oct 2017 15:12:22 GMT Интерпретируемый / компилируемый, какая разница? Язык это одно, а стандартная библиотека - это другое. <br><br>Если в glibc найдётся уязвимость, мы будем кричать про новый релиз языка с++? Или все таки следующего стандарта подождем?<br> https://opennet.dev/openforum/vsluhforumID3/112424.html#2 Thu, 05 Oct 2017 14:17:46 GMT он компилируемый. один из фиксов -- в стандартной smtp-библиотеке (оторвали plain, если нет tls и не localhost), второй -- в своего рода пакетном менеджере go get.<br> https://opennet.dev/openforum/vsluhforumID3/112424.html#1 Thu, 05 Oct 2017 13:27:39 GMT Наверное, правильней говорить "обновление интерперетатора языка", ибо сам язык не претерпел изменений ведь, верно?<br>