Openshot-qt: Installer needs admin on windows

[MysticOdin]

I know this is more of a question than a bug, unfortunately there isn't a "question" type issue.

Why does the installer need admin? the tool works out of a zip with no issues, the installer also automatically shuts if the permission is not granted.

[peanutbutterandcrackers]

It requires admin privileges to install the program into the C:\ directory. It is not a stand-alone/portable type programs that can work out of the box. That is why it needs admin. You can give it admin rights. It does not contain any malicious code.

Hope that helps.

[DylanC]

@MysticOdin - Most Windows programs need to be installed like this to have a nice shortcut in the menu etc.

[ankostis]

But what if we don't care about the nice shortu in the menu?
Is there some other shotcoming if it is not installed through the executable?

[peanutbutterandcrackers]

@ankostis - You could try out the PortableApp Version of OpenShot if you want. That does work without installing. Hope that helps.

[generic-user]

If you only need admin rights for installing to the program folder, you really should only ask for those privileges when the user asks your installer to install in that location.
Otherwise, just let the user select where he wants to install the application.
I never understood why developers keep asking for elevated privilege's, even wen they are not needed for the application to function correctly.

_Anyway, just my two cent's._

[half2me]

Can we please reopen this? I'm on a machine where I don't have admin privileges, but would love to use this program. Why does it force admin privileges, instead of letting me choose to install to my own folder?

[DylanC]

@generic-user @half2me - Makes sense.

[ferdnyc]

Hrm. I need to refresh my memory of the Inno Setup configs we use... ah, yeah.

The installer currently performs several functions that require administrative privileges. They vary in how readily they could be made non-privileged:

1. Installs into "Program Files". That could be redirected fairly easily.
2. Installs file association registry keys under HKEY_LOCAL_MACHINE\Software\Classes in the registry. It should be possible to install the same associations in the HKEY_CURRENT_USER hive, instead. Ditto the installation of shortcuts and etc. into the All Users profile, which could be redirected to the current user's profile.
3. Removes some _old_ registry keys we used to install, but no longer do. Honestly it's been > 3 years now since OpenShot last had an installer that created those keys, and that logic should just be dropped in general — it's unnecessary in all cases.
4. Installs a firewall rule. It does that using a netsh.exe command that's launched during the post-install phase. That's a trickier one, I don't think there's any mechanism for regular users to do that. We'd have to disable the firewall rule creation entirely (or, actually, just uncheck and disable that option in the installer tasks)
5. This is the big, ugly one: Renames zlib1.dll files that some (unknown) _other_, poorly-behaved software has previously installed in the C:\Windows\System32\ directory.

Clearly, the last one has no possibility of offering a non-privileged alternative, and that's critical because we have found no solution to the problem: numerous bug reports have been filed from users who, for unknown reasons, have a zlib1.dll file in the System32 directory, who are unable to run OpenShot at all as a result. The DLL is not part of Windows, it was never part of Windows, and it _shouldn't_ be in there. But when it's placed there, Windows will ALWAYS load that DLL rather than the one bundled with the application, and if it's an outdated version that doesn't have all of the functions we make use of, the program crashes instantly.

So, for a non-administrative installation option, we'd also have to turn off _that_ part of the installer logic. In which case, anyone who installs without administrative privileges and who also has an outdated zlib1.dll lurking in their System32 directory is going to end up with an OpenShot install that won't run.

(I realize that _sounds_ like an unusual case that shouldn't be allowed to impact general installer functionality, but the number of bug reports that came in about it begged to differ. Hence the whole forcibly-renaming-"system"-DLLs-from-the-installer method resorted to, an ugly hack which we'd definitely not be doing if we knew of any other solution to the problem.)

There would also have to be a few other changes, mostly around detecting previous installs and using the same location by default, but _mostly_ that additional stuff would only require flipping the correct Inno Setup switches to enable some additional logic.

[half2me]

I understand. But then again, it seems really weird that an installer is renaming files in the system32 directory. I 100% understand why you do that, but maybe that should be an optional thing? For example, check if the file is there (non-admin) If it is there, prompt the user to rename (require priv esc. here).
For now, I'm just using the portableapps version, but would be nice to be able to install it.

[generic-user]

I understand. But then again, it seems really weird that an installer is renaming files in the system32 directory.

It's such a bad behavior to go around and clean up dll files while not informing the user what you are doing.

Be a good housefather while given administrative privileges. Inform the user about the suspicious/malicious dlls in their system 32 folder, and recommend them to perform a "cleanup".
When performing that cleanup ask for the key to the house. Never ask for the key beforehand.

It could even be a seperate tool that performs the cleanup. It would then be executed at users will. Can be maintained separately, and user statistics could be collected to monitor how much the tool is used.

[ankostis]

Sorry to intervene, though i'm not affiliated to the project in any other way than as a casual user.

While @generic-user is not impolite and he is making a constructive criticism, i don't like that the attitude lacks empathy.`

[half2me]

@ankostis I have to aggree with @generic-user .
He makes some very good points including:

• Don't ask for admin privileges right off the bat, and if you do, explain why you need them. Nobody should blindly give admin privileges to an application without knowing what its going to do. For some examples, I really like Apple's guidelines on requesting permission on ios. Only request what you need, always explain to the user why you need it, and make it possible to run your app without the privileges in case the user decides not to grant permission.
• Stay in your scope. I don't think anyone installing an app is expecting that app to go to some completely unrelated folder and rename existing files that belong to some other app. I understand why they did it, and the reasons are legit, but its not the right way to fix things. @generic-user suggested some very good alternatives. But at the least, the user should be aware of what is happening. Stupid example, probably very unlikely, but those files could have been put there by the user for something else, and actually needed. Good luck trying to debug why your other app is suddenly failing :)

So while I'm not involved in this project, I will add my suggestions because they inspire good practice, and I'm glad others do to.
Anyway a big thank you to all the people contributing to this project, and making it awesome! ❤️

[generic-user]

Sorry to intervene, though i'm not affiliated to the project in any other way than as a casual user.

While @generic-user is not impolite and he is making a constructive criticism, i don't like that the attitude lacks empathy.`

I'm sorry if I offended anyone, it was not my intention. I just wanted to contribute my view points. Now I did, so I'm out 😉

Thanks for the hard work on the project everyone! I really appreciate it. 🎉

[MysticOdin]

@ferdnyc I don't know much about zlib, but it looks like its entire source is available, maybe statically link it? this way you don't have to go looking for DLLs

[BadMisterFrosty]

Aside from the Zlib DLL chaos above, is there any reason why you cannot provide a zip of the application where you simply unzip and run? Many other software packages offer this type of "install". It allows the user to copy to their folder and run it from there.

[ganego]

Wondered the same. Testing various video editing programs right now.
Shotcut has portable, Olive has portable, KDEnlive has portable, Natron has portable, ...

[ferdnyc]

There's nothing preventing a portable Windows build of OpenShot other than developer time and priorities. There hasn't really been that much demand for it.

The Linux version is an AppImage, which is inherently a portable build. Since @ganego mentioned KDEnLive I assume we're talking about the Linux platform? There, we only distribute portable builds. (Well, if you don't count the Ubuntu PPA.)

But on Windows, a portable version _could_ be created. It just hasn't been. The contents of C:\Program Files\OpenShot Video Editor\ should be runnable from anywhere, there's nothing hardcoded with that path.

So, creating a portable OpenShot would mostly just require changing either installer/build-server.py or .gitlab-ci.yml (not sure which, but there is a right answer as to which one it should be, which hopefully would be clear upon examining them) so that a zip file of the application folder is created, in addition to the InnoSetup installer build.

@jonoomph would also have to make some website changes so it shows up as a download option, but that's secondary. As far as creating the archive, PRs welcome!

[ganego]

Since @ganego mentioned KDEnLive I assume we're talking about the Linux platform?

Sorry should have specified - I'm on Windows.
It's not really a big deal, I'm just not a big fan of installers - nothing that needs to have lots of hours invested to change though.

[ferdnyc]

@ganego Ah, my mistake. I'm always surprised by how much of their software collection KDE makes available as Windows builds, though I really shouldn't be anymore.