Open Joe-Winchester opened 2 years ago
@Joe-Winchester Do you know if users are installing plugins from npmjs, internal registries, offline tarballs, or all of the above?
Also, are you looking for hash check, digital signature validations, or both? Each have a role in proving an artifact was not tampered with and are often checked in different stages of the provisioning process...
For our plug-in we have two official delivery channels - npmjs and as tarball tha is copied to some USS / zFS directory together with our product deliberable, that is installed via SMP/E.
Hi @MarkAckert . It's all of the above. We have customers using npmjs and offline tarballs, and we also have ones using internal repositories that are proxies/clones of an external repo.
Due to the complexity of this request, we decided to table this issue until the Zowe Security workgroup provides recommendation.
Thank you for raising this enhancement request. The community has 90 days to vote on it. If the enhancement receives at least 5 upvotes, it is added to our development backlog. If it receives fewer votes, the issue is closed.
Problem: Customers have obtained a Zowe plugin. They need to verify that this is unmodified genuine software to ensure that it operates as designed. This is to protect against any tampering and also for support purposes to verify that the software being operated is the same code that the Zowe community or vendor distributed.
Solution. Possible solution could be
zowe plugin verify <plugin-name>
which created a SHA hashkey MD5 number that can be compared against an original value. The original value could be held on npmjs.com in a fixed location for each plugin so the user could compare manually, or the verify command could do an automatic check. The technical solution could be different, but the customer need is to validate and verify the provenance and authenticity of their software.