44604 2022-12-13 13:43:06 +0300 Интерфейс «org.freedesktop.Secret.Collection» для пути /org/freedesktop/secrets/collection/login объекта не найден 2023-12-21 15:04:58 +0300 1 1 4 Development Sisyphus kf5-kwallet unstable x86_64 Linux ASSIGNED P5 normal --- 1 alimektor ptrnine aris shrek varaksaaa zerg qa-sisyphus oldest_to_newest 218822 0 alimektor 2022-12-13 13:43:06 +0300 Версия ====== kf5-kwallet-5.100.0-alt1 kde5-kwalletmanager-22.08.3-alt1 evolution-3.46.2-alt1 Дистрибутивы ============ - p10-kworkstation-10.1-x86-64 Шаги воспроизведения ==================== 1. Установить evolution: # apt-get install -y evolution 2. Очистить конфигурацию KWallet: $ rm -f ~/.local/share/kwalletd/* 3. Запустить evolution и настроить почту, например, Yandex. 4. Ввести пароль от почты. 5. Ввести пароль от кошелька (в окне Служба бумажника KDE → Finish, ввести пароль два раза → OK) 6. Ввести повторно пароль от почты (с отмеченным чекбоксом Добавить этот пароль к связке ключей) → OK. 7. Проверить, что всё настроено правильно закрытием, открытием Evolution, то есть пароль не спрашивается ни от почты, ни от Бумажника. 8. Открыть Управление бумажниками: $ kwalletmanager5 9. Выбрать Настройка → Настроить бумажник → Контроль доступа. 10. Включить параметр "Запрашивать подтверждение при обращении приложений к бумажнику". 11. Нажать "ОК", ввести пароль пользователя → OK. 12. Перезагрузить систему. 13. Запустить Evolution: $ evolution Ожидаемый результат: при запуске необходимо ввести пароль бумажника. После ввода пароля бумажника ввода пароля почты не потребовалось. Фактический результат: запрашивает пароль от почты. Если ввести пароль от почты, будет повторный запрос пароля от почты и так далее. При этом если ввести пароль Каждый ввод пароля сопровождается выводом в терминал: (evolution:4550): e-data-server-ui-WARNING **: 13:05:23.277: credentials_prompter_store_credentials_cb: Failed to store source credentials: Интерфейс «org.freedesktop.Secret.Collection» для пути /org/freedesktop/secrets/collection/login объекта не найден 219222 1 ptrnine 2022-12-19 18:11:48 +0300 Проблема, похоже, возникает из-за того, что кто-то начал запускать gnome-keyring, даже когда kwalletd уже запущен. Если прибить gnome-keyring, все начинает работать как надо. Можно попробовать починить добавлением DBus Service файла. Вообще, service файл для org.freedesktop.secrets для kwallet уже был, но я его не приложил после прохождения Secret Service в апстрим, т.к. все работало из без него. В любом случае этот service файл мало поможет. Чтобы надежно избежать конфликтов kwalletd/gnome-keyring нам нужен какой-то явный механизм переключения бэкендов. 219233 2 ptrnine 2022-12-19 21:09:09 +0300 (Ответ для Slava Aseev на комментарий #1) > Можно попробовать починить добавлением DBus Service файла. Неа, проверил, это не помогает. Тут вообще запускаются сразу два org.freedesktop.secrets сервиса. К тому же, баг https://bugzilla.altlinux.org/42507 воспроизводится и на старой версии, где у kwallet'а еще был dbus-service файл (но там активируется только один сервис, а именно gnome-keyring). В общем, нужно либо решать проблему конфликтом gnome-keyring/kwalletd, либо: > Чтобы надежно избежать конфликтов kwalletd/gnome-keyring нам нужен какой-то > явный механизм переключения бэкендов. Как я понял, в dbus-daemon все активируемые сервисы хранятся в хэш-таблице, где в качестве ключа используется название сервиса (например, org.freedesktop.secrets). Соответственно, никаких дублей там быть не может, а порядок попадания сервисов в эту таблицу нигде не регламентирован (разве что самим кодом). Надо посмотреть, возможно получится сделать так, чтобы перед записью данных в эту хэш-таблицу все service-конфиги сортировались по дате изменения. В таком случае, мы сможем явно задавать сервис-конфиг, в котором указанный там исполняемый файл возымеет приоритет при dbus-активации (и можно будет приделать какую-нибудь настройку/control для этого). 219260 3 zerg 2022-12-20 11:17:11 +0300 (In reply to Slava Aseev from comment #1) > Проблема, похоже, возникает из-за того, что кто-то начал запускать > gnome-keyring, даже когда kwalletd уже запущен. Если прибить gnome-keyring, > все начинает работать как надо. > > Можно попробовать починить добавлением DBus Service файла. Значит, всё-таки зря его убрали. 219261 4 zerg 2022-12-20 11:19:05 +0300 Когда был service-файл KDE-шный, вроде проблемы не было, значит порядок запуска был подходящий. Надо вернуть файл, а потом, если будет проблема, уже думать над порядком. 219274 5 ptrnine 2022-12-20 12:33:50 +0300 (Ответ для Sergey V Turchin на комментарий #4) > Когда был service-файл KDE-шный, вроде проблемы не было, значит порядок > запуска был подходящий. Надо вернуть файл, а потом, если будет проблема, уже > думать над порядком. Попробовал с файлом - разницы нет. Запускаются сразу и gnome-keyring и kwalletd при логине. gnome-keyring запускает xdg-desktop-portal.service. Если остановить gnome-keyring-daemon, и перезапустить xdg-desktop-portal.service, gnome-keyring-daemon снова запускается/активируется. Причем это происходит даже если service-файл для kwalletd на месте. 219280 6 ptrnine 2022-12-20 13:04:14 +0300 (Ответ для Slava Aseev на комментарий #5) > Попробовал с файлом - разницы нет. Запускаются сразу и gnome-keyring и > kwalletd при логине. gnome-keyring запускает xdg-desktop-portal.service. > Если остановить gnome-keyring-daemon, и перезапустить > xdg-desktop-portal.service, gnome-keyring-daemon снова > запускается/активируется. Причем это происходит даже если service-файл для > kwalletd на месте. Хотя, если перезапустить уже kwalletd, а потом повторить всю процедуру, gnome-keyring не будет запускаться. Видимо, при входе в систему получается гонка, что-то вроде такого: - Запускается kwalletd - Запускается gnome-keyring (т.к. org.freedesktop.secrets еще нету на шине) - gnome-keyring регистрирует org.freedesktop.secrets - kwalletd пытается тоже, но уже не может, и при этом продолжает работать 219284 7 ptrnine 2022-12-20 14:17:53 +0300 Кстати, если создать org.freedesktop.secrets.service для kwalletd в /usr/local/share/dbus-1/services, то он возымеет приоритет над gnome-keyring. Похоже, это потому что в XDG_DATA_DIRS /usr/local/share стоит перед /usr/share. /usr/share/kf5 тоже, но с ним это не работает, почему-то. 219288 8 zerg 2022-12-20 15:03:47 +0300 (In reply to Slava Aseev from comment #7) > /usr/local/share/dbus-1/services Низя туда. (In reply to Slava Aseev from comment #7) > Похоже, это потому что в XDG_DATA_DIRS /usr/local/share стоит > перед /usr/share. /usr/share/kf5 тоже, но с ним это не работает, почему-то. Скорее, потому, что <standard_session_servicedirs /> обрабатывается до <includedir>/etc/dbus-1/session.d</includedir> 219299 9 ptrnine 2022-12-20 17:28:36 +0300 (Ответ для Sergey V Turchin на комментарий #8) > (In reply to Slava Aseev from comment #7) > > /usr/local/share/dbus-1/services > Низя туда. Да оно понятно, это я для примера. Проблема там в том, что dbus запускается раньше того, как startplasma прокинет переменную XDG_DATA_DIRS, поэтому /usr/share/kf5 там не оказывается. Прокинуть ее туда потом не представляется возможным, только если перезапустить dbus.service (и после перезапуска начинает активироваться kwalletd вместо gnome-keyring) > Скорее, потому, что > <standard_session_servicedirs /> > обрабатывается до > <includedir>/etc/dbus-1/session.d</includedir> Попробовал поднять строку с <includedir>/etc/dbus-1/session.d</includedir> наверх и у меня заработало, активироваться стал kwalletd. 219327 10 zerg 2022-12-21 10:29:32 +0300 (In reply to Slava Aseev from comment #9) > Попробовал поднять строку с <includedir>/etc/dbus-1/session.d</includedir> > наверх и у меня заработало, активироваться стал kwalletd. Это понятно, но, скорее всего, неправильно. Может, у мантейнера dbus есть мысль на этот счёт? Я бы поменял порядок. Сейчас поломки со стороны мантейнера стала небольшой. Да и тестирвоание работает. P.S. Добавлять в dbus возможность обновить переменные смысла не вижу, т.к. после этого придется его перезапускать по сути. Если нет проблем, чтобы он сам перезапустился после такого, то может и так лучше. 219335 11 ptrnine 2022-12-21 12:16:02 +0300 (Ответ для Sergey V Turchin на комментарий #10) > P.S. > Добавлять в dbus возможность обновить переменные смысла не вижу, т.к. после > этого придется его перезапускать по сути. Если нет проблем, чтобы он сам > перезапустился после такого, то может и так лучше. Перезапускать может и не придется, т.к. у dbus есть метод ReloadConfig(), его можно вызвать после задания /usr/share/kf5 в startplasma. Проблема в том, что к моменту, когда это будет вызвано, gnome-keyring уже может быть запущен. Ну и также в том, что сейчас нет никакой возможности прокинуть переменную окружения в сам dbus. 219336 12 ptrnine 2022-12-21 12:20:22 +0300 (Ответ для Sergey V Turchin на комментарий #10) > Я бы поменял порядок. Сейчас поломки со стороны мантейнера стала небольшой. > Да и тестирвоание работает. Может добавить /usr/share/kf5/dbus-1/session.d для KDE? И впихнуть его как раз в самое начало, ну и перенести туда kf5.conf 219337 13 shrek 2022-12-21 12:42:12 +0300 пока есть /usr/share/dbus-1/services/org.freedesktop.secrets.service врятли kwalletd5 можно бедет запустить раньше gnome-keyring-daemon 219353 14 zerg 2022-12-21 16:18:45 +0300 (In reply to Valery Inozemtsev from comment #13) > пока есть /usr/share/dbus-1/services/org.freedesktop.secrets.service врятли > kwalletd5 можно бедет запустить раньше gnome-keyring-daemon Можно без проблем, как выше обсуждалось. И без изменений в gnome-keyring. 219354 15 zerg 2022-12-21 16:24:50 +0300 (In reply to Slava Aseev from comment #12) > Может добавить /usr/share/kf5/dbus-1/session.d для KDE? В момент запуска пользовательского dbus ещё не дополнен XDG_DATA_DIRS KDE-шным каталогом. А так бы я давно это сделал. Надо посмотреть, как оно с systemd, а то уже всё готово для автозапуска пользовательской сессии через systemd. 219393 16 ptrnine 2022-12-22 20:56:45 +0300 Попробовал сделать рестарт dbus в startplasma сразу после того, как в systemd1 пробросятся переменные и ему пошлется Reload: https://git.altlinux.org/people/ptrnine/packages/?p=plasma5-workspace.git;a=commit;h=5b8493055fbe785400f22ba182eeb30ffaa00256 В итоге все начинает работать как надо, gnome-keyring больше не запускается. По /proc/PID/environ у dbus-daemon видно, что XDG_DATA_DIRS до него долетел. Так что остается только включить systemd boot в плазме по-умолчанию, и можно будет отправлять. Т.е. zerg таки был прав, больше ничего делать не надо, gnome-keyring после этих действий уже не будет запускаться (я до этого, оказывается, просто впихнул рестарт dbus'а не в то место). 239393 17 varaksaaa 2023-12-21 15:04:58 +0300 Воспроизводится на виртуальной машине: [sisyphus] kworkstation-10.2.1-x86-64 evolution-3.50.2-alt1.x86_64 kf5-kwallet-5.113.0-alt1.x86_64 kde5-kwalletmanager-23.08.4-alt1.x86_64 pam0_kwallet5-5.27.10-alt1.x86_64 Не воспроизводится на виртуальной машине: [p10] kworkstation-10.2.1-x86-64 evolution-3.44.0-alt1.x86_64 kf5-kwallet-5.112.0-alt2.x86_64 kde5-kwalletmanager-23.04.3-alt1.x86_64 pam0_kwallet5-5.27.9-alt1.x86_64 При этом: * Если открывать evolution в sisyphus несколько раз, уже на шаге 7 воспроизводится повторный запрос пароля почты. А на шаге 5 создаётся новый кошелёк, даже если не удалять "kdewallet" (т.е. не делать шаг 2). * В p10 в kwalletmanager5 только "kdewallet", в sisyphus - список из "kdewallet" и "Связка ключей по умолчанию", причём пароль от почты сохраняется именно в "Связка ключей по умолчанию", а не в "kdewallet", как в p10. * "Запрашивать подтверждение при обращении приложений к бумажнику" не требует пароль бумажника в p10, просто просит разрешить или запретить доступ. В sisyphus запрашивается пароль бумажника, а затем уже начинает запрашивать пароль от почты много раз.