Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Warp – self-contained, single binary applications

github.com

Post reply on HN
Print view View original

111–120 of 157 posts

Re: Warp – self-contained, single binary applications

#111

Post by stdclass »

paavoova wrote: post #97
rkeene2 wrote: post #29

Earlier quoted context omitted.

Tcl is still the king of this kind of distribution with Starkits/Starpacks. Since you can virtualize the filesystem within Tcl, you can pack in all your resources as regular files and generally scripts will work without knowing that this has happened (and without hacky extracting of the archive to disk before running, or while running).

Python can do something similar albeit far simpler via packaging as an executable zipfile. Just structure everything you need in a directory and zip up with __main__.py in the root. All resources are available as an in-memory binary stream, including individual source .py files. Of course if you want to package something like a C library, you need to unpack that to disk to be able to access it with ctypes.

PHP has something similar, called .phar https://en.wikipedia.org/wiki/PHAR_(file_format)

Re: Warp – self-contained, single binary applications

#112

Post by pmorici »

creatornator wrote: post #102
paavoova wrote: post #97

Earlier quoted context omitted.

Python can do something similar albeit far simpler via packaging as an executable zipfile. Just structure everything you need in a directory and zip up with __main__.py in the root. All resources are available as an in-memory binary stream, including individual source .py files. Of course if you want to package something like a C library, you need to unpack that to disk to be able to access it with ctypes.

Are you referring to the zipapp library? I had no idea this even existed until now but that seems pretty clever. Huh. Why can't it also dynamically unzip a shared object library?

You can simulate a single file exe using py2exe and NSIS. That doesn't have the no library limitation.

Re: Warp – self-contained, single binary applications

#113

Post by GordonS »

haxton wrote: post #73
GordonS wrote: post #53

Earlier quoted context omitted.

Unfortunately, it turns out this is not a completely self contained binary - it's more of a packer. So if you pack a Java app, you're still going to need the JRE, and if you pack a .NET Framework app, you're still going the .NET Framework, etc.

So I don't know what this is doing. But I know that microsoft is developing WPF to run in a fulled contained .NET Core binary. Meaning that there is no requirement of having any preinstalled software when running it. I would assume this technology to be translated into most any .NET core app.

Yes, any .NET Core app can already be 'published' as a self-contained app. That basically means it ships along with the .NET Core files (there are a lot of them), so you don't need to have a globally installed .NET Core to run it.

What Warp does is act like a packer, creating a thin, native executable that compresses and embeds all the files required to run your app, then decompresses them to disk the first time the app is executed.

Re: Warp – self-contained, single binary applications

#114

Post by GordonS »

wildmusings wrote: post #9

From the README, it looks like this unpacks the application and dependencies into a local cache in the user's home directory on first run. Is it possible to instead execute the compressed application code directly and present to the resulting process a virtualized file system that decompresses the dependencies on the fly too? Then you could run the single binary without giving it any filesystem access. One way to do…

It's far from easy, but you can create virtual filesystems on Windows using a minifilter driver. There are some wrappers, like Dokan[1], that make this a lot easier though.

[1] https://github.com/dokan-dev/dokan-dotnet/blob/master/README...

Re: Warp – self-contained, single binary applications

#115

Post by GordonS »

paavoova wrote: post #89
dmitrygr wrote: post #6

Based on the readme, this is basically an SFX archive, which runs a binary upon completion of extraction to temporary folder, much like winzip & the like have created for ages.

Haven't read the link, but that's quite terrible, and the title is misleading. No idea why it's getting buzz in this thread. It means if tmpfs/equivalent isn't available, it will cause disk writes each application launch. Or if it caches the unpacking, it's susceptible to injection. And suppose the binary doesn't have write access to the filesystem?

It's the latter - it caches and is susceptible to injection.

Re: Warp – self-contained, single binary applications

#116

Post by wahern »

weberc2 wrote: post #37
eeZah7Ux wrote: post #28

Earlier quoted context omitted.

Vendorizing libraries and static linking has become a security hell. Just an example: https://blog.acolyer.org/2017/04/03/a-study-of-security-vuln...

Your link cites "little thought to the inclusion of dependencies", _not_ static linkage, as the cause of this "hell".

The implication is that statically linked binaries make it easier to throw in dependencies because you neither need to worry about how to ship them nor bother with re-using the shared libraries on the system.

If there's a bug in Go's TLS implementation, you need to identify, recompile, and redistribute every Go application you use. Whereas if it were using the system's OpenSSL library everything would magically be fixed by a simple `apt-get upgrade` or `yum update`.

Re: Warp – self-contained, single binary applications

#117

Post by antaviana »

nur0n wrote: post #76
ASalazarMX wrote: post #64

Earlier quoted context omitted.

I'm ambivalent about this. It is cool to distribute a single binary, but years ago there was serious vulnerability in a very common open source library library whose name escapes me (it wasn't libgcc, someone help a brother here). It was used in multiple programs in both Windows and Linux. On Windows there was a rush of individual updates as each application was fixed... on Linux, simply upgrading that library fixed…

I think the inverse argument can be made against shared libraries: if an update introduces a vulnerability, now all programs which depend on that library become vulnerable.

If I write malware, I guess it’s possibly easier to infect one library than thousands of executables.

Re: Warp – self-contained, single binary applications

#118

Post by devxpy »

weberc2 wrote: post #23
jpic wrote: post #8

Earlier quoted context omitted.

I wish also had this. However, containers work. Not sure why they do java though, i thought java has been happy with jars so far.

We're struggling using containers for our Python and Javascript applications. I think we're using venvs and node_modules and we oughtn't (or we shouldn't keep them in our project directory where they sometimes--but not always--get overwritten by source code volume mounts).

I've been using shiv recently for my django deploys.

You might wanna check it out.

Here is a small readme I put together...

https://github.com/devxpy/shiv/blob/8d8298d21380dcf0b1970856...

Re: Warp – self-contained, single binary applications

#119

Post by pdonis »

wildmusings wrote: post #9

From the README, it looks like this unpacks the application and dependencies into a local cache in the user's home directory on first run. Is it possible to instead execute the compressed application code directly and present to the resulting process a virtualized file system that decompresses the dependencies on the fly too? Then you could run the single binary without giving it any filesystem access. One way to do…

> From the README, it looks like this unpacks the application and dependencies into a local cache in the user's home directory on first run.

Isn't this a huge security hole? The user should not have write access to the application binaries.

Re: Warp – self-contained, single binary applications

#120

Post by sandGorgon »

The best of breed here is zeroinstall - https://0install.net/. The software catalog is here - http://0install.de/catalog/

comes with its own SAT solver for dependency resolution. zeroinstall is what Canonical was considering before it created Snap Packages.

Post reply on HN