Pull to refresh
64.7
Karma
0
Rating

Пользователь

  • Followers 40
  • Following

Mein Konfig: экскурсия по dotfiles

Выглядит круто и полезно! Работает даже чуть быстрее чем мой штатный find (по CPU). Спасибо, буду пробовать.

Mein Konfig: экскурсия по dotfiles

> Почему не писать в 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

Понимаю что был бы я в других организациях, то это могло бы и навредить, но от спама это ОЧЕНЬ хорошо помогает!

> ~/work/pyderasn

habr.com/ru/post/444272
habr.com/ru/post/498014

Mein Konfig: экскурсия по dotfiles

Спасибо! Выглядит интересно и достойно, но мне не хватает возможности множественного выбора (fzf -m). Я действительно очень часто выбираю сразу по несколько элеменов предложенных, особенно для git команд.

Mein Konfig: экскурсия по dotfiles

Сейчас даже использование слова «master» будет задевать миллионы людей. Не поверите, но я спросил и коллег и родителей, не возникает ли ассоциации с чем-то непотребным у моего названия — ни у кого не возникло. В страшное мы время живём, раз написать «my config» по немецкий (или вообще всё что связано с «mein k*»?), из-за того что у меня этот язык по умолчанию, будет задевать людей.

Mein Konfig: экскурсия по dotfiles

Отсылкой бы был «mein konf». А у меня на компьютере немецкий язык по умолчанию.

Идеальный пароль по науке: трудно взломать, невозможно забыть

Для открытия зашифрованного диска у меня парольная фраза под 120 символов, а для PGP ключей под 100. Набираю каждый день и не один раз. Около 40 символов для SSH ключей. Даже не задавался вопросом удобно ли это, ибо без проблем набирается шустро.

Почему я по-прежнему пользуюсь RSS

Всю информацию и новости, кроме почтовых рассылок, получаю из RSS/Atom. Newsboat как читалка. И из года в год количество feed-ов на которые я подписан всё только растёт и уже приближается к 400: www.stargrave.org/Links.html. Там же их список можно скачать и в recfile формате, и в XBEL и OPML.

Пользуемся офлайн-браузингом, как будто сейчас 1995 год

Согласен. И, более того, авторы сайтов, как правило, и не заинтересованы в этом содействии.

Пользуемся офлайн-браузингом, как будто сейчас 1995 год

Сейчас есть даже де-факто стандарт для архивирования 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...» — упомянута только часть применений описанных в Skein reference whitepaper. Tree-hashing очень полезная штука, имеющаяся и в BLAKE(2?), помогающая распараллеливать вычисления хэша, в BLAKE3 вообще сразу из коробки работающая для «больших» сообщений. Skein из коробки имеет возможности для задания randomized hashing и personalization. Кроме PRNG Skein может безопасно использоваться и для симметричного шифрования. Всё это штатно предлагается и описывается к применению авторами Skein.

Знакомство со Skein

«алгоритм Skein уступил в финале SHA-3 более быстрому и менее уязвимому Keccak» — это очень голословное утверждение, так как Keccak был одним из самых медленных среди всех конкурсантов, а Skein быстрым, причём как на «больших» компьютерах, так и на встраиваемых процессорах. www.skein-hash.info/sha3-engineering eprint.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, при этом всё равно имея высочайшую безопасность).

«Изначально созданные для повышения эффективности цифровых подписей» — вообще криптографические хэш функции появились задолго даже до протокола Диффи-Хельмана, не говоря про асимметричные подписи: 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 у многих вызывает скепсис.

Шифруем по-русски, или отечественные криптоалгоритмы

В LibreSSL ГОСТовые есть, в GnuTLS тоже. В OpenBSD, DragonflyBSD, HardenedBSD и ряде GNU/Linux дистрибутивов вообще LibreSSL по умолчанию ставится, соответственно и наши алгоритмы из коробки идут.

Кунг-фу стиля Linux: великая сила make

Если что, то распараллелить команды можно и через GNU parallel (небольшая программа на Perl): parallel «convert {} {.}.png && touch -r {} {.}.png && rm {}» ::: *.bmp. Плюс не будет проблем с пробелом.

Шифруем по-русски, или отечественные криптоалгоритмы

www.gost.cypherpunks.ru/Russian.html — а вот тут собраны ссылки и на другие стандартизованные алгоритмы, тоже активно используемые в «наших» TLS/CMS протоколах, типа MGM, ACPKM, SESPAKE.

Кунг-фу стиля Linux: великая сила make

apenwarr.ca/log/20181113 — mtime крайне мало даёт гарантий.

Кунг-фу стиля Linux: великая сила make

Вот только сейчас Make не справляется с поставленными для него задачами (из-за использования mtime для определения свежести целей) и требует изучения нового декларативного языка (а точнее одного или сразу нескольких диалектов Make). Можно ничего нового не изучать и писать на любимом языке, полностью выполняя все аналогичные задачи: habr.com/ru/post/517490

Потроха IPsec, меримся с TLS 1.3, ГОСТ и Go

Лично я тоже считаю что для «обычных» домашних применений это всё допустимо. И действительно оно *очень* экономит round-trip-ы, что особенно заметно в WiFi/сотовых сетях с бОльшими задержками. Кроме того, что это всё нужно включать, так ещё и application протоколы тоже должны уметь этим всем пользоваться и предоставлять EarlyData (или pre-Finish application data со стороны сервера) при вызове функций запуска TLS handshake.

Потроха IPsec, меримся с TLS 1.3, ГОСТ и Go

Я не хочу сказать что EarlyData это прям не безопасно. Это просто спорный tradeoff. В ГОСТ TLS 1.3 решили что этот режим работы не допустим. RFC на TLS 1.3 считает позволительным. Каждый сам решает за/против.

Потроха IPsec, меримся с TLS 1.3, ГОСТ и Go

Верно, только при продолжении сессии по iPSK. Но EarlyData отправляется до Finished сообщений, до того, как противоположная сторона вообще ответила TLS-handshake пакетом, не говоря о том, что аутентифицировала handshake сообщения. С одной стороны: мы отправляем зашифрованные данные, на ключе который может знать только знающий iPSK и поэтому вроде бы ничего опасного. С другой стороны: это всё равно остаётся отправкой application данных ещё совершенно не аутентифицированной стороне.

Потроха IPsec, меримся с TLS 1.3, ГОСТ и Go

* Не утверждали что оно по безопасности хуже. Просто ваш неиссякаемый сарказм натолкнул меня на это. Ok. SIV режим мне тоже нравится.
* Всё зависит от реализаций. Я видел и более быстрые аппаратно ускоренные Кузнечики, чем AES-ы. Про timing атаки не поспорю — но это касается и AES-а того же в той же степени.
* Поэтому чтобы не получиться nonce reuse и говорят про 127/63 векторы инициализации. Мои реализации MGM явно проверяют верхний бит и не дают такое использовать. Nonce reuse фатален.

Это всё не nonse-reuse-resistant алгоритмы, использующие таблицы замены — да, это всё мне тоже не нравится. Но я изначально только сказал что MGM является улучшенной версией. Да, не уточнил по какому параметру. С безопасностью у него лучше. И мне очень нравится что у нас безопасность ставят выше остального. Удручает двойное применение шифрования? Поставьте в два раза больше шифраторов/процессоров — не такое уж оно всё и медленное в софте (а в железе не проблема).

Information

Rating
Does not participate
Location
Королев, Москва и Московская обл., Россия
Registered
Activity