On Sat, 13 Jan 2024 18:06:24 +0100, Radoslaw Skorupka wrote: >I can imagine technical reason to not encrypt such libraries. >However encryption is a kind of data protection. Data. Not programs. > But some load modules/program objects aren't really files. As Ifond out to my dismay as a novice when I tried to use IEBGENER to copy a load module to a different PDS.
But UNIX program objects are "really files". "cp -p" works on then. But content Supervision relies heavily on the elaborate format. Part of the reason that UNIX directories don't work in STEPLIB concatenation. (Idea?) What about Format preserving encryption? Should the directory be encrypted likewise? What about driver-level encryption of virtual DASD? Unload it and encrypt the archive? What authority should be needed to use an encrypted program? >W dniu 13.01.2024 o 17:28, Steve Estle pisze: >> Everyone, >> >> Our team is knee deep into pervasive encryption rollout on ZOS 2.5 and >> despite the fact such functionality has been out for years by IBM to do >> this, it is quite surprising how many software vendors when you contact them >> they have no clue what you're talking about - that is a complete aside - I'm >> not going to name vendors here but if you want some examples you can contact >> me offline. >> >> My true reason for composing this is that we've discovered the inability to >> encrypt load libraries - even in PDSE format. I've yet to get a straight >> answer from IBM on why this is?... Is this a "giant" technical hurdle for >> IBM? Or is it just cause there hasn't been anyone who raised the need yet? >> If the latter does this capability interest others here if I were to raise >> as an IBM idea - would you vote for it? >> >> I know this seems innocuous, but we'd like to encrypt as much as possible in >> our environment and due to Top Secret deficiencies we have to encrypt at >> high level qualifier level (HLQ) (all or nothing under each HLQ >> unfortunately). Given we have load module libraries under many differ HLQ's >> this is posing difficulties in moving forward with our rollout when an HLQ >> does have one or more load module libraries as part of that HLQ. You can >> only imagine the pain of renaming a load library given all the JCL, etc that >> is referencing that library name. >> >> Also, while encrypting load module libraries might seem a little far >> fetched, there are of course many malicious viruses that have been launched >> by injecting code into a suspecting piece of code. >> >> So two questions: >> >> 1. Why has IBM not already provided such functionality - can anyone speak to >> the technical hurdles to provide? >> 2. If I were to submit an IBM idea, can I count on this community for some >> backing here to help in upvoting such an idea submission? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
