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/

Reply via email to