Trying to open a remote file from a ftp server in gnome applications (e.g. pdfs in evince, txts in gedit, etc.), krusader launches the application through this command (seen in ps output): >>> /usr/bin/gedit ftp://user:{{password}@172.17.2.1:21/folder/file.txt where {{password}} is actually the password I previously entered in krusader to open the connection Then the classical gnome password dialog appears saying: "Enter password for user:{{password}@172.17.2.1:21" displaying the password Reproducible: Always Steps to Reproduce: 1.Connect to a pasword-protected ftp server 2.Open a file using a gnome application 3. Actual Results: Gnome password dialog shown the password in plaintext Expected Results: Don't show the password (don't include it in the command given to open the application) System environment: Ubuntu 13.04 Gnome 3.10.4
EDIT: It's Ubuntu 14.04, sorry
Note to self and other developers: This is most likeley caused by not using KUrl::prettyUrl() / QUrl::toDisplayString() which remove the password from the url string. Needs separate fix in kde4 branch and master. Places to check for right usage of KUrl/QUrl: Panel/panelfunc.cpp UserAction/expander.cpp and probably others !
Hi! I cannot replicate this issue on krusader-git. @simone.ted can you confirm that it is fixed?
Still in master. Must be fixed!
The problem is actually everywhere. If the initial ftp connection is made by writing the password in plain text into the navigation bar ("ftp://user:password@server.com") the password is never removed. * VFS uses the URL with the password while navigating on the ftp server * all file URLs contain the password, it is not removed when opening files or copying them to clipboard * sometimes debug output with the URL and password is printed Dolphin has exactly the same problems. Removing the password from all URLs is not that simple cause the password is never saved and browsing wont work after the first directory listing without entering the password again. The best solution would be if the KIO listing job saves the password internally and it can be removed after the first connection. This is currently done anyway if no password is provided and the authentication dialog appears.
I don't think we can solve this on our own. * either we remove the password from the URL and the user has to enter it again * or we stay with the current situation leaving the password in plain text everywhere. The latter case is highly insecure and we should at least tell the user about it. Maybe some warning dialog appearing or something.