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
