Для работы с ASN.1 использует куда более лучшую (по моему) библиотеку PyDERASN (https://habr.com/ru/post/444272/), которая и проще в использовании и в PyGOST многие схемы (пускай и не полные, но достаточные для обработки тестовых примеров ТК26) для неё приложены.
В качестве WARC-прокси/просмотрщика может выступать http://www.tofuproxy.stargrave.org, сам который использую. Динамическое добавление, удаление, индексирование, поддержка сегментированных .warc.gz/.warc.zst.
> Почему не писать в tmpfs, а не в шифрованный раздел?
Ну потому что всё же view/undo и прочее мне нужно :-). Это точно не эфемерная информация. А так да: можно и в tmpfs бы было.
Если ваш терминал умеет много наворотов, то согласен что от tmux-а многий функционал отпадает. Держать приложения в tmux это только для «надёжности»: вдруг X11 отвалится, вдруг dwm, вдруг st или ещё чего. Ну а для серверов это must-have, ибо канал связи может когда угодно отвалиться.
sendmail команда всюду и везде будет фигурировать, ибо и Postfix и Exim «эмулируют» её поведение — можно сказать что это такой API.
% pkg which =sendmail
/usr/local/sbin/sendmail was installed by package postfix-3.3.1_1,1
Касательно urlview и URL-ов терминала: мне кажется что терминал не может чисто технически точно знать информацию об URL. У меня полно встречаются очень длинных URL-ов, которые не умеющаются на одной строке экрана. Если эта строка будет показана в Vim, то чисто технически это длинная часть URL на одной строке, далее идёт вторая строка, начинающаяся с колоночек Vim-а (всякие номера строк, fold, ...), а потом продолжение части длинного URL. Терминал не имеет представление что кусок одной строки является продолжением второй. Mutt при wrapping строчек любит рисовать красный "+" — терминал же тоже не знает что этот "+" не является частью длинной URL строки. Некоторые приложения, знающие ширину экрана, после каждой визуальной строки могут вставлять "\n", а какие-то не парятся по этому поводу — тоже может смутить терминал. Согласен что удалённый Mutt тогда не сможет у меня локально что-то запустить, поэтому… тут применяю tmux перехват экрана для парсинга URL-а… получая все те же самые потенциальные проблемы (с длинными URL) как и обычный бы терминал :-). Я URL-ы в терминале парсил когда-то в urxvt — не спорю что это конечно тоже бывает удобно.
Про ~/.Xmodmap спасибо за намёк — надо будет поискать. Возможно у меня другие коды клавиш посылаются и из-за этого всё равно он будет нужен.
>F2 далеко от home row
Это аргумент из той же серии как и Escape, часто используемый в vi, тоже далеко находится. Парировать мне нечем — действительно далеко :-). Есть знакомые которые Esc на другие клавиши переносят. Но… вот честно, даже Esc никогда не парил меня. Просто наверное привык так часто проводить рядом с этим высоким рядом клавиш своими руками, что просто не замечаю. А если более серьёзно подойти к этому вопросу, то есть мнение что рукам тоже нужно давать «волю» и временами выполнять не совсем на 100% эффективные действия (чтобы они двигались рядом с одним местом, грубо говоря), заставляя их переносить к отдалённым клавишам чтобы хоть насколько то давать им отдых, сбрасывать напряжение от 100% эффективности. Есть просто такое мнение, которое греет мои Esc и функциональные клавиши — типа для здоровья полезнее, пускай и небольшим падением КПД.
> Имхо удобнее это делать выставлением формы курсора
Хм, даже не знаю как эта форма меняется, если честно — не силён тут в терминальных штуках. Но если её можно поменять какими-нибудь escape-последовательностями (и st терминал это поддерживает), то мне этот вариант однозначно нравится!
> Microsoft Outlook
Понимаю что был бы я в других организациях, то это могло бы и навредить, но от спама это ОЧЕНЬ хорошо помогает!
Спасибо! Выглядит интересно и достойно, но мне не хватает возможности множественного выбора (fzf -m). Я действительно очень часто выбираю сразу по несколько элеменов предложенных, особенно для git команд.
Сейчас даже использование слова «master» будет задевать миллионы людей. Не поверите, но я спросил и коллег и родителей, не возникает ли ассоциации с чем-то непотребным у моего названия — ни у кого не возникло. В страшное мы время живём, раз написать «my config» по немецкий (или вообще всё что связано с «mein k*»?), из-за того что у меня этот язык по умолчанию, будет задевать людей.
Для открытия зашифрованного диска у меня парольная фраза под 120 символов, а для PGP ключей под 100. Набираю каждый день и не один раз. Около 40 символов для SSH ключей. Даже не задавался вопросом удобно ли это, ибо без проблем набирается шустро.
Всю информацию и новости, кроме почтовых рассылок, получаю из RSS/Atom. Newsboat как читалка. И из года в год количество feed-ов на которые я подписан всё только растёт и уже приближается к 400: www.stargrave.org/Links.html. Там же их список можно скачать и в recfile формате, и в XBEL и OPML.
Сейчас есть даже де-факто стандарт для архивирования web-сайтов: en.wikipedia.org/wiki/Web_ARChive (WARC). А вообще можно используя GNU Wget делать «зеркалирование» (--mirror) целых сайтов, автоматически заменяя внутри HTML-ек ссылки с абсолютных на относительные и иметь возможность локально в offline смотреть сайты. Wget может из коробки и WARC-и делать. На python есть программы которые позволяют в режиме прокси «путешествовать» по .warc файлам. Тема offline-а не мертва, все инструменты до сих пор вовсю имеются. В документации к NNCP (утилиты для store-and-forward обмена данными) даже есть раздел посвящённый WARC-ам и пересылкам друг другу целых сайтов: www.nncpgo.org/WARCs.html. Учитывая всё разрастающуюся цензуру в Сети, это точно будет всё актуальнее.
«В конце хотелось бы упомянуть области применения хеш-функции Skein...» — упомянута только часть применений описанных в Skein reference whitepaper. Tree-hashing очень полезная штука, имеющаяся и в BLAKE(2?), помогающая распараллеливать вычисления хэша, в BLAKE3 вообще сразу из коробки работающая для «больших» сообщений. Skein из коробки имеет возможности для задания randomized hashing и personalization. Кроме PRNG Skein может безопасно использоваться и для симметричного шифрования. Всё это штатно предлагается и описывается к применению авторами Skein.
«алгоритм Skein уступил в финале SHA-3 более быстрому и менее уязвимому Keccak» — это очень голословное утверждение, так как Keccak был одним из самых медленных среди всех конкурсантов, а Skein быстрым, причём как на «больших» компьютерах, так и на встраиваемых процессорах. www.skein-hash.info/sha3-engineeringeprint.iacr.org/2010/531.pdf. Как и утверждение про «уязвимость» Keccak vs Skein, мягко говоря, очень спорное (на чём основано?). Среди требований к SHA3 было и то, что хэш наоборот не должен быть слишком быстрым, что возможно было одной из причин «проигрыша» Skein. По анализам www.researchgate.net/publication/235677375_Security_Margin_Evaluation_of_SHA-3_Contest_Finalists_through_SAT-Based_Attacks вообще Skein имеет самый высокий порог безопасности, тогда как Keccak плетётся в конце финалистов SHA3. BLAKE считается имеет очень большой «запас прочности» и в BLAKE2 даже снижали его, ради производительности (BLAKE2 поэтому в целом очень и очень популярен во множестве задач, ибо быстрее MD5, при этом всё равно имея высочайшую безопасность).
«что показало наличие уязвимостей в алгоритмах и ставило под сомнение безопасность электронной цифровой подписи на основе данных хеш-функций» — тоже очень громкое утверждение. Проблемы с коллизиями есть у SHA1. Потенциально могут быть в теории у SHA2, который имеет схожую конструкцию. Это не значит что они есть, не значит что конструкция сама по себе плоха, не значит что SHA2 уязвим/сломан, поэтому на данный момент, даже когда создают какие-то системы с нуля (например Git переводят с SHA1), то всё равно продолжают с чистой совестью выбирать SHA2, так как SHA3 даже по производительности не покажет ощутимые плюсы и его выбор мало даст очевидных и осязаемых преимуществ. Никто от SHA2 не избавляется и не считает его уязвимым. А смысл перехода на SHA3 у многих вызывает скепсис.
В LibreSSL ГОСТовые есть, в GnuTLS тоже. В OpenBSD, DragonflyBSD, HardenedBSD и ряде GNU/Linux дистрибутивов вообще LibreSSL по умолчанию ставится, соответственно и наши алгоритмы из коробки идут.
Если что, то распараллелить команды можно и через GNU parallel (небольшая программа на Perl): parallel «convert {} {.}.png && touch -r {} {.}.png && rm {}» ::: *.bmp. Плюс не будет проблем с пробелом.
www.gost.cypherpunks.ru/Russian.html — а вот тут собраны ссылки и на другие стандартизованные алгоритмы, тоже активно используемые в «наших» TLS/CMS протоколах, типа MGM, ACPKM, SESPAKE.
Вот только сейчас Make не справляется с поставленными для него задачами (из-за использования mtime для определения свежести целей) и требует изучения нового декларативного языка (а точнее одного или сразу нескольких диалектов Make). Можно ничего нового не изучать и писать на любимом языке, полностью выполняя все аналогичные задачи: habr.com/ru/post/517490
Лично я тоже считаю что для «обычных» домашних применений это всё допустимо. И действительно оно *очень* экономит round-trip-ы, что особенно заметно в WiFi/сотовых сетях с бОльшими задержками. Кроме того, что это всё нужно включать, так ещё и application протоколы тоже должны уметь этим всем пользоваться и предоставлять EarlyData (или pre-Finish application data со стороны сервера) при вызове функций запуска TLS handshake.
Я не хочу сказать что EarlyData это прям не безопасно. Это просто спорный tradeoff. В ГОСТ TLS 1.3 решили что этот режим работы не допустим. RFC на TLS 1.3 считает позволительным. Каждый сам решает за/против.
Исходный код PyGOST имеет различные тестовые примеры, масса которых взята из ТК26 документов. Среди них есть и PFX-контейнер, полностью разбираемый и дешифруемый: http://www.git.cypherpunks.ru/?p=pygost.git;a=blob;f=pygost/test_pfx.py
Для работы с ASN.1 использует куда более лучшую (по моему) библиотеку PyDERASN (https://habr.com/ru/post/444272/), которая и проще в использовании и в PyGOST многие схемы (пускай и не полные, но достаточные для обработки тестовых примеров ТК26) для неё приложены.
В качестве WARC-прокси/просмотрщика может выступать http://www.tofuproxy.stargrave.org, сам который использую. Динамическое добавление, удаление, индексирование, поддержка сегментированных .warc.gz/.warc.zst.
Ну потому что всё же view/undo и прочее мне нужно :-). Это точно не эфемерная информация. А так да: можно и в tmpfs бы было.
Если ваш терминал умеет много наворотов, то согласен что от tmux-а многий функционал отпадает. Держать приложения в tmux это только для «надёжности»: вдруг X11 отвалится, вдруг dwm, вдруг st или ещё чего. Ну а для серверов это must-have, ибо канал связи может когда угодно отвалиться.
sendmail команда всюду и везде будет фигурировать, ибо и Postfix и Exim «эмулируют» её поведение — можно сказать что это такой API.
Касательно urlview и URL-ов терминала: мне кажется что терминал не может чисто технически точно знать информацию об URL. У меня полно встречаются очень длинных URL-ов, которые не умеющаются на одной строке экрана. Если эта строка будет показана в Vim, то чисто технически это длинная часть URL на одной строке, далее идёт вторая строка, начинающаяся с колоночек Vim-а (всякие номера строк, fold, ...), а потом продолжение части длинного URL. Терминал не имеет представление что кусок одной строки является продолжением второй. Mutt при wrapping строчек любит рисовать красный "+" — терминал же тоже не знает что этот "+" не является частью длинной URL строки. Некоторые приложения, знающие ширину экрана, после каждой визуальной строки могут вставлять "\n", а какие-то не парятся по этому поводу — тоже может смутить терминал. Согласен что удалённый Mutt тогда не сможет у меня локально что-то запустить, поэтому… тут применяю tmux перехват экрана для парсинга URL-а… получая все те же самые потенциальные проблемы (с длинными URL) как и обычный бы терминал :-). Я URL-ы в терминале парсил когда-то в urxvt — не спорю что это конечно тоже бывает удобно.
Про ~/.Xmodmap спасибо за намёк — надо будет поискать. Возможно у меня другие коды клавиш посылаются и из-за этого всё равно он будет нужен.
>F2 далеко от home row
Это аргумент из той же серии как и Escape, часто используемый в vi, тоже далеко находится. Парировать мне нечем — действительно далеко :-). Есть знакомые которые Esc на другие клавиши переносят. Но… вот честно, даже Esc никогда не парил меня. Просто наверное привык так часто проводить рядом с этим высоким рядом клавиш своими руками, что просто не замечаю. А если более серьёзно подойти к этому вопросу, то есть мнение что рукам тоже нужно давать «волю» и временами выполнять не совсем на 100% эффективные действия (чтобы они двигались рядом с одним местом, грубо говоря), заставляя их переносить к отдалённым клавишам чтобы хоть насколько то давать им отдых, сбрасывать напряжение от 100% эффективности. Есть просто такое мнение, которое греет мои Esc и функциональные клавиши — типа для здоровья полезнее, пускай и небольшим падением КПД.
> Имхо удобнее это делать выставлением формы курсора
Хм, даже не знаю как эта форма меняется, если честно — не силён тут в терминальных штуках. Но если её можно поменять какими-нибудь escape-последовательностями (и st терминал это поддерживает), то мне этот вариант однозначно нравится!
> Microsoft Outlook
Понимаю что был бы я в других организациях, то это могло бы и навредить, но от спама это ОЧЕНЬ хорошо помогает!
> ~/work/pyderasn
habr.com/ru/post/444272
habr.com/ru/post/498014
«Изначально созданные для повышения эффективности цифровых подписей» — вообще криптографические хэш функции появились задолго даже до протокола Диффи-Хельмана, не говоря про асимметричные подписи: crypto.stackexchange.com/questions/56404/what-was-the-first-hash-and-what-problem-was-it-supposed-to-solve
«что показало наличие уязвимостей в алгоритмах и ставило под сомнение безопасность электронной цифровой подписи на основе данных хеш-функций» — тоже очень громкое утверждение. Проблемы с коллизиями есть у SHA1. Потенциально могут быть в теории у SHA2, который имеет схожую конструкцию. Это не значит что они есть, не значит что конструкция сама по себе плоха, не значит что SHA2 уязвим/сломан, поэтому на данный момент, даже когда создают какие-то системы с нуля (например Git переводят с SHA1), то всё равно продолжают с чистой совестью выбирать SHA2, так как SHA3 даже по производительности не покажет ощутимые плюсы и его выбор мало даст очевидных и осязаемых преимуществ. Никто от SHA2 не избавляется и не считает его уязвимым. А смысл перехода на SHA3 у многих вызывает скепсис.