Журнал Витуса

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

А вот теперь в версси 2.9 Ричард Хипп прикрутил туда более автоматическую миррорилку и сам миррорит код fossil на гитхаб.

Подумал и сделал гитхаб миррор vws.

Теперь думаю
а) а не сделать ли фоссиловские мастер-репозитории для dyngo и ctypescrypto у которых сейчас на гитхабе мастер-репозиторий.
б) а не сделать ли на гитхабе клоны фоссиловских репозиториев моей фантастики
в) а не оживить ли гит-репозитории в https://wagner.pp.ru/git/fiction, приделав туда автопуш из соответствующих фоссиловских репозиториев, где идет работа.

При апгрейде wagner.pp.ru на Debian 10 больше всего сил и нервов сьел маленький radicale, у которого всех данных-то 150 кб телефонной книги и 15 кб календарных событий.

Потому что:
1. Из конфигурации убрали префикс URL для работы за reverse proxy. И блин хоть бы написали
"вместо base-prefix используйет http-заголовгок X-Script-Name".
2. Переехали с python2 на python3. А в модуле vobjects при работе в python3 была бага. (которую я уже зарепортил) из-за которой при попытке сериализовать честно распарсенную vcard оно выдавало
Failed to store item '4c393f45-ae9b-4e32-9720-33118152246c.vcf' in collection 'vitus/2b6f78b0-270c-b45d-6e18-3238dad34b44': a bytes-like object is required, not 'str'
Стэк-трасса конечно никуда не показывалась и догадаться в чем дело было довольно непросто.В конце концов выяснилось что последовательность

import vobject
vcard=vobject.readOne("""....""")
vcard.serialize()

эту ошибку прекрасно воспроизводит.
3. После того как эта проблема решилась, началась фигня с фотографиями. Пришлось довольно долго возиться. прежде чем я понял, что PHOTO;TYPE=JPEG;ENCODING=BASE64 оно понимать перестало. Ему теперь надо PHOTO;TYPE=JPEG;ENCODING=B (и версия VCARD тут абсолютно ни на что не влияет). Кстати PHOTO:data:image/jpeg;base64,.... оно тоже не понимает, хотя в спецификации на VCARD 3.0 это предусмотрено.

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

В общем, я чувствую, что после того как python 2 официально объявят deprecated борьба с кодировками во всех библиотеках для python 3 предстоит куда более суровая чем 20 лет назад в tcl и несколько позже в perl.

Мне вот тут на этой неделе в ctypescrypto баг зарепортили что в python3 оно не умеет работать с бинарными данными в CMS. (Ох, ну когда ж я тесты на этот самый CMS напишу? Судя по багрепортам на гитхабе, CMS это основное для чего народ ctypescrypto использует).

Ну, допустим, переписал я этот скрипт с sh+awk на python. Он вырост в длине почти вчетверо, обзавелся
конфигом в ini-стиле и заюзал аж 6 стандартных модулей.

А какой с этого приварок? Ну разве что url-ки на gitweb научились генерировать.

В принципе, можно, конечно подцепить туда еще argparse и научить его генерировать ссылки не только в виде, пригодном ддя jira, но и в markdown (для github), raw html (для DW/LJ) и еще в каких форматах в голову взбредет.

( по-моему это пора на гитхаб коммитить )

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

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

А в комментариях у него пишут что кое-где выпалывают даже слова "черный список" и "белый список". Хотя уж это по-моему к расизму никакого отношения не имеют. В России нету в заметных количествах негров, нет и проблемы расизма, а черные списки - есть. Кстати, а с greylisting-ом что делать?

Там еще есть интересные истории по поводу замены "соска" на "Рождественскую елку" (которая сама по себе не слишком политкорректна.

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

Upd Идея. Если к вам в проект придут с предложением убрать термины master и slave, скажите: «Прекрасно, заменим их на Ubermensch и Untermensch».

Дано: 3-й питон, юникодная строка, примерно до миллиона символов длиной.
Надо: преобразовать эту строку в произвольную 8-битную кодировку, заменяя все символы, отсутствубщие в данной кодировке на html-ные entities.

Как это быстрее всего сделать?

По идее питоновский стиль это "попытаться преобразовать, получить исключение, обработать".
Собственно, так и написал:

from html.entities import codepoint2name

complete=False
while not complete:
    try:
        binary=data.encode(output_encoding)
        out += binary
        complete=True
    except UnicodeEncodeError as e:
        badchar = data[e.start]
        out +=data[:e.start].encode(output_encoding)
        data=data[e.start+1:]
        if ord(badchar) in codepoint2name:
            out+=b'&'+codepoint2name[ord(badchar)].encode("ascii")+b';';
        else:
            out+=b"&#%d;"%ord(badchar);

Но что-то скорость работы этой конструкции мне не нравится (даже на довольно быстрой моей рабочей станции миллион символов из которых только 7200 не представлены в целевой кодировке, жует 0.9 секунды).

Какие еще способы решения этой задачи можно предложить?

Помнится. там были вопросы

Ever change the value of 4?
... Unintentionally?
... In a language other than Fortran?

Так вот, Python 3 is language other than Fortran.

За выходные дописал туда модуль mac. Теперь если мне потребуется вдруг срочно реализовывать гостовскую имитовставку, у меня есть где посмотреть правильную последовательность вызовов функций OpenSSL.

Кстати, надо бы еще написать тесты на PKey.derive. Заодно и вспомню куда там UKM кладут при VKO 34.10. А то вдруг VKO тоже срочно потребуется реализовывать.

И в общем с test coverage там все не так уж плохо:

Name                     Stmts   Miss  Cover
--------------------------------------------
ctypescrypto/__init__        7      1    86%
ctypescrypto/bio            64      6    91%
ctypescrypto/cipher        121     15    88%
ctypescrypto/digest        100      5    95%
ctypescrypto/ec             63     16    75%
ctypescrypto/engine         24      8    67%
ctypescrypto/exception      24      0   100%
ctypescrypto/mac            58      5    91%
ctypescrypto/oid            55      4    93%
ctypescrypto/pbkdf2         13      1    92%
ctypescrypto/pkey          196     48    76%
ctypescrypto/rand           34      4    88%
ctypescrypto/x509          338     55    84%
--------------------------------------------
TOTAL                     1097    168    85%

Ну это, правда, если не учитывать того что на модуль cms тестов вообще нет (это 152 оператора всего и 97 непротестированых).
Большая часть не покрытых тестами строк, правда, представляет собой обработку
возвращенных функциями OpenSSL ошибок. Как сделать, чтобы эти ошибки устойчиво в тестах воспроизводились, пожалуй. не скажет и Хэнсон. Конечно, есть здоровые куски в модулях pkey и x509, до тестирования которых просто не дошли руки. В заметном числе случаев там в конце соответствующего метода вместо вызова OpenSSL-ной функции стоит raise NotImplementedError. Проблема в том, что соотвествующая функциональность нифига не документирована ни в родных man-ах, ни в криптокомовском руководстве программиста, и выяснять как это использовать можно исключительно посредством RTFS.

Полтора месяца назад я жаловался что не нашел удобного средства делать pdf из markdown (и что pandoc таким не является).

Оказалось что всё еще хуже. Хотя формат cуществует всего десятилетие, там уже образовалась своя вавилонская башня. То есть существует как минимум два способа описания таблиц, причем pandoc поддерживает один из них, а fossil - другой. Поэтому из документации с таблицами, которая нормально показывается как embedded documentation в fossil-е нельзя ничего делать pandoc-ом без препроцессирования.

Разозленный этим обстотятельством я взялся за дальнейшие исследования вопроса и, кажется, добился успеха.

Успех пришел в виде сочетания питноновского модуля markdown (пакет python-markdown) и xhtml2pdf (пакет python-pisa). Это дело с неприличным названием я уже пробовал и получил кучу черных квадратиков вместо русских букв. Оказывается, оно всё что надо прекрасно умеет, надо только в CSS не забывать все что надо прописать.

Что-то вроде

media print {
   @font-face {
      font-family: Arial;
      font-weight: normal;
      src: url("/usr/share/fonts/truetype/msttcorefonts/Arial.ttf");
   }
}

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

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

Upd: дальнейшее исследование показало что pandoc 1.12.4 понимает таблицы в том же формате, в каком их понимает fossil.

Чего-то в течение трех дней в любую минуту, свободную от основной работы (в том числе и по вечерам, вместо писания "Императрицы Кэт") вожусь с ctypescrypto.

Выяснил что то что там было написано. работать в общем-то толком и не могло. А где могло, там его функциональность полностью дублирована hashlib-ом. Но по аналогии теперь у меня работает все что было якобы написано у оригинального автора, да плюс еще ряд операций с открытыми ключами.
(низкоуровневых, которые EVP_PKEY_...). Еще бы неплохо сгенеренные ключи сохранять научиться.

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

Хотя на самом деле от сертификатов хочется больше - получить, наконец, корректную и удобую извлекалку полей из X509NAME и extension - в первую очередь.

Тестами покрыто процентов на 20 от силы. (что в бесконечное число раз лучше оригинала).

Правда, вот чего мне непонятно. Есть функция EVP_CipherInit_ex, которая получает в качестве параметров указатели на ключ и iv. Длин этих буферов не получает, видимо предполагая, что если оно не NULL то там не меньше чем EVP_CIPHER_key_length(текущий шифр). Я делаю контекст AES-256-OFB, передаю туда питоновскую строку из 8 символов, а оно не падает. Ни в 32-битной среде, ни в 64-битной. И под электрическим забором - тоже. Но не падает это ладно. Оно ж еще и расшифровывается потом на совсем другом независимо созданном контексте с тем же урезанным ключом.

В общем, если кому интересно https://github.com/vbwagner/ctypescrypto

Сегодня открыл для себя существование в питоне модуля сtypes.

А так же то, что некоторые добрые люди выложили на Google Code интерфесы к некоторым интересным мне функциям OpenSSL, сделанные посредством этого модуля.

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

Теперь вот сижу рисую интерфейс к низкоуровневым фукнциям подписи и проверки (включая доставание ключа из сертификата). Чтобы избавиться в текущем проекте от вызова openssl через subprocess совсем. Оставлю только вызов openssl cms -verify.

Не то чтобы я собрался по этому поводу совсем отказываться от использования pyasn1. хотя часть функциональности явно будет дублироваться. Но боюсь, что нужные мне извраты с ASN1 через ctypes не сделать - в OpenSSL в этом месте очень любят препроцессор.