Puppy Linux Discussion Forum

While looking for something else I ran across this dialog about Exodus at https://github.com/AppImage/AppImageKit/issues/963:

"
Calinou commented May 24, 2019

What about using Exodus? It should work well with command-line tools at least.
@anderspitman
Author
anderspitman commented May 24, 2019 •

Wow exodus is awesome! And very easy to use. I ran it on my samtools binary and it just worked. So it seems like the way to go would be to run exodus on a dynamically linked binary, then package the exodus bundle into an AppImage for easy distribution (and perhaps versioning)?
@Calinou
Calinou commented May 24, 2019 •

You could compress and distribute the binary generated by Exodus directly, but if you want better desktop integration, you'll want to pack it into an AppImage (which may or may not work, I haven't tested)." [Elsewhere, it was reported that it does work].

As 'Exodus' in the context of Linux was unknown to me I followed the path to https://github.com/intoli/exodus where it says:
Exodus is a tool that makes it easy to successfully relocate Linux ELF binaries from one system to another. This is useful in situations where you don't have root access on a machine or where a package simply isn't available for a given Linux distribution... With exodus, transferring a piece of software that's working on one computer to another is as simple as this.

exodus aria2c | ssh intoli.com

Exodus handles bundling all of the binary's dependencies, compiling a statically linked wrapper for the executable that invokes the relocated linker directly, and installing the bundle in ~/.exodus/ on the remote machine."

Well, this is all way above my pay-grade. But I figure some of our vanguard might not already know of its existence and might find it useful.

Very interesting and promising, it seems an improvement of CDE that I used in past. I also used magicermine to make standalone binaries virtually working on every linux distro (and puppy version) but magicermine's licence prices are very expensive (althought worthy for price/usefulness ratio)

I doubt it can be compiled with gcc 4.1.2 in puppy 3.01, puppy version that I used for 10+ years compiling tons of useful software I miss in my fresh xenialpup pupsave, but I'll give a look, especially for useful apps whose sourcecode is no more available

@Dingo

Have you worked with the Ermine Free version? I have been doing packaging manually and now I am developing a 32 bit OS (WeeDog32-Void) and I'm looking for package construction methods and tools.

Exodus looks very interesting!

rockedge wrote: ↑Sat Jan 09, 2021 3:22 pm

@Dingo

Have you worked with the Ermine Free version? I have been doing packaging manually and now I am developing a 32 bit OS (WeeDog32-Void) and I'm looking for package construction methods and tools.

Exodus looks very interesting!

Free version of magicermine is

statifier
http://www.magicermine.com/sesl.html

It is very far from perfection, it is barely usable. I failed everytime to create standalone binaries working into any puppy linux version, magicermine works better, it is useful, although not perfect, but astonighingly expensive

Some of apps I made portable standalone with magicermine
viewtopic.php?f=108&t=976

CDE
https://pg.ucsd.edu/cde/manual/

Trends to generate bigger packages (in terms of size) and there are some annoying things (for instance, if you make a CDE package of a browser, you can only download files from browser into CDE generated subdirectory package, not outside)
I see that sources and binaries seem no more available from pgbovine home page, but I have 32 bit CDE binary somewhere
EDIT: UPLOADED CDE 32 BIT

md5 0075e9315389e328406f88c5b1cdfa92
sha1 54c7e73bbdd2e577438510ba9be790adce307c3b

Dingo wrote: ↑Sat Jan 09, 2021 4:16 pm

...CDE... and there are some annoying things (for instance, if you make a CDE package of a browser, you can only download files from browser into CDE generated subdirectory package, not outside)...

Actually, that could be very useful. My exploration, http://www.murga-linux.com/puppy/viewto ... 3d#1047984 suggests that the supposed limitation of the Spot routine doesn't work. Access from the internet isn't restricted to the Spot folder. Yes, downloads will "only" go into /spot/downloads if configure your web-browser to download there AND not ask. But click "ask every time" and your system is wide open. I doubt that it is much of a challenge for a hacker to by-pass that specified download setting.
You file-manager run as root, of course, can usually access any directory --for example the CDE generated one. Is that not the case? and a mechanism such as Mike Walsh's Spot2Root Permission Changer, http://www.murga-linux.com/puppy/viewto ... 45#1050245 can make transfer from a restricted folder an easy routine: after all, the objective is to hobble hackers, not legitimate users.

mikeslr wrote: ↑Sun Jan 10, 2021 3:14 pm

You file-manager run as root, of course, can usually access any directory --for example the CDE generated one. Is that not the case? and a mechanism such as Mike Walsh's Spot2Root Permission Changer, http://www.murga-linux.com/puppy/viewto ... 45#1050245 can make transfer from a restricted folder an easy routine: after all, the objective is to hobble hackers, not legitimate users.

That's interesting! I noticed when experimenting with chroots that unless you start rox with the "-n" option, you use the currently running version of rox rather than a new instance started in chroot. So even if rox tries to run things as spot, there could be potential for privilege escalation here. I think that tazpup prevents some of this by giving each user it's own unix domain sockets.

@mikeslr
This is an example of what CDE does:

http://jpeters.net/apps/exactimage-cde.tar.gz

A CDEized version of exactimage tools. They do not accept, as input, images outside path of CDE-root folder subdirectories tree