Опубликованы корректирующие выпуски распределённой системы управления исходными текстами Git 2.40.1, 2.39.3, 2.38.5, 2.37.7, 2.36.6, 2.35.8,...Подробнее: https://www.opennet.me/opennews/art.shtml?num=59033
ну что тут скажешь, уязвимости были, есть и будут, выбор ЯП от этого них спасает, такая уж архитектура современных пекарей и серверов
Да.
Главное не быть луддитом, и во время затыкать дырки 🍩
Луддиты тоже могут затыкать дырки, если ты понимаешь о чём я.
Одну дырку заткнут, две добавят.
пожалуйста
> Главное не быть луддитом, и во время затыкать дырки 🍩Главное ерунды не писать, как спешунчики. И тогда неолуддитам новое тоже начнёт нравиться.
Проблема в глупости, а не новизне.
Не совсем так. Это говорит об уровне разработки.Одно дело уязвимости в каких-то сложных алгоритмах и структурах данных, многопоточности и т.п.
Другое дело не уметь обработать правильно чуть более длинную строку.Это днищенское дно ((
У тебя с детства заученное чувство вины и ты его на всех теперь проецируешь.
Поработать бы сишникам в областях, где от ПО зависят человеческие жизни - вот тогда бы они узнали, что такое чувство вины.А так чел правильно написал. Одни сишечные г*кодеры десятилетиями продолжают писать сишечный г*код. Другие сишечные г*кодеры рассказывают, что это норма и иначе нельзя.
Слава богу, что всех этих экспертов отфильтровал естественный отбор, и они еще в нулевых осели на выгребании вонючего embeddedда за гроши. Там им и место.
Embedded это есть сфера от которой часто зависят человеческие жизни ты в интеллект вообще умеешь?
Только вот не весь embedded написан на си. Если бы ты вылез из сишечного танка, то знал, что embedded, от которого зависят человеческие жизни (тот самый high-integrity software - авиация, комонавтика, ЖД, АЭС), еще с восьмидесятых не пишут на сях.Я уже представляю, как после условного падения самолета с N человеческих жертв сишечный кодер разводит руками: "ну что тут скажешь, уязвимости были, есть и будут...". Самому-то не смешно? Слава богу, таких горе-экспертов к серьезному программированию не допускают.
> embedded, от которого зависят человеческие жизни [...] еще с восьмидесятых не пишут на сяхИнтересуюсь с целью саморазвития: а на чём пишут такое embedded?
SPARK Ada, Misra C (там такое количество ограничений, что с Си оно связано только синтаксисом)
Из более экзотичкского - Modula-2 - всегда хвастаются что на ней написан софт спутников ГЛОНАСС.
Спасибо, почитаю на досуге!
> Спасибо, почитаю на досугеЛучше Embedded C Coding Standard by M. Barr почитать и тому подобное по смыслу. Это более реалистичное нечто. Мисру кстати сложно прочитать нахаляву легально, заживают ее, увы.
И читать это надо не как истину в последней инстанции а для понимания общих принципов "antibug" и "понятного кода, который подлежит майнтенансу". Если вы не клали в поле грабли, вы не получите ими в лоб.
А на аде пишут очень сильно некоторое только и по популярности она ни в какое сравнение с си. Даже прсото найти вакансию на этом уже целый квест.
И что, сильно легче стало паре ошпареных на станции из-за того, что одни гении решили порулить вторым контуром на j2me, а ей приспичило хлам пособирать?Сдуйте щёки.
На PHP!Очевидно, речь идёт о Ada/SPARK и т.п.
> тот самый high-integrity software - авиация, комонавтика, ЖД, АЭС), еще с восьмидесятых не пишут на сях.Как же NASA отстала от передовых анонимов блин, жалко за организацию
> жизни (тот самый high-integrity software - авиация, комонавтика, ЖД, АЭС),
> еще с восьмидесятых не пишут на сях.Вообще-то в практически всех перечисленых немеряно сишного кода. А фирмвари микроконтроллерам (которые часто last line of defence) на чем кроме сей вообще писать, по большому то счету?
> Я уже представляю, как после условного падения самолета с N человеческих жертв
> сишечный кодер разводит руками: "ну что тут скажешь, уязвимости были,А представляете, самолеты еще и падают. И даже из-за софта. А ариан5 упал даже и с адой. Правда и там и там как раз обычно из-за алгоритмики. Для начала в внутреннюю сеть самолета совсем посторонних по задумке не очень то и пускают. Правда, с этим тоже были нюансы. Поэтому sci-fi где злой вирус перехватывает управление звездолетом постепенно перестает быть лишь sci-fi и понемногу становится буднями продвинутых инженерных систем.
>> жизни (тот самый high-integrity software - авиация, комонавтика, ЖД, АЭС),
>> еще с восьмидесятых не пишут на сях.
> Вообще-то в практически всех перечисленых немеряно сишного кода. А фирмвари микроконтроллерам
> (которые часто last line of defence) на чем кроме сей вообще
> писать, по большому то счету?"Yeah, I thought some time back that it would be a week till I got back to my dev system. But the 737MAX thing has turned into a really big problem. I should refrain from predicting an end time. As it looks now it might be never. Sigh."
Это пишет автор fasmarm https://board.flatassembler.net/topic.php?p=211090#211090
Интересно, зачем ему было надо адаптировать flat assembler под ARM?
> Поработать бы сишникам в областях, где от ПО зависят человеческие жизниочередной лунтик свалился, хехе
Мисра конечно крута, по ней код для всяких марсоходов пишут за охулиарды денег
Но... как это применимо к пользовательскому софту?
В ядре мисрой даже не пахнет - такое ***кодище невозможно на нее переписать, как и заставить тех же драйверописателей ее использовать. А про всякие поделки типа гита вообще говорить нечего.
Для начала, MISRA запрещает аллокацию на куче... всё - нигодится нидлячего, кроме ембеда в лифтах или автомобилях.
> В ядре мисрой даже не пахнетно современные ракеты на обычном линуксе и С летают
https://www.opennet.me/opennews/art.shtml?num=53083
шах и мат военам супротив сишки
> Мисра конечно крута, по ней код для всяких марсоходов пишут за охулиарды денегДля начала по ней пишут код для автомобилистов. Который очень даже может убить своих пользователей внезапным глюком. А как вы думаете что с вами будет если ECU, ABS или что там еще начнет жить своей жизнью? Да даже просто отстрел подушек безопасности невовремя (это тоже микроконтроллер, мониторящий ускорение и его выход за безопасные пределы делает, с фирмварой на понятно чем) может вас угробить на раз.
> Но... как это применимо к пользовательскому софту?
Пользовательский софт это вообще глюкавый наколенный крап зачастую. Вон вам питоны электроны где кодеры даже не скрывают что они "время себе экономили". За счет всех остальных параметров софта, от жора ресурсов до забагованости.
> В ядре мисрой даже не пахнет - такое ***кодище невозможно на нее
> переписать, как и заставить тех же драйверописателей ее использовать.А линух тем не менее применяют и в довольно ответственных штуках. Если кто не понял, MISRA сама по себе не панацея. А автомотивщики, авиаторы, космос и индустриалы достигают надежность и безотказность целым комплексом мероприятий. Где замена 1 яп на другой мало что меняет.
> А про всякие поделки типа гита вообще говорить нечего.
Гит критичными системами не рулит. А если что-то ну вот совсем сломается, бэкапы есть. Особенно у гита где бэкапом является каждая клонированая репа.
Это до тех пор пока новая версия git не попортит КАЖДУЮ локальную репу))) Это лишь вопрос времени, если такая бага просочитсяВон, на React Native новый релиз случайно поломал сборки всех прошлых версий приложений, те вообще всех приложений в мире
https://repository.tudelft.nl/islandora/object/uuid:646de5ba..."From the data obtained, we can make the following key observations. First, there are 9 out of 72 rules for which violations were observed that perform significantly better (α = 0.05) than a random predictor at locating fault-related lines. The true positive rates for these rules range from 24-100%. Second, we observed a negative correlation between MISRA rule violations and observed faults. In addition, 29 out of 72 rules had a zero true positive rate. Taken together with Adams' observation that all modifications have a non-zero probability of introducing a fault, this makes it possible that adherence to the MISRA standard as a whole would have made the software less reliable."
Может сможешь привести пример ЯП или области где все шоколадно? Или только дерьмом поливать умеешь?
> Поработать бы сишникам в областях, где от ПО зависят человеческие жизни -
> вот тогда бы они узнали, что такое чувство вины.
> А так чел правильно написал. Одни сишечные г*кодеры десятилетиями продолжают писать сишечный
> г*код. Другие сишечные г*кодеры рассказывают, что это норма и иначе нельзя.Да, то ли дело г@вн@код на других ЯПах, они ещё и выдают жирное потребление ресурсов, зато стильно, модно, молодёжно и со вкусом смузи, как вы это любите. xD
Там хотя бы библиотеки есть и структуры данных)))Здесь как бомжара шаришься чтобы по всему интернету чтобы собрать всякие ring buffer, queue, linked list, red black tree, etc.
Вообще ничего нормального нет 🤣
Либо писать своё наколеночное г.но. Но зная уровень Сишников уровень этих поделок предсказуем.
> Здесь как бомжара шаришься чтобы по всему интернету чтобы собрать всякие ring buffer, queue, linked list, red black tree, etc.это проблема не языка а тупых поисковиков
> У тебя с детства заученное чувство вины и ты его на всех теперь проецируешь.Посмотри код SVN и Git. Сравни. Это объясняет критицизм Гита.
Просто сишка - это пыхыпэ для системного программирования.
Порог вхождения околонулевой, кодить на си можно научить даже обезьяну, а на баги, cve и всякие ub всем пофиг. Надо же быстрее фигак-фигак и релизить.
Вот сишка и вытеснила нормальные надежные языки типа Ада из масс-маркета, потому что сишные быдлокоделы оказались дешевле нормальных программистов, а остальным языкам достались только узкие ниши.Потом уже, после кучи факапов, сишники начали задумываться как сделать это Г надежным.
И первая мисра вышла аж в 1998 для с89/90, это ж через столько лет после самой сишки.
И в большей часте свелось к запретам всяких динамических штук, потому что и так было понятно, что заставить ЭТО быть надежным никто не может, а отвечать за факапы не хотелось... в общем проще было запретить))
Все так и есть... Забавно при этом читать, как эти сишные макаки авторитетно заявляют "уязвимости были, есть и будут, выбор ЯП от этого них спасает". Сразу чувствуется уровень экспертизы и компетенции :)
Мне интересно, как ты комментируешь новости об уязвимостях на rust. Покраснев обходишь стороной?
> Вот сишка и вытеснила нормальные надежные языки типа Ада из масс-маркетанаркоман? Вытеснила оттуда, где Ады никогда не было? Ада появилась через 10 лет после С.
Первый стадарт на язык:
Ada 87 - ISO 8652:1987 - 1987 год (хотя по факту еще раньше - ANSI/MIL-STD 1815A или "Ada 83" из 1983 без изменений перекочевал в ISO)
ANSI C - 1989 год
Одно дело стандарт, другое, когда сделали. С был сделан в 1969 году, годом релиза 1973 считается.
И как же страуструп свой С++ писал поверх Сишки за два года до того, как эта сишка появилась. Да, еще UNIX написали на языке созданном в будущем, и sendmail. Сарказм, если что.
Ада изначально разрабатывалась вояками для написания критических систем, систем реального времени и всякого embedded.
Сишка создавалась как "переносной ассемблер" для ̶б̶ы̶д̶л̶о̶к̶о̶д̶и̶н̶г̶а̶ быстрого переноса программок с одной архитектуры на другую во времена PDP-11. А за счет своей ̶у̶б̶о̶г̶о̶с̶т̶и̶ простоты компилятор для него мог написать практически любой погромист, чем многие и развлекались в 70х-80х.
> Просто сишка - это пыхыпэ для системного программирования.Кодить можно на чём угодно научить кого угодно.
А вот понимать чужой код... ;)))))))))))))
Си - это то, как работает процессор. А потому и сейчас хорошо и ещё долго будет хорошо.
> Си - это то, как работает процессор.Угу, процессор где-то из 70х, примерно оттуда же родом что этот копролит.
Где нет многоуровневых кешей, многоядерности, спекулятивного выполнения, где ради пары тактов готовы удавиться и выкинуть любые проверки, и заодно получить пару cveшек.> А потому и сейчас хорошо и ещё долго будет хорошо.
И сейчас баговоный кусок, и таким и останется до скончания времен. Ибо обратная совместимость.
> заодно получить пару cveшекэто ерунда, через год ИИ всё будет находить а вот что делает наркоманский раст проверить невозможно
И кто-то внял голосу разума: https://github.com/Byron/gitoxide
Уязвимость - не в доступе в неразрешенное место памяти. А в обработке симлинков. Ваш раст бы от этого не защитил.
Но наш Раст защитил бы от CVE-2023-29007 и CVE-2023-25815 из новости, о которых ты решил тактично не упоминать.
> ну что тут скажешь, уязвимости были, есть и будут, выбор ЯП от этого них спасает, такая уж архитектура современных пекарей и серверовСуть CVE-2023-29007 в том, что необучаемые сишечные кудесники по привычке опять влепили "char buf[1024]" вместо использования нормального строкового типа.
Так что конкретно от такого выбор ЯП как раз спасает. И коллеги спасают, не пропуская такую дрянь на ревью. Но ведь здесь сишники г*кодят на сишечке, поэтому такая дичь для них - это в порядке вещей и "было, есть и будет". По другому мы не умеем...
> Суть CVE-2023-29007 в том, что необучаемые сишечные кудесники по привычке опять влепили "char buf[1024]" вместо использования нормального строкового типа.Эти твои нормальные строковые типы работают с кучей, чтоб раздвигать булк^W границы массива, а потому медленные. Этот char buf[1024] создается на стеке и это самый быстрый способ работать со строками.
Ох уж эти сишечные душевные терзания с выбором между скоростью и пачкой CVE.Ты профайлер-то запусти прежде чем говорить, какие части кода тормозят.
> это самый быстрый способ работать со строкамии память освобождается автоматически
> создается на стеке и это самый быстрый способ работать со строками.учитывая что тот разбор строк подразумевает чтение данных с диска, все эти ускорения дадут примерно нулевой результат
А ещё можно написать строковый тип, который со строками до 1024 работает "быстро" (мы, конечно же, поверим на слово, что разница в быстроте обнаружима), а больше — корректно, но корректность — это... знаете ли, как-то не по нашему, не по сишному
>>это самый быстрыйпоспешишь - людей насмешишь.
То есть с функцией alloca вы не знакомы.
Знаком, но она может стек повредить при неправильном использовании. Примерано как VLA.
Ну поскольку к тому же хорошо знакомы с оптимизацией, значит слышали о спекулятивном исполнении и предсказателе переходов. То есть проверка займёт 0 тактов.
>вместо использования нормального строкового типа.Это какого, например? Даже в Аде несколько типов строк, потому что универсального решения для строк еще не придумали.
Любого динамически аллоцируемого. Вот конкретный фикс этого char[1024]:https://github.com/git/git/commit/528290f8c61222433a8cf02fb7...
Ты чаво это! На куче выделять память очень долго!111
Оно же тормозить на всяком мусоре будет!!111
Скажите спасибо что не на баше говнокодят.
Тут не выбор ЯП решает, а архитектура. git - это нагромождение скриптов, понятное дело, что они глючат. Не хочешь таких багов, используй софт, который разрабатывается как единое целое, например Fossil
Вот что бывает, когда вместо JSON используешь свой нескучный формат со своим нескучным парсером.
JSON не нужен.
JSON нужен, а нескучные форматы не нужны, тем более если они дают CVE RCE.
Нет не нужен. У всего должен быть свой формат, вся это универсальщина зло.
JSON нужен, а нескучные форматы, несовместимые между собой - не нужны. Иначе для N форматов придется писать M конвертеров из одного нескучного формата в другой. А это N + M уязвимых библиотек -- настоящее раздолье для любителей RCE.
Чего тогда doc не перейдет на json? Да потому что твой json ненужен прими это как данность.
Какой док? Док Эмметт Браун или какой-то другой? JSON - не серебряная пуля, применять его надо только там, где уместно. Хранение конфигов, предназначенных для человека - это уместно. А с твоими нескучными форматами наблюдаем RCE, потому что "шел сишник по буферу, видит - буфер уже закончился, вышел за его пределы и CVE-шнулся".
В этой жизни кроме хранения конфигов ещё очень много интересных задач, которые тебе неведомы.
Я бы не назвал изобретение очередного нескучного формата и RCE-парсера к нему "интересной задачей". Но возможно тебя это прикалывает, и ты готов этим заниматься всю жизнь. Для по-настоящему интересных задач у тебя времени не останется - будешь пилить нескучные RCE-форматы. А я использую JSON и другие изобретения человечества, поэтому занимаюсь только новыми задачами -- такими, к которым человечество еще не приступало. Стою на плечах гигантов. А ты путайся у гигантов под ногами со своими RCE-велосипедами.
> занимаюсь только новыми задачами -- такими,
> к которым человечество еще не приступалоКажется, у нас впервые комментируют марсиане :D
Первый контакт, получается
или рептилоиды (не впервые)
Может потому, что MS не пытались сделать нормальный формат, а наоборот более сложный, чтоб никто его полностью не смог реализовать (libreoffice так и не смогли)
Нет формат документа сделанных на json это ещё хуже чем doc.
> Может потому, что MS не пытались сделать нормальный формат, а наоборот более
> сложный, чтоб никто его полностью не смог реализовать (libreoffice так и
> не смогли)Какой-то бред.
1) LibreOffice особо и не пытались. У них нет такой задачи, потому что у них другой формат документов во многом не совместимый.
2) У многих офисов для которых формат MSO родной (а это считай чуть ли не все кроме LO/OO) с совместимостью вполне нормально.
3) Проблемы с совместимостью есть везде при использовании сложных форматов для сложных задач. Даже между LO и OO поколов хватает. Как и глюков в самом LO.
> Чего тогда doc не перейдет на json?Потому что современный doc (который docx) и так уже на html.
> уже на html(фикс) на xml.
*на xml. Это разные вещи.
Хотя лучше бы на html был, как markdown. Не лучший формат конечно, но хотя бы не такое нагромождение всякого ненужного, как OOXML
(docx,xlsx,pptx) и читается любым браузером
Если ты про офисный doc, так его использовали до нулевых, а потом поняли, что получилась фигня и выкинули, перейдя на docx, который, внезапно, просто zip архив с набором xml файлов. Т.е. даже ms заюзала стандартизированные форматы, вместо самописных велосипедов.
> Если ты про офисный doc, так его использовали до нулевых, а потом
> поняли, что получилась фигня и выкинули,Эта "фигня" является чем-то типа виртуальной ФС так то, и используется газилионом майкрософтовских тулсов во всех закоулках и по сей день.
> перейдя на docx, который, внезапно, просто zip архив с набором xml файлов.
...со спеками на 6000 страниц, фоточку ЭТОГО можно у гугл картинок попросить.
После чего народ попробовал по этим спекам файлы делать и оказалось что мсовский же эксель и ворд не открывают самые тривиальные примеры сделаные по майкрософтовским же спекам.
> Т.е. даже ms заюзала стандартизированные форматы, вместо самописных велосипедов.
И получилась фигня под другим соусом. И тоже самописный велосипед - потому что ODF на тот момент уже был стандартом, и они продавливали второй стандарт для одного и того же. Почему его за это "самописным велосипедом" не назвать бы?
> ...со спеками на 6000 страницДа. Так и ODT к этому подбирается.
А то как новость про новый формат ODT. Так там постоянно что-то что в MSO уже двадцать лет есть.А потом конечно вся это очень сложная штука кривит и ползёт. Тоже самое что с CSS в браузерах.
Так-то на простых задачах не бабахает, когда мы в рамках RTF. Ну может ещё таблицы простые без оформления.
А как сложнее, то привет. У сложных задач нет простого решения. И ODF это тоже касается.
Зачем нужен JSON там, где его никогда не читает глазами человек? Для увеличения объема данных раз так в 6-10 ?
$GIT_DIR/config предназначен для человека. Если бы не предназначался, то было бы проще его оформить в бинарном виде безо всяких JSON. Хотя бы минимально изучай тему, тогда удастся не приземляться с грохотом на лужу.
> $GIT_DIR/config предназначен для человекаА json?
А json предназначен для удобной сериализации сообщений при передаче из точки А в точку Б.
Отсутствие комментариев в дизайне как бы намекает.
Да, с некоторой (но гораздо скромнее чем в XML) избыточностью. Зато с возможностью кожаного мешка влезть в процесс с минимальным инструментарием (jq например).Разумеется, конфиги тоже можно так хранить (как частный случай передачи сообщений). Но в первую очередь те что программа сохраняет сама для себя.
Для человекообразных придумали TOML. В простых случаях можно ограничиться "INI" или YAML.
Нотации вида "ключ = значение" получили широкое распространение хотя бы потому что прошиваются в голову в рамках школьного курса математики.
> Вот что бывает, когда вместо JSON используешь свой нескучный формат со своим
> нескучным парсером.Коректно парсить все приколы которые JSON позволяет - это целый отдельный квест. Далеко не любая программа вообще готова сжевать произвольно слепленый JSON без тех или иных спецэффектов.
CVE-2023-25815
переполнение буфера при обработке специально оформленных файлов
Не, ну как же без этого...
> избегать выполнения команды "git apply --reject"Даже не знал о такой :)
Просто строку обработать... C программисты во всей красе, лишь бы не аллоцировать кучу, зато сразу 5 CVE'шек на ровном месте.
Перепиши на Rust
Уже переписали, надо попробывать разные имплементации
Ошибку сами найдёте? (строго говоря, две, но сперва хотя бы очевидную)
Почему вы ищите ошибки в написании, когда у вас у самого море ошибок в мышлении. Но да, за то знаете как писать. И скорее всего, эти знания только в этой области ограничивается. (В каждой дырке - затычка)
Шегорин знаток языков программирования, он на них собаку съел. И в архитектурах процессоров разбирается лучше всех. Не совсем ясно почему он позорным мейнтенером при этом работает, а не программистом и не разработчиком железа... я думаю это изза поцреотизма, а не потому, что на самом деле он нихрена не понимает ни в чём.
> Перепиши на RustТак уже есть:
Ты Byron? Просили тебя переписать, а не тыкать в чужое переписывание.
C'mon please help me doctor git -
Моя бошка уже болит...