Полагаю небезынтересным поцитировать поучительный диалог профессионалов технической поддержки разработчика коммерческого продукта (программно-аппаратного комплекса, где ПО идёт приложением к приобретаемому устройству, т.е. «пиратов» там нет), заявляющего поддержку не только Micro$oft Window$, но и наиболее широко распространённой свободной альтернативы в лице GNU/Linux с пользователем СПО:

Вопрос пользователя (12 июня 2017 года):

librtpkcs11ecp.so и openssh-7.5_p1-r1

$ ssh-add -s /opt/rutoken/librtpkcs11ecp.so
Enter passphrase for PKCS#11:
Could not add card "/opt/rutoken/librtpkcs11ecp.so": agent refused operation

librtpkcs11ecp.so: v.1.5.3.0 от 27.03.2017

такая ситуация с openssh-7.5_p1-r1, с openssh-7.3_p1-r7 работает нормально. как скоро обновите либу?

Ответ специалиста ТП, 19 июля [того же года]

Спасибо за сообщение о проблеме - попробуем воспроизвести у себя. Если проблема воспроизведется, то тогда можно будет говорить о сроках.

На сколько я понимаю, в основных последних дистрибутивах используется версия 7.3 или 7.4. На сколько для Вас критично использование именно версии 7.5? Каким именно дистрибутивом вы пользуетесь?

…

13 августа [всё ещё того же года], напоминание пользователя:

Удалось продиагностировать проблему?

Оперативная отписка ТП (16 августа):

К сожалению, загрузка наших разработчиков не позволяет нам поддерживать все дистрибутивы Linux. Мы поддерживаем в первую очередь версии пакетов в популярных дистрибутивах. На сколько я понимаю, в Ubuntu openssh 1.75 попадет только в конце октября. Поэтому проблема будет решаться к этому времени. Как только появится релиз в котором проблема решена - мы Вам сообщим.

Пользователь закономерно переходит к «троллингу» (начало определения здесь, свои мысли по вопросу пока думаю), 17 августа:

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

Как мне, мягко говоря, кажется, не менее важный фактор – совместимость с версией, стабилизированной апстримом пакета. Но еще более важный момент – указание в данном случае в явном виде рантайм зависимостей (включая версии) для librtpkcs11ecp.so.
То есть если это ограниченный сверху и снизу диапазон версий – то это необходимо знать _до_ установки библиотеки. Иначе получается «воткните-и-попробуйте». Выглядит несколько непрофессионально для коммерческого продукта.

Очередная отписка профессионала ТП, подтверждающая справедливость утверждений Дж. Фокса, той же датой:

Мы поддерживаем интеграцию с массой различного ПО как в Windows так и в Linux (несколько сотен). Мы бы рады проверять совместимость при каждом релизе и при каждой стабилизации очередной версии пакета. Но к сожалению, у нас физически нет на это ресурсов.

P.S. Спасибо Вам и всем остальным, кто проверяет различные сценарии и пишет нам о возникновении проблем. Мы стараемся их исправлять как только появляется возможность\ресурсы.

И тут же, образцом «троллинга» по методичке «страдальцев» — ещё одно замечание пользователя:

Я не буду комментировать заявление про «несколько сотен» в разрезе конкретно librtpkcs11ecp.so :-) каждый может оговориться, понимаю.

Вопрос тут скорее в том, что в данный момент это кот в мешке – нигде нет четкого и полного списка зависимостей, которые, к слову, совершенно обязательны для любого пакета-кандидата на включение в любой репозиторий.
С чем-то не проверяли, с новой версией итд? Да, возможно, никто за это не будет наезжать. Однако все то, что необходимо для работы, должно быть явно перечислено. Тогда либо не будет проблемы, либо она будет целиком на совести пользователя/майнтайнера итд.

Касательно этой конкретной проблемы – мне удалось быстро найти причину и откатиться, но это совершенно не общий случай. А корень проблемы именно в закрытости зависимостей. Кроме того, отсутствие зависимостей – большое препятствие для пакетирования, даже для самодельного.

Вопрос заинтересованного пользователя о протоколе тестирования закономерно был проигнорирован. Следующая отговорка — 21 августа:

Спасибо за обратную связь по зависимостям.
Давайте разберемся чуть глубже. Вопросы совместимости не имеют никакого отношения к зависимостям\пакетам\репозиториям. Вы можете легко посмотреть зависимости нашего пакета - они там есть. Это именно версии пакетов без которых использование librtpkcs11ecp невозможно.
Здесь же мы говорим про взаимную совместимость. Наш пакет не может проставить внутрь себя в зависимость все, что он поддерживает. Вы же не хотите, чтобы при установке librtpkcs11ecp, к Вам автоматом прилетал какой-нибудь LibreOffice, который мы поддерживаем? Такую зависимость могли бы поставить внутрь своих пакетов разработчики openssh, хотя это тоже было бы нелогично - далеко не всем пользователям openssh вообще нужны наши токены.

Есть ли у Вас какие-то предложения, как может выглядеть подобный список совместимости, чтобы Вам было удобно?

P.S. Наша основная инструкция по настройке openssh - dev.rutoken.ru/pages/viewpage.a … Id=3440675 вообще обходится без использования ssh-add и скорее всего отлично отработает даже на новой версии 1.75.

Продолжение курса ликвидации безграмотности от пользователя — уже 19 ноября:

Если рассматривать вопрос буквально, то да – зависимости времени компиляции и исполнения не имеют прямого отношения к вопросам совместимости. Однако давайте представим такую ситуацию – librtpkcs11ecp с Firefox работает только с определенными версиями, с openssh – тоже, pam вообще непонятно работает или нет… и в итоге получится, что совершенно неясно – как и с чем использовать токен, и, что *более* важно – можно ли не бояться обновлять эти «поддерживаемые» пакеты?
Если рассматривать иерархию в терминах здравого смысла, то будет звучать нелепо что «новая версия Firefox стала несовместима с моим плагином», ибо все та́ки наоборот. Ну что ж, разработчики openssh решили внести какие-то изменения, которые вызвали проблему совместимости, но наверное было бы смешно создавать там тикет типа «commit #xxxx breaks librtpkcs11ecp»? В любом случае *придется* обеспечивать совместимость со стороны librtpkcs11ecp. Ну если конечно разработчики согласны со мной, что openssh – одно из наиболее часто используемых применений.

Полагаю, что *особенно* ввиду проприетарной природы librtpkcs11ecp именно его разработчикам необходимо выработать стратегию, включающую реально «поддерживаемые» применения, своевременное тестирование на совместимость с новыми версиями оных… плюс мы (пользователи) где-то должны мочь легко и просто ознакомиться с текущим списком совместимых версий.

>> Как только проблема будет продиагностирована и решена, мы Вам сообщим. не было диагностирования и решений? замораживаемся на openssh-7.3?

>>Наша основная инструкция по настройке openssh … вообще обходится без использования ssh-add и скорее всего отлично отработает даже на новой версии 1.75.

Если речь про

ssh -I /usr/lib/librtpkcs11ecp.so

… то это никак не релевантно проблеме ssh-add, который используется прежде всего чтобы не вводить каждый раз пин.

23 ноября прошлого года пользователь сообщает о выпиливании совместимой версии openssh, а 30-го числа того же месяца ТП снисходит до хоть каких-то обещаний:

Задачу взяли в работу. Но приоритет ее не высокий. Поэтому по срокам пока не смогу что-то обещать.

…и тишина. 7 июня уже сего года пользователь пытается напомнить о проблеме:

На данный момент librtpkcs11ecp.so работает только с openssh <= 7.3. (7.4, 7.5, 7.7 проверено, agent все так же refused operation). Полагаю, версию 7.3 за истекший период выпилили даже из самых слоупочных дистрибутивов. Не пора ли немного активизировать решение проблемы?

13 октября проблему подтверждает пользователь дистрибутива, отличающегося, скажем так, не самым свежим ПО.

Справедливости ради: в самой распространённой ОС оно (сертифицированные системы криптографической защиты информации) работает… примерно также.

Только там — люди привычные. В первую очередь к использованию чёрных ящиков. И вообще ересям.

А ещё куда больше ресурсов вкладывается в протаптывание используемых троп.

ЗЫ: В качестве приложения к отмеченной проблеме можно напомнить… дискуссию про закупку ПО в МВД.

И памятник технической грамотности профессиональнов по связям с общественностью из ФСБ.