@robocoder opened this issue on March 17th 2010

This is to allow for file integrity check of 3rd party plugins downloaded from the plugin repository.

Expands on #1097

Keywords: wishlist

@mattab commented on March 17th 2010

I don't know if this is required, because plugins would be downloaded from a central repository, and unzipped, which would ensure that all files are correct, wouldn't it?

@robocoder commented on March 17th 2010

The website frontend for the repository will also allow plugins to be downloaded manually. In those cases, I anticipate we'll have that segment of users who unzip and ftp the individual files to their server.

@robocoder commented on March 19th 2010

While we're at it, add a test to the SecurityInfo plugin to re-run the check.

@mattab commented on March 20th 2010

Replying to vipsoft:

While we're at it, add a test to the SecurityInfo plugin to re-run the check. what did you mean by that?

@robocoder commented on March 31st 2010

re: comment:5

It means the SecurityInfo plugin could re-run the file integrity check -- i.e., test for core files for tampering.

@mattab commented on April 15th 2010

If we want to allow for file integrity checks, we need to have all plugins go through our "build script". This could be possible when plugin authors set a SVN path for the build... but if they directly submit their .zip, it will already be built and harder to add the manifest (even though we can always unzip it, add the manifest and zip it back).

I vote for won't fix in V1 of plugin repo, until other more important things are working.

This issue was closed on April 15th 2010
Powered by GitHub Issue Mirror