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

No Python interpreter? this simple RAT installs its own copy

isc.sans.edu

Post reply on HN
Print view View original

31–40 of 62 posts

Re: No Python interpreter? this simple RAT installs its own copy

#31

Post by musingsole »

krageon wrote: post #12
css wrote: post #2

CD Projekt's GoG client has a feature where users can write Python extensions [0] for third party account integrations. To enable this, they ship an entire Python interpreter alongside the app binary [1]. I guess this kind of makes sense, it is way easier than having users manage their own `venv`s and other Python environment stuff. Packaging Python apps for distribution outside of a Python development context is qui…

> quite pesky I've never had a bigger packaging nightmare than for Python and at this point I've worked with a substantial spread of available languages. It's simply embarrassing, especially because I used to like recommending it to people.

The C Language thanks you for your propaganda.

Re: No Python interpreter? this simple RAT installs its own copy

#32

Post by PufPufPuf »

css wrote: post #2

CD Projekt's GoG client has a feature where users can write Python extensions [0] for third party account integrations. To enable this, they ship an entire Python interpreter alongside the app binary [1]. I guess this kind of makes sense, it is way easier than having users manage their own `venv`s and other Python environment stuff. Packaging Python apps for distribution outside of a Python development context is qui…

GOG Galaxy 2.0 is also an Electron app, so it bundles the whole Chromium as well. The whole app is over 100 MB IIRC, but nobody cares since you'll be using it to download 100 GB games anyway.

(On a side note, I highly recommend it if you play games and have them on different PC platforms - Steam, Epic, GOG, UPlay... The plugin system is unique and fantastic.)

Re: No Python interpreter? this simple RAT installs its own copy

#33

Post by coliveira »

krageon wrote: post #12
css wrote: post #2

CD Projekt's GoG client has a feature where users can write Python extensions [0] for third party account integrations. To enable this, they ship an entire Python interpreter alongside the app binary [1]. I guess this kind of makes sense, it is way easier than having users manage their own `venv`s and other Python environment stuff. Packaging Python apps for distribution outside of a Python development context is qui…

> quite pesky I've never had a bigger packaging nightmare than for Python and at this point I've worked with a substantial spread of available languages. It's simply embarrassing, especially because I used to like recommending it to people.

Agreed. Python is one of the worst languages in the sense of packaging and distributing code. It is incredible how bad they manage to make the whole process. And it is not for lack of effort, they have attempted several things, but the end result is complete confusion. Every year they come with a new way to solve the packaging problem, but in the end the result is just more complexity.

Re: No Python interpreter? this simple RAT installs its own copy

#34

Post by coliveira »

musingsole wrote: post #31
krageon wrote: post #12

Earlier quoted context omitted.

> quite pesky I've never had a bigger packaging nightmare than for Python and at this point I've worked with a substantial spread of available languages. It's simply embarrassing, especially because I used to like recommending it to people.

The C Language thanks you for your propaganda.

The C language may be complex to setup an environment. But once you have the build system complete, there are mature tools to create and distribute your artifacts. That is not the case with Python.

Re: No Python interpreter? this simple RAT installs its own copy

#35

Post by dragonwriter »

icegreentea2 wrote: post #3
css wrote: post #2

CD Projekt's GoG client has a feature where users can write Python extensions [0] for third party account integrations. To enable this, they ship an entire Python interpreter alongside the app binary [1]. I guess this kind of makes sense, it is way easier than having users manage their own `venv`s and other Python environment stuff. Packaging Python apps for distribution outside of a Python development context is qui…

Shipping your own runtimes as part of heavy application isn't that unusual or limited to Python, especially in the Windows world. For example, JetBrains ships its own Java runtime for all of its IDEs. In fact, the Python world would be simplified if "ship your own runtime and env" as part of your final application was the norm. The Python runtime and stdlib by itself is like 20-30MB packaged up or something. For cert…

> In fact, the Python world would be simplified if "ship your own runtime and env" as part of your final application was the norm.

AFAIK, it is for final applications whose main purpose isn’t to be used as development tools tied to whichever python environment it is installed in.

Re: No Python interpreter? this simple RAT installs its own copy

#36

Post by stordoff »

m463 wrote: post #24
css wrote: post #2

CD Projekt's GoG client has a feature where users can write Python extensions [0] for third party account integrations. To enable this, they ship an entire Python interpreter alongside the app binary [1]. I guess this kind of makes sense, it is way easier than having users manage their own `venv`s and other Python environment stuff. Packaging Python apps for distribution outside of a Python development context is qui…

Also, when they ship a dosbox game, the installation includes not only dosbox, but a zip file of the dosbox source code. ...and strangely - I don't know if this is only the mac version - they randomly include the manual for a PC game called Harvester /Extras/dosbox/dosbox_svn.zip ... /Extras/Manual.pdf

I only own a couple of DosBox games (Duke 3D, Ultima: Worlds of Adventure 2: Martian Dreams), and whilst both include the source on Windows (dosbox-0.74-2.1.tar.gz), I can't find any manuals that look out of place.

The DMG for the Mac version of Duke 3D doesn't appear to include the source or a Harvester manual, though it seems to be based on Boxer, not just DosBox. The Mac PKG for Ultima does have the source (dosbox_svn.zip), but no (edit: out of place) manuals as far as I can tell.

I wonder if the Harvester manual you're seeing is a GoG artifact from reusing the same DosBox setup as Harvester and they forgot to remove it, as the source from Ultima includes a file called "harvester_mouse_clean.diff".

Re: No Python interpreter? this simple RAT installs its own copy

#37

Post by vorticalbox »

PufPufPuf wrote: post #29
icegreentea2 wrote: post #3

Earlier quoted context omitted.

Shipping your own runtimes as part of heavy application isn't that unusual or limited to Python, especially in the Windows world. For example, JetBrains ships its own Java runtime for all of its IDEs. In fact, the Python world would be simplified if "ship your own runtime and env" as part of your final application was the norm. The Python runtime and stdlib by itself is like 20-30MB packaged up or something. For cert…

Isn't that what PyInstaller already does? It bundles your Python app with a runtime. I've seen a few apps distributed like this, even GUI ones.

Yes, bit for malware you want your dropper to be small and lightweight so it can be downloaded and ran very quickly.

Hence and vb script that downloads python, they could have hosted the rat and downloaded that too rather than writing it line by line.

Re: No Python interpreter? this simple RAT installs its own copy

#38

Post by geofft »

lostmsu wrote: post #28
formerly_proven wrote: post #26

Earlier quoted context omitted.

DosBox is GPL. Shipping the source code isn't required, but an easy way to immediately comply with the license.

I always assumed if you ship something, that contains a GPL part, the whole product needs to be GPL too. Is it wrong, and shipping binaries is OK?

It depends on whether the other parts of the product are derivative works of the GPL'd work or not.

In general, a reasonable boundary is that if it runs the GPL'd work as a command, then it's not a derivative work, but if it links against the GPL'd work, then it is. (This is of course not a distinction established in law, which knows nothing of subprocesses and linkers, but it's a good approximation, most of the time. Making a modification to a GPL'd binary to expose a particular interface for another non-GPL'd process to call probably makes that non-GPL'd process a derivative work, though. Conversely, using a standardized API that happens to be implemented by a GPL'd library probably does not make the program linking it a derivative work.)

The GPLv3 says:

> A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

GOG presumably believes that they are shipping an aggregate, and DOSBox is an individual work, and the game they're shipping is a separate individual work, and the wrapper script to put them together is its own work, independent of the specific game or specific emulator. They must comply with the license of DOSBox, i.e., they must provide the corresponding sources, but that license doesn't apply to other things in the aggregate.

For comparison, the Linux kernel also says:

> NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work".

Re: No Python interpreter? this simple RAT installs its own copy

#39

Post by rripken »

pansa2 wrote: post #17
wzdd wrote: post #13

Earlier quoted context omitted.

I've had both Sophos and Windows Defender pick up innocuous Pyinstaller-based packages as malware, presumably because packaging malware with Pyinstaller is such a common technique. It's quite frustrating if you intend to release the software. Example issue: https://github.com/pyinstaller/pyinstaller/issues/3802

The other issue with using PyInstaller to build a program into a single binary is that every time the program runs, it needs to extract its own contents to a temporary directory. This causes slow start-up and, if the program exits abnormally, orphaned files left on disk. I think other packaging tools have a workaround for this particular problem but, in my experience, have other issues. I’d love to use Python for bui…

What you are describing sounds like the onefile mode. Pyinstaller also has a onedir mode which is much faster to start. I packaged some python ml models into a pyinstaller built exe and a larger java application calls them. Onedir makes for a big install but they only take a second or two to run.

Re: No Python interpreter? this simple RAT installs its own copy

#40

Post by pjc50 »

musingsole wrote: post #31
krageon wrote: post #12

Earlier quoted context omitted.

> quite pesky I've never had a bigger packaging nightmare than for Python and at this point I've worked with a substantial spread of available languages. It's simply embarrassing, especially because I used to like recommending it to people.

The C Language thanks you for your propaganda.

C is the original language where you can reliably build an executable and ship it as a single file where it will run with no extra dependencies not already on the target system.
Post reply on HN