URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 125739
[ Назад ]

Исходное сообщение
"Атака Trojan Source для внедрения изменений в код, незаметных для разработчика"

Отправлено opennews , 01-Ноя-21 22:01 
Исследователи из Кембриджского университета опубликовали новую технику незаметной подстановки вредоносного кода в рецензируемые исходные тексты. Подготовленный метод атаки (CVE-2021-42574) представлен под именем Trojan Source и базируется на формировании текста по разному выглядящего для компилятора/интерпретатора  и человека, просматривающего код. Примеры применения метода продемонстрированы для различных компиляторов и интерпретаторов, поставляемых для языков C, C++, C#, JavaScript, Java, Rust, Go и Python...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56083


Содержание

Сообщения в этом обсуждении
"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено InuYasha , 01-Ноя-21 22:03 
o_O
Три раза прочитал на превьюхе Satan прежде чем понял, что это Safari. Возможно, из-за его околонулевой популярности )

А по сабжекту - ну, ждём патчей для Студии.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено QwertyReg , 01-Ноя-21 22:46 
> Возможно, из-за его околонулевой популярности )

Лол, это с учётом того, что он в 6 раз популярнее Firefox?


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Rev , 01-Ноя-21 23:21 
Вынужденно :(

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 01:02 
Среди попу'лярных.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 01:47 
Это где, на 15% яфончиков, где запрещено ставить нормальные браузеры?

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 03:32 
Большинство из тех, доя кого он популярен, даже не подозревают о существовании "сафари", для них он " айфон".

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено ryoken , 02-Ноя-21 08:16 
>>доя кого

Очень правильная опечатка, ящитаю :D.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено MsGod , 02-Ноя-21 08:17 
В макси - сафари топовый браузер.
Впрочем гнутым с их корявыми поделками с ужасными шрифтами не понять

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 09:27 
когда привыкаешь к никакующему хитингу глифов в макоси тогда для тебя все остальное кажется инородным угу.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 12:23 
Да тут речь не о топовости и шрифтах... впрочем единственной прямой извилиной это не понять.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 23:02 
Для большинства яблоюзеров
Сафари - просто интернет
100500 раз слышал ответ
на вопрос "каким ты браузером пользуешся?" )))

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено X86 , 07-Ноя-21 08:06 
Так у них там и chrome - это safari. Никакой разницы)

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено trdm , 02-Ноя-21 08:55 
Переходите на Notepad++. Там уже это реализовано..

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено ОШИБКА Вы забыли заполнить поле Name. , 01-Ноя-21 22:07 
Не баг а фича.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 01:09 
Особенно для раста с его крейтами из онлайн-хранилищ.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Прохожий , 02-Ноя-21 07:06 
Раст уже починили (добавили опцию соответствующую), и все крейты проверили.
Да и вообще, вредоносный код можно подхватить, где угодно. И его надёжность от способа распространения не зависит. Но тебе же надо было в очередной раз прогазифицировать лужу зачем-то.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 08:10 
Ну так делай тогда вывод: Раст такой же небезопасный как и все языки.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено bOOster , 02-Ноя-21 08:37 
ТОлько со значительно большим гиммором в системном программировании.
Каждому языку свое применение.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 09:22 
Есть языки у которых нет реального применения.  

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено bOOster , 02-Ноя-21 09:28 
> Есть языки у которых нет реального применения.

Если язык появился - значит у него БЫЛО, но сплыло применение. Эволюция однако. ..опой чтоли думаете когда пишете такие комменты?


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 09:38 
Какое у брейнфака или у yoptascript было применение и куда оно спыло? Такое ощущение что ты в каждой ерунды ищешь скрытый смысл, которого нет.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Урри , 02-Ноя-21 10:45 
Мозги развивать.
Попробуй, возможно тебе понравится.

Например, тривиальная задача - написать на брейнфаке (машине тьюринга) умножение двух беззнаковых 8-битных чисел. А если покажется слишком легкой - то написать брейнфак на брейнфаке.

Лучшей физкультуры для ума вряд ли придумаешь.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 16:30 
Брейнфак не с целью развития мозгов создавался.)) Это простейшая и минимальная виртуальная машина для тьюринг-полного языка. Челендж такой был у создателя, и он его достиг своим компилятором в 240 байт. Никакого практического, или идейного смысла "программирование на брейнфаке" не несет. Впрочем, его можно выдумать, что ты и сделал. С растом та же фигня.))

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Урри , 02-Ноя-21 17:44 
Судя по твоему комментарию и смайлам - для тебя таки не несет.

А для остальных - несет, да еще как. С его помощью наглядно можно показать саму идею вычислительного устройства (упомянутая уже машина тьюринга), на коей базируются все без исключения вычислители.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено freecoder , 02-Ноя-21 12:05 
> Ну так делай тогда вывод: Раст такой же небезопасный как и все
> языки.

Раст был такой же небезопасный как и все языки в отношении данного CVE.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 01-Ноя-21 22:07 
Как всегда vim победил, а говно-перделки на электроне где-то в жопе

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено a. , 01-Ноя-21 22:17 
Кафирный вим не даёт читать на языке правоверных.

А по делу. Это ж как надо кодревью проводить что бы игнорировать сомнительные комментарии.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 01-Ноя-21 22:19 
> Как всегда vim победил,

*смотрит на точно такой же результат SublimeText*
Но только в фантазиях вимеров.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено myhand , 02-Ноя-21 04:25 
Где vim победил, фантазер?

Показывает криво, также как и emacs, увы.  Проверял на их питоновских тестах.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 07:54 
C код: 8.2.3455 -- показывает **без** перекрытия.  То есть видно, что будет "видно" компилятору.  На python'овских тестах не смотрел.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 09:26 
Безопасный язык это как безопасная бензопила что-то из области фантастики.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Урри , 02-Ноя-21 17:46 
Самое забавное в этом комментарии - "+29" оценка.

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


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 03-Ноя-21 13:00 
Скорее ты вообще не врубаешься кто и зачем тут ставит плюсики. )

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 01-Ноя-21 22:16 
Хакер и солонка, 100500я серия...

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Жироватт , 02-Ноя-21 09:41 
Эх, как же нрацца это шоу.
То скрипты-плагины в хоме объявят главным мировым злом, то юникод обплюют за RTL и символы разных алфавитов, так похожие на латиницу...
Гарсон, еще попкорна!

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Michael Shigorin , 01-Ноя-21 22:17 
> в современном текстовом редакторе, web-интерфейсе или IDE

:q!


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено морошка ягодка такая , 01-Ноя-21 22:21 
ZQ надо

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено kusb , 01-Ноя-21 22:30 
killall -9 vim

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 04-Ноя-21 15:43 
sudo rm -f /sbin/vim

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено морошка ягодка такая , 01-Ноя-21 22:22 
ZQ надо

Дурацкий вим. Лет 5 уже не пользуюсь, но машинально через каждые 10 секунд нажимаю esc


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено kusb , 01-Ноя-21 22:32 
Звучит реально неприятно. Как ОКР какое-то...

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 08:13 
Обычная мышечная память. Как выключатель на кухне, если заходишь в другую кухню всё равно свет пытаешься включить так как запомнил.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 12:14 
Надо продолжать пользоваться -- тогда все ESC пригодятся и проблем не будет.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено pansa2 , 02-Ноя-21 22:48 
А я не могу выйти из nano :(

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 02:44 
Всегда думал что у пользователей, в первый раз зашедших в vim без подготовки, должно быть лицо к этот "смайлик".

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено InuYasha , 02-Ноя-21 10:13 
Смайлик :q символизирует либо облизывание, либо закусывание языка от интенсивного труда. Почему-то мне кажется, что в здесь актуальнее второе )

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено myhand , 02-Ноя-21 04:14 
C-c C-q

А вот гитхабчик, кстати, показывает "This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below."


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено имя_ , 01-Ноя-21 22:20 
багофича

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено freecoder , 01-Ноя-21 22:24 
В Rust уже пофиксили: https://blog.rust-lang.org/2021/11/01/cve-2021-42574.html

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено О.Тсо.Сишник , 01-Ноя-21 22:29 
> В Rust уже пофиксили: https://blog.rust-lang.org/2021/11/01/cve-2021-42574.html

А для Си CVE? Нету? То-то! Очередная расто-дырка!
Выкусите, растаманы!


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 01-Ноя-21 22:48 
Ваще-то это во всех компиляторах

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Ivan_83 , 01-Ноя-21 23:25 
Просто С/С++ имеет далеко не один компилятор.
А в случае с крестами там ещё коммитет бездельников есть, который будет натужно думать не сломает ли такое поведение что то.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 08:05 
О да запретить комментарии на иврите и арабском это же так просто и точно ничего не сломает. Лол ржу в голос.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 08:05 
Как такое вообще могло быть в самом безопасном языке в галактике? Ой так нифига он небезопасный язык как язык на уровне Nim.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Растоманя , 02-Ноя-21 08:57 
Что такое Nim?

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 09:35 
Это современный, безопасный язык системного программирования.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено freecoder , 02-Ноя-21 12:33 
Безопасность - это не состояние, а процесс. Nim до Rust как до Луны.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Урри , 02-Ноя-21 10:51 
В раст снова быстро влепили какую-то заплатку, не относящуюся напрямую к языку. Аджаааааааайл!

А-ха-ха-ха-ха-ха-ха.
А проверку времени перехода на зимнее/летнее время и правильный цвет носков программиста туда еще не добавили?


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Enamel , 02-Ноя-21 12:31 
Я уже обновил компилятор своего языка с исправлением, а ты своего?

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Урри , 02-Ноя-21 17:48 
А я пишу на лиспе и мне как-то все равно.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено deeaitch , 02-Ноя-21 19:08 
Нет, не пофиксили, всё ещё работает.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 01-Ноя-21 22:26 
рили? за такой код нужно нещадно бить по рукам!

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


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено myhand , 02-Ноя-21 04:22 
> во-первых, код должен быть самодокументируемым.

Мамкин погромист писал что-то сложнее хеллоуворлда?

> только многострочные, только с новой строки

Это не поможет, если я правильно понимаю метод.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 05:46 
>> во-первых, код должен быть самодокументируемым.
>Мамкин погромист писал что-то сложнее хеллоуворлда?

Понять содержимое метода обычно нетрудно. Все ведь умеют читать! Но это только при условии, что документация на каждую функцию и структуру есть в .html/info. Комментарии внутри функций как правило бесполезны, если там какой-нибудь WARNING/TODO/HACK не написан. Право на жизнь имеют только псевдокомментарии для автоматического генератора документации, но если она локализирванна и требует юникода, то этот код будут хейтить все программисты мира.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено myhand , 02-Ноя-21 07:46 
>>> во-первых, код должен быть самодокументируемым.
>>Мамкин погромист писал что-то сложнее хеллоуворлда?
> Понять содержимое метода обычно нетрудно. Все ведь умеют читать!

На, читай:
https://www.researchgate.net/publication/221564800_On_factor...

Буржуинский-то хоть знаешь, гуру? :)

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

Такое впечатление, будто все "программисты мира" (тм) (r) сидят в каких-то допотопных
консолях с шириной экрана в 80 символов и ASCII.  Вот только прокрутку в Linux-консоли
поддерживать почему-то было некому...


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 08:15 
А тебе не приходило в голову что это не из-за консоли, а из-за того что так просто удобнее читать код. Нет? ну подумай об этом на досуге. Заодно о своём стайлгайде как ты думаешь почему твой разорви экранный код удобно читать только тебе?

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено myhand , 02-Ноя-21 08:49 
> А тебе не приходило в голову что это не из-за консоли, а
> из-за того что так просто удобнее читать код. Нет?

Тебе вот что удобнее было бы читать?  alpha или α?  А если
формула с однобуквенными обозначениями
один-в-один совпадет с тем, что написано в статье, а всякие
alpha, beta, гаммы - сделают ее на пяток строк, вместо одной?

> Заодно о своём стайлгайде как ты думаешь
> почему твой разорви экранный код удобно читать только тебе?

На основании чего ты так подумал?


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 09:40 
> На основании чего ты так подумал?

Есть такая штука она называется "Логика" погугли на досуге, но до тебя она точно не дойдет.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено myhand , 02-Ноя-21 10:01 
Логика, мой дорогой юный друг, не может работать без некоторой базы фактов и правил.  Какова она в твоем случае?

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Тот_Самый_Анонимус , 02-Ноя-21 14:17 
>Тебе вот что удобнее было бы читать?  alpha или α?

Мне удобнее «альфа», а не латинизированное алпха. И?


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено myhand , 02-Ноя-21 15:03 
"альфа" - в ASCII не влазит, тоже харам.  И размер формулы вряд-ли сильно скукожит.

> И?

Да ничего.  Главное, чтоб ндравилось.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Тот_Самый_Анонимус , 02-Ноя-21 16:37 
>"альфа" - в ASCII не влазит

И чо? Значит аски — не нужен.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Ordu , 02-Ноя-21 12:09 
> А тебе не приходило в голову что это не из-за консоли, а из-за того что так просто удобнее читать код.

Приходило. Но как показывают исследования, программисты читают комментарии. eye-tracker'ом следили за программистом, изучающим код, и чётко показали, что программисты читают комментарии. Если бы комментарии только мешали, они бы не читали их.

Тут я могу встречный вопрос задать: а тебе не приходило в голову, что комментарии могут быть полезны? И если приходило, то какие действия ты предпринимал, чтобы найти ответ на этот вопрос?

Ты сам пишешь выше:
> Комментарии внутри функций как правило бесполезны, если там какой-нибудь WARNING/TODO/HACK не написан
> как правило

Да, как правило. Но это одно из тех правил, которые выполняются в 95% случаев, и всегда остаются неустранимые 5% других случаев, когда комментарии нужны.

> какой-нибудь WARNING/TODO/HACK

Во-во, например в этих случаях. Или, скажем, когда ты используешь какой-нибудь совсем не очевидный алгоритм. Из тех, которые ты вычитал в статье по мотивам диссертации на PhD, и два дня переваривал статью, чтобы понять, как вообще это работает. И после этого, ты реализовал алгоритм оттуда на выбранном языке программирования, добавил в начало кода ссылку на статью, дал краткое, упрощённое объяснение основной идеи алгоритма, а потом ещё в своей реализации расставил комменты вида "тут мы используем адаптированный баблсорт, потому что массив почти отсортирован (максимум два элемента могут быть не на месте), и баблсорт в таком случае порвёт все квиксорты" или "этот цикл соответствует врезке кода 3.2 из статьи".

Код надо писать так, чтобы когда ты через полгода будешь читать этот код, ты бы смог разобраться в нём минимумом усилий. Не гадать почём зря "а не будет ли здесь квиксорт быстрее", или о том "что это за хрень такая, и где об этом в статье написано".

Хочешь ещё примеров, когда комменты внезапно оказываются нужны? Неочевидный edge-case, ради которого тут надо поставить проверку, и совершить пару дополнительных телодвижений, или наоборот прервать работу раньше времени. Иногда проверка на неочевидный edge-case делает edge-case очевидным, но не всегда. В некоторых случаях это выглядит бессмыслицей: "ну и что, что node->depth % 3 == 2"? Чем нам ноды с глубиной равной двум по модулю три не угодили? Тебе не приходилось сталкиваться с таким? Когда одна дурацкая непонятная проверка требовала остановиться, и десять минут сочинять такой случай, когда она сработает, и потом ещё полчаса думать, почему в этом случае надо досрочно завершать работу алгоритма с ошибкой? Гайды по работе с кодом, часто в таком случае рекомендуют, разобравшись в случае, проконсультироваться с другими о том, правильно ли ты понял, и дописать в код комментарий, изложив вкратце свои находки, с тем чтобы следующий, кто будет читать этот код, не тратил бы столько времени на понимание.

Или, скажем, коммент вида "здесь нет нужды проверять всю эту кучу указателей на NULL, а индексы на выход за границы, потому что..." и далее следует какое-то объяснение этому.

Или тебе всё это вышесказанное ни о чём не говорит? Твоё мышление догматично, и ты слепо веришь признанным авторитетам? Ок, давай зайдём с этой стороны. Для тебе Торвальдс авторитет? Открой CodingStyle linux и почитай там, что написано о комментах. И ты увидишь там что-то типа (я по памяти, сорри): комменты нужны на top-level'е, перед функцией, и они должны отвечать на вопрос "что?" -- что функция делает; комменты в теле функции нежелательны, но если они есть, они должны отвечать на вопрос "как?" -- как функция делает то, что она делает; комменты внутри нежелательны, потому что код должен быть самоописательным, но иногда это невозможно -- есть семантический разрыв между кодом и задумкой программиста, и его не всегда можно устранить переписав код иначе, и в таких случаях, комменты нужны. CodingStyle linux не запрещает комменты, более того явно разрешает, оговариваясь при этом, что по-возможности надо писать так, чтобы комменты были бы не нужны.

Но догматизм или нет, CodingStyle linux'а заточен под C и 80x25 окно текстового редактора. Первое просто не обсуждается, а второе -- технические ограничения из 90-х. (Если ты почитаешь внимательно этот CodingStyle, то увидишь прямые отсылки к этим самым техническим ограничениям). Сегодня эти технические ограничения неактульны (глянь на это[1], например), а C используется не во всех проектах. В C++, например, 80 строк -- это дурацкое ограничение которое не работает, потому что строчки длинее, там может быть что-нибудь типа for(auto iter = my_collection.begin(); iter != my_collection.end(); iter ++), и это что-то может оказаться на два-три уровня идентации сдвинуто. Отчасти это забарывают отказом от табов шириной в 8 пробелов, но даже этого часто недостаточно. И ежели ты сегодня начинаешь новый проект, я тебе очень серьёзно рекомендую подумать о том, чтобы ограничить ширину строки значением побольше -- чем-нибудь из диапазона 90..110.

[1] https://blog.immersed.team/working-from-orbit-39bf95a6d385?g... Если лень читать эту стену текста, то поиском по странице поищи "glance" и позырь на скриншот. 80x25? Хаха.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Урри , 02-Ноя-21 12:16 
Вы прослушали короткую вырезку из "Стив Макконел. Совершенный код".

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Урри , 02-Ноя-21 12:13 
А я использую редактор кода, а не less.
И в нем есть комбинация 'Alt+Z', которая включает автоматический перевод слишком длинных строк.

Удобно! Попробуй.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено OpenEcho , 01-Ноя-21 22:37 
Самое прикольное, что эта техника применяется хакерами как миниум лет 5.
Кто анализироавл взломы, то наверняка сталкивались с чудесами в сырцах на пыхе, питоне благодаря этим "вперед/назад" спецсимволам...

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним84701 , 01-Ноя-21 22:51 
> Самое прикольное, что эта техника применяется хакерами как миниум лет 5.

Еще лет 10 назад так (RLO - Right to Left Override) прятали палевные окончания scr,exe и (т.д.) для малвари.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 08:07 
даже 20 лет назад применяли непечатаемые символы в экселе и всё работало.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено _kp , 02-Ноя-21 11:25 
Почти 40 лет назад, еще на ZxSpectrum применяли нечитаемый или частично скрытый исходник.
Все теми те способами, управляющие символы в исходном коде. :)

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 01-Ноя-21 22:45 
А потому что нехер пропихивать в utf8 (и юникод в целом) всякое дерьмо. Сюда же современные opentypeвые шрифты, которые уже стали мини программами - сливания в лигатуры и прочая-прочая. Реально хочется огородиться в koi8r.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Ivan_83 , 01-Ноя-21 23:27 
Фу!
Только ASCI!

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено ryoken , 02-Ноя-21 08:18 
>>ASCI

ASCII же.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Тот_Самый_Анонимус , 02-Ноя-21 14:22 
Лови предателя!

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 01-Ноя-21 23:52 
Ну, тогда опеннет для тебя один из последних островков счастья.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено myhand , 02-Ноя-21 04:23 
> А потому что нехер пропихивать в utf8 (и юникод в целом) всякое дерьмо.

Вы антисемит?!


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 23:48 
Я не против даже 2байтовых кодировок, когда мой Я против кодов модификаторов. Еле-еле устаканилились концы строк CR+LF, а тут изощренность в квадрате. Это просто источник бездны ошибок в реализации, неочевидной техники применения, приводящей к неожиданным эффектам.
Всё равно, что сказать человеку, чтобы тот обходил зимой озеро по берегу, а не шлёпал по льду, потому что видите ли у него снегоступы и вообще всё продумано. На раз 20ый провалится.
Дебилы, б..дь (с) Лавров, б..дь.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 23:50 
>Я не против даже 2байтовых кодировок, когда мой

когда мой текст будет занимать в 2, 4, да хоть 8 раз больше против условных 7ми-, 8битных кодировок.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено myhand , 04-Ноя-21 12:14 
Что мне делать, если в середине ответа я пожелаю таки обматерить тебя на иврите?

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 04-Ноя-21 23:36 
Обматерить меня на иврите с начала новой строки? Я могу придумать применение смены направления письма по середине строки, но как по мне, всё это очень не консистентно и усложняет коммуникацию больше, чем решает проблем.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено myhand , 06-Ноя-21 15:46 
Мат (на любом языке) порой катастрофически упрощает коммуникацию.  Это я вам говорю.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 06-Ноя-21 19:31 
Я не против мата.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 08:08 
Люди виноваты что не могут писать все 256-ю символами. Напридумывали языков, шрифтов, написаний вот гады.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 10:37 
А нечего было Вавилонскую башню строить.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 11:22 
Пусть своими языками на заборе пишут, а в исходниках ASCII.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено другой аноним , 04-Ноя-21 23:29 
Реально видел на заборе слово БНАПНЯ (sic!). Использование заборов от проблем с кодировками не спасает, увы.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 23:55 
Расскажи это емодзи с модификаторами на цвет кожи. Математика, cjk символы и прочие текстовые прелести, естественно, я не предлагаю резать ради того, чтобы уложится в 8 бит, допустим.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 01-Ноя-21 22:55 
Это косяки программ редакторов. Текст с направлением справа налево должен просто печататься задом наперед, но не должен залазить на предыдущий тескт. А про всякие буковки это мы и так знаем. Они прямо америку открыли. О нормализации юникода никогда не слышали?

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 01-Ноя-21 23:30 
А как именно Misrendered в vim в Linux? Кодировка что ли кривая и вопросик показывает?

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 01-Ноя-21 23:31 
А, виноват, слепой - это в Windows. Тогда нет вопросов.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Михрютка , 01-Ноя-21 23:43 
>>>предложен ещё один вариант атаки (CVE-2021-42694), связанный с использованием омоглифов

День 96-ой

Директор покупает специально спроектированные солонки с кодовым замком. Посетители столовой чувствуют, что они в этой жизни чего-то не понимают.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 01:55 
Поэтому и появился язык Ада. Он в том числе разрабатывался для точной читаемости кода.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Урри , 02-Ноя-21 11:02 
Вот здесь http://rosettacode.org/wiki/Category:Ada куча готовых решений различных небольших (и больших) задач на Ada.
Например, обычный бинарный поиск http://rosettacode.org/wiki/Binary_search#Ada

Не сказал бы, что там такая уж "точная читаемость кода" - паскаль паскалем.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 11:23 
Соотношение сигнал/шум традиционно ужасное.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено pavlinux , 02-Ноя-21 02:18 
> опубликовали новую технику

Скуяли она новая? Детский баян конца 80-х - 90-х годов.


#include <stdio.h>\b\b\b\b\b\b\b\b\b /*\b\b "stdio.h" */\b\b

Препроцессор видел как:  #include "stdio.h"

Бэкспейсы естественно в гексах.
MS Word под DOS, или Нортон Командер из первых, бэкспейсы в сишниках (*.с, *.h, ...) игнорили
и отображали как пробелы. В Дельфи тоже было, в Борланде...

Самой "технике" уже 3000-4000 лет....

Да чо там, Ильич на нарах писал молоком. )))  


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено burjui , 09-Ноя-21 12:33 
> Ильич на нарах писал молоком

Хотел спетросянить, но чудом удержался.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Alexey , 02-Ноя-21 02:34 
Вопрос был описан на Хабре лет несколько назад (давно уже). После чего я добавил в CudaText лечение - все эти символы показываются теперь явно хекс-кодами...., да и до этого наложения там не было, просто символы пропускались при рендере. Из того поста на русском никакого CVE никто не соорудил. В комментах хабра пожевали тему, пожевали, и разошлись по норкам....

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено pavlinux , 02-Ноя-21 02:36 
> Вопрос был описан на Хабре лет несколько назад

[censored]


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Alexey , 02-Ноя-21 11:43 
Что сказать то хотел? :)

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено pavlinux , 04-Ноя-21 13:44 
> Что сказать то хотел? :)

Там (18+) ))


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 02:38 
Для контента и там текстов ресурсов Unicode - штука незаменимая, но в исходниках не нужно и стоило бы на входе в компиляторы просто ставить какой-то фильтр.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено pavlinux , 02-Ноя-21 02:44 
> на входе в компиляторы просто ставить какой-то фильтр.

Компилятор компилит то, что в него суют.
Конктретно в Cи, UTF-8/16/32 ещё надо уметь пропихнуть через wchar,
printf("%s\n", "我動搖了你"); не везде прокатит ))



"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 05:03 
По идее линтер не должен такоеьпропучкать.
И по подсветке кода можно увидеть что что-то не так.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 03-Ноя-21 09:46 
По идее спелчекер тоже не должен пропускать всяческие "такоеьпропучкать", а поди ж ты.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 07:50 
>> В качестве меры для защиты рекомендуется реализовать в компиляторах, интерпретаторах и сборочных инструментах, поддерживающих Unicode-символы, вывод ошибки или предупреждения при наличии в комментариях, строковых литералах или идентификаторах непарных управляющих символов, меняющих направление вывода

А писать на RTL-языках такие запреты не помешают?


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 11:27 
Национальные символы в исходниках должны быть только в файлах .po
За все остальное пороть на конюшне.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Alexey , 02-Ноя-21 11:44 
Не. Символ "троеточие" - который юзается на концах строк меню - юникодный.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 11:51 
Запишешь кодом символа. Юзеру всё равно, а у тебя читабельный текст.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 08:03 
А еще есть непечатаемые символы. Вот где не паханое поле для злоупотреблений.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 10:27 
Нет. Они просто пропускаются при рендере или там например накладывают один глиф на следующий.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 03-Ноя-21 09:48 
А кое где они часть языка, прикинь?

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 08:25 
Данный троян используется с расчётом на невнимательность программиста. Просто надо либо //, котрый работает до конца строки, либо /* за которым может быть только 2 символа */.

Старый трюк. Например, шрифт в терминалах должен визуально отличать символы: "латинский эл" и "цифра единица". Букву "о" от "цифры ноль".


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 08:43 
Всегда ли программист просматривает уже отлаженные исходные коды перед сборкой, особенно если проект достаточно крупный? Вопрос риторический.

И второй вопрос. Не является ли хранение исходных текстов на внешних сервисах благоприятным фактором для реализации сабжа, особенно если взлом может быть не зафиксирован длительное время?


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Растоманя , 02-Ноя-21 08:46 
Это делает борроф чекер

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 09:34 
Вот чем чем, конкретно этим борроу чекер точно не занимается. В Visual Studio например этим может заниматься c++ core check. И в него же добавить правила про юникондные символы.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 13:07 
>Вопрос риторический.

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


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Тот_Самый_Анонимус , 02-Ноя-21 14:28 
>Всегда ли программист просматривает уже отлаженные исходные коды перед сборкой, особенно если проект достаточно крупный?

Так эта техника против тех, кто _смотрит_ код. Против тех, кто не смотрит, можно просто вносить правки, не опасаясь обнаружения.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 09:24 
анализатор сравнения набранных символов к отправляемым?
сравнениие сумм файла?
запись/чтение в изолированном окружении?
велосипед?

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 10:29 
Обкуреный бред программиста, который не может выразить мысль.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 10:48 
Хиленько.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено keydon , 02-Ноя-21 11:21 
Сначала запихивали все что можно в юникод, а теперь удивляемся что там больше чем хотелось бы. Накину еще - символы (или их комбинация) не поддерживаемые конкретной либой, символы неотличимые визуально от других символов (впрочем сабж), разные пробельные символы которые парсятся одной либой, но другой считаются за непробельные.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Alexey , 02-Ноя-21 11:47 
То что ты "накинул еще", не дает проблем с секурити, не дает CVE.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено keydon , 03-Ноя-21 02:16 
> То что ты "накинул еще", не дает проблем с секурити, не дает
> CVE.

Не дает но предрасполагает, что в реальном мире фактически дарит эти проблемы.
Так то если ты все везде будешь правильно проверять и обрабатывать то и Trojan Source для тебя невозможен, но дефакто вот он в новости.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 13:10 
На Юникод не наезжай, это правильная технология, он тут не причём. Ты как маленький виноваты все, но не ты сам.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено keydon , 03-Ноя-21 02:10 
Что ж в этом правильного?
1) Что-то много стандартов кодировок. Надоело! Давайте сделаем одну, пускай и медленную, но со всем фаршем! А нет, что-то не идет. Давайте еще к ней еще наклепаем пару кодировок! Да! UTF-8. А давайте еще UTF-16! А еще UTF-32! А еще 2 вида BOM добавим! А еще кривую реализацию для винды! Больше кодировок юникода! Больше!
2) Давайте кодировать как можно компактнее? Не, бред какой-то лучше давайте каждый символ, даже очень похожий будет кодироваться по отдельности? Ну чтобы различать эти символы. Разработчики железа уже за нас заплатили, гулять так гулять. Минуточку, а почему сербская А КОДИРУЕТСЯ как русская А? А польское А это английское А? Ммм... логично? Не очень. Просто живи с этим. Но в большинстве других символов это не так. Мы сделаем тебе несколько одинаковых крестиков с разными кодировками.
3) А давайте запихнем в юникод знаки вымершей цивилизации, алхимические знаки, древнеегипетский или древнепермское письмо http://unicode.org/charts/PDF/Unicode-7.0/U70-10350.pdf! Ну и еще бесконечные эмодзи (эти хотя бы как-то используются, но имхо это довольно костыльно).
4) Так давайте добавим символы заставляющие текст писать справа налево (ха-ха, посмотрите на этих жалких разработчиков библиотек для нашей кодировки), но не добавим символов чтобы писать сверху вниз и снизу верх! Ок, все равно я никогда не любил китайцев.
5) Так, у нас столько всего есть, а где взять библиотеки чтобы это отобразить? Удачи, это не наше дело. Встретимся через пару-десятков лет когда научишься хотя бы тестировать юникод.
6) Подскажите шрифт для юникода? Для латиницы вот эти, для русского вот этот, вот этот для математических символов...
7) А помните мы решили для каждого символа сделать свою кодировку? Что-то пошло не так, хакеры выдают xn--ggle-55da.com (о русская) за google.com за google.com.
Ну и что мы имеем? Гору библиотек разной степени безопасности, кривизны, функционала и производительности, несколько видов самого протокола, множество проблем как при его использовании, так и при работе с ним, и все равно есть проблемы с локализацией условного канадского диалекта французского.

Итого семейство юникода худшее семейство кодировок:
Производительный: нет
Компактный: нет
Простой: нет
Безопасный для копирования: нет
Безопасный для приложения: нет
Решил проблему с языками: нет
Поддерживается шрифтами: нет
Специализирован: нет
Стал всемирным стандартом-горцем: нет
Можно добавить свой символ за мешок денег: да
Придется вам жить с этим: да

> Ты как маленький виноваты все, но не ты сам.

Я просто вижу очевидные проблемы и говорю о них. Немного грустно что пришли к такому !@#$%, но искать виноватых я не намерен. И уж тем более мне не понятно в чем моя вина. Вот если бы заткнулся и восхвалял очевидно проблемную кодировку, то тут можно было меня обвинить в апатии.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 03-Ноя-21 08:05 
>Что ж в этом правильного?

Юникод рационален, поэтому правилен.

>Что-то много стандартов кодировок. Надоело! Давайте сделаем одну, пускай и медленную, но со всем фаршем! А нет, что-то не идет. Давайте еще к ней еще наклепаем пару кодировок

Флуд. А если по делу, то UTF-8 придумали отцы юниксоиды специально для англоговорящих стран, в нём неиспользуемые, или же малоиспользуемые символы кириллицы кодируются дополняющимися битами. Китайцы выбрали UTF-16 и UTF-32 потому-что их иероглифы не помещаются в 8 бит.

>А еще 2 вида BOM добавим!

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

>А давайте запихнем в юникод знаки вымершей цивилизации, алхимические знаки, древнеегипетский или древнепермское письмо

Что предлагаешь? Исследователям и учёным вместо символов векторные картинки всталять, ты серъёзно?

>Так давайте добавим символы заставляющие текст писать справа налево

Арабский мир щемишь? Они же с лева направо пишут.

Ты видимо решил процитировать всю Википедию? Ешё раз тебе говорю, Юникод - дна из самых лучших вещей, которое сделало человечество.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено keydon , 03-Ноя-21 13:17 
>>Что ж в этом правильного?
> Юникод рационален, поэтому правилен.

От того что вы называете его рациональным, рациональнее он не становится.

> Флуд. А если по делу, то UTF-8 придумали отцы юниксоиды специально для
> англоговорящих стран, в нём неиспользуемые, или же малоиспользуемые символы кириллицы
> кодируются дополняющимися битами. Китайцы выбрали UTF-16 и UTF-32 потому-что их иероглифы
> не помещаются в 8 бит.

И что это меняет? У нас есть 3 довольно сильно отличающихся кодировки и еще 4 вариации с различным BOM.

Как мы можем определить длину последовательности?
1) Зафиксировать длину (быстро, не расширяемо)
2) Обозначить динамически символом (зато все поместится)
Что делает юникод? Он для толстого UTF-32 ФИКСИРУЕТ длину кода, а для UTF-8 и UTF-16 НЕ ФИКСИРУЕТ длину кода. Так что и в микроконтроллеры не засунешь и гигабайты текста не сэкономишь на суперкомпьютере. И не быстрый (потому что диакритические знаки, парные символы, регистр превращает в другой символ, вот это все) и не ультимативно функциональный (потому что что-то недопихали) и не простой (потому что фарша гораздо больше чем может переварить большинство разработчиков).

Немного про нейминг:
UTF-8 с динамической длинной кодирования 8 бит (вообще-то больше, но потом его ограничили. зачем?)
UTF-16 с динамической длинной кодирования 16 бит
UTF-32 с фиксированной длинной кодирования в 32 бит. WHAT? Почему же он называется также как и UTF-8 и UTF-16? Я могу решить что он тоже с динамической длиной.

Также и с BOM напрашивается 2 стратегии:
1) всегда один и тот же BOM (хорошо для стандартизации и обмена)
2) для разных архитектур разный BOM (хорошо для производительности на некоторых архитектурах, плохо для всего остального)
Что делает Юникод для UTF-16 и UTF-32? Правильно не стандартизирует и не претендует на скорость. Т.е. худшее из двух миров.

Зачем вообще нужен UTF-32 если он и не быстрый и все алфавиты не покрывает, но включает много чего ненужного? Да никто не знает. Он просто есть.

>>А еще 2 вида BOM добавим!
> Ты ошибся адресом, Юникод тут не причём. Отправляй претензию программистам текстовых редакторов.

Не знаю повлияли ли как то на это текстовые редакторы, но виды BOM зафиксированы в стандартах юникода. Если их не под пытками добавили, то я по адресу.

>>А давайте запихнем в юникод знаки вымершей цивилизации, алхимические знаки, древнеегипетский или древнепермское письмо
> Что предлагаешь? Исследователям и учёным вместо символов векторные картинки всталять,
> ты серъёзно?

А ты серьезно предлагаешь сначала на основании недостаточной длины кодирования символа придумать новые кодировки (UTF-16, 32), а потом забивать пространство "кодировки 21 века" плохоизученным древнегипетским? Завтра откопают альтарь ктулху, его символы тоже будешь добавлять? А что насчет графиков? Их тоже векторными картинками вставлять? Зачем такие полумеры? Может тогда сразу к растру перейдем - как кодируется, так и рисуется? Кроме того я не видел в научных кругах никого кто писал бы формулы юникодом (и ты тоже так не делаешь).

>>Так давайте добавим символы заставляющие текст писать справа налево
> Арабский мир щемишь? Они же с лева направо пишут.

Нет, китайцев. Они же сверху вниз пишут и для них ничего такого нет. Или древних ливийцев.  Логично что для кого-то есть а для кого-то нет?

> Ты видимо решил процитировать всю Википедию? Ешё раз тебе говорю, Юникод -
> дна из самых лучших вещей, которое сделало человечество.

Повторяй это почаще.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено А , 05-Ноя-21 19:51 
Арабский мир пишет справа налево (только цифры слева направо)

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Урри , 03-Ноя-21 10:33 
Начать надо с того, что вы не отличаете понятия "кодовая страница" и "кодировка".

Чтобы было понятнее, считайте, что UTF-8, UTF-16 и все они - это аналог ZIP, RAR, ARJ для обычного бинарного кода (юникода). И сразу часть претензий снимается, ибо они относятся не к юникоду, а вашим заблуждениям относительно него.

Далее, вы не в курсе, что поляки пишут латиницей. Тоже претензия снимается, хотя выглядит довольно забавно.
-- cut ---------
> Минуточку, а почему сербская А КОДИРУЕТСЯ как русская А?

Потому, что и русская и сербская - кирилличная.

> А польское А это английское А?

Польский алфавит, на секундочку, латинский. Потому, что латинская.

> Ммм... логично?

ДА!

> Просто живи с этим.

Хы.
--------- cut --

> А давайте запихнем в юникод знаки вымершей цивилизации

Да, давайте. Мне нравится писать на древнеегипетском и я теперь могу это спокойно делать. А еще на нем можно программировать.

> Так давайте добавим символы заставляющие текст писать справа налево

Евреи тоже люди, как ни странно, и тоже хотят спокойно писать как привыкли.

> но не добавим символов чтобы писать сверху вниз и снизу верх

Да, хорошо было бы добавить.

> а где взять библиотеки чтобы это отобразить? Удачи, это не наше дело.

Да, не их. С понятием RFC, я так понимаю, вы не знакомы?

> Подскажите шрифт для юникода? Для латиницы вот эти, для русского вот этот, вот этот для математических символов...

https://en.wikipedia.org/wiki/GNU_Unifont - 60691 глиф.

А вообще юзай Anonymous Pro - прекрасный программерский фонт с кириллицей.

> А помните мы решили для каждого символа сделать свою кодировку?

Вы путаете понятия character и letter. Вы путаете понятия "кодирование" и "кодировка".

> несколько видов самого протокола

О, откуда то всплыл какой-то протокол. Вы еще и что такое "протокол" не в курсе?

--------------------------------------------------------------------------------
Итого:
> Немного грустно что пришли к такому !@#$%, но искать виноватых я не намерен.

Я вам помогу - нету тут виноватых. Просто потому, что никто к такому "!@#$%" не приходил.
Это все ваши голые фантазии, основанные на незнании и ошибочных представлениях о мире.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено keydon , 03-Ноя-21 12:22 
> Вы путаете понятия character и letter. Вы путаете понятия "кодирование" и "кодировка".
>> несколько видов самого протокола
> О, откуда то всплыл какой-то протокол. Вы еще и что такое "протокол"
> не в курсе?

Мб я и не писал корректно термины в 2 часа ночи, но сути это не меняет. Как были проблемы, так они и остались, а ваши ответы сводятся к "вы назвали отверстие дыркой".

> Начать надо с того, что вы не отличаете понятия "кодовая страница" и
> "кодировка".

В контексте не принципиально.

> Чтобы было понятнее, считайте, что UTF-8, UTF-16 и все они - это
> аналог ZIP, RAR, ARJ для обычного бинарного кода (юникода). И сразу
> часть претензий снимается, ибо они относятся не к юникоду, а вашим
> заблуждениям относительно него.

Спасибо, я в курсе, только проблем это не решает. Нам по-прежнему нужно это учитывать, по-прежнему нужно переформатировать кодировку под разный софт(потому что он не ожидает например unicode с BOM), по-прежнему нужно досконально выбирать либы. Проблем не сильно меньше чем с наличием совершенно разных кодировок. Почему претензии должны быть сняты не понятно.

> Далее, вы не в курсе, что поляки пишут латиницей. Тоже претензия снимается,
> хотя выглядит довольно забавно.
> -- cut ---------
>> Минуточку, а почему сербская А КОДИРУЕТСЯ как русская А?
> Потому, что и русская и сербская - кирилличная.
>> А польское А это английское А?
> Польский алфавит, на секундочку, латинский. Потому, что латинская.

Но претензия была не к польскому, а к различию подходов для разных символов.
Напрашивается очевидные 2 стратегии:
1) похожие символы кодировать одним значением экономя байты (и бонусом есть шанс что пользователь различит 0 от о).
2) каждый символ кодировать своим значением, обеспечивая 100% идентификацию каждого символа и немного упрощая жизнь разработчиков, позволяя например в парсере ограничить русский язык просто фильтруя все что не входит в диапазон русского языка (и для русского в юникоде так и работает, но не для всех языков).
Но юникод СМЕШИВАЕТ оба подхода, нивелирует плюсы и получает минусы от обоих

>> Минуточку, а почему сербская А КОДИРУЕТСЯ как русская А?
> Потому, что и русская и сербская - кирилличная.

По такой логике и кириллическая А это латиница.

>> А давайте запихнем в юникод знаки вымершей цивилизации
> Да, давайте. Мне нравится писать на древнеегипетском и я теперь могу это
> спокойно делать. А еще на нем можно программировать.

Сам пошутил, сам посмеялся. Надеюсь для программирования вы не используете Модификатор эмодзи для шкалы Фицпатрика тип-4 или Заполнитель хангыль чхосон (что это вообще такое?).

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

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

Вот и я про то же: кто-то люди, кто-то не люди, зато вы можете на древнеегипетском писать.

>> а где взять библиотеки чтобы это отобразить? Удачи, это не наше дело.
> Да, не их. С понятием RFC, я так понимаю, вы не знакомы?

Почему то многие забывают что стандарты надо писать чтобы им следовали, а не чтобы их написать. Наличие RFC не делает из мифического вечного двигателя решение проблем с получением энергии. И юникод забывает про это больше остальных.

>> Подскажите шрифт для юникода? Для латиницы вот эти, для русского вот этот, вот этот для математических символов...
> https://en.wikipedia.org/wiki/GNU_Unifont - 60691 глиф.

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

>> А помните мы решили для каждого символа сделать свою кодировку?
> Вы путаете понятия character и letter. Вы путаете понятия "кодирование" и "кодировка".
>> несколько видов самого протокола

Уход от ответа.

Вот вам добавка: коллизии повышения и понижения регистра когда символ из одного алфавита после смены регистра становится ДРУГИМ символом и обратно его не восстановить! БЕСКОНЕЧНО БОЛЬШАЯ СТРОКА КОТОРУЮ НЕЛЬЗЯ РАЗДЕЛЯТЬ потому что она состоит из кучи диакритических знаков, отсутствие(например удаление) каждого меняет букву(ы).

> Я вам помогу - нету тут виноватых. Просто потому, что никто к
> такому "!@#$%" не приходил.
> Это все ваши голые фантазии, основанные на незнании и ошибочных представлениях о
> мире.

Ну да, проблем с юникодом нет, сам стандарт совершенно не переусложнен, каждый второй студент знает его наизусть как ASCII, проблем с его отображением, редактированием нет, для использования уже давно достаточно не парясь подключить какую-нибудь бибилиотеку, каждые полгода не всплывает никаких новостей что приложение N опять можно положить прислав строку на иврите, а сабжевая новость это розыгрыш к следующему 1 апреля. Успокаивайте себя дальше.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Урри , 05-Ноя-21 13:04 
> Но претензия была не к польскому, а к различию подходов для разных символов.

Я вам только что показал, что подход совершенно одинаковый.

Польское "А" - это латинское "А". У поляков письмо - латиница(!). Поэтому их "А" - это английское "А", немецкое "А", фрацузское "А".

Сербское "А" - это кирилличное "А". У сербов письмо - кириллица(!). Поэтому их "А" - это русское "А", болгарское "А", белорусское "А".

Подход - одинаковый. И правильный.

> По такой логике и кириллическая А это латиница.

Перечитайте то, что я написал выше. Погуглите "кириллица" и "история появления кириллицы". Думайте.

> каждый символ кодировать своим значением, обеспечивая 100% идентификацию каждого символа

Оно так и есть. Кирилличная "А" вне зависимости от языка кодируется как кирилличная "А". И даже если какая-нибудь донская область внезапно объявит себя Донской Республикой со своим, Донским Языком (вернет в язык букву ѣ), всем программистам мира не придется переделывать таблицу юникода.

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

Какого именно русского языка - до реформы 1918 или после? Вы предлагаете менять таблицу кодов под каждое изменение национальных правил, заставляя переписывать все парсеры?
Языки, напомню, развиваются. В них появляются и исчезают даже буквы (украинцы вернули букву ґ, например - совершенно непонятно зачем, но закон есть закон). Теперь что, всю украинскую кодировку после "г" сдвигать и все переписывать? А как насчет русской "ё", которая то есть, то нет (гляньте на википедии, там статья почти как война и мир по размеру)?

И, в конце-концов, вам так сложно в парсере сделать бинарный поиск по собственной таблице допустимых национальных символов? Это будет почти так же быстро, как и проверка x <= y <= z,

У меня парсер, например, так и делает. Он даже умеет приводить буквы любого языка из нижнего в верхний регистр - когда выходит обновление таблицы юникода, куда включают новые языки (или меняют правила для уже существующих) я запускаю скрипт, который парсит последнюю редакцию CaseFolding.txt из https://www.unicode.org/Public/ и генерирует мне простую табличку, сложность поиска по которой составляет log(n).

>> Вы путаете понятия character и letter. Вы путаете понятия "кодирование" и "кодировка".
> Уход от ответа.

Слив засчитан. Будем считать, что вы поняли ошибку но решили ее просто замять, ибо слишком позорно.

> коллизии повышения и понижения регистра когда символ из одного алфавита после смены регистра становится ДРУГИМ символом и обратно его не восстановить!

Это особенности естественных языков. Юникод им только следует, не более того.
Да, греческую "ᾙ" действительно можно приводить либо к "ᾑ" либо к "ἡι" - это особенности правописания. И эти особенности отражены в юникоде.

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

>> https://en.wikipedia.org/wiki/GNU_Unifont - 60691 глиф.
> Но он только для части юникода.

Вы на английском читать не умеете? Ну тогда понятно откуда такое желание все взять и переделать.
Цитирую:

The Unicode Basic Multilingual Plane covers 216 (65,536) code points. Of this number, 2,048 are reserved for special use as UTF-16 surrogate pairs and 6,400 are reserved for private use. This leaves 57,088 code points to which glyphs can be assigned. Some of these code points are special values that do not have an assigned glyph, but most do have assigned glyphs.

GNU Unifont покрывает ВСЕ ваши потребности в юникоде, причем с запасом. 60691 глифов против 57088 предлагаемых.

> сам стандарт совершенно не переусложнен

Стандарт прост как два байта. Что может быть проще таблицы всех человеческих букв/рун/символов письма?

> каждый второй студент знает его наизусть как ASCII

Я уверен, 999999 ил 1000000 тысяч студентов не скажут код буквы "ё" в любой из кириллических кодировок. Да даже код ETX или SYN из ASCII не скажут, как и вы.

Так что даже тут вы, мягко говоря, облажались.

--
На этом, надеюсь, все? Можете сделать выводы из написанного и немножечко дообразоваться? Или будете просто глупо упираться в свои заблеждения, как всегда делают 95% народонаселения.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено keydon , 09-Ноя-21 18:45 
> Подход - одинаковый. И правильный.
> Перечитайте то, что я написал выше. Погуглите "кириллица" и "история появления кириллицы".

Если по происхождению формировать блоки, то по вашей логике кириллица должна использовать глаголицу и например ь в русском должен быть U2C13 а не U042C. Но в юникоде это не так. Т.е. как сделано в юникоде все равно не логично, а если бы и было сделано по такой логике то это все равно был бы кусок !@#$%%^, т.к. логика сводить к историческим причинам крайне не надежно - что там было в древности никто не знает, исторические представления неоднократно переписывались и что делать если на язык воздействовало сразу два языка с одинаковым символом и какой из них оказал большее влияние - не понятно.

> Оно так и есть. Кирилличная "А" вне зависимости от языка кодируется как кирилличная "А". И даже если какая-нибудь донская область внезапно объявит себя Донской Республикой со своим, Донским Языком (вернет в язык букву ѣ), всем программистам мира не придется переделывать таблицу юникода.

Сами юникодовцы придумали проблему - кодировать символы, а не глифы, сами же от нее отказались делая такое "наследование" между схожими алфавитами, сами же придумали планы и разделение внутри планов, самим же пришлось тусовать планы как придется без всякой логики.
Просто кодируйте глифы и не надо никаких заморочек с алфавитами, историей и т.д..

>Какого именно русского языка - до реформы 1918 или после? Вы предлагаете менять таблицу кодов под каждое изменение национальных правил, заставляя переписывать все парсеры?
> Языки, напомню, развиваются. В них появляются и исчезают даже буквы (украинцы вернули букву ґ, например - совершенно непонятно зачем, но закон есть закон). Теперь что, всю украинскую кодировку после "г" сдвигать и все переписывать? А как насчет русской "ё", которая то есть, то нет (гляньте на википедии, там статья почти как война и мир по размеру)?

Я то как раз против разделения по семантике (за глифы и там таких проблем нет принципиально и бнз маппинга принципиально не обойтись). А юникодовцы сами себе проблемы придумали разбивать по блокам и теперь тасуют и блоки как придется и вроде как и не глифы но вроде как и не совсем семантика.

> Это будет почти так же быстро, как и проверка x <= y <= z,

Почти также быстро это логарифмическая сложность против константной? Вы это серьезно?

> Слив засчитан. Будем считать, что вы поняли ошибку но решили ее просто замять, ибо слишком позорно.

Ошибка весьма условная и в кругу дотошных филологов можно долго выяснять что значит кодировка на русском, charset на английском и что они значили до юникода. Все всё поняли, но снобы все равно посмеялись чтобы потешить ЧСВ. Вы же называете логарифмическую сложность почти такой же быстрой как и константную и это уже не смешно.

>Это особенности естественных языков. Юникод им только следует, не более того.
> Да, греческую "ᾙ" действительно можно приводить либо к "ᾑ" либо к "ἡι" - это особенности правописания. И эти особенности отражены в юникоде.

Это особенность семантического разделения. Или недосемантического как в юникоде.

> Стандарт прост как два байта.

Ну да, ну да. Видимо в этой https://www.oreilly.com/library/view/unicode-explained/05961.../ книге первые 10 страниц рассказывается как все просто, а оставшиеся 670 страниц пустые. И в других книгах https://www.unicode.org/announcements/books.html то же самое. И документация только core specification на 1000+ страниц просто была рассчитана на альтернативное использование в виде топки, а не распухла из-за излишней сложности. А бесконечное статьи от опытных разработчиков про проблемы с юникодом это затянувшиеся на несколько лет первоапрельские розыгрыши.

> Что может быть проще таблицы всех человеческих букв/рун/символов письма?

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

>Вы на английском читать не умеете? Ну тогда понятно откуда такое желание все взять и переделать.
>Цитирую:
>The Unicode Basic Multilingual Plane covers 216 (65,536) code points. Of this number, 2,048 are reserved for special use as UTF-16 surrogate pairs and 6,400 are reserved for private use. This leaves 57,088 code points to which glyphs can be assigned. Some of these code points are special values that do not have an assigned glyph, but most do have assigned glyphs.
>GNU Unifont покрывает ВСЕ ваши потребности в юникоде, причем с запасом. 60691 глифов против 57088 предлагаемых.

Тогда почитайте получше потому что в цитате вы упустили _Basic_Plane, что значит что шрифт покрывает только базовый план и еще на сайте http://unifoundry.com/unifont/index.html они указывают что поддерживают 12613 глифов plan1, а всего их планов 16 и пускай большая часть не заполнена, но как миниум plan2 в unifont'е нет, а значит и всей поддержки юникода тоже нет.

>Перечитайте то, что я написал выше. Погуглите "кириллица" и "история появления кириллицы". Думайте.
>Слив засчитан. Будем считать, что вы поняли ошибку но решили ее просто замять, ибо слишком позорно.
>Так что, теперь еще человеческие языки переделывать, вот прям с Плутарха начиная? Для вашего удобства?
>Ого как замахнулись.
> Вы на английском читать не умеете? Ну тогда понятно откуда такое желание все взять и переделать.
> На этом, надеюсь, все? Можете сделать выводы из написанного и немножечко дообразоваться? Или будете просто глупо упираться в свои заблеждения, как всегда делают 95% народонаселения.

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


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 11:52 
Великий Расс Биг Кок из го-тимы уже уничтожил этот "баг" и заодно всю раст-тиму https://research.swtch.com/trojan

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено freecoder , 02-Ноя-21 12:20 
Что же, если раст-тима уничтожена, то значит теперь никаких новостей и разговоров про Rust на опеннете не будет? А если будет, значит ли это, что вы просто трясете своими текстами в бессильной злобе, потому что с растом не происходит того, что вы ему желаете?

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено PnD , 02-Ноя-21 12:00 
КМК, если уж мы за мульти…генд^W направленность текста, надо добиваться корректной отрисовки. При подобном методе "зачистки", исходные символы должны бы обзавестись подозрительной "лапшой".

С другой стороны, сам факт смены направления "inline" заслуживает некой пометки. Это ж практически UB: дальше нужно как-то выяснить с какого места "канвы" продолжать чтение.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 13:02 
Фиксить компилятор. Омайнгад. Тока растоманы могли до этого додуматься.))

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 19:00 
Простейший фикс - пересохранить файл как кои-8 или cp866.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним12345 , 02-Ноя-21 14:50 
Безумный, безумный, безумный мир
Вместо того, чтобы приносить пользу, код приносит вред

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Gogi , 02-Ноя-21 18:11 
Это ещё раз доказывает, какие ДE6ИЛЫ проектировали юникод. Маялись маялись, 1 байта им мало, ASCII им мало, так на тебе ТРИ стандарта юникода, да ещё вот эта идиотия прямо в стандарте символов(!!!) написание слева направо - разве это не забота операционной системы?!?! Символ - это значок, ни больше, ни меньше. Ублюдство юникода ещё долго будет канифолить нам мозг (как и USB).

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 02-Ноя-21 18:58 
Это они от добра хотели, чтобы в одном файле были и левые английские тексты, и правая вязь...

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено qwert , 03-Ноя-21 09:15 
Нет. Правильное отображение текста справа-налево зависит от его смысла. В простом тексте смысл выражается особыми символами.

"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено Аноним , 03-Ноя-21 14:48 
>Это ещё раз доказывает, какие ДE6ИЛЫ проектировали юникод ...
>Ублюдство юникода ещё долго будет канифолить нам мозг (как и USB).

И это русский педагог? Мда, когда русский человек внезапно поносит технологию, это может означать одно - он просто её не осилил и не понял. Gogi свои сообщением полностью раскрыл загадочную русскую душу.


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено adolfus , 03-Ноя-21 18:34 
if access_level != "user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}" {

Чушь какая-то. Мой slickedit никак на такое не реагирует -- все зависит от кодировки. Если у Вас utf8, мусор из utf16 просто не распознается -- "stray in code".


"Атака Trojan Source для внедрения изменений в код, незаметны..."
Отправлено поле name , 05-Ноя-21 14:44 
это вот так внедрили системди получается?