Web lists-archives.com

No good way to play video files located on password-protected Samba shares in KDE Plasma

It seems that our users don't have a good way to play videos on password-protected Samba shares: https://bugs.kde.org/show_bug.cgi?id=355328

For programs that use it, KIO transparently provides network protocol access, abstracting away the details and security aspects. DragonPlayer is the only one KIO-using video player I'm aware of, and its samba access seems broken (https://bugs.kde.org/show_bug.cgi?id=386192), and the program itself seems largely unmaintained. Other popular video players like VLC, MPV, and MPlayer do not use KIO. For these and other such non-KIO-using programs, KIO is able to fall back to passing them URLs and trusting them to handle the situation. However, for password-protected Samba shares, KIO doesn't include the password in the URL (which Samba requires for password-protected Samba shares), so the file can't be opened.

So in a nutshell, there is currently no good way to play video files located on a password-protected Samba share in KDE Plasma. This breaks the common use case of accessing videos stored on a NAS with password-protected Samba shares. I'd like to brainstorm how we fix this. Here are the solutions I can see, presented with what I can anticipate are their pros and cons:

1. Change KIO to include the credentials in the URL when falling back to URL behavior for non-KIO-aware programs
- Pros: easiest to implement
- Cons: leaks the share's password on the local machine, since it's passed around in plaintext

2. Change KIO to mount things locally using FUSE like GNOME's GVFS does
- Pros: maintains security
- Cons: huge amount of work (see prior abandoned effort: https://bugs.kde.org/show_bug.cgi?id=355328); performance regression associated with using FUSE (see e.g. https://trac.videolan.org/vlc/ticket/7638 and https://trac.videolan.org/vlc/ticket/7953)

3. Change KIO to always download the file locally when a URL is being passed to a non-KIO-aware program and show a download progress bar while it downloads, mimicking a desktop file's %F behavior
- Pros: maintains security
- Cons: probably a lot of work; requires enough space on local storage (video files can be very large); download time imposes a delay before file starts playing, which could be very long for big files and slow network connections

4. Fix KDE DragonPlayer (https://bugs.kde.org/show_bug.cgi?id=386192)
- Pros: Maintains security and performance; doesn't require changes to KIO
- Cons: may not be worth the effort as this program seems largely unmaintained (the last non-localization commit was 4 months ago) in the face of more popular alternatives like VLC, MPV, and MPlayer. Kubuntu now ships with VLC instead of DragonPlayer, for example, and even if we do this, most people are still probably going to want to use VLC, MPV, or MPlayer instead

5. Port VLC, MPV, MPlayer and other popular non-KDE software to be KIO-aware
- Pros: maintains security and performance; doesn't require changes to KIO
- Cons: probably a huge amount of work, and it's not unlikely that the developers of those programs would want to do it or accept patches

6. Encourage distros to put %F instead of %U in the desktop files of VLC, MPV, and MPlayer, which makes the files always download locally
- Pros: maintains security, doesn't require changes to KIO
- Cons: distros almost certainly won't agree to this do this since other network protocols and passwordless Samba access are supported just fine; equires enough space on local storage (video files can be very large); poor user experience as file takes a long time to download and there is no UI to indicate that anything is happening during the download

Thoughts? How should we fix this?

Nate Graham