[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-ideas] Enhancing Zipapp


Abdur-Rahmaan Janhangeer
pythonmembers.club | github

On Wed, Jan 8, 2020 at 1:32 AM Brett Cannon <brett at python.org> wrote:
> This would be a packaging detail so not something to be specified in the

Yes, the module opening the zip will look for it

>> - [  ] Signing mechanism
>> Mechanisms can be added to detect the integrity of the app. App hash can
>> used to check if the app has been modified and per-file hash can be used
>> detect what part has been modified. This can be further enhanced if
>> - [  ] Protecting meta data
>> Metadata are not protected by basic signing. There existing ways to
>> metadata and beyond [7]
> This can be tricky because people want signing in specific ways that vary
from OS to OS, case by case. So unless there's a built-in signing mechanism
the flexibility required here is huge.

Let's say we have a simple project


The first step is to include in the info file the file name and hashes

file.py: 5f22669f6f0ea1cc7e5af7c59712115bcf312e1ceaf7b2b005af259b610cf2da

Then by reading the info file and hashing the actual file and comparing,
we can see which file was modified if any.

But now, a malicious program might try to modify the info file
and modify the hash. One way to protect even the metadata is
to hash the entire content

    file.py # we can add those in a folder if needed

Then after zipping it, we hash the zipfile then append the hash to the zip

[zipfile binary][hash value]

We can have a zip file and yet another file stating the hash value but
to maintain a single file structure, the one described above is best.

Then when opening the zip file, we start reading upto the hash value. The
value becomes the checking signature of the zipfile.

This forms a base on which more sigining mechanism can be added like
author keys

Since zipfiles are the same across OSes, this kind of approach supposedly
don't pose a problem

> Install the wheels where? You can't do that globally. And you also have
to worry about the security of doing the install implicitly. And now the
user suddenly has stuff on their file system they may not have asked for as
a side-effect which may upset some people who are tight on disk space
(remember that Python runs on some low-powered machines).

Yes, global folders also defeat the spirit.

Using the wheel-included zip (A), we can generate another zip file (B) with
the packages installed. That generated zip file is then executed.
Zip format A solves the problem of cross-platforming.
Normal solutions upto now like use solution B where you can't share
your zips across OSes.

As for space, it's a bit the same as with venvs. Zip format B is the
of packages installed in venv.

Venv usage can be a hint as to when to use.