Зарелизил NNCP 3.2 с исправлением зависимости от баги в самом Go

https://lists.cypherpunks.ru/pipermail/nncp-devel/2018-June/000069.html
Использовал сегодня nncp-bundle команду для перелива одних данных.
Ничего не падает, но не работает. -debug говорит что корявый tar
заголовок встречает в потоке.

Оказалось что в Go 1.9 archive/tar библиотека не создавала валидные tar
архивы с длинными путями (более 100 символов). А я nncp-bundle код делал
рассматривая как-раз именно эти архивы. Более того, BSD tar успешно их
обрабатывал. В Go 1.10 они исправили багу в https://github.com/golang/go/issues/9683
и начали создавать корректные архивы которые уже nncp-bundle не в
состоянии был обработать.

В чём проблема? Мне необходимо в потоке байт (которые например льются с
CD-ROM, ленты, просто блочного устройства) искать так называемые NNCP
bundle-ы, которые чисто технически являются tar архивом с пакетами
сложенными в виде:

    NNCP/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/PKTJQKU5M62LF3IND7JTPIJB5A45FSSQ7TEP4SGGT26RW4WAE76A/HKKECXX7PWZ6YCDMWU74BT6OYKDBZLKF25NI4S3LZ3CJ57WTVMAA

где (в данном конкретном случае):
* 2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ -- получатель
* PKTJQKU5M62LF3IND7JTPIJB5A45FSSQ7TEP4SGGT26RW4WAE76A -- отправитель
* HKKECXX7PWZ6YCDMWU74BT6OYKDBZLKF25NI4S3LZ3CJ57WTVMAA -- шифрованный пакет

Всё это в Base32 и поэтому суммарная длина такого пути -- 163 символа.
Сократить это можно каким-нибудь Base64, но оно всё-равно будет длиннее
100 символов и менее удобно для использования человеком.

tar заголовок (USTAR и PAX) имеет фиксированные позиции для хранения
путей. Но в нём два поля: само имя файла и некий префикс который к нему
можно добавить. Длина имени файла ограничена сотней символов.

Для чего я добавлял NNCP/ директорию? Чтобы как-раз таки именно его
искать в потоке байт и пытаться интерпретировать последующие байты как
tar заголовок. Go 1.9 archive/tar библиотека не проверяла длину пути и
буквально просто засовывала эти 163 байта. Почему BSD tar это читал?
Видимо ориентировался по нулевым байтам каким-нибудь. Просто повезло.

Go 1.10 библиотека стала делать корректно: определяет длину пути и
разбивает его на части. Имя пакета (в моём случае) шло в имя файла, а
остальное отправлялось в середине заголовка в поле префикса. В итоге
"NNCP/" оказался где-то в середине заголовка и вся логика по поиску tar
заголовка ломалась. А искать название пакета я не могу потому-что это
псевдослучайная строка. Можно конечно усложнить сам код поиска и в
памяти, найдя NNCP/, "расчитывать" поток байт назад чтобы найти начало
заголовка.

Я решил более простым (с точки зрения кода) способом, но требующим чуть
больше места для хранения. Я просто добавляю перед каждым файлом "NNCP"
директорию в архив. Так как её длина маленькая, то она помещается
полностью в поле имени файла и находится в начале архива, как и прежде.
В коде я, как и прежде, ищу "NNCP", интерпретирую начиная с него байты
как tar заголовок, проверяю что это директория, дальше считываю
следующий заголовок, который уже должен быть файлом с NNCP пакетом.
То есть, теперь хранится вот так:

    NNCP/
    NNCP/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/PKTJQKU5M62LF3IND7JTPIJB5A45FSSQ7TEP4SGGT26RW4WAE76A/HKKECXX7PWZ6YCDMWU74BT6OYKDBZLKF25NI4S3LZ3CJ57WTVMAA