Yours, Abdur-Rahmaan Janhangeer pythonmembers.club | github Mauritius
On Wed, Jan 8, 2020 at 1:32 AM Brett Cannon <br...@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.
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QMCN47RA5ICM3E4JAF4SWZPTOLQEERWB/ Code of Conduct: http://python.org/psf/codeofconduct/