From: Sergey Matveev Date: Sun, 16 Feb 2020 18:45:09 +0000 (+0300) Subject: Зарелизил PyDERASN 7.0 (и 7.1) X-Git-Url: http://www.git.stargrave.org/?a=commitdiff_plain;h=4dffb278147e009b0844a147587b148313f22a2b;p=stargrave-blog.git Зарелизил PyDERASN 7.0 (и 7.1) Тьма работы проделана над этим релизом! Из важнейших изменений, ради которых необходимо обновляться: * сортировка элементов при кодировании в DER делалась неправильно. На практике, по чистому везению с номерами IMPLICIT/EXPLICIT тэгов, оно получается корректным, но я в курсе только про X.509 область * в SET кодирование можно было засунуть несколько элементов с одним и тем же тэгом и последний "выиграет", ничего не упадёт, хотя ситуация абсолютно недопустимая Ну а дальше я увидел как-то что в pyasn1 появилось что-то не тему потокового декодирования. И меня в дополнение не оставляла мысль что отпарсить CACert.org CRL-ку занимает полгига в PyDERASN (в других библиотеках ещё больше ощутимо): http://pyderasn.cypherpunks.ru/performance.html Реализовал я режим декодирования evgen (event generation). Это позволяет буквально поток событий декодирования обрабатывать на лету, вообще не занимая память декодированными структурами (ну, почти). Добавил поддержку (ну точнее оно и так работало, просто не было удобных обёрток) mmap-ed файлов над которыми можно сделать memoryview -- это позволяет вообще не загружать декодируемый файл в память. Хорошо, может теперь декодировать всё что угодно. А как закодировать? Добавил возможность кодирования в CER. Декодировать его в BER режиме и так можно, правда без валидации что это валидный CER. CER пишет сразу напрямую в writer: хоть память, хоть файл на диске. Мне CER очень понравился: реально можно без проблем его кодировать потоково, плюс он имеет одно и только одно представление, что делает пригодным для криптографии. Но... насколько понимаю, появился он чуть попозже чем DER, чуть посложнее требует кодеки и поэтому на практике в массы не пошёл криптографические. Теперь можно в памяти иметь только Python структуры. А если хочется много гигабайт закодировать? Добавил поддержку чтения OCTET STRING-ов из memoryview. Если этот memoryview будет над mmap-нутым файлом, то эти гигабайты не придётся загружать в память, а прям буквально килобайтными кусочками копирую из mmap файла в какой-то выходной буфер/файл. Но эти бинарные данные в CER кодировании будут разбиты на множество кусочков! Добавил agg_octet_string который из evgen-ов может удобно собрать их воедино, например сразу записывая в файл или там hasher какой-нибудь. А если хочется создать всё же CRL-ку, в которой миллионы записей? Добавил возможность использования итераторов в SEQUENCE OF. ---