Hackerplace should: 1) Enforce the use of TLS for the retrieval of all application manifests and package files, not allowing their accidental use in apps.json (or whatever comes in the future), and 2) Use either digital signatures or cryptographic hash functions in verifying the contents of the application packages. Right now, apps.json has a "revision" tag that nominally contains cryptographic hashes of the package.zip files: it should enforce them, either through the "revision" attribute or some other attribute. It should not allow the use of MD5, as most packages currently do, due to weakness in both collision resistance and weakness to chosen prefix attacks.
Hackerplace is not a production solution, its a temporary hack as we developer the add-ons model. At the work week discussed moving to marketplace, which should hopefully solve this bug IIUC.
From an security operations perspective we could also mitigate this by s/http/https/g. If we pick status quo we should at least send a note to everyone foxfooding to let them know that apps they load may not be the apps they end up with.
(In reply to Jeff Bryner [:jeff] (use NEEDINFO) from comment #2) > From an security operations perspective we could also mitigate this by > s/http/https/g. > > If we pick status quo we should at least send a note to everyone foxfooding > to let them know that apps they load may not be the apps they end up with. Note that we have updated the apps.json to only use https for manifest URLs. We will not accept manifest URLS without https from now on.