Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1509459 - Keyring password always required
Summary: Keyring password always required
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: chromium
Version: 26
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Tom "spot" Callaway
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-03 20:11 UTC by Piergiorgio Sartor
Modified: 2018-05-29 12:42 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-29 12:42:02 UTC


Attachments (Terms of Use)

Description Piergiorgio Sartor 2017-11-03 20:11:31 UTC
Description of problem:
It appears that "chromium" requires some password storage (either keyring or basic) even if password management is completely disabled in the preferences.

Version-Release number of selected component (if applicable):
61.0.3163.100-1.fc26

How reproducible:
Always.

Steps to Reproduce:
1.
In the preferences disable all possible password storage options available.

2.
Re-start "chromium".

Actual results:
The keyring password is requested.

Expected results:
It should not require any keyring or "basic" storage for passwords, since the user does not wish password management from "chromium" at all.

Additional info:
There should be at least a "--password-store=none" option, even if better just to skip this password thing, if disabled in preferences.

Comment 1 Tom "spot" Callaway 2017-11-17 18:44:16 UTC
I'm not sure I entirely understand this issue, to be honest. It sounds like you want chromium to have an option to not use the gnome-keyring, but this does not currently exist. If this is accurate, you should file a bug (bonus points for including a patch) with the chromium upstream on this issue. I am uncomfortable making such a significant change to chromium without upstream approval.

Comment 2 Piergiorgio Sartor 2017-11-17 19:10:47 UTC
(In reply to Tom "spot" Callaway from comment #1)
> I'm not sure I entirely understand this issue, to be honest. It sounds like
> you want chromium to have an option to not use the gnome-keyring, but this
> does not currently exist. If this is accurate, you should file a bug (bonus

I'll try to explain in a different way.

Currently, at start, "chromium" ask for a password for the gnome keyring.
If "chromium" is started with, I guess, "--password-safe=basic", it does *not* require any keyring password, but it stores credentials somewhere else.

Now, in the settings, it is possible to disable completely, at least this is what I understand, the built-in password management capabilities.

I think that, if the "chromium" password manager is disabled in the configuration, then there should be no need to store passwords, hence there should be no keyring password to request, nor basic storage should be necessary.

I consider this a bug, that is if not password manager is enabled, then no keyring password should be asked.

Unless, of course, there is some other reason to create a keyring.

> points for including a patch) with the chromium upstream on this issue. I am
> uncomfortable making such a significant change to chromium without upstream
> approval.

Uhm, my understanding is that *bugs* should be reported here and then, if required, this should be passed upstream (or not) from you.

Note that, as written above, I consider this a bug, not a RFE.

Anyway thanks for the attention and suggestions,

bye,

pg

Comment 3 Tom "spot" Callaway 2017-11-17 20:17:46 UTC
Okay. I think I understand. 

From what I can see here, Chromium can either be hardcoded to use a specific encryption storage backend, or it detects the best backend automatically (where the choices are kwallet, kwallet5, gnome, gnome-keyring, gnome-libsecret, basic)

If you enable logging (--enable-logging --v=1), you can see it choose in the chrome_debug.log:

[18153:18153:1117/151320.763456:VERBOSE1:key_storage_util_linux.cc(53)] Password storage detected desktop environment: GNOME
[18153:18153:1117/151320.763472:VERBOSE1:password_store_factory.cc(214)] Trying libsecret for password storage.
[18153:18259:1117/151320.777016:VERBOSE1:key_storage_linux.cc(53)] OSCrypt using Libsecret as backend.

But, there is a way to tell it not to try to use a backend at all:

1) In your ~/.config/chromium/, run:

touch "Disable Local Encryption"

2) Now, run chromium --enable-encryption-selection

3) You should see the log output change to:
[18552:18660:1117/151549.216976:VERBOSE1:key_storage_linux.cc(90)] OSCrypt did not initialize a backend.

I think that this option, combined with disabling password storage altogether, will get you where you want to go.

Comment 4 Piergiorgio Sartor 2017-11-18 12:19:01 UTC
(In reply to Tom "spot" Callaway from comment #3)
> Okay. I think I understand. 
> 
> From what I can see here, Chromium can either be hardcoded to use a specific
> encryption storage backend, or it detects the best backend automatically
> (where the choices are kwallet, kwallet5, gnome, gnome-keyring,
> gnome-libsecret, basic)

Ah! Well, between the two of us :-), this does seem to me somehow forcing the user to store password within the browser.
This practice, while maybe comfortable, is not considered the safest or most secure.
I guess it would be nice to have further option, like "none", storing passwords in /dev/null... :-)

> If you enable logging (--enable-logging --v=1), you can see it choose in the
> chrome_debug.log:
> 
> [18153:18153:1117/151320.763456:VERBOSE1:key_storage_util_linux.cc(53)]
> Password storage detected desktop environment: GNOME
> [18153:18153:1117/151320.763472:VERBOSE1:password_store_factory.cc(214)]
> Trying libsecret for password storage.
> [18153:18259:1117/151320.777016:VERBOSE1:key_storage_linux.cc(53)] OSCrypt
> using Libsecret as backend.
> 
> But, there is a way to tell it not to try to use a backend at all:
> 
> 1) In your ~/.config/chromium/, run:
> 
> touch "Disable Local Encryption"
> 
> 2) Now, run chromium --enable-encryption-selection
> 
> 3) You should see the log output change to:
> [18552:18660:1117/151549.216976:VERBOSE1:key_storage_linux.cc(90)] OSCrypt
> did not initialize a backend.
> 
> I think that this option, combined with disabling password storage
> altogether, will get you where you want to go.

Yep, thanks!!!
The configuration file and the command line option did the trick.
Now "chromium" starts without asking any keyring password or else.

While I'm OK with the configuration file, I find a bit odd the command line option.

What's the recommended solution, in these cases?

Should I modified the launcher? The menu? Add a shell script with the option?

Or would it be possible to configure somewhere "chromium" to have that command line flag enabled?

Thanks a lot for the attention and the support,

bye,

pg

Comment 5 Fedora End Of Life 2018-05-03 08:24:59 UTC
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 6 Fedora End Of Life 2018-05-29 12:42:02 UTC
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.