Про GPG asci- armor

[vitus_wagner]

Коллеги, а как правильно снять ascii-armor с GPG-шного ключа, пользясь только coreutils?

У меня получилось вот так:

sed -n '/^$/,/=$/p' public_key.asc |base64 -d> public_key.gpg

Но мне самом это решение не нравится, потому что вообще говоря никто не обещал, что в последней строчке base64 будет '=' на конце. Если размер бинарного файла случайно получится кратным 3, его там не будет. И то что последняя строка будет короче предыдущей - тоже никто не обещал.

Контекст задачи следующий - есть скрипт подключения репозиториев. Он поддерживает три десятка разных дистрибутиов - и redhat-подобные. и sles, и debian-подобные. И, естетсвенно носит в себе ключ для проверки подписей под метаинформацией или пакетами. Носит его в ascii-armored виде, так как rpm-y его именно в таком виде скармливать надо. А в debian и ubuntu после того, как решили отказаться от apt-key, ключи в /etc/apt/trusted.gpg.d надо класть в бинарном формате. При этом у меня почему-то имеется упорное впечатление что shell у нас не 8-bit clean, и не надо без base64 закладывать ключи в скрипт. При этом наличия полнофункциональногп gpg на системе, куда будет подключаться репозиторий (весьма вероятно это будет какой-нибудь минимальный контейнер) никто не обещал. Только gpgv, которы ключи менеджить не умеет.

К сожалению, формат GPG ascii armor это не pem, где бы вопрос решался условием '/-----BEGIN/,/----END'. Впрочем. в pem в наше время тоже норовят напихать какой-нибудь гадости в виде MIME-пододных заголовков после ----BEGIN (См например ближайший секретный ключ ssh). Но в GPG-шном ключе почеу-то после основного base64 блока присутствует маленький второй, на который base64 из coreutils реагирует болезненно.

Upd Как написано в RFC2240 этот хвост всегда начинается с = Поэтому вот такой скрипт будет лучше работать:

sed -n '/^$/,/^=/{
s/^=.*$//
p
}' public_key.asc |base64 -d > public_key.gpg

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

Comments

[juan_gandhi]

Да ладно, просто прицепить в конце =, а выбирать до первого =, раз base64 такой капризный.

[yurikhan]

Но вот сделать возможным работу с файлом где после ----BEGIN нет опциональных хедеров и пустой строки так не получится.

Так а в RFC и не сказано, что такие файлы валидны. Хедеры опциональны (точнее говоря, их от 0 до *), пустая строка обязательна. Впрочем, она может быть не совсем пустой, а containing only whitespace, так что ^[ \n\t]*$.

[inkelyad]

При этом у меня почему-то имеется упорное впечатление что shell у нас не 8-bit clean, и не надо без base64 закладывать ключи в скрипт.

Скорее всего проблем с бинарными данными не будет. self-extracting архивы-скрипты, создаваемые, например, makeself, вполне успешно такие себе в хвост добавляют. Впрочем, эти данные даже текстом скрипта, похоже, не являются - просто добавленный в конец архив, с которым сам скрипт работает.

[vitus_wagner]

Если в конце, то да. Это пожалуйста. Но ключи-то они в середине.