Complexity hides insecurity
Jul. 25th, 2015 07:56 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerПохоже, что желание создать нормальное Free Software, в смысле, такое, которое пользователь действительно свободен модифицировать, потому что способен понять, таки начинает у народа возникать.
Вот, например, Tomb, юзер-френдли инструмент для создания криптованных дисков, написанный на shell. Под лозунгом complexity hides insecurity.
Надо, что-ли почитать, и понять, удалось авторам добиться заявленных целей, или insecurity пробралась в проект с другой стороны.
Но в общем и целом подход вполне заслуживает внимания.
Вот, например, Tomb, юзер-френдли инструмент для создания криптованных дисков, написанный на shell. Под лозунгом complexity hides insecurity.
Надо, что-ли почитать, и понять, удалось авторам добиться заявленных целей, или insecurity пробралась в проект с другой стороны.
Но в общем и целом подход вполне заслуживает внимания.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2015-07-25 05:26 am (UTC)no subject
Date: 2015-07-25 05:40 am (UTC)Шелл - язык высокоуровневый. Куда более высокоуровневый чем python или tcl.
И именно поэтому код на нем получается компактным и обозримым.
В принципе, конечно, шелл как язык программирования GUI малопригоден. За 30 лет существования X11 так и не придумали достаточно удобного способа писать на шелле GUI. Но нужен язык сравнимой высокоуровневости.
no subject
Date: 2015-07-25 07:45 am (UTC)Угу, и состоит из вызовов внутренностей *sh (писанных скорее всего на сях) и внешних программ, писанных на черт знает чём. Т.е. просто заметание мусора под ковёр.
no subject
Date: 2015-07-25 09:35 am (UTC)К концу прошлого века эти компромиссы оформились в виде Ады и Оберона.
no subject
Date: 2015-07-25 10:15 am (UTC)Ещё хорошо что они bash не использовали, тот вообще до недавнего времени выполнял произвольные команды из окружения при запуске, да и сейчас механизм импорта функций из окружения такой что в общем случае вообще ничего нельзя передавать из пользовательского ввода, потому что любая переменная может оказаться с тем же именем что и используемая в скрипте команда. Но и zsh тоже такой комбайн что не удивлюсь что там что-то найдётся.
no subject
Date: 2015-07-25 12:13 pm (UTC)facepalm.jpg
- арифметика указателей
- логика помещения в стек параметров и возвращаемых значений
- отсутствие в рамках языка средств контроля адресных пространств
Порождены и упомянутый Вами, и эти спецэффекты именно низкоуровневостью изначальной архитектуры и нежелании (на начальных этапах существования языка) потратить на средства контроля хоть копейку имеющихся ресурсов КАК на этапе исполнения, ТАК и на этапе компиляции.
Зато мне неоднократно удавалось написать содержательный код на Си, который компилировался в не менее эффективную программу, нежели тот же самый алгоритм, реализованный на ассемблере той же машины.
no subject
Date: 2015-07-25 02:32 pm (UTC)Вроде как сейчас считается, что опытный программист проигрывает современным компиляторам в попытке написать столь же эффективный ассемблерный код в подавляющем большинстве случаев, и эта попытка в принципе не имеет смысла (а вот посмотреть что компилятор сгенерил и попробовать улучшить в критическом цикле — может иметь смысл).
Кстати, в связи с этим крайне интересен язык Rust. Сохраняя идею «нулевого рантайма» (в смысле ни капли ресурсов на контроль во время исполнения), он пытается проверить и доказать корректность использования указателей на этапе компиляции.
no subject
Date: 2015-07-26 04:08 pm (UTC)Я лично считаю, что опытный программист способен написать и ОТЛАДИТЬ одинаково эффективный код на низкоуровневом языке МЕДЛЕННЕЕ, чем сколь угодно опытный на языке высокого (в смысле контроля) уровня.
И современный рынок программного обеспечения попросту изжил "медленных" программистов как значимое явление.
no subject
Date: 2015-07-25 05:55 pm (UTC)Вот для арифметики указателей как раз наибольшие проблемы доставляет переполнение всяких смещений. Остальные ошибки как я понимаю, тривиальны и ловятся при минимальном тестировании.
no subject
Date: 2015-07-26 04:04 pm (UTC)Вашими бы устами...
no subject
Date: 2015-07-25 10:00 pm (UTC)+1024
no subject
Date: 2015-07-25 06:41 am (UTC)P.S.: Ну или для sys.* придумать сопоставимый синтаксис.
no subject
Date: 2015-07-25 06:51 am (UTC)Попытки написать высокоуровневые библиотеки для того же Tcl делались, но как-то к успеху не привели.
В то же время существует make - язык с совсем другой парадигмой - логической, а не процедурной, который прекрасно пользуется теми же внешними командами, что и shell.
no subject
Date: 2015-07-25 07:07 am (UTC)В таком стиле можно писать, например, на хаскеле. Или на эрланге. Да хоть на перле.
А шелл ужасен. сколь-либо серьезные преобразования формата данных (чтобы вывод одной утилиты скормить другой) на нем - сущее мучение.
no subject
Date: 2015-07-25 07:40 am (UTC)no subject
Date: 2015-07-25 08:08 am (UTC)Т.е. я понимаю, что на шелле иначе нельзя, но это не достоинство. Ладно еще, что для преобразований колоночных форматов есть awk, и то хлеб. Но если однострочника на оном не хватает, приходится делать то самое (писать программу на нормальном языке)
no subject
Date: 2015-07-25 07:08 am (UTC)При чем здесь переменные, я не понимаю, в функциональном стиле полвека без них пишем, и не всегда получается более высокоуровнево.
no subject
Date: 2015-07-25 07:43 am (UTC)Кстати говоря. многие современные утилиты не являются "привязками к шеллу", поскольку не соблюдают соглашений, например о кодах возврата.
no subject
Date: 2015-07-25 07:55 am (UTC)По поводу второго: ты совершенно прав.
no subject
Date: 2015-07-25 08:57 am (UTC)Потому что использовать для интеграции компонент язык уровня Java - довольно занудно. Недаром для Java понаписали такое количество IDE и прочих инструментов, пытаясь возложить на эти инструменты тот труд по автоматизации работы программиста, который должен выполнять язык.
Кстати, вот в python rundll есть. В смысле ctypes. Ну и в tcl (там оно по-моему ffiddl или как-то так называется).
Но вообще, похоже единственным серьезным кандидатом на роль "шелла для нелинейных (т.е. GUI) сред" является ECMAScript. Если только в нем заменить HTML DOM на что-нибудь более вменяемое...
Одной из попыток так сделать был XUL, но он не вышел за пределы расширений мозиллоидных продуктов.
no subject
Date: 2015-07-25 09:13 am (UTC)При этом я бы очень удивился синтаксису, обеспечивающему такую семантику и сопоставимому по фундаментальной простоте с шеллом. А некоторые моменты с безопасностью в акторной модели, действительно, решались бы (если бы акка не на JVM была реализована).
no subject
Date: 2015-07-25 10:05 pm (UTC)Аргумент от рынка, у тебя? Или я чего-то не понял?
Не выстрелило. Экономщики тактов победили. Тактов этих у нас теперь завались и залейся, а накопившиеся в победившей парадигме проблемы и десятикратным их количеством не решишь. По-моему, Вирт был просто вчистую прав, только и всего.
no subject
Date: 2015-07-26 04:23 am (UTC)no subject
Date: 2015-07-25 09:05 am (UTC)линуксонли
no subject
Date: 2015-07-25 10:25 am (UTC)Не факт, что удастся обеспечить совместимость по формату контейнеров, но совместимость по интерфейсу - легко.
no subject
Date: 2015-07-25 02:10 pm (UTC)no subject
Date: 2015-07-25 04:50 pm (UTC)no subject
Date: 2015-07-25 05:09 pm (UTC)Мне бы очень хотелось, чтобы создатели Linux и *BSD озаботились совместимостью драйверов, чтобы драйверы можно было легко портировать между системами.
no subject
Date: 2015-07-25 06:09 pm (UTC)no subject
Date: 2015-07-25 07:49 pm (UTC)Планировщик процессорного времени, родная файловая система и много чего ещё м.б. разным. А вот драйвер сетевой карты хорошо бы сделать универсальным или хотя бы свести различия к минимуму.
no subject
Date: 2015-07-26 04:48 am (UTC)А вот драйвера сетевой карты должны быть разными. Если на одну сетевую карту не будет написано пять разных драйверов разными людьми под операционные системы с разной идеологией, уязвимости в дизайне железа окажутся не выявленными.
Просто надо законодательно запретить разработчикам железа поставлять драйверы для него. Только публиковать спецификации. А за попытку стребовать с разработчиков ОС NDA - конфисковывать все имущество фирмы и ее закрывать.
no subject
Date: 2015-07-26 05:36 pm (UTC)Интересно было бы прочитать про разницу драйверов в разных OS. Ну что там м.б. разного кроме названий функций и порядка аргументов?
Запрет разработчикам железа поставлять драйверы - не сработает. Ну, сделают отдельную фирму для написания драйверов. А M$ и без NDA никому ничего не расскажет.
Тут правильнее требовать раскрытия исходных кодов драйверов.
no subject
Date: 2015-07-27 07:53 am (UTC)Они не будут выявлены теми, кто получает деньги не за безопасность, а за фичи. Это не значит, что они будут не выявлены (и сохранены в тайне) и теми, кто получает деньги за "безопасность".
no subject
Date: 2015-07-25 09:24 pm (UTC)и вот морда к администренью контейнера - может быть мультиплатформенной. своя в репах линуксы или портах фри. благо, что основа одна.
no subject
Date: 2015-07-25 09:58 pm (UTC)no subject
Date: 2015-07-26 04:32 am (UTC)С тактами у него всю жизнь было не хуже, чем у C. а Турбо Паскаль двадцать лет назад генерировал более компактный код, чем Turbo C.
Вопрос в том, что авторы C осознавали, что делают низкоуровневый язык. И предоставлии средства для работы с битовыми полями, адресную арифметику и т.д.
А Вирт от этого откаазлся. но не предоставил взамен высокоуоровневых средств, которыми можно решать те же задачи - динамической типизации, интроспекции, замыканий. В результете получилось ни то ни се, несмотря на последующие достаточно удачные попытки фирмы Borland впихнуть в Паскаль низкоуровневые конструкции, которые Вирт туда так старался недопустить.
no subject
Date: 2015-07-26 05:30 am (UTC)Но в целом критика понятна, хотя многое доделано в Обероне.
no subject
Date: 2015-07-26 05:51 am (UTC)Кстати, заметим что stdcall конвенция в API Windows осталась с тех времен, когда ядро Windows было написано на Паскале. Потом его где-то по-моему к 3.0 переписали на С, но неродная конвенция вызовов API осталась до сих пор.
Ядро MacOS по-моему тоже было изначально на Pascal-е.
То есть соревнование между C и Pascal на этом поприще было честным и поначалу Pascal лидировал.
Опять же, существует тренд по выносу драйверов в Userspace. Я уже как-то писал, что "гони микроядро в дверь, оно влезет в окно". Не стал Линус в начале 90-х делать микроядро, погнался за тактами, так что мы сейчас имеем?
libusb, tun/tap, fuse. Файловые системы можно в userspace, драйвера usb-устройств можно, сетевые драйвера можно. Во FreeBSD кстати, нет ядерного драйвера Bluetooth PAN. А нафига, если оно прекрасно через tap работает.
no subject
Date: 2015-07-26 06:07 am (UTC)...с адовыми тормозами...
no subject
Date: 2015-07-26 02:27 pm (UTC)А так - да, хорошо, в Паскале, каким он был в критический момент, не хватало требуемых для ядра средств. Но почему тогда в юзерспейсе пошли косяком монстры? C++/COM - вообще без комментариев, он меня и отпугнул от программирования. В параллель развивался Unix, но там был то Си в хвост и в гриву (а совсем не только в ядро), то абсолютно непредсказуемый и сложный на ровном месте shell, то потом perl, поощряющий obfuscated code чуть ли не нарочно.
Из всех этих нечитаемых наборов я могу понять, пожалуй, почему занял прочное место regexp. Там за write only мы получаем "быстро сделать со строкой ровно то, что надо, при условии что везде правильно попали". Но почему ТАК выглядит всё остальное?
no subject
Date: 2015-07-27 08:03 am (UTC)no subject
Date: 2015-07-27 08:09 am (UTC)no subject
Date: 2015-07-27 09:08 am (UTC)no subject
Date: 2015-07-29 12:34 pm (UTC)no subject
Date: 2015-07-26 08:07 pm (UTC)маниаки всё ещё есть...