Компания Veracode опубликовала результаты исследования проблем с безопасностью, вызванных встраиванием открытых библиотек в приложения (вместо динамического связывания многие компании просто копируют в состав своих проектов нужные библиотеки). В результате сканирования 86 тысяч репозиториев и опроса около двух тысяч разработчиков определено, что 79% перенесённых в код проектов сторонних библиотек в последующем никогда не обновляются...Подробнее: https://www.opennet.me/opennews/art.shtml?num=55396
27% обязательно проверяют лицензию на совместимость
54% не всегда проверяют лицензию на совместимость
19% - ?
буратины
Ну, логично что не проверяют вообще)
Мне не раз предлагали творчески переработать GPL софт и продавать без исходников. На отказ удивлялись и недальновидно заявляли "да тут очередь из исполнителей". :)
Он вроде и так без проблем продается. Особенно на таких закрытых платформах как плей и апстор.
И на госзакупках
Как ломать нумерацию версий -так у нас нет обратной совместимости, а как "проблемы с безопасность", так у нас все совместимо.
Продаётся. А помимо закрытых платформ есть лоббирование и другие способы заменить авторов SJW-активистами. Интересно бы ещё где-то посмотреть %, сколько из апологетов свободы, которые учат как и под какой лицензией правильно писать ПО, что-то сами написали.
А чего не согласился? Твоего имени там не будет, с деньги за работу бы получил. 👍Да и на нарушения гпл всем плевать с высокой колокольни, особенно в РФ. Зарабатывай-нехочу.
Что бы Вам осталось на покушать. Главное, в кредиты в расчёте на "деньги за работу бы получил 👍" не влезайте.
определить не удалось.
> 19% - ?прибегает автор нужного и важного патча, поменявшего colour на color в комментарии, и бьет себя пяткой в груть - я, у мамы, разработчик этой библиотеки! Вы украли мою лицензию, немедленно уберите и прекратите!
(можете посмотреть на образцового м-ка подобного типа в ruffle)
Авторам кода не до того - они херачат код, кто бы мог подумать! Да и было ли автору патча убирающего лишние пробелы, чем?
В исследовании не раскрыто сколько процентов разработчиков пересчитывают лицензии всех встраиваемых библиотек при их обновлении. Лицензии же могут поменяться.Про "отговорки" вообще шизофрения написана. То что в 70% патчи безопасности шли отдельным коммитом не означает, что в проекте больше не было коммитов , в том числе ломающих совместимость. В итоге 30% это не так и мало, грубо, каждое 3 обновление вероятно может что-то сломать, не говоря уже о том, что и патчи безопасности могут что-то сломать и автор может коммитнуть нерабочий код.
Да и разработчики библиотек все такие нарисованы в белом, хотя автотесты не в состоянии написать, а разработчики, что их библиотеки используют прям диверсанты.
whitelist на allowlist
19% - по.уисты
Они просто не понимают, что делают. Вот такой обращается ко мне, говорит, слева вверху кнопка, на нее нажать нужно. Обращается через моего руководителя, я его рабочий стол смотрю. Нет кнопки. Она из интернета подтягивается.
19% используют современные ЯП вроде Rust и не задаются такими глупыми вопросами. В конце концов зачем проверять вручную, если при наличии инфраструктуры можно автоматизировать сей скучный процесс проверок и обновлений.
19 % — NaN.
Это больше бесконечности.)0x7ff0000000000000 - Infinity
0x7ff0000000000001 - NaN
...
0x7fffffffffffffff
> Это больше бесконечности.)А поправка на военное время?
В случае применения спецназа или ЯО всё ПО становится свободным?))
Долбаный JS
В таком виде сравнить - это надо уметь и постараться.
Да я и не считаю JSников глупыми. Там просто доширак в коде, что тока квантовый компьютер разрулит. Мне недавно пришлось касаться фронта, это после бэка и Си. Моск сломался.
А чему вы удивляетесь? Большинство качают свои сериалы и музыку с торрентов. Уж с софтом как будто кто-то заморачивается?
Ну раз свои качают, то в чём проблема?
Вот если бы чужие, тогда да, прям мировая проблема была бы.
Плюю на все лицензии и никогда их не читаю. Публикую свой код под Unlicense/WTFPL/PublicDomain и прописываю это только в COPYING и не засоряю этим файлы с кодом. 19% нас таких?
Не вас альтернативно одаренных гораздо больше.
Порадуйте, пожалуйста, ссылочкой на публикации.
Молодец! Поклон и уважуха! 😻Пихать вирусную гпл - не уважать свой код и его пользователей.
У нас в корпе (большая, известная, японская, работаю в Токио) обязательная проверка лицензий на любой код со стороны - в том числе ревью юридическим отделом. А если используется какая-то особая интересная математика в своем коде, то надо еще и патентное исследование делать.Что про ＧＰＬ－ код - его нельзя трогать десятиметровой палкой и точка. Любые ＢＳＤ／ＭＩＴ исходники - процедура описанная выше. Большинство используемых либ или полностью свои велосипеды (например, у нас есть аналоги ＯｐｅｎＣＶ， ＴｅｎｓｏｒＦｌｏｗ，разнообразных баз данных и прочего) или купленные/лицензированные у других фирм и обязательно с вагонами документов и всяких ＥＵＬＡ. Иначе вообще никак.
Извините за ушлёпищный английский шрифт, в браузере почему-то только полноширинная клавиатура работает.
работает -- не трогай ®
Ну да. Бэкдор же тоже можно рассматривать как часть функционала программы.
После выявления бэкдора состояние программы уже следует характеризовать не как "работает", а как "сломано", поэтому да, принцип сохраняется. "Не сломано - не чини". Сюда же. Обновления ради обновлений не нужны и несут только распухание кода и потерю совместимости.
После выявления бэкдора логично срочно запилить невыявленный бэкдор.
А потом у тебя базу скачали и на сайте разместили криптомайнер/или редирект .
И потом ой а мы вылетели из выдаче в яндаксе/гугле ой а что делать ??? И реальные убытки каждый день.
А если одновишь либу у тебя сломается обратная совместимость и отвалятся клиенты которые дают деньги. Лучше уж слить базу с точки зрения бизнеса, а потом прислать требование сменить пароль, ибо они все равно хэшированы и задолбаются использовать радужные таблицы.
Копируешь из своего репозитория - дыра в безопасности, нет обновлений. Копируешь из стороннего репозитория - дыра в безопасности, неподконтрольный код.
Выбор меньшего из зол.
Это говорит о том, что большинство программистов - некомпетентные говнокодеры.
Это говорит всего лишь о том, что у большинства разработчиков над душой стоит очень слабо разбирающийся в разработке дедечка/тетенька/комитет, выкатывающие нереальные сроки, режущие по живому бюджет и вообще, всячески мешающих процессу, вместо заявленной им "помощи".*Летела ракета - упала в болото. Какая оплата (какие условия, какие делайны, etc) - такая работа!*
Например, "разработчики" Rosa Tresh хвалились, что у них там полная свобода и демократия. Обещали в прошлом году выпустить версию, которая по плану должна было выйти ещё в 2018-м, потом в 2019-м. До сих пор обещают. Лишь недавно опубликовали какую-то альфу, поскольку прежняя версия 2016 ̶с̶о̶в̶с̶е̶м̶ ̶п̶р̶о̶т̶у̶х̶л̶а̶ в 2021-м выглядит странно.
А вот опять наш поехавший на никому нафиг не сплющившимся дистре. Поаплодируем господа, его тупой настойчивости в повышении индекса цитируемости этой ненужной шняги!
> А вот опять наш поехавший на никому нафиг не сплющившимся дистре.Кстати, в прошлый раз Вы так и не представились. Почему? Вы, случаем, не тот фанат Rosa Tresh, который считает, что он одновременно Виндос и Опух? https://www.opennet.me/~ВыньОпух
> Поаплодируем
> господа, его тупой настойчивости в повышении индекса цитируемости этой ненужной шняги!Ну, Вы определитесь. Она же Вам не нужна. Но Вы про неё пишете, и меня преследуете заодно.
Сударь, вам самим не смешна ситуация, в которой вы, приняв изрядно от росы треш, принимаете теперь от альта, а когда его сожрёт астра, то и от астры будете принимать кое-что кое-куда?
Не знаю, над чем тут смеяться. Слова вроде знакомые, но в законченную мысль не складываются. Развернёте её?
Их же там два калеки осталось, удивительно что вообще выпустили
Выпустили - это когда на официальном сайте и в новостях анонсировано, а не когда выкладывают что попало, поскольку пользователи который год просят и уходят. И двое их оставалось после банкротства, когда они клянчили "помогите". Потом выкружили финансы и желающих "помочь" прибавилось.
Я бы еще добавил, что обратная совместимость у большинства библиотек напрочь отсутствует. На примере libgit2 - от версии к версии интерфейсы перелопачиваются, желание переводить проект на новую версию отпадает.
Да что тут говорить, если даже широко рекламируемые ЯП (не буду называть чтобы не провоцировать контекстный срач) таким страдают.
Всё правильно делают. Не с недоработангым API же до тепловой смерти вселенной сидеть.
Это говорит о том что нужно использовать репозиторий, такой как npm, composer и maven, а не копировать исходный код.
Пропадает интернет, вы на объекте без оного и т.п. и вы его не соберете.
Почему? Есть кэширующие прокси реестры. Например verdaccio для npm
maven и gradle сохраняют в кэш, один на все проекты
npm скачивает в каталог node_modules каждого проекта
в yarn 2 сделан так что позволяет каталог с библиотеками сохранять в git репозиторий и при этом установочные скрипты выполнялись. Даже CI даже не понадобится интернет.
у maven кэш в HOME/.m2 и у gradle в $HOME/.gradle/caches/
они не выкачивают библиотеки для каждой сборки. Даже если новый проект создать они возьмут библиотеки из кэша
Используйте Rust. У пакентого менеджера cargo есть опция --offline которая позволяет не только собрать бинарник, но и документацию по используемым пакетам, если вдруг на некое время прервался доступ к интернету.
> нужно использовать репозиторий, такой как npm, composer и maven, а не копировать исходный код.это так не работает. в энтерпрайзе значительная часть софта не разрабатывается активно, а лишь поддерживается в рабочем состоянии. и постоянно гнаться за ломающими изменениями в сотнях библиотек никто никогда не будет. да и концепция контейнеров, которая нынче популярна, тоже этому не способствует, побилдил контейнер и используешь его 10 лет без изменений.
Эти npm бегут впереди головы, делать ради делания. Они только своё перевелосипедируют, а тебе еще всё переперевелосипедировать у себя надо из их велосипедов. Но также немало и умерших проектов, дойдут до версии 1.0.0, в портфолио положат, и досвидося.
а чо ты хочешь от картизоловых оленяк-работяг
Скорее о том, что современные инструментальные средства хреново развиты. Это тольок молодые реализации языков вроде Node, Python, Java моуг похвастаться NPM, PIP, MVN и другими пакетыми менеджерами, а вот что делять сидятлам? Они с трудом собрали свои говноскрипты башевые что бы хоть что-то заработало, а тут надо что-то обновлять.Пока какой-нибудь meson или conan не дорастет до индустриального стандарта все это будет фактом!!!!
> а вот что делять сидятлам?Что вам таким делать (окромя как флудерасить про незнакомые языки, как вот ржавый наброс в теме про neovim рядом Ваш был) -- не знаю, а сишники давно уж изобрели операционные системы и их дистрибутивы.
Рис. 1: "Свинья под Дубом" // по одноименной басне И.А. Крылова
Вот поэтому во всех нормальных языках используют репощитории. frontend можно просто сделать npm update и всё обновиться согласно правилам, а не абы как.
В spring вообще достаточно обновить версию spring boot
Npm даже об уязвимостях предупреждает
про leftpad он тоже предупреждал?
помнити
> frontend можно просто сделать npm update и всё обновитьсятолько работать перестанет. Не смотря на заявления о том что "мы только устранили баги, зуб даем, совместимо-совместимо".
См, опять же, репо единственного вроде бы нужного проекта на "нормальном языке" - сколько совершенно нечеловеческих усилий тратится на бессмысленные "bump version ...." - а сколько там реально кода.
Новость о том что разработчики не тратят время на bump version того что скопипастили. Они молодцы и правильно делаютTypescript в строгом режиме и java при измени api в большинстве случаев просто не скомпилируют это будет видно сразу.
> Новость о том что разработчики не тратят время на bump version того что скопипастили. Они
> молодцы и правильно делаютда. Они занимаются вместо этого - разработкой, использовав результат чужого труда с наименьшей потерей своего времени.
> Typescript в строгом режиме и java при измени api в большинстве случаев просто не скомпилируют
> это будет видно сразу.и? Это как-то поможет разработчику с миллионом не закрытых _собственных_ проблем - заниматься разработкой, а не бессмысленной тратой времени на выяснение что опять поломалось и как теперь снова все переделывать?
А еще в новой улучшенной версии конечно же не бывает ошибок, бэкдоров из-за продолбанных авторами учеток, изменившегося недокументированного поведения в граничных случаях - нет нет, что вы, что вы, нескучные язычки ведь никак не позволяют такого, всегда новая версия - самая наилучшая и безошибочная! (правда потом зачем-то приходится выпускать еще более новую и лучшую, и так каждый раз)
> с наименьшей потерей своего временине своего, а бизнеса. сильно разные вещи. иначе на зп прогерам не хватит
Те же самые это вещи. В случае отсутствия какого-либо бизнеса за спиной - "зп прогеров и их свободного времени, тратимых на хобби-проект, не хватит", чтобы довести его до более-менее законченного состояния. Все усилия уйдут на фуфел - погоню за новыми и новейшими версиями библиотек.
> Разрабочик Larry Hullison продал компании Huei LaoWei Pedul HongKongPong Inc. права на библиотеку SuperHellYeahJSONSmooozyFractalEditor.
> B npm автоматом прилетела свежая версия с трояном от китайцевДа...
Автоматически она не прилетит потому что npm сохраняет версию и хэш. При каждом npm install будет прилётать одно и тоже, даже если в новой версии появился троян.
А если обнаружется уязвимость то npm о ней будет сообщать.> Разрабочик Larry Hullison продал компании Huei LaoWei Pedul HongKongPong Inc. права на библиотеку SuperHellYeahJSONSmooozyDzenEditor.
> настоящий разработчик скопировал себе версию с трояном и следующие 20 лет она так и лежала в lib
> Автоматически она не прилетит потому что npm сохраняет версию и хэш.И чем это тогда отличается от встраивания библиотек?
Логика не очень понятна большинству комментаторов опеннета.
Вероятно тем, что автоматически сообщается об уязвимостях, и исправить их можно одной командой.
Одна команда, которая исправляет уязвимости, класс!
Че за команда? Фиксики?
npm audit fix
Не всегда работает, к сожалению. На моей практике обновляются порядка 5% пакетов. Остальные требуют изменения мажорной версии с возможной потерей совместимости.
тем что библиотеками управляет npm.
Не анонимный комментатор opennet лезет в git непозиторий или неизвестно какую помойку чтобы скачать исходный код чтобы сохранить их себе на флешку с проектом, чтобы через неделю забыть какие библиотеки накачал, какой версии эти библиотеки и откуда они взялись, не говоря о другом разработчике который эту помойку первый раз видит.npm командой install уставливает те библиотеки которые указаны в package-lock.json. Каждый раз когда новый разработчик или CI вызывает npm install они получают те же самые библиотеки с которыми разрабатывался проект.
Когда разработчик вызывает npm update, менеджер пакетов обновляет библиотеки указанные в package.json на допустимую для обновления версию. Так как версии библиотек задаются на по semver то можно то можно зарание сделать выводы о совместимости с новой версией.
npm outdated покажет какие библиотеки и версии используются, какие доступны для обновления и последнюю версию.
npm audit покажет уязвимости>И чем это тогда отличается от встраивания библиотек?
всем
Это имеет смысл, если этим пользоваться.В 79% продуктов этим, разумеется, никто пользоваться не будет — качнул, работает и ладно.
Справедливо для любого репозитория и любого пакетного менеджера. Нужно Окончательное Решение этого вопроса средствами language-based security.
с обновлением часто может поломаться сайт, а может оказаться так что для одной библиотеки можно jq обновить до последней а для другой нет.
146% разработчиков - разработчики.
5% разработанных программ - могут считаться секурными на 100%
80% всего бюджета разработки съедают 20% менеджеров, вставляющих 80% педуль разработчикам.
Бандлинг дно, сегодня VCS позволяют указывать конкретные поддерживаемые версии сторонних зависимостей и подгружать их автоматически. Примерно 100% проектов бандлит зависимости просто так, большинство при этом не позволяет цеплять другие версии (скажем, системные) совершенно без причины (хотя поддерживаемые версии могли бы и указывать, это не так сложно обнаружить проблемы при самом минимальном тестировании).
> конкретные поддерживаемые версии сторонних зависимостейУдобно ты придумал.
А что если уязвимость исправлена в версии 2.99.1, а у тебя 1.01?
Кто заплатит программисту за работу с BC при переходе с 1.05 -> 2.99?Дядя Петя? Тётя Мотя?
А потом спрашивают -- зачем нужны дистрибутивы, или затягивают сагу про обои...
это то чем занимаются разработчики дистрибутивов? тут мои познания на уровне тумбочки, можешь пояснить свой коммент?
Это то, чем они по замыслу должны заниматься.На деле "разработчик" Rosa Tresh сочинял сегодня рифму:
Арчем деб манжит кубину
Улыбок тебе, дед Макар.
Чел, вот прям жаль тебя даже.
Плюнь ты на эту росу.
Ну кинули, ну да, бывает со всеми.
Живи спокойно дальше, эти сами сдохнут.
Лучше что нибудь полезное сделай или приятное, чем вот так с обидкой няньчиться.
Неужели других достижений в жизни нет, всё роса украла?
> Чел, вот прям жаль тебя даже.Да-да. Где-то я уже это слышал. https://lurkmore.to/Мне_вас_жаль
> Плюнь ты на эту росу.
Я и плюю, как Вы просите. Одновременно отвечаю человеку на его вопрос. Они служат примером. Все довольны. Кроме Вас.
> Ну кинули, ну да, бывает со всеми.
Точно, кинули своего работничка Алзима. https://www.opennet.me/openforum/vsluhforumID3/124359.html#204
> Живи спокойно дальше, эти сами сдохнут.
> Лучше что нибудь полезное сделай или приятное, чем вот так с обидкой
> няньчиться.
> Неужели других достижений в жизни нет, всё роса украла?Я и делаю. Вас то что так волнует?
> это то чем занимаются разработчики дистрибутивов?В том числе...
Однодневок и единороллингов не касается -- там или забивают на вопрос в целом, или решают его исключительно текущими апстримными версиями (последнее само по себе бывает хорошо, только вот имеет свою цену и свои побочки в зависимости от повадок конкретного апстрима).
У кого есть поддерживаемые ветки -- все так или иначе сталкиваются и так или иначе занимаются и поддержкой совместимости того, что в них.
А зачем нужны бинарные дристрибутивы кроме чесания ЧСВ их разрабов? К примеру, во всех испробованных за последние полтора года (включая альт) имелась одна и та же проблема с неполной русификацией VLC - часть пунктов по-русски, часть на английском. Понятно, что я сам могу взять соответствующий файл из виндовой версии, где с этим вопросом все в порядке и подсунуть в линупcячью, но это - брать на себя работу майнтайнера. Или другой пример из практики: есть такой epub-редактор, называется Sigil (понятно что рядом с Adobe Indesign поделка по функционалу и близко не лежала, но на халяву и линупc готов для десктопа). Если используемый дристрибутив не роллинг, то этот самый sigil при запуске будет постоянно задалбывать сообщениями что у тебя стоит древняя версия и надо бы обновиться, ага (по умолчанию обновы проверяются каждые 6 часов и в самой софтине это дело неотключаемо). Простейший способ исправить это дело - прописать #define DISABLE_UPDATE_CHECK в src/main.cpp и в таком виде собрать, но для рук и интеллекта майнтайнера это абсолютно непосильный труд, а потому снова сам собирай из сорцов как оно тебе надо. Или, к примеру, неимоверно доставила последняя opensuse, в которой wine из их собственной репы не видел без доработки напильником wine-mono, поставленный по зависимостям вместе с этим же wine из той же репы. А потому неизбежно возникает вопрос: а нужны ли вообще эти майнтайнеры если половину их работы потом переделывать приходится, нужны ли кучи пакетов в разных форматах если все равно качаешь сорцы и собираешь сам, и нужны ли эти 100500 сортов кocтылинупca вообще или надо по уму (то есть как в бсдшках): есть base system, а все остальное - в портах и пакетах?
В ФрииБСД свой отдельный ад.
Например бинарные пакеты оказываются с отличными от портов опциями сборки.Таки вся эта клоунада спакетами нужна для системного софта.
Прикладное ПО должно быть самодостаточным в рамках системы.
Флетпак и АппИмаже поняли прикладное ПО верно.С вайном отдельная история, работает он через не известное проктологам место.
Зачем-то требует предоставлять вин приложениям доступ к корню и вообще страшно костыльный.
Я когда-то установил FreeBSD из сорцов, тупо нажимая пол часа continue в конфигураторах. Потом ставил приложения и так, и эдак. Через год прочёл, что оно работать не должно в теории. Решил, что наконец я готов для Линукс. Наткнулся рекламу на Rosa Tresh. Протухший DKMS, который не понимает актуальные сборочные сценарии и который никто не собирается обновлять; какие-то левые файлы возникают в корне после обновления системы (разработчики, само собой, не могли их заметить). Wi-Fi не работает в инсталляторе -- ну и что? это не критичный баг, подключат провод, можно релизить! Зато масса видосиков, насколько это здорово и лучше Венды с Убунтой, потому что когда-то было Мандривой.
Ну, Фре нужно отдать должное, она практически разумна и без мусора. Практически нее делает того, о чём её не просят.Дистрибутивы линукса же в большинстве, это набор костылей делающих удобно. Даже самые минимальные сегодня идут с систеемой-Д. Положительная сторона в том, что оно само обладает разумными дефолтами для выполнения широкого круга задач. Отрицательная - добавочная сложность, в том числе в возникающих проблемах и их решении.
> В ФрииБСД свой отдельный ад.
> Например бинарные пакеты оказываются с отличными от портов опциями сборки.И в чем ад-то?
Бинарные пакеты - это порты, собранные с определенным набором опций.
Вместе с возможностью простого редактирования мейкфайла (ну или использования своего оверлея) и такой же простой возможности добавления своих патчей - получается достаточно гибкий инструмент, вполне "дружащий" (на практике) с установкой пакетов из репы.
В том что опции по умолчанию в портах должны совпадать с опциями сборки бинарных пакетов.
В противном случае появляется системная неоднородность.Никаких разумных причин для которой нет. Единственное объяснение которое приходит в голову - по*** мейнтейнеров и прочих участников проекта.
Кроме всего прочего, большая часть прикладного ПО в FreeBSD банально не тестируется перед выкладыванием пакетов или добавлением изменений в порты.
Частая ситуация - порт не собирается.
Вторая частая ситуация - программа при запуске крашится, или крашится при попытке использования (открыть файл например).
> В том что опции по умолчанию в портах должны совпадать с опциями
> сборки бинарных пакетов. В противном случае появляется системная неоднородность.
> Никаких разумных причин для которой нет. Единственное объяснение которое приходит в голову
> - по*** мейнтейнеров и прочих участников проекта.Никуя не понял.
Дефолтные опции портов == опции с которыми из них собирают пакеты. Естественно, что не все возможные комбинации совместимы (или тестируются) - при нестандартных хотелках уже желательно немного подключать голову и иметь какое-то представление, что делаешь и зачем.Я почти два года спокойно сидел в репе "latest" (которая по актуальности и обновляемости софта переплевывает AUR c Федорой: https://repology.org/) c замороженным harfbuzz-2.1.3 кастомной сборки.
До сих пор спокойно использую (принцип "... или ишак или падишах", как c harfbuzz)
freetype2 2.9.1
Installed on : Fri Nov 23 15:19:19 2018 CET
(актуальная версия в репе - freetype2-2.10.4)Это самые "интересноые" (т.к. имеют большие обратные зависимости) - а так, из 1595 установленных пакетов только 54 "самосбор", в основном из-за отличных от дефолта опций сборки или кастомных патчей или убирания "лишних" зависимостей.
Куда уж тут еще "неоднороднее" ...> Кроме всего прочего, большая часть прикладного ПО в FreeBSD банально не тестируется
> перед выкладыванием пакетов или добавлением изменений в порты.
> Частая ситуация - порт не собирается.Это частая байка опеннета, разве что.
Еще раз, медленно и по буквам: бинарные пакеты - это собранные в эти самые пакеты порты.
cd /usr/ports/foo
make package clean
соберет пакет foo.txz в /usr/ports/packages
pkg repo /usr/ports/packages/ - сделает (или обновит) из этого "настоящую" репу, из которой pkg update/upgrade/install сможет брать пакеты.
Далее, сборка оф. пакетов из портов предельно автоматизированна, пакеты _никем_ не выкладываются, а собираются билдсервером из среза портов. И весь смысл портов в том, что их сборка юзверем - это штатная операция, а не ритаул одинокого мейнтейнера раз в полгода, с танцами и бубном как-то чудом собрать бинарный пакет.При сборке оф. репы, не собирающиеся порты автоматом помечаются как "broken" (и со временем, если их не фиксят, удалаются).
Сейчас таких в портах аж 87
https://www.freshports.org/
Calculated hourly:
Port count 44153
Broken 87
Deprecated 169
Ignore 320Остальное - проблемы окружения сборки (обычно - излишних наворотов и опций компилятора в make.conf). Не можешь/хочешь/умеешь определить причину - тупо собирай в чистом джейле/poudriere.
А собираемость во всех возиожных 100500 вариациях окружения и комбинаций никто не обещал.> Вторая частая ситуация - программа при запуске крашится,
Угу-угу. Частота (и причины) - примерно как с первым пунктом. Но мне лень комментировать очередные "предания опеннета о бздах".
Я так же как и вы юзаю фрю и описывают свой опыт.
Ваши щёконадувания выглядят жалко. Попробуйте в следующий раз вести добросовестный диалог и слушать собеседника.
> Я так же как и вы юзаю фрю и описывают свой опыт.Да-да-да, только вас таких "опытных пользователей" - как обычно, пол опеннета.
> Ваши щёконадувания выглядят жалко.
> Попробуйте в следующий раз вести добросовестный диалог и слушать собеседника.Ваше чтение жпопой, как и невладение темой и неумение выразить свою мысль/внято описать проблему - выглядят куда лучше, о да.
Вы бы хоть чем-то читали бы, уже был бы прогресс.Ещё раз, опции сборки бинарных пакетов отличаются от дефолтных опций портов.
Перечитывать пока не прийдёт просветление.
> Ещё раз, опции сборки бинарных пакетов отличаются от дефолтных опций портов.Еще раз, опции сборки бинарных пакетов и есть дефолтные опции портов.
> Перечитывать пока не прийдёт просветление.Прекратить нести чепуху пока не придет просветление.
> А зачем нужны бинарные дристрибутивы кроме чесания ЧСВ их разрабов?Ну вот чтоб Вы своё могли почесать.
> К примеру, во всех испробованных за последние полтора года (включая
> альт) имелась одна и та же проблема с неполной русификацией VLC -
> часть пунктов по-русски, часть на английском. Понятно, что я сам могу
> взять соответствующий файл из виндовой версии, где с этим вопросом
> все в порядкеЕсли всё же почесать затылок, а не ЧСВ, то может оказаться, что переводы-то в обоих случаях или апстримные (и различие для конкретного языка тогда может быть только в версии, которые Вы не потрудились привести), или добавленные создателем сборки (и тогда включаются все плюсы и минусы любого форка).
Конкретно в случае альта можно как багу повесить -- мол, чё это в VLC таком-то под виндой перевод такого-то меню полный, а у вас мне мяса недодают в такой-то версии пакета -- или запросить доработку перевода, благо у нас уже несколько дел как барышни специально обученные появились и такая работа с апстримами тоже ведётся.
http://altlinux.org/BugTracking/BugzillaMiniHowto в помощь, если вдруг отважитесь :-)
> и подсунуть в линупcячью, но это - брать на себя работу майнтайнера
Вообще-то нет, это "работа" пресловутого Дениса Попова и прочих зверьсиделателей. Сам как майнтейнер порой брал и дорабатывал переводы (того же recoll, да много чего), отправляя их и разработчику.
>. Или другой пример из практики: есть такой epub-редактор, называется
> Sigil [...] Простейший способ исправить это дело - прописать
> #define DISABLE_UPDATE_CHECK в src/main.cpp и в таком виде собрать,
> но для рук и интеллекта майнтайнера это абсолютно непосильный трудНу так вешайте соответствующее рацпредложение на пакет в том дистрибутиве, где майнтейнер им сам не пользуется (это точно не у нас, поскольку такого пакета в репозиториях попросту не наблюдаю).
Но самым коварным было бы взяться поддерживать пакет в подходящем виде в том дистрибутиве, который меньше всего Вас достал своими выбрыками и косяками.
> Или, к примеру, неимоверно доставила последняя opensuse, в которой
> wine из их собственной репы не видел без доработки напильником
> wine-mono, поставленный по зависимостям вместе с этим же wine из той
> же репы.Ну попробуйте туда WINE@Etersoft поставить, в альте-то его Виталик в репозитории и поддерживает (и несколько лет назад конкретно с wine-mono всё завелось вообще без пинков).
> А потому неизбежно возникает вопрос: а нужны ли вообще эти
> майнтайнеры если половину их работы потом переделывать приходитсяБез них приходится переделать те 99,9% работы, которые Вы принимаете за данность и попросту не замечаете. Посмотрите, что ли, инструкции по установке третьей слаквари какой и подумайте, "половину" ли.
> нужны ли кучи пакетов в разных форматах если все равно качаешь сорцы
> и собираешь самВот как думаете -- как я стал майнтейнером? :)
> и нужны ли эти 100500 сортов кocтылинупca вообще или надо по уму
> (то есть как в бсдшках): есть base system, а все остальное -
> в портах и пакетах?Доо, то-то у нас "и умные, и красивые" тащат патчи из линукса (но почему-то наоборот не особо), чтоб хоть как-то жить на нынешнем железе. Да и с поддержкой штанов, простите, портков тоже всё настолько вышло неоднозначно со временем (те же разные компиляторы), что пришлось заводить пакеты, "как у этих нелетающих".
И вишенка на торте -- нужны ли эти 100500 сортов бздей, почему одной-то не хватило?..
(если вместо риторики посмотреть трезво, то получится всё то же неизбывное: люди разные, цели разные, средства -- как ни странно, тоже оказываются тем ещё разноязычием; а что-то общее вырастает там, где люди находят смысл и возможность ради него объединиться и найти в чём-то компромиссы, которые неизбывно вылезают другими боками порой)
>А что если уязвимость исправлена в версии 2.99.1, а у тебя 1.01?надо было об этом думать десять лет назад.
тот же кто оплатил появление в проекте версии 1.01, очевидно же.
Причина - что умному достаточно один раз получить по лбу граблями от очередного улучшизма.Чтобы указать "поддерживаемые версии" - надо для начала потратить время на проверку, какие же версии работают - а потом еще и разгребать багрепорты от тех кто подсунул-таки "поддерживаемую", а она, ну надо же - что-то поломала.
Очевидно, что нах никому не вперлось этим заниматься.
Нет, "самым минимальным" не отделаешься. Тестировать надо весь апи, включая неиспользуемые части - сегодня не используешь, завтра что-то по мелочи изменил в коде - и уже используешь, даже сам этого не зная (потому что при другом параметре той же функции оно внутри библиотеки начинает использоваться).
Разработку нужно вести на самом актуальном окружении, тестировать мохнатые версии заявленные поддерживаемыми только по остаточному принципу. Собственно, многие так и делают. Другие действуют по принципу "нас и версия 50 летней давности устраивает, в что там нового мы не знаем". Что-то ломается конечно и внезапно, но такие низкокачественные зависимости вещь нечастая.
Когда актуальность окружения сведётся к месяцам, а доллар будет по 300 рублей - запоёшь
> Когда актуальность окружения сведётся к месяцам, а доллар будет по 300 рублей
> - запоёшьМожно пример где так часто ломают совместимость между версиями? Когда ты используешь новый функционал, ты понимаешь, в какой версии он появился (и что он может быть сыроват). Если ты пользуешься кодом, объявленным устаревшим 10 лет назад, ты тоже понимаешь, к чему это приведёт.
1С например :)Причем оплачивать совместимость конфигурации с последней версией вы будете из собственного кармана.
Или можно присылать счета вам?
Куда лучше на годы завязываться на неподдерживаемые версии? Мигрировать всё равно придётся, и чем быстрее, тем меньше проблем это вызовет.
Вот и обновляй железо каждый месяц. Все равно придётся, че
Вот прямо сейчас и начнем.
Счете вам присылать?
> Вот прямо сейчас и начнем.
> Счете вам присылать?Т.е. я должен отвечать за опрометчиво принятые вами решения? Нет, спасибо, это ваш бизнес прогорит и отвечать тоже вам.
Вы поняли что сейчас написали?
Вы сейчас назвали опрометчивым решением свою сентенцию "Мигрировать всё равно придётся, и чем быстрее, тем меньше проблем это вызовет."И эта ситуация совершенно типична- философы и экспреты призывающие к обновлению как-то сразу сдуваются когда им напоминаешь что то к чему они призывают- вообще говоря не бесплатно... и часто СИЛЬНО НЕБЕСПЛАТНО.
Что, это я вас подписал взять агрессивно-монетизируемые проприетарные решения?
Когда вам пишут код на заказ- не имеет значения проприетарный код или нет. Он кастомный. И его любое изменение - стоит денег. а использовать не кастомный код- не получится. Есть универсальные варианты конфигурации, но они настолько универсальны- что нигде кроме угла под вывеской "кофе на вынос" применятся по сути не могут. Тоесть код будет кастомный. И это значит платный. В простых случаях вам его поправит ваш программист. В чуть более сложных- только разработчик конфигурации. Ибо СЛОЖНО СИЛЬНО. И за каждое изменение - плата отдельная. Ну или вы будете оплачивать тысячи разработчиков как Сбербанк :)
Это всё ещё последствия принятой модели. А значит, бюджет на подобную миграцию заложен (зато сэкономили на разработке собственного поддерживаемого решения, правда?). Если не устраивает регулярность, с которой разработчики ломают совместимость и монетизируются, задавайте вопросы им. При этом, конкурирующие решения могут и не доить, но вам очевидно интереснее, чтобы вас доили.
>зато сэкономили на разработке собственного поддерживаемого решения, правда?То есть вы утверждаете что существует некий вариант кода, который будет совместим с любыми изменениями любых зависимостей в будущем? Вы забавный человек :)
Нет, я утверждаю только то, что нагло доить клиентов это очень неприлично, и что клиенты эти сами согласились на это, а значит, это только их проблема. Это какого же низкого уровня должен быть код, чтобы он регулярно рассыпался? Компоненты могут и обновляться, но совместимость в них сохраняется.
Давайте смоделируем по предлагаемой вами модели "код пишется для актуального на момент времени окружения".После очередного обновления windows поддерживает только актуальное железо, браузер поддерживает только актуальные версии дров, вебсайт только актуальную версию jquery, jquery только актуальную версию браузера. Остальное по остаточному принципу/желанию левой пятки.
Сколько понадобится времени, чтобы всё рухнуло?
Вы меня не поняли. Я только за , чтобы обновлять парк железа сразу же после выхода нового... Я только говорю что это не бесплатно.
Счета вам на какой счет присылать? В этом месяце миллиарда на два обновим...
А, я не тому ответил похоже. Сорри..
вас то я как раз-таки понимаю, в отличие от нашего собеседника, предлагающего поддерживать только актуальное :)
Rust, например.
> а доллар будет по 300 рублей - запоёшьВы графики увеличения долларовой и рублёвой массы если давно не видели -- у Макафи при встрече спросите, он-то, поди, в курсе был.
По такой жаре и в свитере... Отсюда и коменты такие...
В случае обострения кризикса- доллар по курсу и 30 000 рублей может быть...
Миша, ты что, сатанист?
Нет, он просто свидетель скорого краха доллара и америки.
В Новом завете США обозначены как блудница Вавилонская. Так что он прав.
> Миша, ты что, сатанист?Нет, я православный. По крайней мере надеюсь, что таким буду сочтён на Суде.
Давайте смоделируем мир по предлагаемой вами модели.После очередного обновления windows поддерживает только актуальное железо, браузер поддерживает только актуальные версии дров, вебсайт только актуальную версию jquery, jquery только актуальную версию браузера. Остальное по остаточному принципу/желанию левой пятки.
Сколько понадобится времени, чтобы всё рухнуло?
Это может означать провал новой версии окна. Если ей никто не сможет пользоваться, она уйдёт в минус, тут всё просто. На некоторое время. Новое железо будет поставляться с новой версией окна, и потеряют опять же те, кто завязывался на неподдерживаемые проприетарные решения. Зато сэкономили (и тут).
Вот и я говорю: хорошую модель предлагаете. Простую, и, что самое главное, надежную.
> Вот и я говорю: хорошую модель предлагаете. Простую, и, что самое главное,
> надежную.Кстати по поводу железа. Посмотрите на игровые приставки например, или на телефоны, там ведь всё так и происходит: новая версия ПО для нового железа. Это маленькое развитие привычной модели продажи проприетарного ПО, в данном случае ещё и железо проприетарное. Скорее всего, не будь IBM PC, мы до сих пор жили бы в обществе, где за все обновления надо платить.
Я пользуюсь свежими версиями приложений на смартфоне 18 года, и пишу это сообщение в свежей версии дистра и браузера на лэтпопе 13 года
В том и дело, что по завязывается на новые версии железа только искусственно и практически новый софт будет работать и со старым оборудованием, только намного хуже. Не понимаю, почему тут некоторые пытаются прировнять циклы обновления (проприетарного) аппаратного обеспечения к развитию (проприетарных) программ.
А пользователи не провалятся, у которых доступ к Госуслугам или к Ютубу только с новым браузером который только на новой ОС которая только на новом железе?
К госуслугам закрывать доступ старых систем это правильно, может поменьше историй будет в духе "у меня украли 3 квартиры". Но не старых, а более старых чем официально принятый на общегосударственном уровне стандарт минимальной версии. Обновляться надо. И стандарт этот тоже обновлять надо -- дырявые версии прикрытые бумажкой это не выход. С ютубом же так и происходит, причём, всё больше 1 специальный браузер новой версии, или будут разнообразные проблемы.
> Причина - что умному достаточно один раз получить по лбу граблями от очередного улучшизма.И он же готов регулярно получать по лбу граблями от древних багов. Может, дело не в уме?
> Чтобы указать "поддерживаемые версии" - надо для начала потратить время на проверку
CI, тесты, да. Тут вот какое дело. Либо ты пишешь код и сам с ним брачуешься, либо ты берёшь чужой и экономишь время на разработке. Вся проблема в том, что когда код весь твой, ты можешь забить на его проблемы (или даже не знать о них до поры-до времени) и даже на развитие, а вот когда код чужой тебя ткнут носом. Т.е. если в первом случае экономия понятна всем и признаётся желаемой, по второму варианту есть разночтения.
> Очевидно, что нах никому не вперлось этим заниматься.
Только тем, кто проблемы своего кода склонен заметать под коврик с криками "мне за это не платят".
> Тестировать надо весь апи, включая неиспользуемые части
Да, конечно. Но нормальной альтернативой будет свой форк с обязанностью мейнтейнинга, бэкпортов, а вовсе не завернуть древнее гуано в докер и бежать дальше, забыв про это.
Очередное подтверждение того, что опенсурс - это рай для вирусописателей. Ни о какой безопасности тут не может быть и речи. Ведь тут даже не надо ничего дизассемблировать, проводить трассировку, перехватывать вызовы и т.п. - просто пишешь скрипты для отслеживания за диффами и смотри, какие уязвимости были исправлены, и кто эти библиотеки юзает и не обновляет. Все бекдоры у тебя прямо на ладони в открытом виде.
И поэтому под откытые оси вирусов единицы, а под НЕрай для вирусописателей - терабайты баз с сигнатурами этих вирусов?
Зачем писать вирус нацеленный на 2% маргинальных пользователей "откытых" ОСей, если можно писать вирус для 98%?
Когда выгодно - тогда и "откытость" ОСи не спасут
Зачтем, что более лакомый кусок (сервера под линухом содеривативы и фрибзд содеривативы), несмотря на 2%, а терминалы юзеров в большинстве своем не содержат ничего ценнее пережатой порнухи, игр и -самое ценное- пользовательских фото-видео?
Странно.
> Зачем писать вирус нацеленный на 2% маргинальных пользователей "откытых" ОСей, если можно
> писать вирус для 98%?
> Когда выгодно - тогда и "откытость" ОСи не спасутВот так внезапно все миллиарды андроидов превратились в 2%. Опеннетчики день ото дня пробивают новые днища.
Это, дайте почитать... Аноним утверждает, что в мире работают 125 миллиардов(!) десктопов под управлением офтопика. маск-курит-травку.жпег.
Долго ждал этого лицемерия.Как только считать проценты то андроид сразу становится линугсом.
Как только в андроиде очередное шерето - его тут же выписывают из линугса.
> Как только в андроиде очередное шерето - его тут же выписывают из линугса.Лицемерие _тут_ не в любимом "клссическом" опеннетно-пингвинячьем финте ушами.
Лицемерие тут - в упоминании андроида (вендорной установки) в качестве "открытой" ОС.
Др Веб обновляет базу за три секунды. Терабайты такие терабайты.
Тупо держа в себе некую малую базу актуальных зловредов, всеми силами ужимая сигнатуры в семейства и все больше топя за ложноположительную эвристику?
Зависит от вендора. Этот имеет возможность доступа к базам в облаке если при установке было разрешено такое вами. Многие вендоры так делают и в первую очередь бесплатные варианты. Ваши познания в мире Windows несколько устарели. Анонсировали не так давно Windows 11, как выйдет обновите свои мантры и чакры.)))
Да у них там уже больше десяти лет тупой робот эти сигнатуры штампует. ХЗ кто этим пользуется вообще, в оффтопике встроенный бесплатный примерно такой же по бесполезности
Сам с таким столкнулся. Не Dr.Web конечно, но всё равно обидно https://github.com/koutoftimer/sqrc/issues/6
В таких случаях лучше писать в поддержку антивируса о ложном детекте. Могли клонировать репозиторий, добавить "полезную нагрузку" и в таком виде его и поймали.
"
- Сколько вирусов под Линукс?
- 8. И еще надо пое..тся чтобы заработали!
" (с)анек
Угу. И ядро собрать с определенными флагами, и библиотеки строго определенных версий, и самостоятельно дать право на запуск вируса, и ловить его (вируса) сегфолты...
Вирус можно слинковать статически и под гнилукс.
Или у вас там зоопарк glibc такой что пересобирают весь юзерленд раз в неделю?
> Вирус можно слинковать статически и под гнилукс.
> Или у вас там зоопарк glibc такой что пересобирают весь юзерленд раз
> в неделю?Ну ты же понимаешь, что тот же Mirai на рутерах и прочих IoТ
https://www.theregister.com/2018/01/16/arc_iot_botnet_malware/
> A new variant of the notorious Mirai malware is exploiting kit with ARC processo
> The Mirai botnet of 100,000 IoT devices wreaked havoc across the web in 2016 by taking down DNS services provider Dyn.https://www.fortinet.com/blog/threat-research/iot-botnet-mor...
был давно и поэтому уже НЕПРАВДА!?
2%.
то ли дело у нас - все проблемы под ковриком, хакер не подкопается!
дак описаны проблемы виндузятников... а они вечно страдают :)
Статическая линковка кода библиотек в приложение возможна и на Unix и на GNU/Linux. Например, Bash можно статически слинковать с его зависимостями и получить автономный bash-static.
Можно, но в каком дистре bash слинкован статически?
Здравствуй, страус. Сам поищешь, или тебя за ручку отвести?
Пруфца бы не помешало.
> Очередное подтверждение того, что...некоторым и впрямь более к лицу жевать, чем вещать: заодно и за умного сойти можно.
Какой ты умный.. это чтото :)
Это не я умный, а он чушь сморозил посреди лета.
>Ведь тут даже не надо ничего дизассемблировать, проводить трассировку, перехватывать вызовы и т.п.Security by obscurity закрытого софта несомненно лучше, да.
Красивоэпичное "Security by obscurity" кратко и по-русски - "прикрыли лопухом".
Наоборот, программирование под что-то опенсорсное - это ад для любого программиста, в том числе вирусописателя. Потому что в мире OpenSource слово "совместимость" самое страшное ругательство, и любой ваш софт будет запускаться только на той машине, на которой он разрабатывался/собирался. А чтобы охватить хоть сколько-то заметный процент чужих машин, приходится прикладывать просто титанические усилия.
Да блин, даже из исходников собрать для опенсорса - тот ещё квест. Вот просто выберите любой C/C++ проект на github'е, сделайте git clone и попробуйте собрать стандартной связкой configure-make. Я вас уверяю, ни один такой скачанный проект с первого раза не соберётся, хоть на чём-то да засыплется сборка из-за зависимостей этих сраных. И ждут вас часы шаманства...
>А чтобы охватить хоть сколько-то заметный процент чужих машин, приходится прикладывать просто титанические усилия.Это мягко говоря не так.
Просто часто авторы уникального красивого лучшего ПО заняты всякой *** вместо даже банального латания багов.
Ну это не в укор им, делают то что им интересно, такова реальность.
>Да блин, даже из исходников собрать для опенсорса - тот ещё квест. Вот просто выберите любой C/C++ проектЭто особенность волшебного мира сишки, а не опенсорса в целом.
>хоть на чём-то да засыплется сборка из-за зависимостей этих сраных. И ждут вас часы шаманства...
Удивляет почему так мало проектов поставляют докер контейнеры (или любые другие) для сборки и разработки.
О какие плохие и неправильные пользователи библиотек! Ату их! О какие хорошие и правильные разработчики бублиотек! Хвала им!Реальность несколько иная - нет дыма без огня.
Причём тут динамическое связывание? Ну вот лежит у меня в папке с автокадом миллиард ДЛЛ файлов. Допустим некоторые это динамические библиотеки с уязвимостью. Они предлагают мне пойти скачать откуда-то свежие ДЛЛ и перезаписать их у себя? Или они предлагают разрабам вместо копирования их в папку с приложением класть их в system32 порождая dll hell?
Они предлагают отслеживать лицензию, и обновлчть вам автокад автоматически на каждый пук автора длл...
Упаси аллах, пусть валяется кривое тухлое. Пользователь деньги уже занёс, к чему лишние хлопоты?
То есть вы признаете что продали недоброкачественный продукт и знали об этом заранее...
А ведь это сокрытие существенной информации при сделке...
в еуле все это прописано, что покупаете гомнецо. так что никаких претензий.
> То есть вы признаете что продали недоброкачественный продукт и знали об этом заранее...Тебя ждёт unbundle libsarcasm и обновление зависимостей.
> А ведь это сокрытие существенной информации при сделке...
На языке маркетологов это может быть заботой о стабильности софта. Или что-то ещё. Да и покупателей это может вообще не парить.
> Причём тут динамическое связывание? Ну вот лежит у меня в папке с
> автокадом миллиард ДЛЛ файлов. Допустим некоторые это динамические библиотеки с уязвимостью.
> Они предлагают мне пойти скачать откуда-то свежие ДЛЛ и перезаписать их
> у себя? Или они предлагают разрабам вместо копирования их в папку
> с приложением класть их в system32 порождая dll hell?Они ничего не предлагают, а лишь констатируют печальный факт.
А вот в Huawei не 79%, они там для KPI могут стилевые правки делать
Разве для борьбы со Spectre v2 не нужно пересобрать все бинарники?
Не все же подряд программы работают с чувствительными к утечкам данными.
Photoshop сольет АНБ твои мемасы с обамой и российскими подьездами
> Отговорки, что обновление библиотек не производится из-за возможного нарушения совместимости, в большинстве случаев беспочвенныЭто про проекты на c++ где берут указатели на произвольные участки памяти и выполняют их?
У нас наоборот, запрещено зависимости обновлять потому что проект на дотнете и 100% кода - безопасный код.
Просто не пишите на дырявом решете
Я пришлю Вам счёт за услуги проф.химчистки - весь монитор жиром залило.
> Я пришлю Вам счёт за услуги проф.химчистки - весь монитор жиром залило.спасибо. Жирнвато - да. Но автор статьи совсем не учёл специфику различных проектов и технологий разработки.
Например, нашей библиотеке, которая взаимодействует с сериализацией сетевых сообщений более пяти лет. И только человек, который желает получить в печень может попытаться обновить её.
С другой стороны, в том же джаваскрипте обновления - это вечная погоня за своими пятками. В условиях дикого запада люди обновляют обновляют обновляют обновляют... и зачем? Лучше и безопаснее не становится
Вот так вот прямо на произвольный? А если там окажется середина машинной команды? Машинные коды они далеко не всегда однобайтовые.
> Вот так вот прямо на произвольный? А если там окажется середина машинной
> команды?Будет обработана процессором как другая команда.
> Просто не пишите на дырявом решетеВот поэтому ты и пишешь всю жизнь обёртки к софту на "на дырявом *ешете". Дай тебе "дырявое *ешето" и мы будем свидетелями удивительных вещей.
> Дай тебе "дырявое *ешето" и мы будем свидетелями удивительных вещей.Спасибо, не надо. Выжигали это архитектурное недоразумение годами
> У нас наоборот, запрещено зависимости обновлять потому что проект на дотнете и 100% кода - безопасный код.(помечает в блокнотике)
...разработчики на дотнете напрочь оторваны от реальности, придумали 100% безопасный код.
Veracode - шарлатаны. Продают воздух за килобаксы
"простым" обновлением кода библиотеки
но на C/C++ что-ли обновление простое?))
Если после исправления бага нужно повторно проходить сертификацию продукта, то руководство предпочтёт подождать ещё лет пять.
Мистер Cargo к нам придёт и порядок наведёт, Мистер Cargo.
В психологическую ловушку попадаете вы. Новое не означает более лучше.
Так старые дыры позакрывали... как новые то подсовывать? Обновляться надоть...
истину магистр говорите вы
Я думаю отчасти виноваты авторы библиотек, которые срать хотели на пользователей и мчатся впереди паровоза не думая ни о чём: ни о проектировании, ни об обратной совместимости, ни о переносимости.
Авторы библиотек бывают разные. Некоторые всё ломают, некоторые - нет. Некоторые некоторое время тянут две версии - старую, до радикальной смены API и новую.И разработчики бывают разные. Некоторые забивают на развитие библиотек (которые кстати сами выбрали) и стонут по форумам "слоооожно", некоторые не забивают.
Очевидно авторов библиотек, которые делают нехорошо, можно и нужно критиковать. Но ровно то же и про разработчиков. В головной новости даже не критикуют, просто указывают на проблему. И тут уже вой от любителей прибитых гвоздями версий библиотек.
Ну ладно уязвимости - это ещё фигня, их и пофиксить можно. Но ведь не секрет что многие разработчики до сих пор не проверяют проекты, из которых наследуют функционал, на инклузивность! А что если в разработке по поучаствовало ни одного содомита!? Я понимаю что такое теперь редко встречается, но опасность всё равно пока остаётся. Репозитории должны уделять больше внимания этому вопросу и помечать неинклузивные проекты предостерегающим значком.
Тут еще вот ведь какая опасность: унаследовавшись от master автоматически получаешь white privilege
Вот! Нашелся человек который поставил вопрос остро и по существу! Необходим общедоступный фреймворк от уважаемой компании, который мог бы проводить анализ автоматически и исключать из дерева зависимостей неблагонадежные коды.
И кстати еще не закончена борьба с master, slave и подобным. Репозитории должны блокировать исходный код, инклюзивность которого сомнительна. А те разработчики которые присылают патчи повышающие KPI - должны изгоняться из сообщества, и патчи от них приниматься не должны.
А еще встроенный на этом сайте спелчекер в редакторе не знает слова "инклюзивность". На опасную тропинку вступаете Максим... Ой опасную...
> Необходим общедоступный фреймворк от уважаемой компанииУ которого тоже есть версии :(
А мы не будем их менять :)
Так вот как это делается!
Фу! Это прошлый век. Проверять коды, помечать их....Нужно сделать полицию инклюзивности. Вот ты выложил свой хеллуворлд в паблик, и к тебе прихал сквад из трех жирных феминисток, гея-п**ора-латиноса, зеленоволосого вонючего ОНО в мешковатой одежде, трех укуренных ниггеров-исламистов, экосектанта-вегана индейца и затравленного белого куколдиста в очочках без права голоса в ошейнике.
И он будет долго и вдумчиво изучать тебя и твой код. А еще дело заведут - как ты посмел, белый умный гетераст написать в одно рыло код аж в три юнита и не привлечь к разработке меньшинства! Почему у тебя в семье нет квот на ниггеров, даунов, жиробасов и инвалидов? Ты что, угнетатель тут дох***я, а? Ты вообще с какой гендерной идентичности, пацанчик? Почему ты тут пердишь и твой углеродный след тут всю планету парниковым эффектом затянул, а? Вообще не по масти живешь тут, черт христианский! А ну быстро отдал нас все свои деньги, мужло!
Просто говорите что вы инклюзивно угнетённый, еще больше чем все остальные. Проблем то?
"
- А ты Мариос - ты всегда на стороне девок, ты зло.бучий, подлый, х.есо.ущий верблюдов .бущий нацист-уголовник!
- Во первых - я не принимаю сторону девушек, и во вторых- я совершенно точно не .бу верблюдов
" (С) Освободите Джимми. Гоблин
Так у них там русские к цветным приравнены уже, ибо тоже угнетались в этой их Америке не меньше прочих. Так что сиди спокойно, а лучше присоединяйся к описанной тобогй весёлой команде. Заодно недотрах вылечишь.
а все навсего надо не заниматься этой дурью и просто динамически связываться с библиотекой, не встраивая её в проект
это как?
> это как?не засовывать исхи библиотеки в свой проект, а просто использовать её системную версию
Как правило, связываются динамически :)
Существуют header-only библиотеки.
> Существуют header-only библиотеки.и? хидеры тоже обычно системные при сборки используются.
бывают конечно случае исключительные, где это обоснованно (видел проект где используются хидеры boost, но не сам boost, там это было обоснованно, чтоб буст в систему не ставить). Однако в основном включение библиотек в код не имеет смысла
хуже всего когда даже опцию при сборе для использования системноой версии не делают
>> Существуют header-only библиотеки.
> и? хидеры тоже обычно системные при сборки используются.Осталось понять, как это обеспечит "просто динамически связываться с библиотекой".
> бывают конечно случае исключительные, где это обоснованно (видел проект где используются
> хидеры boost, но не сам boost, там это было обоснованно, чтоб
> буст в систему не ставить). Однако в основном включение библиотек в
> код не имеет смыслаБуст - это набор библиотек, часть из них header-only. Что-то из них даже принимают в стандартную.
> хуже всего когда даже опцию при сборе для использования системноой версии не
> делаютНе спрашивали разработчиков, почему они так поступают?
я имел ввиду использовать системные версии библиотек.буст в любом случае это один тарбол и собирать его придеться полностью
и зачем писать 2 раза сообщение, есть кнопка "правка"
> я имел ввиду использовать системные версии библиотек.Вы смотрите на вопрос с точки зрения сборки Линукс, Вам так удобнее. У разработчиков свои критерии, и не всегда "удобнее" в приоритете.
> буст в любом случае это один тарбол и собирать его придеться полностью
Не в любом. Можно извлечь только требуемые библиотеки при помощи bcp https://www.boost.org/doc/libs/1_75_0/tools/bcp/doc/html/ind...
Особенно header-only.> и зачем писать 2 раза сообщение, есть кнопка "правка"
Спасибо, отправил жалобу на первое. Криво его отредактировал.
имел ввиду использовать системную версию библиотек
Ты всё проспал. Разработчики прибитых гвоздями версий ненавидят системные библиотеки. Им нужна среда, в которой всё как они захотят.
И чтобы было меньше вопросов к системным либам пихают многие разработчики свое творчество в снапы, флатпаки, а то и в докеры и почему то случается, что и это не помогает. Кто же все-таки виноват и что делать?
Подскажи мне, в какой версии какой системной библиотеки можно найти реализацию perfect hash table? Да такую, чтобы она в качестве ключей принимала бы строку заданную указателем на кусок памяти + длина строки, не полагаясь бы на наличие терминатора \0. И чтобы с C'шным API, без всех этих няшностей сиплюсплюса.А ещё, что-нибудь маааленькое, C'шное, для парсинга url'ов в подстроки совместимые с perfect hash table выше?
А ещё, да, что-нибудь такое, для генерации выборок случайных чисел, подчиняющихся заданному распределению. Чтобы там было бы распределение Гаусса, распределение Пуассона, может ещё парочку каких. И да, неплохо было бы, если бы оно умело пару десятков статистических методов сравнения выборок. В смысле, вот те стандартные которые включают любой курс статистических методов, типа хи-квадрат, anova, T-вилкоксона, t-Стьюдента, U-манна-уитни, и тп. Желательно при этом, чтобы я тупо туда скармливал семпл за семплом, потом вызывал бы что-то типа finish, и получал бы результат -- значение параметра, p-значимость, и тп.
Ещё было бы неплохо иметь всяких библиотечек для извлечения данных из /proc. Там блин синтаксисы простейшие, но так задалбывает с ними разбираться, обрабатывая на ходу всевозможные ошибки ввода-вывода, что прям ппц. Причём, местами -- это не просто синтаксис, это надо взять открыть директорию, перечислить там все поддиректории с именами определённого вида, залезть в эти поддиректории, найти файлы с определённым именем, распарсить их в соответствии с определённым синтаксисом, и собрать всё это в одну сводную табличку. Ипааать. И это же на фоне того, что любой вызов open или read может вернуть ошибку, которую либо надо заигнорить и повторить операцию, либо вернуть её как ошибку наверх. Начинаешь задумываться, почему бы ядру не освоить sql в качестве языка запросов, да?
Или, скажем, библиотечку для рисования табличек в терминале. В смысле, чтобы не мухой на стекле выёживаться с printf("| %03.7d | %.25s |"... , ох блин, надо ж не фиксированные размеры полей, а подобрать их по содержимому таблички и под ширину терминала... А с переносами по словам в ячейке что делать? Есть ли какие алгоритмы, позволяющие легко и быстро получить достаточно хороший результат в 99% случаев? Ух ты ёкарный бабай, хрен с ними с няшной псевдографикой типа
╔═════════════════════════╗
║ НЯШНАЯ ПСЕВДОГРАФИКА ║
╚═════════════════════════╝(сорри, не ипу как тут в комментах получить fixed-width шрифт, чтобы действительно няшно вышло, в маркдаун форум не хочет, а все эти bb-коды, насколько я вижу, не работают).
Не, действительно, хрен с ним, и можно ведь и обычными ASCII +-| обойтись. Или даже на них забить, чтобы не создавать себе проблем на несколько вечеров кодинга кряду на няшность, которая не добавляет ни йоту функциональности. Вообще вывести всё в виде записей вида:
row1: value1,
row2: value2,
...
rowN: valueN.кстати так парсить проще будет, если чо.
Но с другой стороны, можно ведь взять что-нибудь типа [1], что в достаточно простых случаях позволяет получать достаточно хороший результат, а потом просто озаботиться тем, чтобы не создавать слишком сложных случаев? М? Но есть ли что-нибудь такое среди "системных библиотек"?
[1] https://crates.io/crates/term-table
Нет. Среди системных библиотек есть только старпёрство 80 уровня. Никакой няшности. Никаких послаблений. Если библиотека не была предложена в 80-х годах лично Керниганом, то это ересь, а не библиотека. За такие библиотеки надо сжигать на костре. Либо, альтернативы вида "gnome в депендансах". Которые тоже не решают всех проблем, потому что туда тоже не так то и просто включить свою библиотечку, которая няшно рисует таблички в терминале, или реализует H-краскала-уоллеса, делая сомнительные и неоднозначные допущения о том, в каком формате данные будут загружаться туда.
системные библиотеки = установленные в систему то есть в /usr/lib или еще куда нибудьустановить туда можно что угодно
> системные библиотеки = установленные в систему то есть в /usr/lib или еще
> куда нибудь
> установить туда можно что угодноХаха. Ты пробовал?
Не, ну ты вот сам подумай. Вот, допустим, ты пишешь софтину, которая не под Debian заточена, не под RedHat, не под Arch и не под Gentoo, ты пишешь софтину, задумывая её как кроссплатформенную промежь unix'ов. И теперь вопрос: как ты будешь при инсталляции своей софтины убеждаться, что в системе уже установлена libsomething-I-need-a-lot.so, причём достаточной версии?
configure? Эмм... ну это в принципе вариант, да. Если твой configure выдаст диагноз системе вида "здесь не установлена libsomething-I-need-a-lot.so.3.12" то это сработает: если человек снизошёл до запуска configure, то можно надеятся, что такое заявление подтолкнёт его у установки something-I-need-a-lot. Гарантировать этого нельзя, но если он не может, то это его проблемы.
A если не configure, то что? pkg-config? Это тоже вариант, но того же уровня.
rpm? apt-get? emerge? pacman? Но они не позволяют описать депенданс, которого нет в репах. В смысле, ты не сможешь проверить свой build/install-скрипт, не занеся предварительно в репы эту библиотеку. Но разработчик этой библиотеки считает, что возня с репами тысячи дистров -- это не та деятельность, которую он готов выполнять в качестве хобби. На самом деле, скорее всего, он не готов даже для одного репа поддерживать пакет: ему, в качестве хобби, интересно писать алгоритмы, реализовывать структуры данных, парсить синтаксисы, сериализовывать данные, но ему не интересно писать шелл-скрипты, под разные версии дистров, которые там что-то сделают. Ему не интересно связываться с бюрократией, которая требует десятка справок в трёх экземплярах, только для включения пакета в репы.
В результате, ты не имеешь никакой библиотеки в репах, которая решит твою проблему. Я поэтому выше и задавал конкретные вопросы, типа "подскажи мне библиотеку, которая делает X". Я надеялся, что это будет хорошо демонстрировать точку зрения. Нет такой библиотеки. И либо ты начинаешь атаковать лбом кирпичную стену, в надежде протолкнуть такую библиотеку в репы, которую можно подключить, либо ты забиваешь на всё это, и включаешь библиотеку в виде сорцов.
Покажи мне как можно установить в систему библиотеку, которая реализует для C строки вида struct {size_t len; size_t *bytes}. Которая реализует url_encode/url_decode. Которая позволяет легко получать выборки из различных распределений вероятностей. Которая позволяет легко форматировать данные в таблички, используя наилучшее возможное представление для терминала. Как это сделать? Так, чтобы часик повозиться единожды, и установить.
Нет такого способа. Linux-дистры не заточены под такое. Они распространяют лишь достаточно "серьёзные" библиотеки, которые достаточно часто используются. Если они попытаются двинутся хоть на полкарасика ниже, если они попытаются предоставлять больше библиотек, то их накроет dll-hell'ом, и мейнтейнеры linux'ов взвоют, и выкинут свои рабочие компьютеры от бессилия. dll-hell -- это фундаментальная проблема, есть разные способы справляться с ней, но ни один из них не является серебряной пулей. Подход linux-дистров не решает её, лишь снижает её влияние: по сравнению с вендой, он (за счёт трудов мейнтейнеров дистра) даёт возможность для ограниченного списка софта и депендансов иметь наилучшее решение проблемы. Всё что выходит за пределы ограниченного списка софта/депендансов, будет решать проблемы dll-hell так, как сможет. Причём дистры не предоставляют _ваабще_никаких_инструментов_ для этого. Программист вынужден костылить свои решения.
Тут могут помочь всякие решения, типа maven, gridle, cargo, npm, gem, pip, ..., но даже с ними возникают ОГРОМНЫЕ проблемы, если их пользовать через apt-get, emerge и тп. В том смысле, что все эти apt-get лишь добавляют больше проблем. Когда я игрался с ruby, я быстро забил на "emerge dev-ruby/something-i-need" и перешёл к использованию gem напрямую, устанавливая всё что нужно в $HOME. Потому что репы больше создают проблем в этом случае, чем решают. Они не могут найти решение для dll-hell в столь мелком разрешении: dll-hell -- это фундаментальная проблема со сложность O(exp(N)), под её решение не хватит никаких вычислительных ресурсов, и никаких человеческих ресурсов.
Самый простой способ для разработчика: оставить эти проблемы "кому-нибудь-ещё". Вот кому будет не лень с ними возиться, кому будет интересно или очень нужно, вот пускай он и возится.
configure проверяет либы через pkg-config. Всегда нормально работало это и никаких проблем подобных не было. потом линкеру идет -lsome-lib и он уже решает so.3.12 или so.3.13 и тдесли же ты про бинарники (их распространяют только дистры и виндузятники) то
1. их кстати принято распространять ввиде пакетов для дистрибутивов (а значет зависимости решаются дистрибутивным ПМ)
2. просто сказать что требуются установить определенные библиотеки нельзя
3. ld.so если что сам скажет что какаято либа не найдена
Ну а если вы используете какието странные васяноподелки которых даже в репах дистров нету то в случае бинарников прилинкуйте статически. При нормальной установке пользователю не составит труда собрать также и эту зависимость
> Ну а если вы используете какието странные васяноподелки которых даже в репах
> дистров нету то в случае бинарников прилинкуйте статически. При нормальной установке
> пользователю не составит труда собрать также и эту зависимостьДык они и делают именно это: они включают статически, вместе с сорцами.
А насчёт сваливать на потенциального пользователя обязанность скачать сорцы и собрать их, я расскажу тебе байку. [в качестве оправдания] Я был молодой и глупый, я два месяца назад впервые поставил linux, за три дня убил XFree86, пытаясь его отконфигурировать, провёл полтора месяца в ядерной консоле, и смог-таки скомпилять XFree86, до состояния когда у меня запустился xterm. [/в качестве оправдания] И вот я думаю: теперь надо собрать gnome. Я залез на сайт gnome, и там ипааать в рот сколько всяких разных тарболлов. Я скачал все. В смысле, закинул в список закачки, и wget выкачивал метров по сто за ночь, через dialup, который по ночам был по дешёвке ваще -- там были карточки Web-Plus, которые на неделю ночей за какие-то копейки продавались. И вот у меня лежит хренова туча тарболлов, и я такой: а в каком порядке их собирать? Хз, думаю. Я тогда выкрутился посредством создания шелл-скрипта, который брал первый тарболл, распаковывал, пытался собрать, и если это не работало, то брал второй тарболл, пытался собрать... и так далее. И если какой-то тарболл собрался в процессе, то просто убираем его из списка, и начинаем сначала. Именно тогда я возненавидел autootols.
Но я к тому, что тебе видимо не приходилось сталкиваться с ситуацией, когда софтина для сборки требует какого-то очень специфического окружения, и хрен его знает что именно надо. Причём, я отмечу, что мой пример с гномом -- это ещё цветочки, потому что эти примеры чётко знали, что им нужно. В более общей ситуации, программисту сложно понять, что именно нужно его софтине, чтобы собраться. Он может принимать за данность какое-то свойство системы, а оно на самом деле не является данностью в FreeBSD. Или может у него просто установлена библиотека, и он её использует, не замечая того. А может не библиотека, а расположение файлов в etc важно. Или может наличие какого-то файла в /proc (что накладывает ограничения на версию ядра и/или на его конфигурацию). А может быть это работает только в локали en_US.C, и нихрена не работает в локали ru_RU.KOI8-R? А разработчик не замечает, потому что единственная установленная у него локаль -- это en_US.C.
обычно на эту тему есть документация. В том случае проблема была совсем в другом, т.к. одна программы была кучей тарболов и ты не нашел документации. Если что https://www.linuxfromscratch.org/blfs/для пользователя юзающего бинарники лучше всего использовать ПМ дистра
> Дык они и делают именно это: они включают статически, вместе с сорцами.
дык я про установку в систему для сборки статической версии если ты очень хочешь бины распространять без ПМ. Но опять же - так делают только виндузятники. А обычно либо дистро ПМ либо сорцы
А если ты хочешь дополнительно собрать tar.*z пакет для любого дистра - линкуй системные либы статически или засунь внутрь тарбола динамические. А тут речь идет о включении их в код и сборки по дефолту вместе с прогой
Ты сейчас излагаешь точку зрения энд-юзверя. Точку зрения "зделайте так, чтобы мне было хорошо".> А если ты хочешь дополнительно собрать tar.*z пакет для любого дистра - линкуй системные либы статически или засунь внутрь тарбола динамические. А тут речь идет о включении их в код и сборки по дефолту вместе с прогой
Естественно: это самый простой способ избежать бюрократии дистромейнтейренов. Подумай как программист, ну вот хотя бы попытайся. Тебе нужна функция, которой нет ни в одной из системных либ. Что делать? Скопипастить её в код со stackoverflow? Проигнорить stackoverflow и написать заново? Или подключить несистемную библиотеку, которая реализует эту функцию?
обычно linux разработчики вообще не распространяют бинарники. в конечном итоге - почти все пакеты LFS и большая часть пакетов BLFS встроеных копий либ не имеют и нормально живут. И собственно библиотеки нельзя разделить на "системные и несистемные" - системные = установленные в систему, а туда может быть установлена любая библиотека.К счастью для большей части либ есть --with-system-somelib и т.д.
> Подумай как программист, ну вот хотя бы попытайся. Тебе нужна функция, которой нет ни в одной из системных либ. Что делать? Скопипастить её в код со stackoverflow? Проигнорить stackoverflow и написать заново? Или подключить несистемную библиотеку, которая реализует эту функцию?
ну я бы скорее всего использовал первый вариант т.к. второй лень, а подключать доп либы когда это не нужно т.к. есть 1 и 2 вариант - так себе
Вот чего ты мне пытаешься доказать? Что программисты так не делают? Но ведь в новости написано, что они так делают. Ты пытаешься логикой опровергнуть реальность сейчас, или что?>> Подумай как программист, ну вот хотя бы попытайся. Тебе нужна функция, которой нет ни в одной из системных либ. Что делать? Скопипастить её в код со stackoverflow? Проигнорить stackoverflow и написать заново? Или подключить несистемную библиотеку, которая реализует эту функцию?
> ну я бы скорее всего использовал первый вариантЭто и есть встраивание открытого кода в свой проект. Только хуже, чем с библиотекой, потому что обновлений точно не будет. Не только простых обновлений, которые не ломают совместимость, но и ломающих совместимость обновлений не будет. И на stackoverflow при этом достаточно дырявого кода, эпизодически в новостях всплывает очередной пример. Кроме того, stackoverflow работает только пока функция укладывается в несколько десятков строк. Если тебе нужна, скажем, библиотека для вменяемой работы со строками в C, то это уже сотни строк, и на стековерфлоу не будет такого. Придётся копипастить с github'а. Что уже и есть встраивание открытой библиотеки в свой проект.
то что значительная часть проектов отлично без этого обходится.> Если тебе нужна, скажем, библиотека для вменяемой работы со строками в C, то это уже сотни строк, и на стековерфлоу не будет такого. Придётся копипастить с github'а. Что уже и есть встраивание открытой библиотеки в свой проект.
В таком случае как раз стоит подключить библиотеку. Ну а ради 10 строк не стоит.
> то что значительная часть проектов отлично без этого обходится.Да, очень часто посредством выпиливания лобзиком велосипедов. Или использования не тех алгоритмов, которые подходят лучше, а тем что есть. Скажем, конструкции вида
if(strcmp(s, "hello") == 0)
{ ... }
else if(stdcmp(s, "world") = 0)
{ ... }
else ...И так пара десятков else-if'ов. Хотя сложив все эти строчки в хештабличку, можно обойтись подсчётом хеша s, и использования этого хеша как индекса в хештабличке, с дальнейшим switch'ом. Но для этого нужна perfect hash-табличка, желательно такая, которая собирается в compile-time. Хрен ты найдёшь такое в репах. Поэтому костыли if-else'ов, или, скажем, libc'овой реализации хеш-таблички (которая вовсе не perfect, и как её собрать в compile-time я даже не представляю). Или велосипеды выпиленные лобзиком ad hoc.
Бывают люди, кто ценит своё время, и понимает что весь код в мире не напишешь сам, но C и C++ в этом смысле очень недружелюбны к тем, кто пытается код заимствовать со стороны и ещё потом отслеживать эти заимствования, обновляя их по возможности. Поэтому таких людей относительно немного.
>> Если тебе нужна, скажем, библиотека для вменяемой работы со строками в C, то это уже сотни строк, и на стековерфлоу не будет такого. Придётся копипастить с github'а. Что уже и есть встраивание открытой библиотеки в свой проект.
> В таком случае как раз стоит подключить библиотеку. Ну а ради 10
> строк не стоит.А они не подключают, они включают код библиотеки в код программы. И это работает даже для 10 строк. Ну, в смысле, почти работает. Потому что хоть задумка и хороша (если в этих 10 строках найдётся баг, то на них прилетит багфикс), на практике этот багфикс часто оказывается невостребованным.
> if(strcmp(s, "hello") == 0)
> { ... }
> else if(stdcmp(s, "world") = 0)
> { ... }
> else ...+
> И так пара десятков else-if'ов. Хотя сложив все эти строчки в хештабличку,
> можно обойтись подсчётом хеша s, и использования этого хеша как индекса
> в хештабличке, с дальнейшим switch'ом. Но для этого нужна perfect hash-табличка,
> желательно такая, которая собирается в compile-time. Хрен ты найдёшь такое в
> репах. Поэтому костыли if-else'ов, или, скажем, libc'овой реализации хеш-таблички (которая
> вовсе не perfect, и как её собрать в compile-time я даже
> не представляю). Или велосипеды выпиленные лобзиком ad hoc.Идеальный хеш на этапе трансляции подразумевает, что определено конечное множество строк, верно? Не ясно, зачем тогда при ветвлении оперировать со строками, а не с их индексами в массиве (в какой задаче такое может понадобиться).
Кроме того, else намекает, что s возможно указывает на произвольное значение, значит вероятна коллизия. В таком случае на этапе трансляции следует генерировать пефиксное дерево (оно может оказаться быстрее, поскольку не требует сканирования всей строки). Но если транслятор произведёт подстановку (inline) strcmp() и оптимизирует, то результирующий код окажется гомоморфен поиску по дереву.
Надеюсь это не мне написано было, а то для меня тут темный лес.
ldd
> Надеюсь это не мне написано было, а то для меня тут темный
> лес.разуметься тебе, ну кому же еще это может быть написанно. Ведь точно не тому на чье сообщение это ответ
В начале не понятно кому, потом было конкретно не мне, но я кажется понял о чем разговор идет и себе же ответил.)
> а все навсего надо не заниматься этой дурью и просто динамически связываться с библиотекой, не встраивая её в проектЕсть у меня программка, собранная под Ubuntu 16.04. Использует системные библиотеки, в т.ч. libpng12.so.
Знаешь, почему она перестала запускаться под Ubuntu 18.04? Да потому, что системная библиотека PNG исправила уязвимости, стала лучше и вообще обновилась. И стала по этому поводу называться libpng16.so.
Всего-навсего.
P.S. Причем, ЧСХ, этой программе были глубоко до пуговицы любые уязвимости в этой библиотеке, потому что НИ ОДНОГО внешнего PNG-файла в программе НИКОГДА не открывается.
>> а все навсего надо не заниматься этой дурью и просто динамически связываться с библиотекой, не встраивая её в проектlibpng.so.12 или .16 определяеться во время сборки
и если программа не работает с PNG то зачем ей libpng?
> libpng.so.12 или .16 определяеться во время сборкиДа, поэтому программу "достаточно" было пересобрать под 18.04. Или тупо создать симлинк на либу, потому что больше никаких проблем у этой программы под обновленной системой не было.
> и если программа не работает с PNG то зачем ей libpng?
Читаем медленно и внимательно: она не работает с PNG, приходящими со стороны. Так что сценарий "злоумышленник прислал специально сформированный файл, эксплуатирующий уязвимость в библиотеке" отсекается, а больше ничем уязвимости в этой библиотеке и не грозят.
Даже jquery даёт ссылку на релизы вместо роллинга.
Когда основные доработки библиотек сводятся к имитации бурной деятельности и постоянному ломанию обратной совместипости, потому что "надо выпустить новую версию", встроить и никогда больше не трогать единственная альтернатива варианту написать самому только то, что тебе требуется. А в плане временных затрат, в которых разработчики урезаны до невозможно, потому что пипл требует вчера и со всистелками и на халяву, то и единственная.
Что просили, то и получили. Чё ныть то теперь?
Непонятно о каком софте речь. Для серьёзного софта существуют регрессион тесты. Заменил либвер1.0 на либвер1.1, прогнал регтесты. Прошли тесты заменяешь на новую версию, нет - досвидос. Либо разбираешься где сломалось, если изменения нужные, либо забиваешь. При этом добавить новую зависимость в такой софт, как кстати и новый регрессион тест - это такой квест, что предпринимается только действительно в обоснованных случаях.Ну а если они имеют ввиду говнософт от васи пупкина, то там конечно всё так как они описали.
Есть два варианта развития серьёзного софта. Первый - как ты описал. Второй - как мы встречаем на каждом шагу: всё прибито гвоздями, предложение не прибивать встречается заунывными песнями "а кто будет тестить", "а кто мне за это заплатит" и прочими. Лично у меня велик соблазн сказать "потому что в бывшем они виндузятники, у них так принято", но это неправда. Я видел софт который пишется чистыми виндузятниками, но так, что хочется некоторых привести за ухо и показать, как надо. Ещё приятно видеть когда некая контора, которая пишет опенсорс, на основании багрепортов меняется. Unbundle либ, свитч на другую билд-систему, обновление зависимостей. И никаких визгов "кто будет платить?", "это всё ж надо проверять!". Ну речь как вы догадываетесь о европейских компаниях. Российские например вообще крайне не любят писать инструмент для себя и выкладывать в опенсорс. Про остальное и речи нет.
Ну ты сравнил. Европейцы за деньги пишут.
> Ну ты сравнил. Европейцы за деньги пишут.вот это вообще не оправдание в данном случае. напротив - чем больше бюджет на российский софт "для себя", тем меньше шансов его увидеть в опенсорсе. исключений - единицы. Ну типа яндекс с кликхаусом.
Только вот в жизни наличие или отсутствие регрессионных тестов никак не зависит от серьёзности софта. Может быть ынтырпрайз продукт, который тестируется только вручную обезьянками за еду, а может быть утилита от васи пупкина, который для себя эти тесты написал.
>нет - досвидосПервый раз досвидос...
Второй раз досвидос...(хотя могли бы понять что будет как в первый)
А третий раз даже тест запускать ненадо- сразу сообразили ясно что досвидос гарантирован...А делать то что? Непонятно как это вообще меняет проблему или показывает ее под другим угол? Вы вообще о чем сейчас?
>>>без предоставления сведений - устранения уязвимости приходилось ждать 7 и более месяцев.естебственно.
- У нас дыра в безопасности!
- Ну слава богу, хоть что-то у нас в безопасности...
Это всё из-за пиратсва. Школьники-то на каникулах.
Британские ученые видимо пилили эту статью(((
А ниче что у тех самых пресловутых библиотек нет стабильного API и ни одна нормальная программа не будет рисковать динамически подрубать непротестированную либу?
Для большей наглядности можно привести Qt и его лицензию LGPL для коммерсов, которую те обходят десятой дорогой и покупают лицензию Qt, потому что софтоделам не нужен гемморой с угадыванием, та ли версия Qt что нужно стоит у пользователя и есть ли Qt у юзера вообще
Блджад!
>>в 69% случаев уязвимости были устранены в корректирующих выпускахТ е в 31% случаев программа бы сломалась из-за потери совместимости? Много этих разработчиков либ поддерживают отдельные ветки в плане безопасности?
Сначала обновляют, а потом ломают, отбирают функционал, не тестируют. Не. Обновления - зло, зло и зло.
> так как в 69% случаев уязвимости были устранены в корректирующих выпусках, не связанных с изменением функциональности.Ага. Только уязвимость внесли года три назад и пару мажорных версий. И толку от корректирующих вупысков для новых версий, когда ты всё равно их использовать не можешь.
А если кто и поддерживает старые версии - то только за деньги.
69% процентов багфиков не ломают API))) почти половина))) подгружать такое чудо это как монетку подбрасывать повезет не повезет
Для двух библиотек вероятность не сломанного API = 0.69 ^ 2 = 0.48Для трёх - 0.33, 4 - 0.23, 5 - 0.16, 6 - 0.11, 7 - 0.07, 8 - 0.05, 9 - 0.04, 10 - 0.02...
К чему это казино? Давай считай, какая вероятность сломанного хотя бы одного из двух и более.
Вероятность появления хотя бы одного из событий (А1, А2,…,Аn), независимых в совокупности, равна разности между единицей и произведением вероятностей противоположных событий.для 2: 1- 0.69*0.69 = 1 - 0.48 = 0.52
для 3: 1- 0.69*0.69*0.69 = 1 - 0.33 = 0.67
для 4: 1- 0.69*0.69*0.69*0.69 = 1 - 0.23 = 0.77
и так далее...
Чушь всё полная! Бизопасность, бизопазность.... как курица тупая бегает!
Не надо нам внушать мысль, будто мы перманентно должны быть онлайн и мониторить свежие либы.
Есть "релиз" либы - это более-менее проверенное состояние, в котором можно держать либу достаточно долго. Если всё обновлять как параноики, есть риск сломать систему или даже ВНЕСТИ ошибки безопасности.
Не надо впадать в паникёрство и бесконечную "боязнь дыр", просто РАБОТАЙТЕ! Пока вы делаете свою работу, разрабы либы делают свою. Так и движется прогресс.
У нас на работе не только нужно ждать разрешения от юриста и исследования безопастности на внедрение любой версии библиотеки, даже если это просто апдейт. Но они ещё и репозиторий переодически сканят на предмет «заимствования» кода, что постоянно дает фалспазетив. Хотя все равно где-то кто-то умыкнёт куски кода, которые не заметили во время рецензированиях. Связи с чем у нас интернет блочат на работе… чтобы всякие плебы переставали копировать строчки кода с гитхаб или стаковерфлов
Работодателя назовёте?
Обычный нормальный работодатель. Те у кого не так- просто еще не осознали...
Honeywell
Твоя фирма производит велосипеды?
Это в точку… Много велосипедов… плоть до 2017 или 18го был свой компилятор…
Вы пишите уникальные строчки кода которые не могут никогда нигде и никак походить на другие. И алгоритмы придумываете новые уникальные нигде не повторяемые.
А вы там выкалываете глаза и в лагерях содержите людей чтобы дизайн не своровали?
Менеджерам руки отрубают за воровство идей бизнеса.
Нет, раз в пару месяцев заводят одну и туже пластинку про «заимствование» кода из других источников, на что отвечаем это сложившиеся общепринятая практика или общий алгоритм… для обработки сигналов используется куча всяких функций которые построены на преобразование фурье… там уже мало что уникального напишешь… но начальству с образованием юриста или инженера из другой области это не очень в голове укладывается
Надо C++ проверить на совместимость со старыми библиотеками и удалить все новые не совместимые со старыми
"Линкуй статически" - говорили они.
"Поставляй флатпаки" - говорили они.
И я их не слушал.
И где их советы сейчас? )
$ ./AoW3Launcher
./AoW3Launcher: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directoryЗато через Proton -- работает!
Ну так это изветная виндузятская болезнь. Ну теперь ещё и всех этих флатошлаков.
> Компания Veracode опубликовала результаты исследования проблем с
> безопасностью, вызванных встраиванием открытых библиотек в приложения
> (вместо динамического связывания многие компании просто копируют в
> состав своих проектов нужные библиотеки).Что они имеют ввиду? Cтатическое связывание или использование библиотек в виде исходного кода? А ведь эти два способа позволяют сократить размер загружаемого кода, а второй -- обаспечиитть глобальную оптимизацию и вынос инвариантов из циклов.