probonopd / linuxdeployqt

Makes Linux applications self-contained by copying in the libraries and plugins that the application uses, and optionally generates an AppImage. Can be used for Qt and other applications
Other
2.22k stars 414 forks source link

Request - package ffDiaporama v2.1 in an AppImage #203

Closed phd21 closed 6 years ago

phd21 commented 6 years ago

Dear probonod,

Happy New Years to you and yours!!!

I did not know how to contact you directly to ask this.

I noticed you created an AppImage for "Ksnip" where I have been communicating with its developer, and I followed your comments to this very interesting project of yours. Will this work with Ubuntu 14.04 and QT4 applications, or just Ubuntu 16.04 and higher using QT5?

One of my favorite applications for creating training videos, movies, and or slideshows "ffDiaporama v2.1" has been abandoned (version 2.2 does not work as well). It will install in Ubuntu 14.04 Trusty (Linux Mint 17.x), but not easily in Ubuntu 16.04 Xenial + (Linux Mint 18.x). I was wondering if you could create an AppImage of this super application. I do not know enough about QT5 to upgrade this package, nor have I found anyone to take over this project that could or would. And, I noticed that AppImages created for Ubuntu 16.04 will usually work well in Ubuntu 14.04, I do not know if this works visa-versa (yet).

Best regards to you and yours, Phil phd21mint@gmail.com

probonopd commented 6 years ago

Hello Phil,

this should also work for Ubuntu 14.04 and QT4 applications.

I noticed that AppImages created for Ubuntu 16.04 will usually work well in Ubuntu 14.04, I do not know if this works visa-versa (yet).

I am happy to help upstream authors of applications to generate AppImages for their software, but in this case the project seems to have no active upstream authors at this time, so there is no one I can work with... Actually, the other way around: Binaries generated on older systems will usually continue to run on newer systems (and if they don't, then it's a bug). This is how it works on most operating systems, it has nothing to do with AppImage specifically.

phd21 commented 6 years ago

Hi probonopd,

Happy New Years to you and yours !

Thank you for replying so quickly.

I am still learning how to use this.

I have two issues:

1.) Another one of my favorite applications is "qTox" an excellent multimedia messaging application and secure Skype alternative. They used to have a repository that went away on OBS, so they created a new one there, links below. I mentioned creating an AppImage which OBS can also do, but neither they nor I know how to do that yet. Then, I came across your wonderful project to create AppImages. I am going to recommend your project to them, and if you do not mind, could you also contact them and perhaps facilitate creating "qTox" AppImages using your project? They are also having issues maintaining newer qTox versions for the Ubuntu 14.04 (Linux Mint 17.x) system, and if they created AppImages for Ubuntu 16.04+ , it would work on that too, like the "Ksnip" AppImage from Ubuntu 16.04 (Linux Mint 18.x) worked perfectly on the slightly older system. FYI: qTox requires the "toxcore" libraries as well. which if you click the link below for "qTox" on OBS, then click xubuntu 16.04 on the right, click go to Download repository on top, you can see what packages are involved, the binaries are in the "amd64" and "i386" folders.

qTox on GitHub https://github.com/qTox/qTox

qTox on OBS using OBS - https://build.opensuse.org/project/show/home:qTox

New qTox Maintainer anthonybilinski/tox.pkg https://github.com/anthonybilinski/tox.pkg

2.) I would really love to create an "ffDiaporama" v2.1 AppImage, even if it is only a onetime thing. Here is what I tried to do as a test today with "ffDiaporama" and "qTox".

I booted into my Linux Mint KDE 17.3 system based on Ubuntu 14.04, downloaded your current "linuxdeployqt-continuous-x86_64.AppImage" file, and ran the command below once without sudo and again with sudo and got the same results.

/home/user69/Downloads/linuxdeployqt-continuous-x86_64.AppImage /usr/share/applications/ffDiaporama.desktop

These are the results... Desktop file as first argument: "/usr/share/applications/ffDiaporama.desktop" desktopExecEntry: "ffDiaporama" desktopIconEntry: "ffdiaporama" Found binary from desktop file: "/usr/bin/ffDiaporama" FHS-like mode with PREFIX, fhsPrefix: "/usr" app-binary: "/usr/bin/ffDiaporama" ERROR: '/' is not a valid AppDir. Please refer to the documentation. ERROR: Consider adding INSTALL_ROOT or DESTDIR to your install steps.

I did the same thing with "qTox" and got the same results? /home/user69/Downloads/linuxdeployqt-continuous-x86_64.AppImage /usr/share/applications/qtox.desktop

Desktop file as first argument: "/usr/share/applications/qtox.desktop" desktopExecEntry: "qtox" desktopIconEntry: "qtox" Found binary from desktop file: "/usr/bin/qtox" FHS-like mode with PREFIX, fhsPrefix: "/usr" app-binary: "/usr/bin/qtox" ERROR: '/' is not a valid AppDir. Please refer to the documentation. ERROR: Consider adding INSTALL_ROOT or DESTDIR to your install steps.

Best regards to you and yours, Phil (phd21) phd21mint@gmail.com

probonopd commented 6 years ago

Hello Phil, please ask the authors of qtox and ffDiaporama for official AppImages. If they have difficulties, I am happy to help them. Please see https://github.com/AppImage/AppImageKit/wiki for more information.

phd21 commented 6 years ago

Hi probonopd,

I am not sure what you are asking? Do the developers have to ask or register with AppImages?

You already know that "fDiaporama" is not being maintained or updated which is a tragic considering it is one of the best, if not the best, and easiest to use movie makers and slideshow makers I have ever used. I have it installed and working well in Linux Mint 17.3 based on Ubuntu 14.04 and I managed to get it installed in Linux Mint 18.2 based on Ubuntu 16.04 in a convoluted way. But we all know that Ubuntu 14.04 is being phased out ... Using an AppImage would be much better.

Did the results of running the command I gave you give you any idea on how I could run them where they would finish on my Linux Mint KDE 17.3 system?

Best regards ... Phil

probonopd commented 6 years ago

Do the developers have to ask or register with AppImages?

No, but they can make an AppImage of their application if they like to. I am only supporting the original authors of applications.

You already know that "fDiaporama" is not being maintained or updated

Then there is probably no AppImage of it going to be made, unless someone resurrects the project.

Did the results of running the command I gave you give you any idea on how I could run them where they would finish on my Linux Mint KDE 17.3 system?

Please understand that while we are happy to help application authors who want to distribute their software in AppImage format, we cannot resurrect dead application projects here. Sorry.

phd21 commented 6 years ago

Hi probonopd,

Regarding "qTox", "Sudden6" is a developer and or contributor, on the project and the original developer (tox3?) I think is still involved. I do not know if anthony bilinski is a developer or contributer, but he did graciously offer to help maintain a repository. Keeping in mind, these are "open source" projects like "Ksnip".

As for "ffDiaporama", it is an abandoned open source project, so couldn't anyone "fork" it, even just for optional installation methods? A lot of people, besides me, love this application. There are others on GitHub that have helped to create updated deb binaries, and installation options, but not AppImages.

I have the AppImage kit, and have read some of the documentation, but I thought your project would make that a simpler process.

Thank you for your fast responses ...

TheAssassin commented 6 years ago

As for "ffDiaporama", it is an abandoned open source project, so couldn't anyone "fork" it, even just for optional installation methods?

Noone said you may not do this. However, when starting to distribute applications, especially with a method like AppImage which bundles libraries, it's necessary for those people to release updated application bundles from time to time to make sure users receive updates for those libraries, and won't run outdated libraries (that'd be a security risk).

To do so, you can automate the entire process, either manually, or even better on a CI system (like Travis CI) where you just need to click once and re-run the build process.

Re. tox: I think I was participating in making an AppImage build script for one of those tox applications some while ago. They might still be interested in creating AppImages for their other projects. As @probonopd said, instead of asking us to ask them, go there, create an issue, request them to release AppImages. We can help you argumenting if necessary. Just post the issue links here.

probonopd commented 6 years ago

As for "ffDiaporama", it is an abandoned open source project, so couldn't anyone "fork" it

Sure!

phd21 commented 6 years ago

Hi TheAssassin,

Thank you for replying.

I can certainly understand why some applications, especially those that access the Internet, would want and need to have regular updates for security reasons. But, "ffDiaporama" does not fit into that category.

I have already contacted "qtox" regarding making AppImages (see my links) and again today regarding the "linuxdeployqt" project. I am looking forward to an AppImage of their excellent "qTox" application.

Best regards, Phil phd21

TheAssassin commented 6 years ago

I can certainly understand why some applications, especially those that access the Internet, would want and need to have regular updates for security reasons. But, "ffDiaporama" does not fit into that category.

I think your understanding doesn't go deep enough then (no offense, please keep reading, I am going to explain this by an example). The risks aren't limited to applications with online functionality.

Some user downloads your AppImage, which bundles a certain fixed set of libraries. After years, an attacker discovers a fault, and turned into an exploit, e.g., a privilege escalation like DirtyCOW. This bug doesn't allow actual access to the computer, but can be used to gain root access from user space.

Now imagine an attacker finds another way to access the computer. Now, they can exploit the bug if they find a library which is affected by the bug.

Combining both exploits, an attacker can access the computer, gain root access, and can then do whatever they want. Because, like, why not combine two bugs to do the job? If someone really wants to, they're patient enough to do it that way.

You should never, ever trust that a specific bug won't be exploited because it's hidden at a first glance. This is called security through obscurity, and one of the most famous anti patterns in computer science and especially in the IT security area.

As you might now, most libraries are continuously being developed. Bugs are found, bugs are patched, patches are shipped. But as long as such a library remains unpatched, the bug can't be eliminated.

Now, of course, you can't fix the world's problems. But you should do anything that you can to prevent such things from happening. You can't patch the library on people's computers, they need to update their software on their own. But what you can do is ship updates whenever libraries are being patched, even if the main source code hasn't changed.

The AppImage eco system has got you covered. We have tools for building AppImages automatically. Those tools generate files required for our own update system AppImageUpdate. All of this can be automated. And if you don't even want to check whether libraries you ship are being updated, you can just use the awesome OpenSUSE build service, which has a unique feature: Whenever one of the libraries you use (and it is aware of that by how it works) receives an update, it will automatically trigger a build, build an AppImage and update stuff, and deploy it. And your users will soon be notified that there's an update, download the patch, and the issue is gone.

This is not to scare you from building AppImages. Please start and keep making AppImages! AppImage solves a lot of other issues with release deployment. However, if you decide to make AppImages, you should be aware of such stories, and take the responsibility and maintain them. As said before, you can easily automate those tasks so you don't have to do anything. The AppImage developers love creating automagic tools. Our continuous releases for instance are released entirely automatically. You can do the same for any application.

"Fun" fact: Recent studies also discovered that at the time of discovery and/or disclosure, so-called zero day exploits have been known and (ab)used by criminals for 7 years in average.

phd21 commented 6 years ago

Hi TheAssassin,

Thank you for your informative reply.

That is very interesting that OBS will automatically update a project and its dependencies from other software projects that have been updated throughout their entire system, very smart and very cool.

I do not claim to be an expert on hacking or software exploits, and you may know much more than I do about these topics. But for the sake of argument, let's take a package like "ffDiaporama" which does not access the Internet normally, even if a "ffDiaporama" or a dependency file or files were somehow compromised, would not a hacker have to know that you have that software installed, and your system's location (public IP address) and be targeting you, then break through all your defenses, like hardware firewall, Linux software firewall, and other applications like fail2ban, seccomp and firejail, then into that application or its files to compromise your system?

Good reply and thanks again for the information...

I have not been in software development or programming for some years now. So, I have been hesitant to get back into it, but I try to help others when I can. I have been trying to get those that I know that are into programming and software development to help with certain software projects. With a project like "ffDiaporama" to fork it into a new project and perhaps update its QT4 components to QT5 components. You would think there is a QT5 option or script to upgrade an application written in QT4 and automatically locate and change the QT4 code to QT5 code and replace and QT4 components with the corresponding QT5 components? Perhaps there is something like this available, I will have to check on that.

Best regards, Phil

TheAssassin commented 6 years ago

would not a hacker have to know that you have that software installed, and your system's location (public IP address) and be targeting you, then break through all your defenses, like hardware firewall, Linux software firewall, and other applications like fail2ban, seccomp and firejail, then into that application or its files to compromise your system?

Just for clarification, such exploits are normally used "by accident", i.e., an attacker gets on your system, and then scans it for vulnerabilities, not the other way round, as you suggest. And that's a lot more likely than you might think, even if you and I would keep our stuff up to date, grandma won't because she doesn't understand why this is so important. We've seen many exploits which enable attackers to do so. E.g., being able to upload files on unprotected webservers, and making some software like Wordpress execute it, opening a backdoor; or maybe just an SSH server allowing access for a user with a weak or accidentally disclosed password.

For example, there's a tremendous amount of unprotected Raspberry Pis for which people have set up port forwarding for SSH out there, with default credentials left unmodified for "simplicity" because "who would hack them" (arguments I hear a lot, which is pretty sad). To be fair, that's not the classical platform for AppImages. But there's also many servers with weak passwords, badly protected routers, "real world" desktops with the weakest passwords you can imagine, etc. The IoT boom we can observe recently is bad for the same reasons. Systems with insufficient protection, not maintained by the vendor. Even vac robots(!) can be used for DDoS attacks nowadays, ... (If you happen to be interested in this topic, check out https://media.ccc.de/v/34c3-9193-internet_of_fails, which shows how vendors handle those issues).

Really, whenever applicable, keep your stuff up to date.

perhaps update its QT4 components to QT5 components

As long as Qt4 will receive security patches, I don't see a point in switching. But yes, there's upgrade guides etc. However, I'm not a Qt expert (I haven't done much Qt so far), I can't give a general reply. I'm just trying to raise awareness for those real world issues.