[Python-ideas] Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club | github
Mauritius


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
stdlib.


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
be
>> used to check if the app has been modified and per-file hash can be used
to
>> detect what part has been modified. This can be further enhanced if
needed.
>>
>> - [  ] Protecting meta data
>>
>> Metadata are not protected by basic signing. There existing ways to
protect
>> 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

folder/
    file.py
    __main__.py

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

file.py: 5f22669f6f0ea1cc7e5af7c59712115bcf312e1ceaf7b2b005af259b610cf2da
__main__.py:
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

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

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

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

[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
hash
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
equivalent
of packages installed in venv.

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