Default settings: Store broadcast credentials as plain text #2158
Conversation
|
I cannot confirm the issue. I can store passwords with an empty login. |
|
Which libgt5keychain do you uses? My is 0.5.0. |
|
v0.7.0 First start: Restart: KWalletManager is not installed, only GNOME Keyring. I'm not able to get rid of this error message. My existing profile works, no error message pops up. |
|
I'm not able to delete 'Connection 1'. Creating a new connection doesn't help either. |
|
How is this set: |
|
Default Fedora installation with GNOME on Wayland: |
|
OK, so you finally are here: I guess this PR is not a fix. I think we need to single step to the source to identify the issue. |
|
My existing profile works without any issues. Any newly created profile doesn't work and I'm not able to fix this situation in Mixxx. This is a bad user experience and obviously an error, independent of whether Mixxx is able to acces GNOME Keyring or not. |
|
I guess that the old profiles store the password in a file and the new one tried to use the chain. There is a radio button to control this. |
|
The Mixxx profile does not store any passwords and I have never set it. |
|
Ok, so we need to special case the empty passwort instead of the empty login. However, this is still a band aid, because Mixxx should be able to store an empty password to the file and to the key chain. I think the final solution it to check what really happens on your system and give some better error messages and offer to fall back to insecure password storage. |
|
Mixxx should not generate any error messages regarding broadcasting after a fresh install if I never intend to use it. Even if Mixxx is built with QtKeychain support it should not use it unless actually needed. |
|
Yes, of cause. The error message happens if you create a new profile with an empty password, right? We have to figure out why qtkeychain is not able to store a password. Detect this and fall back to insecure password storage. We may special case that passwort empty case, but I am in doubt if it it worth the work, because in almost all real live cases the password is not empty. Do you have a clue why you get such confusing error messages? We need an idea how to work around it. |
|
Once again: Mixxx should not try to store any bogus login credentials anywhere in the system before the user enters one! |
|
This means we need to store a new flag like "password empty" in the profile file. Than we need to migrate all empty passwords to this flag. A lot of work, that does not fix the issue you suffer here. I think we should find a fix first. I don't mind to store an empty password. |
|
The issue I suffer just reveals that Mixxx is not behaving as expected. A default installation of Mixxx should not make any modifications to the system unless the user gives permission. The only allowed exception is the application's settings folder. I don't need neither a broadcast profile nor do I want to store any login credentials. This implementation seems to be really broken and we should not release 2.3 until it has been fixed! Seriously, the non-deletable default connection named 'Connection 1' already looks like a hack. I just never noticed until those issues appeared. As a workaround we can simply switch the default from Secure store to Plain text. That would work for me. |
uklotzde
changed the title
|
Done. This versions works out of the box without any issues. |
|
The default connection 'Connection 1' is a legacy thing. Original we support only one connection and this was also not deletable. I have no strong issue with this. The proposed change works for me. I guess if you try to store a secure password it will still fail right? Would you also mind to single step though the qt5keychain code and check why it fails in your case. |
|
LGTM, waiting for CI. |
|
OK Thank you. Merging now. If you find time it would be nice to do a test run to check what's the real issue in your case. We will later suffer this issue on other users machines using broadcasting i guess. |
I get the following confusing error message when building Mixxx with QtKeychain and starting with a fresh profile:
This fix prevents the error and instead logs a warning. I have no idea what the correct behavior is supposed to do! Please accept this PR or fix it yourself, whoever knows the solution!