Re: Fwd: Log4j hearing: 'Open source is not the problem'
very responsible. Meanwhile, the client is open for attacks. However, he can't protect himself since no one reported it affects his MF. בתאריך יום א׳, 13 בפבר׳ 2022 ב-3:42 מאת Seymour J Metz : > I believe that developing a fix before you disclose the vulnerability is > the responsible thing to do. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of David Crayford [dcrayf...@gmail.com] > Sent: Saturday, February 12, 2022 6:17 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem' > > On 13/2/22 3:38 am, Itschak Mugzach wrote: > > If someone develops code that is vulnerable, only the organization he > works > > for is (potentially) affected and the attacker does not have access to > the > > code to play with. With open source, the code is accessible to everyone, > > and the problem hits millions of organizations. > > Are you sure the attacker doesn't have the code? A huge percentage of > hacks come from insider threats. In the case of Solar Winds the attackers > had the code and access to the build pipeline. > > > > > > The problem is not the vendor that makes use of open source, it is the > fact > > that when the vulnerability is discovered, there is a time window until > it > > is patched. And this is only if it was discovered by an ethical bug > hunter. > > Log4Shell was discovered by a security researcher at Ali-Baba. > Shellshock, Heartbleed, Meltdown etc were discovered by security > researchers at Google. > The difference with IBM or companies is that they don't disclose > vulnerabilities. You probably think that's a good idea. In truth, if > those vulnerabilities are there, especially > on public facing networks there is just as much chance of a breach. > > > > > > This is why I am not impressed (but do appreciate the effort) by the > tools > > David and his company uses. They do their best, > > They do find vulnerabilities. They are amazingly smart and can detect > when you open a secure TCP connection and don't authenticate the > hostname which could result in a MITM attack. That could be considered > a 0-day. > > > > but it will not help in > > case of a zero date and the scale of an open source vulnerability is > > unlimited compared to a specific local code, bad as it is. > > What about the scale of a vendor product, such as IBM Data Risk Manager? > A security research found 4 0-days and a sackful of other > vulnerabilities and IBM refused to accept the report until > the researcher went public. IBMs customers are enterprises such as banks > and insurance companies. > > > https://www.ibm.com/support/pages/security-bulletin-ibm-data-risk-manager-affected-multiple-vulnerabilities-4 > > The security researcher in this video > https://www.youtube.com/watch?v=q8mFhDmBEIc claims to have found > 10 > 0-days on z/OS by exploiting buffer overflows in APF-authorized C programs > by overlaying R14 with his exploit code. I can't verify the veracity of > this claim but it seems plausible. It's the same technique used in the > Logica breach. Last time you scoffed at that and asked > if there had been a breach. So I guess that 0-days are acceptable unless > there has been a breach, or did I misunderstand you? > > > > > > The funny thing is that although millions of eyes look at "open source" > (as > > Chrles mentioned) they rarely find the vulnerability in a very > > common, highly used code (such as log4jv2 that has been here since > > 2012...). > > > > Saying that, open source is here to stay. Just don't wait for the vendor > to > > report on vulnerabilities. Scan it yourself frequently. > > > > My two israeli shekels cents (Actually called "agorot"). > > > > ITschak > > > > *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere > > Platform* *|* *Information Security Continuous Monitoring for Z/OS, > zLinux > > and IBM I **| * > > > > *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 > **|* > > *Skype**: ItschakMugzach **|* *Web**: > http://secure-web.cisco.com/1oH69EmxiPM3D-pi2iMI3amWVgRxjlVjSqd5lhVhG7MlHXIO3a9pNfhJfn-tUCZVQcd2Te-X0rG1t8gj0oKs6fUS1UlG-IyF3G2Q79IcTAByERK-1lba3FjVMT0yVQAqALG-S8HF4TEajq2_HlNh_KCHDDApGXFN5-5UK3ycRgY2t8GAxFALp73R55kIfn7fXCwKsIBuC9pMdVeYQsgdSm28BhrHCnLoE3lzSY78wEaji-Vx_tBUnLbHk6P92sGrIiLA23ICrZQFmoXT5wQhKZghc1leKXK5evoTHq88BAgFJ4t5emIO-uWU5d76CXJzaOexwk12RrG2XPL65hQpZESW-jLugueCtN7MGBF5ph2S3wM7WNEk8zbLJ0NJfBCSdJIkx1WWPcAK6dsoWIeiASmUmeLRm7U4sZC2ToS65mTdasXOZtkvZSCupvhDgoTj0/http%3A%2F%2Fwww.Securiteam.co.il > **|* > > > > > > > > > > > > On Sat, Feb 12, 2022 at 7:04 PM Charles Mills wrote: > > > >> Nobody asked me, but I think David buried the most important point in > the > >> middle. I have seen lots of TERRIBLE code written by "engineers from big > >> tech." That's not the key point. The key point is > >> > >>> the code is in the open and can be
Re: Coding IF statement in BPXBATCH shell
On Sun, 13 Feb 2022 01:26:41 +, Seymour J Metz wrote: >Some shops won't let you install free software, but for everybody else, that >sounds like the reasonable thing to do/ > The supplier should offer a "Pro" version for $0.01; perhaps with more attractive page headers (date in Roman numerals?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AMASPZAP DUMPT and program objects
You wouldn't have a class C_CODE in an assembler program (barring some rather unnatural acts). And apparently the new compilers think using CSECT names is a barbarism or something. You'll have to make do with DUMPT MYMODULE * C_CODE $PRIVnn are not real names, they're generated by the binder for un-named sections, but are only for its listing. sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Registers at entry to subtask (from ATTACH)
The issuer sees the same values in R2-R12 before and after the ATTACH. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tony Harminc [t...@harminc.net] Sent: Saturday, February 12, 2022 5:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Registers at entry to subtask (from ATTACH) On Sat, 12 Feb 2022 at 13:54, Binyamin Dissen wrote: > The manual (MVS Programming: Assembler Services Reference, Volume 1 > (ABE-HSP)) states > > 2-12 Used as work registers by the system. > > but I am looking at some old functional code which seems to expect > (several?) > registers values at ATTACH time be passed as is to the subtask. > Isn't the "Used as work registers by the system" talking about the registers the issuer sees after the ATTACH, rather than what the ATTACHed subtask sees? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Log4j hearing: 'Open source is not the problem'
I believe that developing a fix before you disclose the vulnerability is the responsible thing to do. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of David Crayford [dcrayf...@gmail.com] Sent: Saturday, February 12, 2022 6:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem' On 13/2/22 3:38 am, Itschak Mugzach wrote: > If someone develops code that is vulnerable, only the organization he works > for is (potentially) affected and the attacker does not have access to the > code to play with. With open source, the code is accessible to everyone, > and the problem hits millions of organizations. Are you sure the attacker doesn't have the code? A huge percentage of hacks come from insider threats. In the case of Solar Winds the attackers had the code and access to the build pipeline. > > The problem is not the vendor that makes use of open source, it is the fact > that when the vulnerability is discovered, there is a time window until it > is patched. And this is only if it was discovered by an ethical bug hunter. Log4Shell was discovered by a security researcher at Ali-Baba. Shellshock, Heartbleed, Meltdown etc were discovered by security researchers at Google. The difference with IBM or companies is that they don't disclose vulnerabilities. You probably think that's a good idea. In truth, if those vulnerabilities are there, especially on public facing networks there is just as much chance of a breach. > > This is why I am not impressed (but do appreciate the effort) by the tools > David and his company uses. They do their best, They do find vulnerabilities. They are amazingly smart and can detect when you open a secure TCP connection and don't authenticate the hostname which could result in a MITM attack. That could be considered a 0-day. > but it will not help in > case of a zero date and the scale of an open source vulnerability is > unlimited compared to a specific local code, bad as it is. What about the scale of a vendor product, such as IBM Data Risk Manager? A security research found 4 0-days and a sackful of other vulnerabilities and IBM refused to accept the report until the researcher went public. IBMs customers are enterprises such as banks and insurance companies. https://www.ibm.com/support/pages/security-bulletin-ibm-data-risk-manager-affected-multiple-vulnerabilities-4 The security researcher in this video https://www.youtube.com/watch?v=q8mFhDmBEIc claims to have found > 10 0-days on z/OS by exploiting buffer overflows in APF-authorized C programs by overlaying R14 with his exploit code. I can't verify the veracity of this claim but it seems plausible. It's the same technique used in the Logica breach. Last time you scoffed at that and asked if there had been a breach. So I guess that 0-days are acceptable unless there has been a breach, or did I misunderstand you? > > The funny thing is that although millions of eyes look at "open source" (as > Chrles mentioned) they rarely find the vulnerability in a very > common, highly used code (such as log4jv2 that has been here since > 2012...). > > Saying that, open source is here to stay. Just don't wait for the vendor to > report on vulnerabilities. Scan it yourself frequently. > > My two israeli shekels cents (Actually called "agorot"). > > ITschak > > *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere > Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux > and IBM I **| * > > *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* > *Skype**: ItschakMugzach **|* *Web**: > http://secure-web.cisco.com/1oH69EmxiPM3D-pi2iMI3amWVgRxjlVjSqd5lhVhG7MlHXIO3a9pNfhJfn-tUCZVQcd2Te-X0rG1t8gj0oKs6fUS1UlG-IyF3G2Q79IcTAByERK-1lba3FjVMT0yVQAqALG-S8HF4TEajq2_HlNh_KCHDDApGXFN5-5UK3ycRgY2t8GAxFALp73R55kIfn7fXCwKsIBuC9pMdVeYQsgdSm28BhrHCnLoE3lzSY78wEaji-Vx_tBUnLbHk6P92sGrIiLA23ICrZQFmoXT5wQhKZghc1leKXK5evoTHq88BAgFJ4t5emIO-uWU5d76CXJzaOexwk12RrG2XPL65hQpZESW-jLugueCtN7MGBF5ph2S3wM7WNEk8zbLJ0NJfBCSdJIkx1WWPcAK6dsoWIeiASmUmeLRm7U4sZC2ToS65mTdasXOZtkvZSCupvhDgoTj0/http%3A%2F%2Fwww.Securiteam.co.il > **|* > > > > > > On Sat, Feb 12, 2022 at 7:04 PM Charles Mills wrote: > >> Nobody asked me, but I think David buried the most important point in the >> middle. I have seen lots of TERRIBLE code written by "engineers from big >> tech." That's not the key point. The key point is >> >>> the code is in the open and can be scrutinized by millions of people >> There are thousands (if not millions) of people, ranging from high school >> code nerds to professional security consulting firms, hoping to make a name >> for themselves by being the first to spot some vulnerability in Apache, the >> Linux kernel, etc. That is an incredible free code inspection service. That >> is the key to the security of open source (IMHO). >> >>
Re: Fwd: Log4j hearing: 'Open source is not the problem'
An awful lot of exploits have been in proprietary software. An awful lot of successful cracks have been due to, e.g., insiders, sloppy procedure, social engineering, rather than software bugs. The Devil is in the details. What are the statistics on root causes? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Itschak Mugzach [0305158ad67d-dmarc-requ...@listserv.ua.edu] Sent: Saturday, February 12, 2022 2:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem' If someone develops code that is vulnerable, only the organization he works for is (potentially) affected and the attacker does not have access to the code to play with. With open source, the code is accessible to everyone, and the problem hits millions of organizations. The problem is not the vendor that makes use of open source, it is the fact that when the vulnerability is discovered, there is a time window until it is patched. And this is only if it was discovered by an ethical bug hunter. This is why I am not impressed (but do appreciate the effort) by the tools David and his company uses. They do their best, but it will not help in case of a zero date and the scale of an open source vulnerability is unlimited compared to a specific local code, bad as it is. The funny thing is that although millions of eyes look at "open source" (as Chrles mentioned) they rarely find the vulnerability in a very common, highly used code (such as log4jv2 that has been here since 2012...). Saying that, open source is here to stay. Just don't wait for the vendor to report on vulnerabilities. Scan it yourself frequently. My two israeli shekels cents (Actually called "agorot"). ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: http://secure-web.cisco.com/1dJc8cUdwjcnxoQy7NK9JjnUODSPv2zhqKTQkRI-fNKDoZVm5IIKlO9GD2-lNJOB-diRJzxyDQoy9eSsDqKa_WtmGtbaXEqYi-nGHXjlxqZTHUPjrJBhiA-c-KNIHvaW00aI1LY-2ufYpF9O2Zz747oQhYyZXU6ABtkRDUKiuO1dxFKWxo1ZSzpYygvw4DjLxa770lOum03Xyez4cUNiF7jjjENfhzBuiPOPh4CAh6Qa9Dk-b0hZRDBty2b3nWjvPcfF2NWCsEoE_npKbns7tyiPCQl-tSxmKLaWK4eCj2NTzyEW4BXGh9RS40_hn2YViX3NfA0CuiJipPVo7zh5Lqd3m4h7va5cH5GSb1gnfN9Jz3GFzqvlwgrRLBQileuEsFxoOGFn3G_IO_eSxMev9-e9VRkoDtMc6WEObHzQiaTuxZugKdxafRSvhtCT8gRvn/http%3A%2F%2Fwww.Securiteam.co.il **|* On Sat, Feb 12, 2022 at 7:04 PM Charles Mills wrote: > Nobody asked me, but I think David buried the most important point in the > middle. I have seen lots of TERRIBLE code written by "engineers from big > tech." That's not the key point. The key point is > > > the code is in the open and can be scrutinized by millions of people > > There are thousands (if not millions) of people, ranging from high school > code nerds to professional security consulting firms, hoping to make a name > for themselves by being the first to spot some vulnerability in Apache, the > Linux kernel, etc. That is an incredible free code inspection service. That > is the key to the security of open source (IMHO). > > You can't say that for most in-house software. You all know what corporate > culture is like. #1 your boss is not paying you to scrutinize other > peoples' code. And #2 if you spot some flaw in Bob's code you keep your > head down, because Bob is such a grump and does not take criticism well. > > And BTW this is coming from someone (me) who is basically a proprietary > software guy. I made my money writing conventionally-licensed proprietary > software. I have never contributed to an open source project. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of David Crayford > Sent: Friday, February 11, 2022 11:39 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem' > > On 12/2/22 4:56 am, Radoslaw Skorupka wrote: > > Well, who said it is not a problem??? > > I do. I maintain that proprietary code has just as many vulnerabilities > as open source. In fact, I would suggest that open source code is better > as the standard of engineer tends to be much higher than your average > Joe coder working for a bank. Also, the code is in the open and can be > scrutinized by millions of people. Who do you think develops open source > software? Is it hobbyists, enthusiasts, students, academics etc? The > truth is it's mostly engineers from big tech who are getting paid to > develop open source. Check out the authors of Apache Commons components > and it's IBMers >
Re: Coding IF statement in BPXBATCH shell
Some shops won't let you install free software, but for everybody else, that sounds like the reasonable thing to do/ -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of David Crayford [dcrayf...@gmail.com] Sent: Friday, February 11, 2022 9:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Coding IF statement in BPXBATCH shell My advice is not to use BPXBATCH, it's garbage! Run, don't walk, over to Dovetailed Softwares website and download their Co:Z toolkit. There is a batch utility called COZBATCH which allows you to run shell scripts from data sets, including inline JCL. Co:Z toolkit is free with optional paid support. https://secure-web.cisco.com/1QmaMysIy6vmV-VlgjMJ56Kb9ngXSViU3fshLvPElZvpjLhvwGE1TLJCXM3Lnph7b-KZkJBvlDTImYUCo6RTeTxbVdW_mN3f6s7w-hHqI5qbda8OGHb35p2ZWidf4OL8WeGLmP_fY3riY_5-x6eRvRS8kAzblNio4OxCAMBLKyWtA4zhgP4o0_5bxyyjorKK4Q5koCHDsW1dWtydDCiZILcjV1LwTk3eDDZ5WEJPP62t28PPtqYfMIOkb05cczMpivBIn6ACuuSrLu8-YrlnAtN3fTRE3sDU58s2cMh27xaY_PRqd26ZBzIpt-gY4SXyGe8wR2-tUBgBo7m87Nff4nsS4tFkYL2OLmsIClNwiJTENzyqNTVCE8RFxOgpoeVrSPLXqii7hKN9sC0nrpJBOv681dMU0wKgmmQiTNwVUb_oIEiLT17Azk83w7aEn_Wjs/https%3A%2F%2Fdovetail.com%2Fproducts%2Fcozbatch.html On 12/2/22 4:20 am, Billy Ashton wrote: > Hey everyone...I am having a tough time with a shell script I am > writing for my BPXBATCH step. All I want to do is run one of two > commands depending on a variable that is passed to the script. > > I have tried coding > if [ "$pet" == "DOG" ] ; then >commands... > else >other commands > fi > > and I have tried > if [[ ]] > if [ ... = ... ] > > all with the same result: > + DOG == DOG > DOG: /tmp/bpxshel.sh 48: FSUM7351 not found or > ..: (I think these are the two square brackets) or > .: (this is the one square bracket) > > So, how in the world do I code an IF statement in this BPXBATCH script > to do a simple string compare? > > Thank you and best regards, > Billy Ashton > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AMASPZAP DUMPT and program objects
Do you have code prior to your first CSECT? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Mario Bezzi [subscriptions.mario.be...@gmail.com] Sent: Saturday, February 12, 2022 12:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AMASPZAP DUMPT and program objects Hello, I struggle dumping a single CSECT within a program object of mine, using AMASPZAP. When I compile/bind the program, the binder says: *** M O D U L E M A P *** --- CLASS C_CODELENGTH = 16A0 ATTRIBUTES = CAT, LOAD, RMODE=ANY OFFSET =0 IN SEGMENT 001 ALIGN = DBLWORD --- SECTIONCLASS --- SOURCE OFFSET OFFSET NAMETYPELENGTH DDNAME SEQ MEMBER 0 $PRIV10CSECT 16A0 SYSLIN01 **NULL** 98 98 MYPROGRM LABEL Basing on the above, I think that the CSECT I am interested in is called $PRIV10. But if I try the following AMASPZAP statement: DUMPT MYMODULE $PRIV10 C_CODE The utility fails with RC 8 complaining that CSECT PRIV10 doesn't exist. Apparently, according to AMASPZAP the name is $PRIVATE CODE: AMA103I CSECT ABSENT - ALL CSECTS FOLLOW **RECORD LENGTH: 16A0 CLASS: C_CODE MEMBER NAME: MYMODULE CSECT NAME: $PRIVATE CODE I can't understand why AMASPZAP doesn't find the name shown by the binder (and confirmed by AMBLIST), and I don't know how to pass a name like " $PRIVATE CODE" to AMASPZAP. Help anyone? Thanks! mario -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Log4j hearing: 'Open source is not the problem'
On 13/2/22 1:03 am, Charles Mills wrote: Nobody asked me, but I think David buried the most important point in the middle. I have seen lots of TERRIBLE code written by "engineers from big tech." That's not the key point. The key point is the code is in the open and can be scrutinized by millions of people There are thousands (if not millions) of people, ranging from high school code nerds to professional security consulting firms, hoping to make a name for themselves by being the first to spot some vulnerability in Apache, the Linux kernel, etc. That is an incredible free code inspection service. That is the key to the security of open source (IMHO). It's not just about making a name themselves. It can be incredibly lucrative, with some companies willing to pay six figure sums on bug bounties https://www.bugcrowd.com/bug-bounty-list/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Log4j hearing: 'Open source is not the problem'
On 13/2/22 3:38 am, Itschak Mugzach wrote: If someone develops code that is vulnerable, only the organization he works for is (potentially) affected and the attacker does not have access to the code to play with. With open source, the code is accessible to everyone, and the problem hits millions of organizations. Are you sure the attacker doesn't have the code? A huge percentage of hacks come from insider threats. In the case of Solar Winds the attackers had the code and access to the build pipeline. The problem is not the vendor that makes use of open source, it is the fact that when the vulnerability is discovered, there is a time window until it is patched. And this is only if it was discovered by an ethical bug hunter. Log4Shell was discovered by a security researcher at Ali-Baba. Shellshock, Heartbleed, Meltdown etc were discovered by security researchers at Google. The difference with IBM or companies is that they don't disclose vulnerabilities. You probably think that's a good idea. In truth, if those vulnerabilities are there, especially on public facing networks there is just as much chance of a breach. This is why I am not impressed (but do appreciate the effort) by the tools David and his company uses. They do their best, They do find vulnerabilities. They are amazingly smart and can detect when you open a secure TCP connection and don't authenticate the hostname which could result in a MITM attack. That could be considered a 0-day. but it will not help in case of a zero date and the scale of an open source vulnerability is unlimited compared to a specific local code, bad as it is. What about the scale of a vendor product, such as IBM Data Risk Manager? A security research found 4 0-days and a sackful of other vulnerabilities and IBM refused to accept the report until the researcher went public. IBMs customers are enterprises such as banks and insurance companies. https://www.ibm.com/support/pages/security-bulletin-ibm-data-risk-manager-affected-multiple-vulnerabilities-4 The security researcher in this video https://www.youtube.com/watch?v=q8mFhDmBEIc claims to have found > 10 0-days on z/OS by exploiting buffer overflows in APF-authorized C programs by overlaying R14 with his exploit code. I can't verify the veracity of this claim but it seems plausible. It's the same technique used in the Logica breach. Last time you scoffed at that and asked if there had been a breach. So I guess that 0-days are acceptable unless there has been a breach, or did I misunderstand you? The funny thing is that although millions of eyes look at "open source" (as Chrles mentioned) they rarely find the vulnerability in a very common, highly used code (such as log4jv2 that has been here since 2012...). Saying that, open source is here to stay. Just don't wait for the vendor to report on vulnerabilities. Scan it yourself frequently. My two israeli shekels cents (Actually called "agorot"). ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Sat, Feb 12, 2022 at 7:04 PM Charles Mills wrote: Nobody asked me, but I think David buried the most important point in the middle. I have seen lots of TERRIBLE code written by "engineers from big tech." That's not the key point. The key point is the code is in the open and can be scrutinized by millions of people There are thousands (if not millions) of people, ranging from high school code nerds to professional security consulting firms, hoping to make a name for themselves by being the first to spot some vulnerability in Apache, the Linux kernel, etc. That is an incredible free code inspection service. That is the key to the security of open source (IMHO). You can't say that for most in-house software. You all know what corporate culture is like. #1 your boss is not paying you to scrutinize other peoples' code. And #2 if you spot some flaw in Bob's code you keep your head down, because Bob is such a grump and does not take criticism well. And BTW this is coming from someone (me) who is basically a proprietary software guy. I made my money writing conventionally-licensed proprietary software. I have never contributed to an open source project. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Friday, February 11, 2022 11:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem' On 12/2/22 4:56 am, Radoslaw Skorupka wrote: Well, who said it is not a problem??? I do. I maintain that proprietary code has just as many vulnerabilities as open source. In fact, I would suggest that open source code is better as the standard of
Re: Registers at entry to subtask (from ATTACH)
On 12/02/2022 23:14, Tony Harminc wrote: On Sat, 12 Feb 2022 at 13:54, Binyamin Dissen wrote: The manual (MVS Programming: Assembler Services Reference, Volume 1 (ABE-HSP)) states 2-12 Used as work registers by the system. but I am looking at some old functional code which seems to expect (several?) registers values at ATTACH time be passed as is to the subtask. Isn't the "Used as work registers by the system" talking about the registers the issuer sees after the ATTACH, rather than what the ATTACHed subtask sees? Hi: A few lines above: The contents of the GPRs on entry to the subtask ar otherwise: What is the issuers base register? You don't do a stm/lm around attach. /PS Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Registers at entry to subtask (from ATTACH)
On Sat, 12 Feb 2022 at 13:54, Binyamin Dissen wrote: > The manual (MVS Programming: Assembler Services Reference, Volume 1 > (ABE-HSP)) states > > 2-12 Used as work registers by the system. > > but I am looking at some old functional code which seems to expect > (several?) > registers values at ATTACH time be passed as is to the subtask. > Isn't the "Used as work registers by the system" talking about the registers the issuer sees after the ATTACH, rather than what the ATTACHed subtask sees? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Registers at entry to subtask (from ATTACH)
On Sat, 12 Feb 2022 12:53:41 -0800 Ed Jaffe wrote: :>On 2/12/2022 10:54 AM, Binyamin Dissen wrote: :>> but I am looking at some old functional code which seems to expect (several?) :>> registers values at ATTACH time be passed as is to the subtask. :>Perhaps it's expecting to be invoked via LINK(X) rather than ATTACH(X)? No. Explicitly sets up for ATTACH. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Registers at entry to subtask (from ATTACH)
On 2/12/2022 10:54 AM, Binyamin Dissen wrote: but I am looking at some old functional code which seems to expect (several?) registers values at ATTACH time be passed as is to the subtask. Perhaps it's expecting to be invoked via LINK(X) rather than ATTACH(X)? -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AMASPZAP DUMPT and program objects
> The utility fails with RC 8 complaining that CSECT PRIV10 doesn't exist. It doesn't. Private code is "PC" not a csect. The assembler can produce it if you don't start with a CSECT statement. >From an old MVT manual: GC26-3813-3_OS_VS_Linkage_Editor_and_Loader_May75.pdf Private code -- an unnamed control section. The external symbol dictionary entry specifies the length of the control section, and the origin. The name field contains blanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AMASPZAP DUMPT and program objects
Mario, where does the "MYMODULE" come from in your DUMPT command??? I don't see anything named that in your module map. According to your module map, your CSECT name is $PRIV10. If you DUMPT $PRIV10 $PRIV10 what happens? And in your AMBLIST what is your #1 CESD? Ramsey On Sat, Feb 12, 2022 at 11:45 AM Mario Bezzi < subscriptions.mario.be...@gmail.com> wrote: > Hello, I struggle dumping a single CSECT within a program object of mine, > using AMASPZAP. > > When I compile/bind the program, the binder says: > > *** M O D U L E M A P *** > > > --- > > CLASS C_CODELENGTH = 16A0 ATTRIBUTES = CAT, LOAD, > RMODE=ANY > OFFSET =0 IN SEGMENT 001 ALIGN = > DBLWORD > --- > > > SECTIONCLASS --- SOURCE > > OFFSET OFFSET NAMETYPELENGTH DDNAME SEQ > MEMBER > > 0 $PRIV10CSECT 16A0 SYSLIN01 > **NULL** > 98 98 MYPROGRM LABEL > > > Basing on the above, I think that the CSECT I am interested in is called > $PRIV10. > > But if I try the following AMASPZAP statement: > > DUMPT MYMODULE $PRIV10 C_CODE > > The utility fails with RC 8 complaining that CSECT PRIV10 doesn't > exist. > > Apparently, according to AMASPZAP the name is $PRIVATE CODE: > > AMA103I CSECT ABSENT - ALL CSECTS FOLLOW > > > **RECORD LENGTH: 16A0 CLASS: C_CODE MEMBER NAME: MYMODULE > > CSECT NAME: $PRIVATE > CODE > > I can't understand why AMASPZAP doesn't find the name shown by the binder > (and confirmed by AMBLIST), and I don't know how to pass a name like " > $PRIVATE CODE" to AMASPZAP. > > Help anyone? > > Thanks! > mario > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Registers at entry to subtask (from ATTACH)
Standard IBM z/OS calling convention. R13 Save Area, R14 return address, R15 address being called, R0 ?, R1 address to parameter list, R2-14 will be restored from R13 save area before BR14 to return to caller. https://www.ibm.com/docs/en/zos/2.3.0?topic=guide-linkage-conventions On Sat, Feb 12, 2022 at 6:54 PM Binyamin Dissen wrote: > > The manual (MVS Programming: Assembler Services Reference, Volume 1 (ABE-HSP)) > states > > 2-12 Used as work registers by the system. > > but I am looking at some old functional code which seems to expect (several?) > registers values at ATTACH time be passed as is to the subtask. > > Can someone enlighten me as to whether this is luck or an undocumented API. I > prefer to follow the old adage - if it ain't broke, don't fix it. > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Registers at entry to subtask (from ATTACH)
On Sat, Feb 12, 2022 at 11:17:52AM -0800, Charles Mills wrote: > I would guess that if it works but is not documented then who knows. There > is no guarantee that it does not stop working at some point in the future. I'd guess so too, but might break a lot of things if it was changed.. >From MVS (pre 31 bit) source from IEAVEAT0 - ATTACH - SVC 42 - IGC0004B */* P STORE REGISTERS INTO RBGRSAVE */ 00843000 * 0352 00844000 * RBGRSAVE=R4CURTCB->TCBRBP->RBGRSAVE;/* REGISTERS FOR ATTACHED 0352 00845000 * PROGRAM @YM00058*/ 00846000 L @08,TCBRBP(,R4CURTCB) 0352 00847000 MVC RBGRSAVE(64,R3WORKAD),RBGRSAVE(@08) 0352 00848000 So the new subtask gets a complete copy of the callers registers preset in the new SVRB register save area hung off the new TCB. The SVRB (running on the subtask) may (usually) change R13 in the SVRB register save are to point to a savearea. The subtask (SVRB) then does a branch entry to LINK. When this SVRB (LINK) exits these are the registers the resulting entry point from the attach will get. I'd suspect this was true in MVT too... I glanced at both an MVT and MVS Supervisor Services and Macros manual and don't see any specification of the registers being passed. Perhaps it was never documented as happening, but was coded that way for simplicity (what registers should a new task get?, Oh a copy) and tradition/compatiblity restricted any change. On the other hand, the description of LINK say that the linkage relationship is the same as that created by the BAL instruction. BAL doesn't change any but specified registers. Also way back before MVT (and subtasks), there are indications that ATTACH on some systems acted like link (MFT w/o subtasks?) in the old MVT manuals). > Binyamin Dissen: > The manual (MVS Programming: Assembler Services Reference, Volume 1 > (ABE-HSP)) states: > 2-12 Used as work registers by the system. > but I am looking at some old functional code which seems to expect > (several?) registers values at ATTACH time be passed as is to the subtask. > > Can someone enlighten me as to whether this is luck or an undocumented API. > I prefer to follow the old adage - if it ain't broke, don't fix it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Log4j hearing: 'Open source is not the problem'
I don't disagree. That is the flip side of the situation. I think what you wrote is true, and what I wrote is true. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Itschak Mugzach Sent: Saturday, February 12, 2022 11:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem' If someone develops code that is vulnerable, only the organization he works for is (potentially) affected and the attacker does not have access to the code to play with. With open source, the code is accessible to everyone, and the problem hits millions of organizations. The problem is not the vendor that makes use of open source, it is the fact that when the vulnerability is discovered, there is a time window until it is patched. And this is only if it was discovered by an ethical bug hunter. This is why I am not impressed (but do appreciate the effort) by the tools David and his company uses. They do their best, but it will not help in case of a zero date and the scale of an open source vulnerability is unlimited compared to a specific local code, bad as it is. The funny thing is that although millions of eyes look at "open source" (as Chrles mentioned) they rarely find the vulnerability in a very common, highly used code (such as log4jv2 that has been here since 2012...). Saying that, open source is here to stay. Just don't wait for the vendor to report on vulnerabilities. Scan it yourself frequently. My two israeli shekels cents (Actually called "agorot"). ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Sat, Feb 12, 2022 at 7:04 PM Charles Mills wrote: > Nobody asked me, but I think David buried the most important point in the > middle. I have seen lots of TERRIBLE code written by "engineers from big > tech." That's not the key point. The key point is > > > the code is in the open and can be scrutinized by millions of people > > There are thousands (if not millions) of people, ranging from high school > code nerds to professional security consulting firms, hoping to make a name > for themselves by being the first to spot some vulnerability in Apache, the > Linux kernel, etc. That is an incredible free code inspection service. That > is the key to the security of open source (IMHO). > > You can't say that for most in-house software. You all know what corporate > culture is like. #1 your boss is not paying you to scrutinize other > peoples' code. And #2 if you spot some flaw in Bob's code you keep your > head down, because Bob is such a grump and does not take criticism well. > > And BTW this is coming from someone (me) who is basically a proprietary > software guy. I made my money writing conventionally-licensed proprietary > software. I have never contributed to an open source project. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of David Crayford > Sent: Friday, February 11, 2022 11:39 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem' > > On 12/2/22 4:56 am, Radoslaw Skorupka wrote: > > Well, who said it is not a problem??? > > I do. I maintain that proprietary code has just as many vulnerabilities > as open source. In fact, I would suggest that open source code is better > as the standard of engineer tends to be much higher than your average > Joe coder working for a bank. Also, the code is in the open and can be > scrutinized by millions of people. Who do you think develops open source > software? Is it hobbyists, enthusiasts, students, academics etc? The > truth is it's mostly engineers from big tech who are getting paid to > develop open source. Check out the authors of Apache Commons components > and it's IBMers > https://github.com/apache/commons-bsf/blob/master/AUTHORS.txt. IBM were > the organization that stumped up the cash and resources to develop > Eclipse. A huge amount of Apache open source code is written and > maintained by IBM and it's used extensively in their products. > > > > It sounds like "open source is free of bugs". However I have never > > heard such claim. > > Nobody is saying that. That would be ignorant and stupid. All software > has bugs. > > > > More: companies use some kind of whitelisting open source software. In > > many cases software developer is not allowed to use "fancy, shining > > code" just because there some requirements are on met. It can be > > community, reputation, maturity, etc. > > How can a company whitelist open source software if they purchase a > product from a vendor or IBM that uses open source? As our products are > sold and marketed by IBM we provide
Re: Fwd: Log4j hearing: 'Open source is not the problem'
If someone develops code that is vulnerable, only the organization he works for is (potentially) affected and the attacker does not have access to the code to play with. With open source, the code is accessible to everyone, and the problem hits millions of organizations. The problem is not the vendor that makes use of open source, it is the fact that when the vulnerability is discovered, there is a time window until it is patched. And this is only if it was discovered by an ethical bug hunter. This is why I am not impressed (but do appreciate the effort) by the tools David and his company uses. They do their best, but it will not help in case of a zero date and the scale of an open source vulnerability is unlimited compared to a specific local code, bad as it is. The funny thing is that although millions of eyes look at "open source" (as Chrles mentioned) they rarely find the vulnerability in a very common, highly used code (such as log4jv2 that has been here since 2012...). Saying that, open source is here to stay. Just don't wait for the vendor to report on vulnerabilities. Scan it yourself frequently. My two israeli shekels cents (Actually called "agorot"). ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Sat, Feb 12, 2022 at 7:04 PM Charles Mills wrote: > Nobody asked me, but I think David buried the most important point in the > middle. I have seen lots of TERRIBLE code written by "engineers from big > tech." That's not the key point. The key point is > > > the code is in the open and can be scrutinized by millions of people > > There are thousands (if not millions) of people, ranging from high school > code nerds to professional security consulting firms, hoping to make a name > for themselves by being the first to spot some vulnerability in Apache, the > Linux kernel, etc. That is an incredible free code inspection service. That > is the key to the security of open source (IMHO). > > You can't say that for most in-house software. You all know what corporate > culture is like. #1 your boss is not paying you to scrutinize other > peoples' code. And #2 if you spot some flaw in Bob's code you keep your > head down, because Bob is such a grump and does not take criticism well. > > And BTW this is coming from someone (me) who is basically a proprietary > software guy. I made my money writing conventionally-licensed proprietary > software. I have never contributed to an open source project. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of David Crayford > Sent: Friday, February 11, 2022 11:39 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem' > > On 12/2/22 4:56 am, Radoslaw Skorupka wrote: > > Well, who said it is not a problem??? > > I do. I maintain that proprietary code has just as many vulnerabilities > as open source. In fact, I would suggest that open source code is better > as the standard of engineer tends to be much higher than your average > Joe coder working for a bank. Also, the code is in the open and can be > scrutinized by millions of people. Who do you think develops open source > software? Is it hobbyists, enthusiasts, students, academics etc? The > truth is it's mostly engineers from big tech who are getting paid to > develop open source. Check out the authors of Apache Commons components > and it's IBMers > https://github.com/apache/commons-bsf/blob/master/AUTHORS.txt. IBM were > the organization that stumped up the cash and resources to develop > Eclipse. A huge amount of Apache open source code is written and > maintained by IBM and it's used extensively in their products. > > > > It sounds like "open source is free of bugs". However I have never > > heard such claim. > > Nobody is saying that. That would be ignorant and stupid. All software > has bugs. > > > > More: companies use some kind of whitelisting open source software. In > > many cases software developer is not allowed to use "fancy, shining > > code" just because there some requirements are on met. It can be > > community, reputation, maturity, etc. > > How can a company whitelist open source software if they purchase a > product from a vendor or IBM that uses open source? As our products are > sold and marketed by IBM we provide them with a Certificate of > Originality which is a bill of materials that lists all of the open > source software (with versions) that we use. We scan all of our products > as part of our DevOps pipeline. There are three types of scans: > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to
Re: Registers at entry to subtask (from ATTACH)
I would guess that if it works but is not documented then who knows. There is no guarantee that it does not stop working at some point in the future. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: Saturday, February 12, 2022 10:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Registers at entry to subtask (from ATTACH) The manual (MVS Programming: Assembler Services Reference, Volume 1 (ABE-HSP)) states 2-12 Used as work registers by the system. but I am looking at some old functional code which seems to expect (several?) registers values at ATTACH time be passed as is to the subtask. Can someone enlighten me as to whether this is luck or an undocumented API. I prefer to follow the old adage - if it ain't broke, don't fix it. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Registers at entry to subtask (from ATTACH)
The manual (MVS Programming: Assembler Services Reference, Volume 1 (ABE-HSP)) states 2-12 Used as work registers by the system. but I am looking at some old functional code which seems to expect (several?) registers values at ATTACH time be passed as is to the subtask. Can someone enlighten me as to whether this is luck or an undocumented API. I prefer to follow the old adage - if it ain't broke, don't fix it. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AMASPZAP DUMPT and program objects
Hello, I struggle dumping a single CSECT within a program object of mine, using AMASPZAP. When I compile/bind the program, the binder says: *** M O D U L E M A P *** --- CLASS C_CODELENGTH = 16A0 ATTRIBUTES = CAT, LOAD, RMODE=ANY OFFSET =0 IN SEGMENT 001 ALIGN = DBLWORD --- SECTIONCLASS --- SOURCE OFFSET OFFSET NAMETYPELENGTH DDNAME SEQ MEMBER 0 $PRIV10CSECT 16A0 SYSLIN01 **NULL** 98 98 MYPROGRM LABEL Basing on the above, I think that the CSECT I am interested in is called $PRIV10. But if I try the following AMASPZAP statement: DUMPT MYMODULE $PRIV10 C_CODE The utility fails with RC 8 complaining that CSECT PRIV10 doesn't exist. Apparently, according to AMASPZAP the name is $PRIVATE CODE: AMA103I CSECT ABSENT - ALL CSECTS FOLLOW **RECORD LENGTH: 16A0 CLASS: C_CODE MEMBER NAME: MYMODULE CSECT NAME: $PRIVATE CODE I can't understand why AMASPZAP doesn't find the name shown by the binder (and confirmed by AMBLIST), and I don't know how to pass a name like " $PRIVATE CODE" to AMASPZAP. Help anyone? Thanks! mario -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Log4j hearing: 'Open source is not the problem'
Nobody asked me, but I think David buried the most important point in the middle. I have seen lots of TERRIBLE code written by "engineers from big tech." That's not the key point. The key point is > the code is in the open and can be scrutinized by millions of people There are thousands (if not millions) of people, ranging from high school code nerds to professional security consulting firms, hoping to make a name for themselves by being the first to spot some vulnerability in Apache, the Linux kernel, etc. That is an incredible free code inspection service. That is the key to the security of open source (IMHO). You can't say that for most in-house software. You all know what corporate culture is like. #1 your boss is not paying you to scrutinize other peoples' code. And #2 if you spot some flaw in Bob's code you keep your head down, because Bob is such a grump and does not take criticism well. And BTW this is coming from someone (me) who is basically a proprietary software guy. I made my money writing conventionally-licensed proprietary software. I have never contributed to an open source project. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Friday, February 11, 2022 11:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem' On 12/2/22 4:56 am, Radoslaw Skorupka wrote: > Well, who said it is not a problem??? I do. I maintain that proprietary code has just as many vulnerabilities as open source. In fact, I would suggest that open source code is better as the standard of engineer tends to be much higher than your average Joe coder working for a bank. Also, the code is in the open and can be scrutinized by millions of people. Who do you think develops open source software? Is it hobbyists, enthusiasts, students, academics etc? The truth is it's mostly engineers from big tech who are getting paid to develop open source. Check out the authors of Apache Commons components and it's IBMers https://github.com/apache/commons-bsf/blob/master/AUTHORS.txt. IBM were the organization that stumped up the cash and resources to develop Eclipse. A huge amount of Apache open source code is written and maintained by IBM and it's used extensively in their products. > It sounds like "open source is free of bugs". However I have never > heard such claim. Nobody is saying that. That would be ignorant and stupid. All software has bugs. > More: companies use some kind of whitelisting open source software. In > many cases software developer is not allowed to use "fancy, shining > code" just because there some requirements are on met. It can be > community, reputation, maturity, etc. How can a company whitelist open source software if they purchase a product from a vendor or IBM that uses open source? As our products are sold and marketed by IBM we provide them with a Certificate of Originality which is a bill of materials that lists all of the open source software (with versions) that we use. We scan all of our products as part of our DevOps pipeline. There are three types of scans: -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
