From 4dffb278147e009b0844a147587b148313f22a2b Mon Sep 17 00:00:00 2001
From: Sergey Matveev <stargrave@stargrave.org>
Date: Sun, 16 Feb 2020 21:45:09 +0300
Subject: [PATCH] =?utf8?q?=D0=97=D0=B0=D1=80=D0=B5=D0=BB=D0=B8=D0=B7=D0=B8?=
 =?utf8?q?=D0=BB=20PyDERASN=207.0=20(=D0=B8=207.1)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=utf8
Content-Transfer-Encoding: 8bit

Тьма работы проделана над этим релизом! Из важнейших изменений, ради
которых необходимо обновляться:

* сортировка элементов при кодировании в 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.
-- 
2.51.0