Зарелизил PyDERASN 7.0 (и 7.1)

Что: 4dffb278147e009b0844a147587b148313f22a2b

Когда: 2020-02-16 21:45:09+03:00

Темы: python

Зарелизил 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.

оставить комментарий

Сгенерирован: SGBlog 0.34.0