Вы не авторизованы. Пожалуйста, войдите или зарегистрируйтесь.
Форум Рутокен → Техническая поддержка пользователей → 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 operationlibrtpkcs11ecp.so: v.1.5.3.0 от 27.03.2017
такая ситуация с openssh-7.5_p1-r1, с openssh-7.3_p1-r7 работает нормально. как скоро обновите либу?
Добрый день, beelze.
Спасибо за сообщение о проблеме - попробуем воспроизвести у себя. Если проблема воспроизведется, то тогда можно будет говорить о сроках.
На сколько я понимаю, в основных последних дистрибутивах используется версия 7.3 или 7.4. На сколько для Вас критично использование именно версии 7.5? Каким именно дистрибутивом вы пользуетесь?
Gentoo. В текущий момент стабилизированы в основном дереве net-misc/openssh версий 7.3_p1-r7 и 7.5_p1-r1.
Не то чтобы критично, я пока замаскировал openssh > 7.3, но некоторое неудобство, конечно, есть. Тем более что иметь послдение обновления openssh может быть важным в отношении безопасности.
Добрый день, beelze.
Спасибо за информацию. Как только проблема будет продиагностирована и решена, мы Вам сообщим.
Удалось продиагностировать проблему?
Здравствуйте, beelze.
К сожалению, загрузка наших разработчиков не позволяет нам поддерживать все дистрибутивы Linux. Мы поддерживаем в первую очередь версии пакетов в популярных дистрибутивах. На сколько я понимаю, в Ubuntu openssh 1.75 попадет только в конце октября. Поэтому проблема будет решаться к этому времени. Как только появится релиз в котором проблема решена - мы Вам сообщим.
Неожиданный подход к проблеме. Конечно, совместимость с версиями популярных дистрибутивов – это немаловажно, однако де-факто стабилизация определенной версии в рамках определенного дистрибутива, особенно версионного – процесс, зависящий от многих факторов, в том числе и от занятости майнтайнера :-)
Как мне, мягко говоря, кажется, не менее важный фактор – совместимость с версией, стабилизированной апстримом пакета. Но еще более важный момент – указание в данном случае в явном виде рантайм зависимостей (включая версии) для librtpkcs11ecp.so.
То есть если это ограниченный сверху и снизу диапазон версий – то это необходимо знать _до_ установки библиотеки. Иначе получается «воткните-и-попробуйте». Выглядит несколько непрофессионально для коммерческого продукта.
Добрый вечер, beelze.
Мы поддерживаем интеграцию с массой различного ПО как в Windows так и в Linux (несколько сотен). Мы бы рады проверять совместимость при каждом релизе и при каждой стабилизации очередной версии пакета. Но к сожалению, у нас физически нет на это ресурсов.
P.S. Спасибо Вам и всем остальным, кто проверяет различные сценарии и пишет нам о возникновении проблем. Мы стараемся их исправлять как только появляется возможность\ресурсы.
Я не буду комментировать заявление про «несколько сотен» в разрезе конкретно librtpkcs11ecp.so :-) каждый может оговориться, понимаю.
Вопрос тут скорее в том, что в данный момент это кот в мешке – нигде нет четкого и полного списка зависимостей, которые, к слову, совершенно обязательны для любого пакета-кандидата на включение в любой репозиторий.
С чем-то не проверяли, с новой версией итд? Да, возможно, никто за это не будет наезжать. Однако все то, что необходимо для работы, должно быть явно перечислено. Тогда либо не будет проблемы, либо она будет целиком на совести пользователя/майнтайнера итд.
Касательно этой конкретной проблемы – мне удалось быстро найти причину и откатиться, но это совершенно не общий случай. А корень проблемы именно в закрытости зависимостей. Кроме того, отсутствие зависимостей – большое препятствие для пакетирования, даже для самодельного.
Мы поддерживаем интеграцию с массой различного ПО как в Windows так и в Linux (несколько сотен). Мы бы рады проверять совместимость при каждом релизе и при каждой стабилизации очередной версии пакета. Но к сожалению, у нас физически нет на это ресурсов.
Скажите пожалуйста, с какими сборками каких версий openssh тестировалась данная библиотека?
Добрый день, beelze.
Спасибо за обратную связь по зависимостям.
Давайте разберемся чуть глубже. Вопросы совместимости не имеют никакого отношения к зависимостям\пакетам\репозиториям. Вы можете легко посмотреть зависимости нашего пакета - они там есть. Это именно версии пакетов без которых использование librtpkcs11ecp невозможно.
Здесь же мы говорим про взаимную совместимость. Наш пакет не может проставить внутрь себя в зависимость все, что он поддерживает. Вы же не хотите, чтобы при установке librtpkcs11ecp, к Вам автоматом прилетал какой-нибудь LibreOffice, который мы поддерживаем? Такую зависимость могли бы поставить внутрь своих пакетов разработчики openssh, хотя это тоже было бы нелогично - далеко не всем пользователям openssh вообще нужны наши токены.
Есть ли у Вас какие-то предложения, как может выглядеть подобный список совместимости, чтобы Вам было удобно?
P.S. Наша основная инструкция по настройке openssh - https://dev.rutoken.ru/pages/viewpage.a … Id=3440675 вообще обходится без использования ssh-add и скорее всего отлично отработает даже на новой версии 1.75.
Если рассматривать вопрос буквально, то да – зависимости времени компиляции и исполнения не имеют прямого отношения к вопросам совместимости. Однако давайте представим такую ситуацию – 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, который используется прежде всего чтобы не вводить каждый раз пин.
openssh-7.3 уже удален из репозитория, пробовать 7.5 и 7.6 с риском что придется потом откапывать старые ебилды, не очень хочется. есть какой-либо официальный ответ по совместимости librtpkcs11ecp.so (кстати, у них похоже нет версий) с openssh?
Добрый день, beelze.
Задачу взяли в работу. Но приоритет ее не высокий. Поэтому по срокам пока не смогу что-то обещать.
На данный момент librtpkcs11ecp.so работает только с openssh <= 7.3. (7.4, 7.5, 7.7 проверено, agent все так же refused operation). Полагаю, версию 7.3 за истекший период выпилили даже из самых слоупочных дистрибутивов. Не пора ли немного активизировать решение проблемы?
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
Форум Рутокен → Техническая поддержка пользователей → librtpkcs11ecp.so и openssh-7.5_p1-r1