Is it technically possible to make an AppImage that is also a valid zip file? about type3-runtime HOT 18 OPEN

Ah, yeah it's clever but I fail to see its usefulness as it would just double the disk usage (until someone deletes the first one) and creates the impression that AppImages aren't already compressed all for the sake of avoiding a check box or chmod command.

The ideal macOS-like integration use case for AppImages really isn't possible without it being implemented on the OS-level, so for distros that refuse to give first-party support, there will always need to be some sort of workaround.

I think that the current solution of just having the user make it executable is probably the most straightforward and expected solution, and it wouldn't hurt to discuss getting 1st party support to a distro maintainer every once and a while.

from type3-runtime.

It could be standardized of course. Efficiency wise it's not a very good idea, but we could standardize a payload type for zip archives, too. The AppImage header format is capable of that.

from type3-runtime.

It probably became not clear what I meant yet:

• Say, we can create a format called .AppImage.zip
• If the user unzips the .AppImage.zip, then he gets an .AppImage (which already has +x set, which is why some people like to put AppImages into .zip)
• Now comes the cool part that I'd love to see: If the user does not unzip the .AppImage.zip but merely sets it +x, it also behaves like an AppImage (cause I hate having to unzip AppImages from zip files)

Doable?

from type3-runtime.

That seems very complicated. Everything might be doable, but this is just not a good idea if you ask me. Rather educate users they have to chmod +x. It's not that complicated.

Also, as said before, I'm not sure zip supports permissions properly.

from type3-runtime.

At least I keep hearing this as the reason why people put AppImages into zip files:

The main reason we archive it is to preserve x permission.

aforensics/HiddenVM#10 (comment)

from type3-runtime.

Well, this UX highly depends on whether it's possible to mix ELF and zip, like you did in type 1.

Another question is, can we make it so the .zip doesn't add additional compression?

from type3-runtime.

According to https://superuser.com/questions/411394/zip-files-without-compression/411398,

The ZIP format has always supported archiving files with zero compression ratio, even since pkzip/pkunzip in DOS times.

For Linux this shell command zips mydir folder with no compression:

zip -0 -r mydir.zip mydir

from type3-runtime.

I think this could be the true killer use case for a type 3...

from type3-runtime.

That zero compression stuff might be nice, but it still doesn't tell us if we can make an ELF that is also recognized as a zip archive by software. I think it's only worth it if the thing can automatically convert itself into a "real" AppImage.

from type3-runtime.

it still doesn't tell us if we can make an ELF that is also recognized as a zip archive by software

Indeed.

from type3-runtime.

Zip files start with 50 4b 03 04, which collides with ELF's magic number. So I guess this idea is dead.

But why use zip at all? Using tar would be significantly better, as you don't have to deal with the complexity of zip (in fact, tar contains the entire file just at some offset). I could imagine tar requires magic numbers as well.

Potentially crazy (and really bad) idea: Why not make .AppImage.iso? You've shown that this works actually. And some extraction tools support .iso.

Edit: seems like tar uses the offset 0x101 for its magic bytes. With some ELF header hacking, it should be possible to leave some room there for them. However, I am pretty sure that tar stores its information at the file beginning already. But someone should look into it.

from type3-runtime.

Yes. Let's continue to think along those lines. This is good.
Aren't there self-extracting zip files on Windows? I think so...

from type3-runtime.

Yes. Let's continue to think along those lines. This is good.

They're exes, though.

from type3-runtime.

(I'm not sure this is a good idea but...) https://justine.lol/redbean/index.html is a webserver that's a pe+elf+macho+sh+zip polyglot
in more detailed explained here: https://justine.lol/ape.html where she sais PKZIP markers are at the end of the file.

from type3-runtime.

I think we should just focus on what we're good at, which is shipping non-isolated-but-self-contained application containers with a binary runtime. I have heard of this APE project before, but it seems quite experimental, plus we don't really care about other OSes than Linux. (Fun fact: that the site is served with nginx, not with readbean.)

from type3-runtime.

Just meant to anwer the question that yes, you probably can make an ELF+ZIP polyglot, not that you should.

from type3-runtime.

Having a zip/elf combination is not only possible, it's also very easy as the magic numbers can be at any arbitrary point in the file, not just offset 0. You can append a zip file to an elf and both are valid, so you could simply extract it using any zip software. zip files (at least from info-zip) also do support POSIX permissions.

I think the primary issues with zip are probably the bad compression ratio (also compressing files individually, so similar files will take up extra space), decompression performance and lack of file deduplication. Despite the cool factor, I think using zip files is a step in the wrong direction, at least for the primary format. SquashFS is superior to zip in every way except compatibility and the convenience of being able to extract it like any other zip file.

from type3-runtime.

You wouldn't make the zip file the actual storage. You'd take the regular appimage and then try to polyglot it into a zip quine so that the file extracts to an identical copy of itself. But with the exec bit set.

from type3-runtime.