Sebastian Krause определил источник странной несовместимости с сервисом Bypass скрипта dehydrated, используемого для автоматизации получения TLS-сертификатов по протоколу ACME. С Bypass работают и эталонный клиент, и uacme, но не dehydrated (точнее, он тоже с некоторыми обходными манёврами заработал, но исключительно в режиме dns-1)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53279
Не перевелись ещё норкоманы на Земле.
Придумавшие JSON.
Придумавшие использовать только JSON в протоколе Let's Encrypt.
Криворукая макака не придумала ничего лучше, чем «парсить» json самопальной регуляркой и это в типо_секурном_проекте...
Но виноват JSON ?)Интересно, сколько бы д.ма вылилось на автора проекта, окажись проект написанным на каком-нибу JS...
Но, поскольку это юниксовый скрипт, виноват кто угодно( вплоть до формата данных и фазы Луны, из-за которой разработчику пришла в голову столь дурацкая идея ), но не сама скриптомакака.
Так смысл же был в отсутствии зависимостей.
Написать парсер несложно. Гляньте вон в хаскеле на парсерные комбинаторы, например
> Так смысл же был в отсутствии зависимостей.Отсутствие зависимостей — это статически собранный бинарник.
Статик бинарь лучшее отсутствие зависимостей!
Ну, сделай его размером с эту шеллфигню? :)
Набижали одепты секты статических бинарников.
Вспомни с ними, какие версии TLS-либ вкомпилены унутрь, или тех же парсеров чего ни попадя, и сколько дыр в них с тех пор нашли.
https://stackoverflow.com/questions/1732348/regex-match-open...
читать до конца!
До конца регулярного выражения? :)
Они чуть не рекурсивные бывают - так что с этим поаккуратнее :)
Это божественно!
Блеать, откуда ты нарыл такое, коллега?
Это полная уже деградация, если пропарсить какойто простейший json проблема.
>Это полная уже деградация, если пропарсить какойто простейший json проблема.Dehydrated написан на shell. Использовать node.js, пожалуйста, не предлагать.
Кроме shell и node.js никаких языков очевидно больше не существует.
Бидончик
И потом еще версию этого шита на каждом сервере правильную таскать? :)
>Кроме shell и node.js никаких языков очевидно больше не существует.Насчет node.js, естественно был сарказм. Насчет shell даже комментировать как-то неловко (в этом и смысл dehydrated: минимум зависимостей). Переписывать его на другой я/п- тоже самое, что переписать ядро на rust. Надеюсь, так понятнее.
> Переписывать его на другой я/п- тоже самое, что переписать ядро на rust.Один скрипт — не ядро, если у автора голова не из чугуния — проблем нет.
> в этом и смысл dehydrated: минимум зависимостей
Минимум зависимостей — это Go с CGO_ENABLED=0. Можно запускать даже в абсолютно пустой rootfs.
>Один скрипт — не ядро, если у автора голова не из чугуния — проблем нет.Нет, преписать- проблем нет. Проблема в другом,- зачем? :) Клиентов на C- уже несколько.
>Минимум зависимостей — это Go с CGO_ENABLED=0. Можно запускать даже в абсолютно пустой rootfs.
Клиентов на GO- _уже_ как собак нерезаных. Зачем ещё один?
> Клиентов на GO- _уже_ как собак нерезаных. Зачем ещё один?И мы плавно подходим к пониманию, что дело не отсутствии зависимостей, а в желании "быть не таким, как все".
Похвально, но непрактично.
> Go с CGO_ENABLED=0А что, net уже работает без cgo?
Если говорить о линуксе, то да https://github.com/golang/go/issues/25670
Лови: https://stedolan.github.io/jq/
>Лови: https://stedolan.github.io/jq/С какой долей вероятности этого не будет на сервере?
А вообще - в чем преимущество "быть написанным на шелл"? Возьмите-сделайте сишный/плюсовый клиент
>А вообще - в чем преимущество "быть написанным на шелл"?1. Отсутствие внешник зависимостей (на сервере это важно).
2. Теоретически более простой аудит кода.>Возьмите-сделайте сишный/плюсовый клиент
Кхм, они и так уже есть.
>>Возьмите-сделайте сишный/плюсовый клиент
> Кхм, они и так уже есть.ну, кстати, я посмотрел на uacme - а там - там-тадам, подавай gcc чуть ли не десятый, и непременнейше еще и openssl распоследней версии. Увы, у меня такого не завезли (а где завезли - там и сертификаты пока еще от digicert - правда, уже не зельоные - смысла ни малейшего платить).
Это при том что код ни разу не назовешь простым и понятным.
> А вообще - в чем преимущество "быть написанным на шелл"?"Шелл есть на всем что хоть немного похоже на сервер" :)
> Возьмите-сделайте сишный/плюсовый клиент
Совсем без внешних либ? Нудно. С ними? Кучу зависимостей ставить. А шелл что, он всяко есть.
> Dehydrated написан на shell. Использовать node.js, пожалуйста, не предлагать.Вы так говорите, как будто это не сорта одного и того же.
И shell, и JS — мелконишевые языки, простые для изучения неквалифицированными "разработчиками" и именно поэтому вылезшие за пределы своей ниши. Это и обуславливает "высочайшую" культуру разработки на обоих этих языках.
>Вы так говорите, как будто это не сорта одного и того же.Дело не в этом. Дело в том, что shell на сервере уже есть.
А в чруте или контейнере его может и не быть.
И да, запускать столь сомнительные программы, как сабж, на хостовой системе — идея не очень.
> А в чруте или контейнере его может и не быть.Не может, если там сколько-нибудь полноценная ОС. Впрочем, это не столь важно, учитывая, что dehydrated написан не на shell, а на bash, которого и правда может не быть.
> Не может, если там сколько-нибудь полноценная ОС.Зачем полноценная ОС для запуска статического бинарника? Просто чтобы занять несколько гигов на диске?
Несколько сотен метров. Зачем? Ну затем, чтобы в ней работало хоть что-то кроме твоего статического бинарника.
а слабо показать работающий код парсера json на bash+sed/awk/grep/tr/cut - то есть именно самому пропарсить json юниксными средствами, а не надо читать твой текст как "установить кем-то написанный софт который это делает за меня" (смысл dehydtated ровно в том чтоб обойтись без построннего сложного софта) ?
А то сам код bash / tcsh сильно простой?
а сам код именно bash - уже несколько раз внезапно исполнял левые файлы по нажатию tab, да - но он у неудачников "нового стандарта" так и так уже есть. (с true shell эта поделка, разумеется, не работает, как обычно)В смысле, если в нем найдут очередную дыру - у тебя будут проблемы и без dehydrated (которого они вполне могут и не затронуть).
С труЪ <whatever> обычно нифига и не работает. труЪ не для того чтобы работать.
На bash если и непростой, то сам bash есть из коробки.
вообще-то только в "новом стандарте", и то не в любом (правда, dash, наверное, совместим).> bash
bash: Command not found.
(а на one true sh эта поделка не работает)
В 2020 году bash и есть one true sh, по факту. Есть на любой не-маргинальной системе.Лично я, правда, ориентируюсь на posix-подмножество, потому что на дебиановском семействе /bin/sh — это dash, в котором поменьше интерактивного мусора. Но это уже мой личный перфекционизм.
> В 2020 году bash и есть one true sh, по факту. Есть на любой не-маргинальной системе.то есть в линyпсе, линyпсе и линyпсе? Ну оок.
> Но это уже мой личный перфекционизм.
если твой шелл не позволяет выполнить какой-нибудь неожиданный код, просто нажав tab - ты живешь зря, ага.
> то есть в линyпсе, линyпсе и линyпсе? Ну оок.Ну да, на какой-нибудь AIX или Amiga может и не быть. Это прискорбно, но пренебрежимо.
> если твой шелл не позволяет выполнить какой-нибудь неожиданный код, просто нажав tab - ты живешь зря, ага.
Автодополнение — это неожиданный код?
Ещё на freebsd. А больше то и не надо. Хотя даже на проклятых винде и макос можно bash поставить.
В freebsd нет bash искаропки. А вот в макоси есть, хоть и второй свежести. Иди учить матчасть.
> В freebsd нет bash искаропки.Так и фрибзды нет искаропки. Problem solved! Next!
И как-бы самая банальное решение проблемы с такими приколами это минимизация, trim и т.д. На тех-же awk / sed'ах на раз два делается.
И да, вам уже в новости сказали про JSON.sh, который использует только gawk и egrep.
я эту новость, как бы, писал. Мне интересно было посмотреть на код крякающего комментатора, а не на JSON.shПолагаю, ничего кроме пузырей в лужу, он бы не написал.
> я эту новость, как бы, писал. Мне интересно было посмотреть на код
> крякающего комментатора, а не на JSON.shТроллинг новостью.... технично! Это левелап скилла!
Есть ещё JSON.awk, на чистом awk:
https://github.com/step-/JSON.awk
wow, красота какая.
И даже не на gnu awk.Но, кстати, и не чистый awk - автор ниасилил, такой RS вряд ли хотя бы posix-compliant
Не, на original-awk не пашет. Да и на mawk 1.3.3 тоже, вопреки заявлениям.
для mawk там RS надо поменять на \b (и молиться чтоб он не приехал внутри json), остальное вроде рабочее.Но в целом зверюшка, безусловно, забавная но бесполезная в реальной жизни, как утконос.
кстати, мельком глянув в JSON.sh (кто будет свое показывать - чур не подглядывать, это слишком просто): с одной стороны, автор умел в программирование (то есть правильно понял задачу, а не как это лопоухое недоразумение, грепал чорти что), а с другой:
> #!/bin/shsic!
...
... там еще какие-то попытки что-то zsh-специфичное понаделать ...
...
> if ([ "$0" = "$BASH_SOURCE" ] || ! [ -n "$BASH_SOURCE" ]);
> then
> parse_options "$@"
> tokenize | parse
> fiздрасьте, приехали.
Причем код JSON.sh всего-лишь на 208 строк.
Да нет, не слабо́:
"""
if [ "$(echo $RESULT_ACCEPTING | jq -r '.result')" = "success" ] ; then…
"""
Что, для json нужны инструменты jQuery? (Есть и альтернативные, но этот вот под рукой оказался.)
Ну так рассматривайте очередной инструмент как новую функцию в базисе (того самого "юникс-вея").
В большинство не-гуманитарных специальностей соотв. разделы математики входят, чего бы ими не пользоваться (а не придумывать ярлыки "unix-way" и прочую ∞́ню).
> Ну так рассматривайте очередной инструмент как новую функцию в базисеу нас и в старых не все идеально с безопасностью обработки untrusted данных, а верить что написанное мальчиками в штанцах с подворотиками не блеванет смузи если правильно накормить - надо очень наивным быть.
Применение таких инструментов сводит весь смысл написания dehydrated (если он вообще был, что сомнительно) к х.ю
А какой тогда смысл в написании dehydrated, если его автор ничем не отличается от мальчиков в штанцах с подворотиками, если абсолютно так же выблeвывает смузи?
В написании - дык, эта - "был продан компании Apilayer GmbH", а чего добился в баш-разработке ты?! ;-)
А в использовании - смысл если для кого и был, то да, кончился, об том, собстно, и новость.ТАКОЕ использовать - напрашиваться на неприятности.
Я сбежал на acme-tiny еще пол-года назад, когда всплыла несовместимость с bypass и явное нежелание автора ничего исправлять и разбираться - унеговсеработает. А вчерась просто получил подтверждение, что и правильно не стал время терять - тут уже ничего не исправить, только молнией всех подряд.
А в чем сложность с awk ??
https://github.com/step-/JSON.awk
Примерно так:cat file.json | sed 's/\([,{[]\)/\1\n/g' | tr -s '\n' >tmp.json
Я не вдавался в подробности, может тут не всё сделано, что нужно, но идея должна быть ясна. tr -s, кстати, наверное лишний. Но потом можно работать с tmp.json регекспами так, как dehydrated работал до того. И никакой JSON.sh не нужен.
Проблема в пропарсить любой json.Сейчас добавят парсер. Потом кто-то умный дотумкает, что злонамеренный сервер может хакнуть систему вызвав в ней черти-что специально подготовленным json. И понесется... :)
Да, ведь, как оказалось, валидация пришедших со стороны данных слишком сложно для нынешних программистов
После parse валидировать поздно, до сложно.
Лучше я продолжу сидеть на http-плоколе и сайтах
И смотреть рекламу мегафона и ростелекома?
И не платить денег п-сам, платить тем кто все еще за твои деньги тебе же не гадит, во всяком случае - старается в рамках, оставленных ему конь-ституцией и госмафией.
Бывают места, где никто, кроме мобильных операторов не даёт интернет. Но тебя там нет (впрочем, это хорошо).
> Бывают места, где никто, кроме мобильных операторов не даёт интернет. Но тебя
> там нет (впрочем, это хорошо).Алсо бывают еще всякие кафешки и прочие - и будет очень кстати если логины-пароли там все же не умыкнут. Даже если их вафельница и не шифрованая.
Кто-ж запрещает?
А потом, когда поймёшь - добро пожаловать в волшебный мир айти.
пармер джексона на коленке на сях пишется за полтора дня с перекурами, неужели не осилили? :)
Перекурили
В одном своём проекте тоже использовал самопальный разбор json на regexp-ах. Да, это потенциально несёт проблемы с совместимостью при изменении разметки, но существующие в то время готовые библиотеки для разбора JSON были каким-то верхом неэффективности и наплевательства на безопасность, так же как и библиотеки libxml*.Проблемы с совместимостью оказались меньшим злом по сравнению с возможностью отгрести RCE при обработке хитрого JSON, эксплуатирующего очередную дыру. У dehydrated в этом плане проще, нет необходимости парсить всё подряд и известным ACME-серверам более-менее можно доверять.
Не думаю, что что-то с тех пор поменялось, например, в
json-c последняя дыра CVE-2020-12762 была в мае (https://ubuntu.com/security/notices/USN-4360-1 ) и не какая-то, а "It was discovered that json-c incorrectly handled certain JSON files. An attacker could possibly use this issue to execute arbitrary code.". Криворукость авторов при этом на высоте, исправив уязвимость, они сломали совместимость https://github.com/json-c/json-c/issues/599
Самопальный разбор конечно же исследовался на безопасность, аудит провели?
Вы еще про аудит dehydrated спросите.Работает - не трогай. Сиквел "Это же просто сертификат!" от автора блокбастера "Кто же меня атаковать будет?" и "Ничего там у меня такого нет!".
> Вы еще про аудит dehydrated спросите.весь смысл dehydrated именно в том, что он достаточно прост и мал для того, чтобы такой аудит был возможен (в отличие от навязываемой летсшиткриптой самообновляющейся поделки)
А на практике вот - тысячеглаз не заметил даже такого ужаса, пока не сломалось.
А афтырь (напомню - а то в новости это не одобрила цензура) - недавно успешно продал свой гуаноскрипт за бабки - и теперь у него, по его словам - "ой, совершенно нет времени, никак нет времени" - так что переделывать он будет... когда-нибудь никогда.
Так в том и соль, что регулярно, особенно сложные, едва ли запросто подвергаются аудитом и проверкам
> Так в том и соль, что регулярно, особенно сложные,этот вот был простой, а хрен ли толку? Тысячигласс, бл...
А на практике за пол-года один глазастый и неленивый нашелся, да и то когда уже просто сломалось, а не в рамках рутинной проверки.
Своему коду я доверяю и придерживаюсь концепций безопасного программирования, а вот можно ли доверять чужому коду, в которому уже кучу дыр нашли....
> Своему коду я доверяюЗря. Доверять нельзя никому, но уж себе — вообще ни в коем случае.
> Самопальный разбор конечно же исследовался на безопасность, аудит провели?Использовалась инновационная^W баянная технология аудита "неуловимый Джо" :)
True tool для хардкорных пацанов, которые не доверяют никому ;)
https://github.com/diafygi/gethttpsforfreeгде JSON (JavaScript Object Notation) парсится нативным JavaScript
> где JSON (JavaScript Object Notation) парсится нативным JavaScriptв твоем браузере. Ну его, знаешь ли, нах.
Но, если что - это тот же автор что acme-tiny. Который как раз действительно tiny, действительно позволяет аудитить глазками, и не содержит п-цов типа грепа по json. Минус, правда, есть - он тоже не работает с bypass.no ;-) Но это легко поправить.
> где JSON (JavaScript Object Notation) парсится нативным JavaScriptПроблема в том что сабж актуален для автоматизации серверов. А ваше нечто - оно вообще для чего? Чтобы поднять сайт на 3 месяца - и потом забыть про него когда сдохнет неоплаченый сервак и протухший сертификат? :)
> Проблема в том что сабж актуален для автоматизации серверов. А ваше нечто - оно вообще для чего?Например - протух сертификат (нормальный, двухгодовалый не халявный), а вы в отпуске, а дежурного админа найти не могут(проиграл в карты и его утопили, запил, проспал...) и нужно быстренько поставить что то временно взамен пока не вернешься с отпуска и купишь нормальный серт...
Против acme.sh этот dehydrated и правда слабоват.P.S. Господа из Битрикса запилили именно его старую версию в свою поделку bitrix_env.sh, и им получают серты - и одно время что-то там внутри сломалось, что серты не обновлялись. Думаете, был фикс со стороны Битрикса?
А что такое "Битрикс" ? И под какой лицензией он выпускается ?
Если BSD - то и нафик не надо.
> Если BSD - то и нафик не надо.Круче, это нечто проприетарное. И кстати они додумались использовать xml-like с русскими названими тегов.
acme.sh - это тот самый китаец, который думает что он лучше других знает как должен выглядеть конфиг nginx-a ?
ну я чота не понял - ты хотел автоматики или не хотел?
чур чур от такой автоматики...
В том же обезвоженом есть хуки через которые можно reload nginx вообще без правки конфигов...
И автоматика на месте и ключи обновились
в acme.sh, внезапно, тоже так можно
Никто не заставляет пользоваться китайским генератором конфига. Если его не просить - оно и не генерит.
Сдается, что вранье про nginx: конфиг писать он не пробует, так что не надо гнать волну.Зато работает давно и надежно, и это сильно плюс.
Использование JSON.sh мне видится хорошим решением, в идеале просто выдернуть оттуда нужные функции.> Автор новости: пох.
Ладно.
> Использование JSON.sh мне видится хорошим решениема использование п-ца dehydrated после такого каминаута - тебе видится хорошим решением?
Я в общем новость писал из соображений "бегите, глупцы!"
Ну dehydrated хотя бы легаси не использует в отличие от certbot с Python 2 в зависимостях. acme.sh остается правда.Да, то что он может в любой момент сломаться действительно фатально. Я думал переводить на него свой сервер с certbot , но теперь буду выбирать что-то другое или вообще дождусь пока certbot 2 питон выкинут.
Жаль что на OpenWRT роутере сабж практически единственный вариант.
да как бы ладно сломаться - но я что-то не уверен что он при такой квалификации автыря и подходе на от...сь не выполнит в один прекрасный день то, что должен был погрепать.
acme.sh - ну если много смелости доверять скрипту который роется не в своих конфигах, чем он тогда луче чем certbot ?
А если нужен не легаси питон, то: acme-tiny
что то около 200 строк - вообще без всяких завиcимостей
> acme.sh - ну если много смелости доверять скрипту который роется не в своих конфигахну будь же мужыком, подсунь ему СВОЙ конфиг - не парсящийся твоим nginx, и пусть переписывает его до изумления ;-)
> А если нужен не легаси питон, то: acme-tiny
Вообще-то у него все в порядке с legacy - посмотри в первых строчках, как он обходит проблему с 2.7
У него не все в порядке с тем что автор, кажется, забил х.й, или сделался вечноживой - хороший pr с dns-01 повис в воздухе, с bypass не работает потому что на самом деле нарушает протокол, ну и прочих issues там хватает, а автор похоже даже не читает их.
Ну и там все ручками - ключ, csr, самостоятельно сохранить выхлоп.
Что немного неудобно, если сайтов у тебя сотни - или придется уже свои обертки писать, в то время как acme.sh все это сделал бы за тебя, безобразно, зато единообразно.
Да не трогает он твой конфиг, если не просить.Матчасть учи!
Вы правда думаете что я не читал документацию и вы открыли мне америку ???Зачем ВООБЩЕ трогать конфигурации сервисов использующих сертификаты?
Достаточно переписать существующие сертификаты и все.Весь смысл секьюрности используя обезвоженного, acme.sh, acme-tiny - это генерировать сертификаты, не из под рута, которые можно аудитать самому. Если вы и тот чувак считает, что можно трогать ЧУЖУЮ конфигурацию, из под рута, то от чистого сердца - удачи вам обоим, если не догоняете элементарных основ безопасности...
> Зачем ВООБЩЕ трогать конфигурации сервисов использующих сертификаты?а зачем еще и сам скрипт каждый раз автоматически обновлять, "из надежнейшего источника"?
Пипл любит чтоб поменьше напрягать межушный хрящ.
А что при этом открывается поле для интереснейших экспериментов - это до них не дойдет никогда.> Достаточно переписать существующие сертификаты и все.
ну вообще-то тоже так себе идея.
Даже у варианта с симлинками - потому что симлинк читается от рута потом, и может неожиданно оказаться не тем, чем ожидалось.Но никакой ручной аудит в случаях сотен сертификатов со сроком действия три дня невозможен, поэтому готовиться надо именно к такой работе :-(
Или вот, может кому собачку на юге дефаултсити регулярно выгуливать надо? Да чорт с ним, с югом - в дефаулт сити, не уточняя, каком именно?
Dehygraded
Degraded
> но исключительно в режиме dns-1Другого и не нужно! По другому *. не получишь.
решение проблемы очевидно: четко описать в документации требуемый формат входных данных. В данном случае - то, что json должен быть правильно отформатирован.Не надо подсовывать юзеру незаменяемые костыли вроде JSON.sh. Юзер не дурак и сам разберется, благо задача тривиальная и инструментов куча. А для думающих, что юзер дурак, уже есть макось, винда, андроид и т.п.
> решение проблемы очевидно: четко описать в документации требуемый формат входных данных.Он чётко описан: json
> В данном случае - то, что json должен быть правильно отформатирован.
Это дополнительное требование, если мы добавляем его к стандарту на json, то мы получаем другой стандарт.
> Не надо подсовывать юзеру незаменяемые костыли вроде JSON.sh.
Я тоже так считаю. sh должен научится поддерживать json из коробки. Это будет офигенным плюсом, потому как у sh вообще есть серьёзные проблемы безопасно работать с внешними данными -- внешние данные постоянный источник багов и дыр в шелл-скриптах. Поддержка же json позволит избавится если не ото всех граблей, которые башевский read раскладывает, то по-крайней мере от самых гнусных.
Когда был моден xml, sh не повёлся на моду, и это обернулось к лучшему, потому как xml ужасен. Но json уже доказал себя как формат данных для межпроцессного взаимодействия. И со стороны sh глупо это игнорировать, поскольку весь sh построен на организации этого самого межпроцессного взаимодействия.
Хотя, с другой стороны, sh -- это такая окаменелость, что туда уже ничего невозможно добавить. Единственный возможный выход -- выкинуть sh.
>потому как xml ужасен.А ужасен он в первую очередь тем, что есть стандартный механизм проверки, что этот xml - тот что надо xml. Json же от рождения такого оверинжиниринга не предлагает. Поэтому сначала надо распарсить его отъев 4Tb оперативки, а только потом выяснить - подходит ли он тебе. :)
>>потому как xml ужасен.
> А ужасен он в первую очередь тем, что есть стандартный механизм проверки,
> что этот xml - тот что надо xml.Нет, он ужасен тем, что он весь целиком оверинжиниринг. Попытка адаптировать sgml под произвольные данные. Механизм проверки в целом полезен, но я не думаю, что этот механизм проверки отъедает меньше оперативной памяти, чем парсинг json: чтобы проверить xml на соответствие dtd тебе придётся распарсить xml. Другое дело, что тебе не придётся писать сложный код проверки, потому как есть библиотечный и ещё более сложный код для общего случая.
Кто-то в интернете нашёл баг в какой-то программе. Охренеть новость
> Кто-то в интернете нашёл баг в какой-то программе.во-первых, не в какой-то, а в такой на которой держится безопастность приличной части того интернета. Во-вторых не баг а п-ц, причем полный. В-третьих ушло всего пол-года на то чтобы этот кто-то нашелся.
>> Кто-то в интернете нашёл баг в какой-то программе.Когда я на Хабре высказал своё мнение что нафиг LS ибо раз в три месяца менять руками сертифкат геморройно а ставить на сервер сторонние приблуды которые что-то откуда-то сами качают несекурно - меня кроме ещё одного параноика никто не поддержал :(
Ничего, скоро и платные EV придется раз в три месяца обновлять :)
да не будет уже никаких платных EV. Гугель лучше тебя (и лучше нотариусов) знает, правильный у тебя сертификат, или нет. А пользователю скоро даже после двадцати приседаний и включения ста отладочных флагов перестанут показывать "ненужную" ему информацию.
>да не будет уже никаких платных EV.В итоге, похоже, так и будет. Прекрасные времена.
Именно в какой-то. В первый раз об этом поделии слышу.
> во-первых, не в какой-то, а в такой на которой держится безопастность приличной части того интернета. Во-вторых не баг а п-ц, причем полный.П-ц был бы, если бы оно действительно как-то влияло на безопасность. Но оно не влияет.
А теперь, внимание, вот это — п-ц полнее некуда:
https://src.fedoraproject.org/rpms/dehydrated/blob/master/f/...
> Но оно не влияет.ты, конечно же, проверил?
> https://src.fedoraproject.org/rpms/dehydrated/blob/master/f/...
и в чем тебе померещилась проблема в этой строчке?
> ты, конечно же, проверил?Да, прикинь, я смотрел в код перед тем, как его использовать. И видел эту хрень с JSON. Дело было явно раньше, чем сабжевый баг был зарепорчен.
> и в чем тебе померещилась проблема в этой строчке?
Угадай. (Нет, у certbot не лучше, но у него by design, а тут просто раздолбайство майнтейнера.)
> Дело было явно раньше, чем сабжевый баг был зарепорчен.А, нет, вру. В сентябре, кажись, это было.
Жаль, Кристапс на переносимую версию своего клиента забил. Очень годная штука была.
https://github.com/graywolf/acme-client-portable
> https://github.com/graywolf/acme-client-portableПасиб.
а чего так все возбудились? Найдена ошибка - исправлена. А у тру-админов, которые не мерзкие девопсы-системдос-юзеры, один вечер уйдет написать свой аналог скрипта. Это же просто скрипт, алло, таких по десятку на проде у вас!
> а чего так все возбудились? Найдена ошибка - исправлена.Но-но-но. Здесь философский вопрос ставится - кто виноват? И то, что кто-то уже что-то поправил, не отменяет этого вопроса. Это вопрос столь же фундаментальный как вопрос борьбы добра и зла. Сервер и клиент - кто под кого должен прогибаться? Человечекочитаемый протокол или машиночитаемый - какой лучше? Зачем сложные стандарты передачи данных, если есть простые?
Только думать надо хотя бы на стадии принятия этого JSON во всех щелях. Не очень он и человекочитаемый. Почему бы не использовать `key=value;key2=value2;...` формат по дефолту, не понятно.
> Почему бы не использовать `key=value;key2=value2;...` формат по дефолту, не понятно.Вполне понятно. Потому что он читается на порядок хуже, чем JSON.
Для лучшей читаемости надо "key1=value1\nkey2=value2\nkey3=value3". И грепать намного удобнее.
> интеграция готового парсера на языке shell - JSON.sh.а слабО на csh/tcsh ??
а в чем проблема? Не все ли равно, из какого шелла egrep с sed'ом вызывать?
пох
>When the "authorizations" list in the result contains multiple items with no spaces between them, the next for-loop doesn't work correctly because bash can't split on anything.Но это же некорректный подход? В JSON пробелы не играют значения, очень глупо полагаться на то, что они будут с пробелами или чем там ещё.
То есть автор с самого начала неправильно решил обрабатывать JSON, что вылилось в текущую эпопею. Правильно?
> Автор проекта dehydrated (проект недавно был продан компании Apilayer GmbH) согласился, что разбор JSON является большой проблемой, но добавлять внешние парсеры он не считает хорошей идеей, так как одним из ключевых достоинств скрипта является отсутствие привязки к внешним зависимостям.Передайте кто-нибудь автору, что отсутствие зависимостей -- нахрен никому, кроме него, не нужно. Развелось блин наркоманов.
>Причина оказалась банальна: вместо того чтобы разбирать ответ в формате JSON по настоящему, автор dehydrated использовал особенность форматирования конкретного JSON-вывода от сервиса Let's Encrypt и выполнял разбор при помощи регулярного выражения.А что вы ещё хотели от баше...филов. Если что-то серьёзное сделано на баше, и особенно критичное к безопасности - значит автор этого альтернативно одарён и от него и его поделий надо держаться подальше.
Есть пословица - you are only as good, as your tools. То есть, ты можешь сто раз всем доказывать, что ты умный как Фейнман, но пока ты используешь вилку, чтобы чистить унитаз, а туалетный ёрш - чтобы класть им в рот спагетти, в твой ум никто не поверит, да и до добра такое не доведёт.
> Есть пословица - you are only as good, as your tools. То есть, ты можешь сто раз всем доказывать, что ты умный как Фейнман, но пока ты используешь вилку, чтобы чистить унитаз, а туалетный ёрш - чтобы класть им в рот спагетти, в твой ум никто не поверит, да и до добра такое не доведёт.Среди некоторых людей популярно мнение, что чем менее удобен инструмент, тем круче тот, кто им пользуется. Обычно это называют Unix philosophy.
LetsEncrypt вывод поменял без уведомлений. Это также может сказаться и на других не официальных клиентах.
Во-первых, перечитай новость: ничего он не менял (пока). Во-вторых, имеет полное право менять без предупреждений, не нарушая спецификацию протокола.
Ну и вообще
> The implementation of a protocol must be robust. Each implementation
> must expect to interoperate with others created by different
> individuals. While the goal of this specification is to be explicit
> about the protocol there is the possibility of differing
> interpretations. In general, an implementation must be conservative
> in its sending behavior, and liberal in its receiving behavior.© Jon Postel, RFC791
Let's Encrypt в этом отношении молодец, автор dehydrated — нет.
Самопальный парсинг жсон это дно.
Такое надо на питон писать