On Wed, 8 Jan 2020, 21:29 Andrew Barnert, <abarn...@yahoo.com> wrote:
> > How does this solve the problem? A malicious program that could modify the > hash inside the info file could even more easily modify the hash at the end > of the zip. > > Existing systems deal with this by recognizing that you can’t prevent > anyone from hashing anything they want, so you either have to store the > hashes in a trusted central repo, or (more commonly–there are multiple > advantages) sign them with a trustable key. If a malicious app modified the > program and modified the hash, it’s going to be a valid hash; there’s > nothing you can do about that. But it won’t be the hash in the repo, or > it’ll be signed by the untrusted author of the malicious program rather > than the trusted author of the app, and that’s why you don’t let it run. > And this works just as well for hashes embedded inside an info file inside > the zip as for hashes appended to the zip. > You are right, that's why i said: The hash value becomes the checking signature of the zipfile. > Meaning the hash value at the end of the zipfile becomes the hash by which we identify the file and against which we check. That is for checking the integrity of the app.
_______________________________________________ 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/EQXAC2UYEFXTMF5AXWEE3ICD2NDMUL2V/ Code of Conduct: http://python.org/psf/codeofconduct/
