Как было указано в комментариях к (текущему) принятому ответу, канонический способ сделать это - использовать нулевой регистр ( "0
). Нулевой регистр всегда содержит последнее восстановление и будет не перезаписываются на d
и x
, поэтому "0p
всегда помещает все, что вы выдернули, независимо от того, что редактировалось за это время.
Эта проблема имеет долгую историю , и вы можете возиться с gnome-keyring
если хотите, но я обнаружил, что более простое решение состоит в том, чтобы установить пустой пароль этого приглашения, чтобы он больше не спрашивал вас:
rm ~ / .local / share / keyrings / *
(вы можете сначала проверить / сделать резервную копию этих файлов, если вы не используете новую установку, например, cp -r ~ / .local / share / keyrings ~ / keyrings-backup
) Я не знаю, какой у вас дистрибутив, но я бы создал сценарий в ~ / bin
и назвал его хром
(для Debian) или хром -browser
(для Ubuntu). Обязательно адаптируйте сценарий в соответствии с тем, что Chromium вызывается в вашем дистрибутиве:
#!/bin/bash
/usr/bin/chromium-browser --password-store=basic "$@"
Для Google Chrome вы можете создать другой сценарий в ~ / bin
и назвать его google-chrome-stable
следующим образом:
#!/bin/bash
/usr/bin/google-chrome-stable --password-store=basic "$@"
Вышеупомянутые сценарии будут использовать аргумент - password-store = basic
для каждого экземпляра, когда вы запускаете одну из двух программ.
Из из этого источника :
- хранилище паролей Определяет, какое хранилище шифрования использовать. Возможные значения: kwallet, kwallet5, gnome, gnome-keyring, gnome-libsecret, basic. Любое другое значение приведет к тому, что Chrome автоматически определит лучший сервер. ЗАДАЧА (crbug.com/571003): когда PasswordStore больше не использует связку ключей или KWallet для хранения паролей, переименуйте этот флаг, чтобы перестать ссылаться на пароли. Однако не переименовывайте его раньше; разработчики и тестировщики могут рассчитывать на то, что он убережет большое количество тестовых паролей от своих связок ключей или KWallets.
Не знаю, актуален ли этот вопрос, но я нашел решение, которое работает для меня. Я использую Debian Jessie i386. Используйте рабочий стол XFCE и диспетчер отображения gdm3. Я обнаружил, что вход в меню приложений «Настройки»> «Сеанс и запуск»> «Дополнительно» и выбор «Запуск служб Gnome при запуске» устранили проблему. Не уверен, как это повлияет на другие дистрибутивы, но это работает на Debian Jessie.
Я хотел прокомментировать, но мне сказали, что я не могу из-за слишком низкой репутации. Так что извините за этот «ответ».
Мне тоже помог ответ @Wolf об удалении связок ключей в ~/.local/share/keyrings/
. С этого момента я увидел в Default_keyring.keyring
объяснение такого поведения.
Кажется, в GNOME API libsecret
есть странность, и Google просто добавляет фиктивную запись с libsecret при инициализации OSCrypt. См.:https://bugs.chromium.org/p/chromium/issues/detail?id=660005для более подробной информации.