Was chrome closed before logging out of Plasma?

CC: (none) => davidwhodgins

I suspect that Google Chrome uses KWallet, KDE Plasma Passwords Manager, under Plasma.

Source RPM: ?? => (none)

This may well be so, but it should not cause this serious havoc. This looks a genuine bug, w unruh deserves congratulations for having a relevant backup and saving himself. But is this the fault of Xfce or the browser?

'google chrome' is ambiguous, and we have no package of that name, just
 chromium-browser
 chromium-browser-stable
which I suspect are the same; at least they both come from the same SRPM.
Can you say whether this problem has just appeared (after some update), and if so, when? You can find updates in date order with:
 $ rpm -qa --last | less
and see easily what updates were done when on your system. Can you relate the problem to either a recent chromium or Xfce update?
Or have you only now for the first time tried the browser under Xfce? If not, assume it worked OK in the past?

Source RPM: (none) => chromium-browser-stable-86.0.4240.198-1.mga7.src.rpm
CC: (none) => lewyssmith

google-chrome is the tracking software infested version of chromium browser
https://www.google.com/chrome/
not a Mageia package.

It Chrome from google-- chromium is the open source version of Chrome. (unfortunately it also has some advantages over chromium, especially in terms to recognizing more file types and video types.

I do suspect that the problem has to do with kwallet, because I think that Chrome uses kwallet by default. But kwalletd is, I believe, running when I open xfce. 
And why would xfce destroy the availability in kwallet when I went back to Plasma. 
Note that I am running sddm for both Plasma and for xfce, so it should not be a problem there. 
Somehow running chrome on xfce alters the configuration of the password handling in chrome (since restoring an old chrome configuration directory restores proper behaviour)

This behaviour began recently since it is recently that I started to use xfce (to "solve" a problem with Zoom). I realise that this would be an upstream problem with Chrome if it turns out that it is chrome that is screwing things up when it finds itself in the xfce environment, but it is certainly also an xfce problem since it is presenting the wrong environment to chrome or something.

I will also experiment a bit with chromium since if the bug is also in Chromium, you will have more incentive to figure out what is going on:-)

I have tried Chromium. It is similar, but not exactly the same. 

a) If I save a password to Chromium in Plasma, it disappears in chromium on xfce, just as forchrome.

b) If I save a password in chromium on xfce, it disappears when I run chromium on Plasma.

c) If I run dbux-run-session chromium on xfce after I saved a password on Plasma
the password reappears. Similarly if I save a password on xfce it reappears if I run dbus-run-session chromium on Plasma.

d) If I run dbus-run-session google-chrome on Plasma after I have run chrome on xfce, the passwords that disappeared when I tried to run without that dbus addition suddently reappear. Note that when I do this, the window asking for the kwallet password pops up first.

e) If I run dbus-run-session google-chrome on kde, no kwallet password window comes up and the passwords do not reappear. 

HOw do I sync the passwords that I have on chrome onto chromium? I can save the passwords on chrome onto a cvs file, but I have no idea how I can import them into chromium? (chrome will sync with Mozilla but apparently not with chromium or vice versa)

This is getting more and more confusing in that symptoms are not staying constant. (chrome=google-chrome, chromium=chromium-browser)

a) plasma chrome to xfce chrome-- passwords lost Return to plasma-chrome no passwords but dbus chrome [dbus-run-session google-chrome) and the kwallet signin comes up, and after signing, chrome passwords have returned

b)plasma chrome with passwords ->xfce dbus chrome takes about 20 sec to come up, and no passwords. I suspect that the kwallet popup was supposed to appear during that time, and timed out. No idea why no kwallet window of xfce. Some configuration?

c) plasma chromium  -> import passwords into chromium (chrome://flags import passwords from cvs file) and they appear. ->xfce chromium->no passwords. dbus chromium ->no passwords. ->plasma chromium or dbus chromium no passwords.

Why would kwallet login window not come up on xfce?

Sorry to have left you lately. Thank you for all your painful trials.

To keep this in the Mageia camp, and reduce the confusion, please confine things to our chromium browser offerings, currently:
 chromium-browser-86.0.4240.198-1.mga7
 chromium-browser-stable-86.0.4240.198-1.mga7
No more mention of google-chrome or chrome, please.

Once again I congratulate you on your advanced (if obscure) workaround,
 dbus-run-session chromium            [from 'dbus' pkg]

From comment 6:
> If I save a password to Chromium in Plasma, it disappears in ... xfce
> If I run 'dbus-run-session chromium' on xfce after I saved a password
> on Plasma, the password reappears.
> If I save a password in chromium on xfce, it disappears ... on Plasma.
> if I save a password on xfce it reappears if I run
> 'dbus-run-session chromium' on Plasma
All this is consistent, and talks about one [new] password.
It almost suggests - did you mean it? - that existing passwords survive the desktop change? It seemed that you lost sight of the whole lot - but they never actually disappeared.

> I can save the passwords on chrome onto a cvs file, but I have no idea
> how I can import them into chromium
You seem to have managed that, in comment 7 (c):
> plasma chromium  -> import passwords into chromium (... from cvs file)
> and they appear
But then not for long... They [all?] disappear after going to Xfce, even after running 'dbus-run-session chromium'; and similarly going back to Plasma.

Now some questions:
1. After successfully importing the CSV passwords into Chromium on Plasma, do they survive new sessions - even reboots - staying in Plasma, without going to Xfce at all?
2. If you do the CSV password import into Chromium on Xfce, does that work?
3. If it does, same as Q1 re Xfce: do the imported passwords survive repeat Xfce sessions - even re-boots - without going to Plasma at all?
4. Since this is desktop related, are you able to try another one (LXDE is the obvious candidate: lxde-task-minimum)? That would show whether this an Xfce problem, or more generic about swapping desktops.

It was not at all clear to me that the problem was with Chrome/Chromium or with Mageia. It sure seemed like the latter at first. Now, I have become more convinced that it is a Chrome problem, and I am willing to confine myself to Chromium discussion.
Having put password-store=kwallet or kwallet5 into the Properties->Laucher line, it seems to been behaving itself even through reboots and with a number of switches between Plasma and XFCE. I thnk Mageia should put that into the default installation. (Or you could try --password-store=basic instead) 
This also seems to solve the problem of the kwallet password window popping up under both Chromium and chrome.

So things are improving, and you have found a solution (congrats again):
> put password-store=kwallet or kwallet5 into the Properties->Laucher line,
> it seems to been behaving itself
> (Or you could try --password-store=basic instead)
This is all unknown territory to me, I do not meddle with stored passwords, nor even chromium if I can help it; so I cannot test your proposition. Can you please clarify the difference between the two password-store options you cite:
- kwallet or kwallet5          [works for you]
- basic                        [but does this also?]
and also say what the undefined (default) password-store situation is?
TIA
The kwallet option implies a dependency in chromium for that, which has big repercussions for non-KDE/Plasma users.

> I thnk Mageia should put that into the default installation
Possibly, preferably the second one.

For chromium, --password-store=kwallet works--ie, it recovers the 100 old passwords I had accumulated over the years in Chrome. Chrome appears to use kwallet or kwallet5 (and no I do not know why there are two separate kwallets). reconstructing 100 passwords in Chromium would have been a complete and total bore, waste of time, and impossible task. As it is I had to figure out, by googleing, how one could export passwords from Chrome and intput them into Chromium-- by going into 
chrome://flags URL, searching for password, and then enabeling the Password Input flag.) The in chrome I could export the passwords, and in chrome input them. 
I never tried the password-store=basic option. I think, but do not know, if I had used the password-store=kwallet5 option in Chromium, I would have been able to see the Chrome passwords without import/export. But if you wanted to try it, install and eneble Google Chrome. Store some passwords by going to varius web pages with passwords and save them, making sure that when the kwallet password page came up, you put in the right password (the default I believe is the same as your login password.) Then open chromium with the --password-store=kwallet5. 

There appear to be two kwallets kwallet and kwallet5. As to what the difference is I have no idea, but there is a difference. 
basic, as I understand it, is when Chrome/Chromium stores the passwords itself, which I suspect, but do not know, is much more insecure a way of storing saved passwords that using the kwallet password manager. 

As I mentioned, Chrome seems to use kwallet5 by default, which is why the kwallet password box keeps opening the first time you use chrome after a reboot when you use Chrome. Note that kwallet5d is opened automatically when you log in as you as user when using sddm.

A solution to this:

Use a Google account with google-chrome program. This will stores all your passwords in Chrome's database and will never use other 3rd party programs.
Also, these passwords will be synced with Chrome on your phone device (Android or Chrome on iOS).

That is for Chrome (https://www.google.com/chrome/)

===========================================================

For chromium (our packaged version for M7):

For more clarity: chromium has built-requires on GTK3 and gnome-keyring and not on KDE's KWallet. But, it can detect other Desktop Environment (DE) Password Storage Application wia libsecret,... blablabla... That's why KWallet can store chromium passwords.

Also, navigating through different DE with same user-account can results of setting a new profile inside chromium, so that's why you can't see passwords stored in KWallet under XFCE. It's like you have restarted into an other system, even if you use same user account. By default, XFCE does not start KDE services.

============================================================

This is acting as desired by upstream developers.

Closing this.
Feel free to look for upstream documentation here:

Status: NEW => RESOLVED
CC: (none) => ouaurelien
Resolution: (none) => WORKSFORME

I will never turn over my password management to google.

Since we support the use of multiple desktop environments, we need a way to
ensure a consistent use of password storage across multiple desktop environments.

Resolution: WORKSFORME => (none)
Status: RESOLVED => REOPENED
Assignee: bugsquad => cjw

Placing all of your passwords onto a remote server with absolutely opaque procedures is hardly a reasonable security suggestion. Giving some other organization access to your own passwords is not a good idea, no matter how much you trust Google.

Since Chromium is used in KDE, in XFCE, and since gnome is not really a supported DE in Mageia making chromium depend on gnome-keyring seems a bit strange. I presume that is why I have to have the --password-store=kwallet in Chromium.
I guess I also have to make sure that check that  kwalletd (or kwalletd5 ) is started when I start up XFCE. As I said, I use sddm and I think that it starts up kwalletd when it logs you on. 

I am not sure that "Works for me" is accurate, since I do not think that you have tried switching between between kde and xfce. Unfotunately I have to because Zoom, which is critical to my work, only runs on XFCE since  the updates of about a month ago. Something in updating Mageia broke screen sharing in Zoom (it makes the users screens flicker light mad). I would much rather have just stayed with Plasma.

Adding Nicolas to cc list as packager for recent chromium-browser updates.

Regarding comment 14, gnome is a fully supported desktop environment, just
as kde plasma and xfce are.

CC: (none) => nicolas.salguero

So the request is for a setting that forces the password store to one of the options?

I suppose this can be done in the wrapper script /usr/bin/chromium (which I was planning to remove). All the Shockwave Flash stuff currently in this script should be removed I guess, creating some room for this new feature.

Where should such a setting be stored - in .config/chromium-browser/ ?

How should be user configure the setting?

chromium-browser --help includes the option ...
--password-store=<basic|gnome|kwallet>
              Set the password store to use.  The default is to automatically detect based on the desktop environment.  basic selects the built in, unencrypted
              password store.  gnome selects Gnome keyring.  kwallet selects (KDE) KWallet.  (Note that KWallet may not work reliably outside KDE.)

One way to handle this would be to have the first run of chromium-browser
by a given user select the password store as documented. Then on subsequent
runs auto add the password-store option so it always uses the same method,
no matter what DE is now being used.

This is in expert hands, no need for me to meddle futher.

CC: lewyssmith => (none)

I don't think it's a good idea to bother all users with a configuration dialog, even if it's only once. Note that this bug report now appears to be a duplicate of bug 17385 and related to bug 19093 .

How about this:

The wrapper script adds the contents of $HOME/.config/chromium-browser/args to the command line arguments of the chrome binary. We document this mechanism in the man page.

This feature can then be used to:
  - enable a flash plugin after we remove support for flash
  - set a proxy configuration without relying on a desktop environment
  - set a password store independent of the desktop environment
etc.

For an easier interface, a chromium startup configuration tool could be added (later), maybe as an option of the wrapper shell script.

It appears ArchLinux has what I described, using ~/.config/chromium-flags.conf

For me, chromium with --password-store=kwallet works. --password-store=kwallet5 does not work. Having chromium, by default, using gnome is I believe bad. Mageia "recommends" (uses by default) kde, and having gnome then be used for a key item is at best confusing. 
Some config file (in .config/chromium/ ) would be a good idea. Of course most users will have no idea it exits, but at least it gives helpers somewhere to point. Using the default for the first used DE sounds like a good idea.
XFCE has no default password-store I guess, so one would have to decide which default category to put XFCE into.
[Sorry, yes, Mageia does support gnome as well. My information was wrong]

(In reply to w unruh from comment #20)
> For me, chromium with --password-store=kwallet works.
> --password-store=kwallet5 does not work. Having chromium, by default, using
> gnome is I believe bad. Mageia "recommends" (uses by default) kde,

No we dont, it just happend to be preselected due to some ancient drakx problem that meant something had to be selected, and no-one has had time/interest to fix it all up (or even check if it's still valid...)

Also don't forget a lot of people install from the xfce or gnome live iso images.

Mageia 7 is EOL since July 1st 2021.
There will not have any further bugfix for this release.

You are encouraged to upgrade to Mageia 8 as soon as possible.

@reporter, if this bug still apply with Mageia 8, please let us know it.

@packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead.

This bug report will be closed OLD if there is no further notice within 1st September 2021.

Hi bug reporter and hi assignee and others involved,

Please reopen this bug report if it is still valid for Mageia 8 or 9(cauldron), and change "Version:" in the upper left of this report accordingly.

This report is being closed as OLD because it was filed against Mageia 7, for which  support ended on June 30th 2021.

Thanks,
Marja

Resolution: (none) => OLD
Status: REOPENED => RESOLVED