-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide a way to verify the authenticity of a Zowe driver as being original, untampered, release #1179
Comments
There is already the provision in Zowe to verify that a downloaded file is an original one. Files and their keys are in Jfrog https://zowe.jfrog.io/zowe/webapp/#/artifacts/browse/tree/General/libs-release-local/org/zowe/1.10.0 Instructions for their use are here on the Zowe download site: https://d1xozlojgf8voe.cloudfront.net/post_download.html?version=1.10.0 However, the post-download doc from cloudfront.net does not describe how to verify the driver authenticity for any files except the convenience build .PAX file. I've raised issue zowe/docs-site#1126 for this. |
Support staff will want to verify that the user's runtime directory content is unmodified from the official, released version. The first effort is to verify the USS runtime - verification of the shipped MVS runtime datasets will come later. One solution is to create a key based on the contents of the USS runtime created during The support person will download the key for the customer's release, and run a script to walk the customer's runtime directory tree and run |
Program md5deep looks promising http://md5deep.sourceforge.net/ |
Suggested solutions Phase 1 – compare filenames and file sizes
These can be excluded from the list to be compared. Phase 2 – real checksum of all files Issues:
|
The hash file could be stored in the runtime directory itself, thus rendering the hash check self-contained. |
@Joe-Winchester |
Example on a real z/OS system
|
An improved approach reduced the total time to generate the local hash set to 17 seconds. |
Adapted from slack with @jackjia-ibm
|
Current proposal. The |
The |
This test run of those changes was successful
and
|
@John-A-Davies I saw you also publish |
@jackjia-ibm Yes, it's as stable as the rest of the source files. The We also need to store the |
Feedback from my presentation of this topic to the Zowe team
|
A self-contained version of zowe-verify-authenticity.sh Either • Dowload the file RefRuntimeHash.txt with curl, or Proposed new parm list format:
-r runtime directory path. Defaults to CWD For example:
Or you can just type
with no parameters. The This check could be falsified, but L2 can download these files to
and run
|
-r parameter shouldn't default to CWD - this script is in |
|
Can this be closed ? |
No - it's not done |
@nkocsis This issue will be closed when the pull request #1316 with the code gets reviewed, approved and merged. It was demo'd on a few calls recently to the community, but there is work to do be done to get it into 1.12 and also the have it documented. Once the pull request #1316 that contains the code is closed it gets associated with the issue which will be closed automatically. At the same time the CHANGELOG.md file for the release will be updated to reference that the feature is included in a release, which we're hoping will be 1.12. |
Is your feature request related to a problem? Please describe.
The Zowe release pipeline creates builds, e.g. 1.5, 1.9, 1....
1.9 represents the Zowe SMP/E FMID AZWE001 - the A letter was chosen to make it vendor neutral - other letters are reserved for specific IBM z/OS vendors.
The Zowe drivers can be redistributed as-is by vendors offering enterprise support for Zowe through their own channels. These are enterprise "trusted" SMP/E receive order sites.
The Zowe SMP/E FMID installs into the USS location /usr/lpp/zowe. The design is for a single destination which offers beneifts to users and extenders that a single desktop and single APIML can have app to app communication and single sign on and MFA ... across all products that extend Zowe from all vendors, whether from the original vendor that delivered the SMP/E package or not.
Traditionally a vendor offering support may only do this if the software they are supporting was obtained by the customer through their channel.
Describe the solution you'd like
Provide assistance for a vendor support team to be able to trust a Zowe driver irrespective of where it came from, so the source is based on a customer preference for who their trusted partner for support is but they may choose to install extensions from other vendors into the same base (CLI, APIML, Desktop).
Additional information
Node.js has already solved this. This section is pasted from the README.MD that is delivered with Node.js.
The text was updated successfully, but these errors were encountered: