date:20230829

I've been told by IBMer's not to talk about such things, so I need to 
drop out now.


On 8/29/2023 10:05 PM, Grant Taylor wrote:

On 8/29/23 9:49 PM, Tom Brennan wrote:
Just to be clear, I'm not talking about doing anything to the HMC that 
isn't sanctioned by IBM.


I assumed as much.


And pardon me if you already know this, but HMC's are really locked down.


Well ... IBM took a reasonable pass at making the older HMCs that I've 
worked on recently take a little bit of effort to get in and do things.



For example, no command line access even when standing at the machine.


I was poking around on $WORK's older HMCs three weeks ago and, as a well 
seasoned Linux administrator, found it not quite trivial to get into the 
underlying Linux OS and do whatever I wanted to.


I'll just say that if you're familiar with how Linux boots and what 
different things do, it's one transient non-persistent edit away from 
dropping you at a root shell prompt where you can make any change that 
you want to on the system.


Obviously this is not sanctioned by IBM.

I'm dealing with hardware that is so far out of support that it's not 
even funny.


But under the hood, it's Linux that looks STRIKINGLY like a heavily 
modified Red Hat / CentOS 6.x generation with all visible branding removed.


I've since had someone tell me that there is a method to get a normal 
shell on an HMC.  I speculate it's reminiscent of padmin on VIOS where 
you log in for vtmenu and then do something not well documented.


A quick web search reveals that there is a root account with a less well 
known password.


When you're willing to do unsupported things on hardware that isn't 
capable of being supported, you can do some amazing things if you want 
to.  }:-)


PSA, the HMC that I looked at used file system labels to identify which 
file system was to be mounted where.  So ... which file system with the 
label of "/" is mounted when there are two of them?  }:-)






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert

Just to be clear, I'm not talking about doing anything to the HMC that 
isn't sanctioned by IBM.  And pardon me if you already know this, but 
HMC's are really locked down.  For example, no command line access even 
when standing at the machine.


On 8/29/2023 6:30 PM, Grant Taylor wrote:

On 8/29/23 6:39 PM, Tom Brennan wrote:
It's those last couple of steps that I assume would need to be done 
manually on an HMC via GUI.


I have no idea if IBM offers a supported solution or not.

I would waver that there are some unsupported solutions that IBM would 
wag a finger at you for doing.  But who's going to do that on a piece of 
equipment supporting a mainframe?


The three things that come to mind in the order of most benign to most 
radical are:


  - Script interactions across the HTTP(S) ports pretending to be a user 
walking through the motions with the necessary GET / POST / etc. method 
calls.


  - Enable -- what I assume is unsupported SSH access to an HMC and 
remotely run commands to manage certificates.


  - Really throw caution to the wind and install an ACME client on the 
HMC and get it some sort of Internet connectivity (likely via proxy).


The first is probably the only thing that IBM would say doesn't 
invalidate support / warranty.



Or maybe IBM has addressed this and provides an API or similar?


I hope so.  But I'm not holding my breath.

I never asked, possibly because every HMC I've ever touched, whether 
mainframe or peripheral, came up with a self-signed key warning.


Ya  Pardon while I go over into a corner and cry.

But in their defense, most are only accessible in the datacenter or 
behind a difficult-to-access jump box.


I've had the broken TLS cert cause problems, particularly when Java gets 
involved.


I've found it far better to make the client system be as happy with the 
cert as possible usually yields the best / most long term results.






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert


On 8/29/23 6:39 PM, Tom Brennan wrote:
It's those last couple of steps that I assume would need to be done 
manually on an HMC via GUI.


I have no idea if IBM offers a supported solution or not.

I would waver that there are some unsupported solutions that IBM would 
wag a finger at you for doing.  But who's going to do that on a piece of 
equipment supporting a mainframe?


The three things that come to mind in the order of most benign to most 
radical are:


 - Script interactions across the HTTP(S) ports pretending to be a user 
walking through the motions with the necessary GET / POST / etc. method 
calls.


 - Enable -- what I assume is unsupported SSH access to an HMC and 
remotely run commands to manage certificates.


 - Really throw caution to the wind and install an ACME client on the 
HMC and get it some sort of Internet connectivity (likely via proxy).


The first is probably the only thing that IBM would say doesn't 
invalidate support / warranty.



Or maybe IBM has addressed this and provides an API or similar?


I hope so.  But I'm not holding my breath.

I never asked, possibly because every HMC I've ever touched, whether 
mainframe or peripheral, came up with a self-signed key warning.


Ya  Pardon while I go over into a corner and cry.

But in their defense, most are only accessible in the datacenter or 
behind a difficult-to-access jump box.


I've had the broken TLS cert cause problems, particularly when Java gets 
involved.


I've found it far better to make the client system be as happy with the 
cert as possible usually yields the best / most long term results.




--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: it's all about trust [was: Firefox and HMC self-signed cert]


On 8/29/23 6:10 PM, Charles Mills wrote:
Not browser publishers and CAs; ONE particular browser publisher! The 
CAs were on the other side of this one.


Apple may have been the first to the microphone, but I know that other 
browser manufacturers were writing similar speeches.


About the only thing I can say in their defense is that the revocation 
system is broken.


On a technical level, I don't know that I agree with that.

I believe that there were things in place that someone that wanted to 
could have checked revocation.


Sadly, too many people -- probably the vast majority -- didn't do so for 
one reason or another.


This might even partially be the tyranny of the default.  I think most, 
if not all, browsers opted to forego much of the revocation check in the 
name of performance and page load time.


Most people didn't know better, and most of those that did didn't know 
enough or weren't motivated to change it.




--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert

I looked at letsencrypt and zerossl and decided on zero because I liked 
the support, the 1 year certs, and their API.  The API supports ACME but 
hey, I call myself a programmer so I rolled my own.  I use their email 
authentication through an automated method I created, but they do have 
DNS record authentication too.  And of course a script runs on my server 
to put the new certs in place and reload httpd.


It's those last couple of steps that I assume would need to be done 
manually on an HMC via GUI.  Or maybe IBM has addressed this and 
provides an API or similar?  I never asked, possibly because every HMC 
I've ever touched, whether mainframe or peripheral, came up with a 
self-signed key warning.  But in their defense, most are only accessible 
in the datacenter or behind a difficult-to-access jump box.


On 8/29/2023 12:38 PM, Grant Taylor wrote:
Let's Encrypt supports multiple authentication methods.  One of which is 
DNS based and can be used to authenticate an FQDN that can be resolved 
via the public DNS tree.


This means that you can use an ACME client which supports DNS 
authentication -- there are multiple -- to request a certificate for an 
FQDN that is not accessible from the Internet.  Ergo it is possible to 
get a certificate that is signed by Let's Encrypt, a well known CA, 
which you can then install in your HMC.


However, this will become labor intensive as you will need to do this 
roughly every 90 days.


You could also play other games wherein you have an Internet accessible 
web server running a fully automated ACME client.  Have it act as a 
proxy of sorts to provide a certificate and key for use on the HMC.  -- 
Is this advisable, nope, not at all.  Would it work, I think so.  I'd 
bet a fast food meal that it would work.


Aside:  What is a "real CA" other than one that has their root 
certificate(s) installed in clients?  }:-)






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: it's all about trust [was: Firefox and HMC self-signed cert]

Not browser publishers and CAs; ONE particular browser publisher! The CAs were 
on the other side of this one.

https://www.zdnet.com/article/apple-strong-arms-entire-ca-industry-into-one-year-certificate-lifespans/

About the only thing I can say in their defense is that the revocation system 
is broken.

Charles

On Tue, 29 Aug 2023 17:58:50 -0500, Grant Taylor  
wrote:

>On 8/29/23 2:49 PM, Rick Troth wrote:
>> When they say "certificates shall only last a year", there's little we
>> can do about it, whether they're right or wrong.
>
>The browser manufacturers have power in the browser ecosystem and the
>ecosystems that pander to them (*cough* CAs *couth*).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert


On 8/29/23 3:38 PM, Charles Mills wrote:

Not true for a CA root.

Thought experiment: if DigiCert were to misplace their root private 
key, would you now be unable to log into amazon.com? (There would be 
very disruptive long-term implications, but things would continue to 
work in the medium term even without the private key.)


The private key is necessary to be able to*issue*  certificates. Tom's 
scenario, while it may have some other shortcomings, would work 
exactly as Tom supposes.


Fair enough.

I was thinking about a web / email / etc. server not being able to 
provide encrypted connections without the key being accessible.




Grant. . . .

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: securing the trust store [was: Firefox and HMC self-signed cert]


On 8/29/23 3:16 PM, Rick Troth wrote:
And making it harder (more expensive) for the attacker (relative to his 
ROI).


Some of it is also about making it more noisy and thus likely easier to 
detect when something inappropriate is going on.


I've heard that some Chinese emperors purposely had floors designed 
expressly so that they squeaked when you walked on them specifically so 
that they could more easily hear when attackers were coming.


Door chimes can be annoying, but they do serve a purpose, especially 
when they are unobtrusive.


YubiKey is part of that because it can become a new single point of 
failure.


Ya.

I really hate the idea of needing to rely on an external party.  Even 
more so when that external party becomes a SPOF.


I want to host things myself.

Thankfully, YubiKey, as I've mentioned them, is fully self hosted and 
doesn't rely on anything external beyond initial utility installation.


In all of this, one of the biggest overlooked thingies is new points of 
failure. We forget that locking out bad guys kinda sucks for US when WE 
suddenly look like one of the bad guys. (Machines cannot tell the 
difference.)


#truth


This is not a slam on YubiKey.


Nope.  It's an unpleasant fact about the situation.

It's an observation that our systems need failover factors and most 
developers still don't think about that.


Agreed.



--
Grant. . . .

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: it's all about trust [was: Firefox and HMC self-signed cert]


On 8/29/23 2:49 PM, Rick Troth wrote:
When they say "certificates shall only last a year", there's little we 
can do about it, whether they're right or wrong.


The browser manufacturers have power in the browser ecosystem and the 
ecosystems that pander to them (*cough* CAs *couth*).


But browser manufacturers have exceedingly little say in how I configure 
TLS on my email server.


Crypto alone doesn't make your systems secure. Faster refresh does not 
improve your posture all by itself.


I believe the faster refresh is all about shortening the exposure window.

If the CA is breached, then the issued certs are just as invalid on day 
one as they are on day 398. In that case, what has the shortened 
lifetime bought us?


Recent history (last 10-20 years) has demonstrated that not enough 
people update their system (think software updates, not hardware 
upgrades) nearly as often as they should.


As such, these people don't get the updates wherein the compromised root 
cert / public key therein is distrusted / banned.


So, many in the industry are responding by shortening the natural 
lifetime of such certificates.


Shortening the lifetime of a certificate does shorten the possible 
amount of time when that given compromised certificate can be used 
against people that updated to learn to not trust it.


This is not to say that fast cycle advocates are idiots. Most of them 
are prolly way smarter than I am. It's just that they stopped short of 
solving the real problem. (And some of them are opportunists: if they 
can get you to buy their wares in a panic, then they've made a pretty 
penny and can retire sooner.)


There have been at least three major attempts to convey that 
certificates should be distrusted before their expiration:


 - Certificate Revocation Lists (CRL)  --  Client checks remote data
 - Online Certificate Status Protocol (OCSP)  --  Client checks remote data
 - OCSP Stapling  --  Server fetches remote data, hands it to the 
client, client check verifiable data it was handed.


Sadly, all three of these have left more exposure than people are 
comfortable with.


So, rather than trying to deal with early distrust of certificates, the 
Certificate Authority / Browser Forum (CA/B Forum) has decided to tackle 
things differently by shortening the possible exposure window.



I almost regret this note because I haven't really offered a solution.


Lots of really smart people have put forth multiple solutions.  Some 
were widely deployed.  Most were not as successful as many had hoped.


Some say "security is a process". I hate that slogan, but it's kinda 
true. I DO say that we're foolish to try and shrink-wrap security into 
store-shelf remedies. There's no alternative to educating the staff.




--
Grant. . . .

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: On-Prem to Cloud Mainframe Migration Experiences

2023-08-29 Thread David Elliot

Not seeing much in the way of responses to your question, Lance. Could be
you are asking an impossible question. like ' Is there a god?' or 'is
global warming real?' Were you expecting an outpouring of enthusiasm for
this  nebulous technology? What were your experiences? Did you get what you
were promised or what you deserved?

On Mon, Aug 21, 2023 at 11:23 AM Lance D. Jackson <
ljack...@pandrueassociates.com> wrote:

> List,
>
> Has anyone had experience (good or bad) with migrating their mainframe Db2
> workload from on-prem to the cloud?
>
> --
> 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: Firefox and HMC self-signed cert

> The certificate is only good if you have the associated key.

> If you don't have the key, the certificate isn't worth the disk space 
> that it takes up.

Not true for a CA root. 

Thought experiment: if DigiCert were to misplace their root private key, would 
you now be unable to log into amazon.com? (There would be very disruptive 
long-term implications, but things would continue to work in the medium term 
even without the private key.)

The private key is necessary to be able to *issue* certificates. Tom's 
scenario, while it may have some other shortcomings, would work exactly as Tom 
supposes.

Charles-

On Tue, 29 Aug 2023 14:40:19 -0500, Grant Taylor  
wrote:

>On 8/29/23 2:32 PM, Tom Brennan wrote:
>> Sorry - not clear.  What I meant was that in this case I ran openssl on
>> Linux, not on Windows as Charles thought.
>
>Fair enough.
>
>> What if I deleted the CA key file after creating the one web cert I
>> needed?  That would probably solve the security issue Charles mentioned,
>> but then I would need a long-term web cert, maybe not possible anymore
>> with the browser cap you mentioned.
>
>That's not going to work the way you want.
>
>The certificate is only good if you have the associated key.
>
>If you don't have the key, the certificate isn't worth the disk space
>that it takes up.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

securing the trust store [was: Firefox and HMC self-signed cert]

2023-08-29 Thread Rick Troth


I changed the subject.
Also, while this fork is not specifically a mainframe topic, it's really 
important, and most of us will have it thrown in our face, even as 
mainframers.



On 8/29/23 15:29, Grant Taylor wrote:

On 8/29/23 10:46 AM, Charles Mills wrote:
Don't want to get into one of the peeing contests that have become 
all too common here.


Neither do I.

I do want to have a polite and professional discussion about what 
things are capable of.


Hopefully I'll learn things from you -- I usually do.  :-D  Maybe, if 
I'm very lucky, I'll teach you something.  :-)



Same here.
And I confess to being contrarian.
I relish butting heads with Alan Altmark over things like MAC vs DAC. 
(It's not for the head butt, which hurts, but for sake of digging down 
to the foundation.)





Let me just say that never mind any enterprise PKI CA constraints, I 
think Tom was talking about OpenSSL on a PC.


Why elide what is a very germane safety component?  That being 
restricting what a given CA is allowed to sign?


OpenSSL stores private keys -- private keys -- in a pretty accessible 
format.



The *format* really doesn't bother me, other than w/r/t processability.

It's true that complicated access methods will slow down an attacker. 
Problem is they also slow down legitimate work, and that effect is 
multiplied. (Attacker only needs to succeed once; the good guy must 
succeed time after time after time.)





OpenSSL /can/ store the private key in a file.

OpenSSL /can/ /also/ depend something like a YubiKey to store the 
private key.


If I can get into Tom's PC -- perhaps while he is at lunch, or with a 
clever phish -- and get that private key, then I can generate server 
certificates for any site in the world and Tom's associates will 
trust those certificates.


Maybe, maybe not.  It will depend if the private key is password 
protected or not.  If there is a password, it won't be a walk up and 
sign without knowing the password.


Not criticizing Tom or his processes here. Just pointing out to 
readers that there are some significant risks in general to the 
approach of "oh, I will just create an ad hoc CA and have my users 
trust it."



I agree it's not effective for everyone to run their own CA. But for 
purpose of education, a "live" in-house CA comes in handy.





I agree that there are risks.

It's a question of which is more risky long term:

1)  training users to click past certificate warnings
2)  the potential for someone to abuse Tom's CA which is constrained 
to the enterprise domain name and has a hardware token (YubiKey)?


It's all about the lesser of the evils.



YES

And making it harder (more expensive) for the attacker (relative to his 
ROI).





Trusting a CA is implicitly trusting everything that anyone does with 
its root private key.


That's where a constrained CA / root key comes into play.

Trusting the key to sign *. is very bad.

Trusting the key to sign *.example.com, not so much so. Especially if 
example.com is a private internal domain not possible to use in the 
real world.


Yes, it is no different in some ways than trusting DigiCert. The 
difference is that DigiCert has very rigorous protocols for 
protecting its root private keys. OpenSSL does not.


It's possible for Tom, et al., to make reasonable approximations of 
what DigiCert, et al., are doing.  If Tom's company wanted to, they 
can purchase a more professional Hardware Security Module (HSM) that 
can get quite close to what more professional entities do if they so 
choose.


But using something like a YubiKey to hold the root key of for an 
enterprise CA constrained to the internal domain is probably 
reasonably safe.  Especially if said YubiKey is used to sign an 
intermediate certificatte -- like the big kids do -- and storing said 
YubiKey disconnected, in a safe in between uses once a quarter.  
Especially if the system that does the signing is disconnected from 
the network.



I've been simmering a blog post about MFA since GitHub pressed the issue 
recently.
YubiKey is part of that because it can become a new single point of 
failure.
In all of this, one of the biggest overlooked thingies is new points of 
failure. We forget that locking out bad guys kinda sucks for US when WE 
suddenly look like one of the bad guys. (Machines cannot tell the 
difference.)


This is not a slam on YubiKey.
It's an observation that our systems need failover factors and most 
developers still don't think about that.





I think it's well within reason for individuals, and especially 
businesses to fairly safely have an (Enterprise) CA that is 
constrained to their organization.




Grant. . . .

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- R; <><

--
For IBM-MAIN subscribe / signoff / a

it's all about trust [was: Firefox and HMC self-signed cert]

2023-08-29 Thread Rick Troth


On 8/29/23 11:24, Grant Taylor wrote:

On 8/29/23 10:07 AM, Tom Brennan wrote:

And you can specify an expiration far in the future.


Remember, some web browsers are capping the limit on the lifetime of 
certificates they will work with.



The browser producers have the advantage over the rest of us because 
they affect such a large percentage of consumer clients.
When they say "certificates shall only last a year", there's little we 
can do about it, whether they're right or wrong.


They're wrong. They're at least "imperfect" in a conversation where 
perfection is the goal. So ... they're wrong.
Shortening the viability lifetime brings hidden costs that the browser 
makers either don't see or don't care about. (Covering their own arse. 
They have no incentive to cover yours.)
By contrast, physical indicia (credit cards, driver licenses, and other 
IDs that some of us cannot speak about) have lifetimes/expirations five 
years out.
Shorter lifetimes for web site certs generate business for CAs and make 
work for web site admins. The latter is increasingly error prone. But 
higher frequency replacement is considered "more secure". It's like 
killing the dogs and cats during the plague, when they were the natural 
enemies of the true carriers of the disease.


We protect the wrong things. (And we kill the wrong critters.) We also 
sprinkle such ideas as faster cert replacement and technology like 
cryptography as if it's fairy dust magically making things better. 
Crypto alone doesn't make your systems secure. Faster refresh does not 
improve your posture all by itself.


Charles suggested snagging the private key from the CA. That's exactly 
the kind of attack a smart adversary would take. It's way less expensive 
and more likely to result in exfiltration of cleartext.
If the CA is breached, then the issued certs are just as invalid on day 
one as they are on day 398. In that case, what has the shortened 
lifetime bought us?


This is not to say that fast cycle advocates are idiots. Most of them 
are prolly way smarter than I am. It's just that they stopped short of 
solving the real problem. (And some of them are opportunists: if they 
can get you to buy their wares in a panic, then they've made a pretty 
penny and can retire sooner.)


I almost regret this note because I haven't really offered a solution. 
Some say "security is a process". I hate that slogan, but it's kinda 
true. I DO say that we're foolish to try and shrink-wrap security into 
store-shelf remedies. There's no alternative to educating the staff.



-- R; <><

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert


On 8/29/23 2:32 PM, Tom Brennan wrote:
Sorry - not clear.  What I meant was that in this case I ran openssl on 
Linux, not on Windows as Charles thought.


Fair enough.

What if I deleted the CA key file after creating the one web cert I 
needed?  That would probably solve the security issue Charles mentioned, 
but then I would need a long-term web cert, maybe not possible anymore 
with the browser cap you mentioned.


That's not going to work the way you want.

The certificate is only good if you have the associated key.

If you don't have the key, the certificate isn't worth the disk space 
that it takes up.




Grant. . . .

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert


On 8/29/23 12:58 PM, Charles Mills wrote:
https://letsencrypt.org/  provides free automated "real CA" 
certificates. IIRC they only support requests made using the "ACME" 
automation protocol. Will the HMC support that?


Let's Encrypt supports multiple authentication methods.  One of which is 
DNS based and can be used to authenticate an FQDN that can be resolved 
via the public DNS tree.


This means that you can use an ACME client which supports DNS 
authentication -- there are multiple -- to request a certificate for an 
FQDN that is not accessible from the Internet.  Ergo it is possible to 
get a certificate that is signed by Let's Encrypt, a well known CA, 
which you can then install in your HMC.


However, this will become labor intensive as you will need to do this 
roughly every 90 days.


You could also play other games wherein you have an Internet accessible 
web server running a fully automated ACME client.  Have it act as a 
proxy of sorts to provide a certificate and key for use on the HMC.  -- 
Is this advisable, nope, not at all.  Would it work, I think so.  I'd 
bet a fast food meal that it would work.


Aside:  What is a "real CA" other than one that has their root 
certificate(s) installed in clients?  }:-)




--
Grant. . . .

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert


On 8/29/23 12:13 PM, Tom Brennan wrote:
I trust your certificate experience.  But let's get back to the HMC 
issue for a second.  So the only secure way to get rid of the Firefox 
warnings and red messages is to use an externally-signed certificate 
(paid for), and I think that means a manual process to update the HMC 
web cert/key every year.  Or is there an easier way?


Can you bust the HMC down to use unencrypted HTTP instead of encrypted 
HTTPS?  --  It would get rid of the red bar.  }:-)


If you want encrypted HTTPS, you will need a certificate that the client 
you are using trusts.


Where that certificate comes from is up to you / your organization.



--
Grant. . . .

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert

Sorry - not clear.  What I meant was that in this case I ran openssl on 
Linux, not on Windows as Charles thought.


What if I deleted the CA key file after creating the one web cert I 
needed?  That would probably solve the security issue Charles mentioned, 
but then I would need a long-term web cert, maybe not possible anymore 
with the browser cap you mentioned.


On 8/29/2023 12:08 PM, Grant Taylor wrote:

On 8/29/23 12:07 PM, Tom Brennan wrote:

All true I think, except it's openssl on Linux not Windows.


OpenSSL is multi-platform and can run on Windows a myriad of ways, if 
not natively.


Aside:  The Enterprise CA can also be done with things other than OpenSSL.





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert


On 8/29/23 10:46 AM, Charles Mills wrote:
Don't want to get into one of the peeing contests that have become 
all too common here.


Neither do I.

I do want to have a polite and professional discussion about what things 
are capable of.


Hopefully I'll learn things from you -- I usually do.  :-D  Maybe, if 
I'm very lucky, I'll teach you something.  :-)


Let me just say that never mind any enterprise PKI CA constraints, 
I think Tom was talking about OpenSSL on a PC.


Why elide what is a very germane safety component?  That being 
restricting what a given CA is allowed to sign?


OpenSSL stores private keys -- private keys -- in a pretty accessible 
format.


OpenSSL /can/ store the private key in a file.

OpenSSL /can/ /also/ depend something like a YubiKey to store the 
private key.


If I can get into Tom's PC -- perhaps while he is at lunch, or with a 
clever phish -- and get that private key, then I can generate server 
certificates for any site in the world and Tom's associates will 
trust those certificates.


Maybe, maybe not.  It will depend if the private key is password 
protected or not.  If there is a password, it won't be a walk up and 
sign without knowing the password.


Not criticizing Tom or his processes here. Just pointing out to 
readers that there are some significant risks in general to the 
approach of "oh, I will just create an ad hoc CA and have my users 
trust it."


I agree that there are risks.

It's a question of which is more risky long term:

1)  training users to click past certificate warnings
2)  the potential for someone to abuse Tom's CA which is constrained to 
the enterprise domain name and has a hardware token (YubiKey)?


It's all about the lesser of the evils.

Trusting a CA is implicitly trusting everything that anyone does with 
its root private key.


That's where a constrained CA / root key comes into play.

Trusting the key to sign *. is very bad.

Trusting the key to sign *.example.com, not so much so.  Especially if 
example.com is a private internal domain not possible to use in the real 
world.


Yes, it is no different in some ways than trusting DigiCert. The 
difference is that DigiCert has very rigorous protocols for protecting 
its root private keys. OpenSSL does not.


It's possible for Tom, et al., to make reasonable approximations of what 
DigiCert, et al., are doing.  If Tom's company wanted to, they can 
purchase a more professional Hardware Security Module (HSM) that can get 
quite close to what more professional entities do if they so choose.


But using something like a YubiKey to hold the root key of for an 
enterprise CA constrained to the internal domain is probably reasonably 
safe.  Especially if said YubiKey is used to sign an intermediate 
certificatte -- like the big kids do -- and storing said YubiKey 
disconnected, in a safe in between uses once a quarter.  Especially if 
the system that does the signing is disconnected from the network.


I think it's well within reason for individuals, and especially 
businesses to fairly safely have an (Enterprise) CA that is constrained 
to their organization.




Grant. . . .

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert


On 8/29/23 12:07 PM, Tom Brennan wrote:

All true I think, except it's openssl on Linux not Windows.


OpenSSL is multi-platform and can run on Windows a myriad of ways, if 
not natively.


Aside:  The Enterprise CA can also be done with things other than OpenSSL.



--
Grant. . . .

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Switching between SMT-1 and SMT-2

2023-08-29 Thread Mark Jacobs

Create/update your IEAOPTxx member to set MT_ZIIP_MODE=1 then SET OPT=xx to 
activate it.

Mark Jacobs 

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com


--- Original Message ---
On Tuesday, August 29th, 2023 at 2:22 PM, Jim Elliott  
wrote:


> I know you can do this, but I can't seem to find the right command in z/OS.
> Any help much appreciated. In z/VM I use SET MULTITHREAD to do this.
> 
> Jim Elliott
> Senior IT Consultant - GlassHouse Systems Inc.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAINCreate

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Threading (was: LISTSERV Trivia: Deleting drafts?)

2023-08-29 Thread Paul Gilmartin

On Tue, 29 Aug 2023 14:05:59 -0400, Phil Smith III  wrote:

>...
>https://developers.google.com/gmail/api/guides/threads
>...
>1. The requested threadId must be specified on the Message or 
>Draft.Message you supply with your request.
>2. The References and In-Reply-To headers must be set in compliance with 
>the RFC 2822   standard.
>3. The Subject headers must match.
>
> 
FSVO "matdh"?
Is noise such as "Re:", "AW:", "EXTERNAL", ... to be ignored a noise?
Security mavens here have supported "EXtERNAL", but it's bad if it breaks 
threading.

>So it seems the www interface (which I was unaware still existed; link?) must 
>not be meeting one or both of the first two requirements.
>
It fails to supply "In-Reply-To".

Do you think Darren could submit a Service Request?
List-Owner:   ?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Switching between SMT-1 and SMT-2

2023-08-29 Thread Jim Elliott

I know you can do this, but I can't seem to find the right command in z/OS.
Any help much appreciated. In z/VM I use SET MULTITHREAD to do this.

Jim Elliott
Senior IT Consultant - GlassHouse Systems Inc.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Threading (was: LISTSERV Trivia: Deleting drafts?)

2023-08-29 Thread Phil Smith III

Kirk Wolf asked Gil:
>Not your question, but is the WWW interface why all of your posts
>break into a new thread? ( at least in a few mailers that I have
>used).
and Gil mentioned header:
> References: <7241413257405975.wa.paulgboulderaol@listserv.ua.edu 
>  >

Gmail threading is discussed here:
https://developers.google.com/gmail/api/guides/threads
which says, in part:

In order to be part of a thread, a message or draft must meet the following 
criteria:

1.  The requested threadId must be specified on the Message or 
Draft.Message you supply with your request.
2.  The References and In-Reply-To headers must be set in compliance with 
the RFC 2822   standard.
3.  The Subject headers must match.


If you get the list digested, for example, clipping out a note and replying to 
it creates a new thread, at least in Gmail. This is how I get the list, so I 
cause that a lot, I'm afraid.

Whether it's a Gmail bug/feechur or not is arguable; if I were Gmail, I'd make 
it configurable to JUST base it on Subject, but we know that way 
(configurability) lies madness. OTOH it's pretty dumb to look at Gmail and see 
a half-dozen "threads" with the same subject!

So it seems the www interface (which I was unaware still existed; link?) must 
not be meeting one or both of the first two requirements.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert

>(paid for), and I think that means a manual process to update the HMC
>web cert/key every year.  Or is there an easier way?

I don't know. I am more of a certificate theory expert than a z certificate 
practice expert.

It is true that no commercial CA issues certificates good for much more than 
one year. (Their Web sites may talk about their two-year and five-year plans, 
but trust me, the certificates are only good for 13 months.)

It does sound like a PITA.

https://letsencrypt.org/ provides free automated "real CA" certificates. IIRC 
they only support requests made using the "ACME" automation protocol. Will the 
HMC support that?

Charles

On Tue, 29 Aug 2023 10:13:59 -0700, Tom Brennan  
wrote:

>I trust your certificate experience.  But let's get back to the HMC
>issue for a second.  So the only secure way to get rid of the Firefox
>warnings and red messages is to use an externally-signed certificate
>(paid for), and I think that means a manual process to update the HMC
>web cert/key every year.  Or is there an easier way?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert

I trust your certificate experience.  But let's get back to the HMC 
issue for a second.  So the only secure way to get rid of the Firefox 
warnings and red messages is to use an externally-signed certificate 
(paid for), and I think that means a manual process to update the HMC 
web cert/key every year.  Or is there an easier way?


On 8/29/2023 9:23 AM, Charles Mills wrote:

My sole point is that trusting an ad hoc CA operated on some individual's PC 
carries a significant risk.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert


All true I think, except it's openssl on Linux not Windows.

On 8/29/2023 8:46 AM, Charles Mills wrote:

Don't want to get into one of the peeing contests that have become all too 
common here.

Let me just say that never mind any enterprise PKI CA constraints, I think Tom 
was talking about OpenSSL on a PC. OpenSSL stores private keys -- private keys 
-- in a pretty accessible format. If I can get into Tom's PC -- perhaps while 
he is at lunch, or with a clever phish -- and get that private key, then I can 
generate server certificates for any site in the world and Tom's associates 
will trust those certificates.

Not criticizing Tom or his processes here. Just pointing out to readers that there are 
some significant risks in general to the approach of "oh, I will just create an ad 
hoc CA and have my users trust it." Trusting a CA is implicitly trusting everything 
that anyone does with its root private key.

Yes, it is no different in some ways than trusting DigiCert. The difference is 
that DigiCert has very rigorous protocols for protecting its root private keys. 
OpenSSL does not.

Charles

On Tue, 29 Aug 2023 09:23:16 -0500, Grant Taylor  
wrote:


On 8/29/23 8:31 AM, Charles Mills wrote:

Just being a security PITA here, but that solution makes the security
of their systems subject to whatever safeguards you do or do not put
on yours.


Remember, Certificate Authorities can be constrained.  E.g. it's
possible to create an Enterprise Certificate Authority that can only
sign things in the enterprise.example.net domain and nothing outside of
it.  Thereby significantly limiting exposure to things outside of the
enterprise.


If I can extract the CA private key from your PC than it is trivial
for me to create a www.chase.com certificate that will be trusted by
their browsers without any question, and mount a man-in-the-middle
attack on their banking.


I question the veracity of that statement.


--
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: [EXTERNAL] Re: z13s going EOS anytime soon?

2023-08-29 Thread Ed Jaffe


On 8/29/2023 9:53 AM, Pommier, Rex wrote:

Check Joe Monk's post here from Monday.  According to that, it's been a mixed 
bag.  About half of the generations ended at the same time, the other half the 
business class machines were 1-2 years EOS after the enterprise class machines.


Very interesting.

All of the Business Class z/Architecture machines we have owned over the 
years were dropped at the same time as their Enterprise Class 
counterparts. I assumed that was true across the board. Now I see that 
isn't true.


I learned something today.


--
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: [EXTERNAL] Re: z13s going EOS anytime soon?

Here's the URL that Joe referenced from IBM.  I neglected to put it in my last 
post.

https://www.ibm.com/support/pages/system/files/inline-files/IBM%20Mainframe%20Life%20Cycle%20History%20V2.13%20-%20July%2011%202023.pdf

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Tuesday, August 29, 2023 11:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: z13s going EOS anytime soon?

Ed,

Not according to IBM.  The z12 and z13 are like this, but according to this IBM 
page, previous generations weren't discontinued at the same time.

Check Joe Monk's post here from Monday.  According to that, it's been a mixed 
bag.  About half of the generations ended at the same time, the other half the 
business class machines were 1-2 years EOS after the enterprise class machines. 

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Tuesday, August 29, 2023 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: z13s going EOS anytime soon?

On 8/29/2023 5:46 AM, Pommier, Rex wrote:
> What I found somewhat disheartening was that IBM is dropping support for both 
> the z13 and z13s at the same time despite the fact the z13s was made 
> available a year later than its big brother.

That has always, Always, ALWAYS been true. When a hardware generation is 
dropped, it is dropped.

The solution IBM has been working on is to try to shorten the window between 
the Enterprise-Class and Business-Class models being released...

-- 
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://urldefense.com/v3/__https://www.phoenixsoftware.com/__;!!KjMRP1Ixj6eLE0Fj!vd5nTvXARmQrVroN2FRRA0Bm0ijbnH8WUigKFFDWseMTcl04SV5yW48Oxh7MKabMIDa5FiGxRke0a9qf7xNwl4NhNQ$

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert

True!  I don't think I've created self-signed web certs since before 
they started that capping trend.  But there are other non-web certs I 
deal with, such as SKLM to TS7000/DS8000 communication.  I'll still set 
those to a higher number than the expected life of the hardware.


On 8/29/2023 8:24 AM, Grant Taylor wrote:

On 8/29/23 10:07 AM, Tom Brennan wrote:

And you can specify an expiration far in the future.


Remember, some web browsers are capping the limit on the lifetime of 
certificates they will work with.






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: z13s going EOS anytime soon?

Ed,

Not according to IBM.  The z12 and z13 are like this, but according to this IBM 
page, previous generations weren't discontinued at the same time.

Check Joe Monk's post here from Monday.  According to that, it's been a mixed 
bag.  About half of the generations ended at the same time, the other half the 
business class machines were 1-2 years EOS after the enterprise class machines. 

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Tuesday, August 29, 2023 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: z13s going EOS anytime soon?

On 8/29/2023 5:46 AM, Pommier, Rex wrote:
> What I found somewhat disheartening was that IBM is dropping support for both 
> the z13 and z13s at the same time despite the fact the z13s was made 
> available a year later than its big brother.

That has always, Always, ALWAYS been true. When a hardware generation is 
dropped, it is dropped.

The solution IBM has been working on is to try to shorten the window between 
the Enterprise-Class and Business-Class models being released...

-- 
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://urldefense.com/v3/__https://www.phoenixsoftware.com/__;!!KjMRP1Ixj6eLE0Fj!vd5nTvXARmQrVroN2FRRA0Bm0ijbnH8WUigKFFDWseMTcl04SV5yW48Oxh7MKabMIDa5FiGxRke0a9qf7xNwl4NhNQ$

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LISTSERV Trivia: Deleting drafts?

2023-08-29 Thread Seymour J Metz

While &foo may be either a temporary dsn or a symbol reference, &&foo resolves 
to &foo and can only be a temporary dsn. Absent a symbol definition for foo, 
the two forms are equivalenr.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Grant Taylor [023065957af1-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, August 29, 2023 10:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LISTSERV Trivia: Deleting drafts?

On 8/28/23 6:35 PM, Paul Gilmartin wrote:
> I'll copy/paste a couple lines from:
> 
> Let's see how what appears on the forum compares with
> the original:

Thank you for the clarification Paul.

> &&To identify a temporary data set name, for example,
> &&TEMPDS, and, to identify an in-stream or sysout data set name,
> for example, &&PAYOUT

I would expect that to be "&&TEMPDS".

Sadly, the way that IBM constructs their sight, using content
dynamically loaded by JavaScript, makes it difficult to find the
underlying HTML.

--
Grant. . . .

--
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: GAO recommends upgrades at IRS, Dept Defense Logistics

2023-08-29 Thread Matt Hogstrom

The reality doesn’t matter.  The perception will drive decisions like this.  
Just like the Cloud sucked work into it only to discover that it was more 
expensive than on-prem.

Here is the tool they are likely looking for:

https://newsroom.ibm.com/2023-08-22-IBM-Unveils-watsonx-Generative-AI-Capabilities-to-Accelerate-Mainframe-Application-Modernization

Matt Hogstrom

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom



> On Aug 29, 2023, at 11:53 AM, Rick Troth  wrote:
> 
> "Nor is the watchdog happy about the tax agency’s continued use of COBOL, 
> which they note,
> could lead to 'difficulty finding employees with such knowledge,' adding that 
> this
> 'shortage of expert personnel available to maintain a critical system creates 
> significant risk to an agency’s mission.'"
> 
> I'm not a COBOLer, but this is ignorance on part of the GAO as they listen to 
> popular marketeering from a number of voices in our industry.
> 
> COBOL is *not* a dead language. Dr. Cameron Seay has been teaching COBOL to 
> his students in Tennessee and Carolina for years, rewarding their academic 
> efforts with high paying jobs and a fair amount of renown.
> 
> To confirm the viability of COBOL, I ran a quick compile, link, and execute 
> this morning. This was on PC hardware running Linux and was done via shell 
> script rather than JCL. COBOL is not only alive and well but works great on 
> non-mainframe systems.
> 
> The most reliable code is code which you don't have to modify. Salesmen 
> calling for replacement of COBOL simply because of its age are trying to sell 
> you something. Beware their snake oil. Working COBOL is far better than 
> untested (even as yet unwritten) Java, or even C or Python. Ditching COBOL 
> because of its age as a language is illogical. It's another gubmint mandate 
> likely to ramp-up costs on the overburdened US taxpayers but fail to deliver 
> on promises.
> 
> A smarter direction is to ensure currency of supporting systems and then 
> integrate with the newfangled shiny things. Hopefully the IBM contract will 
> help the GAO see the light.
> 
> -- R; <><
> 
> 
> On 8/28/23 18:48, Mike Schwab wrote:
>> https://planetmainframe.com/2023/08/mandates-and-talent-shortages-are-driving-big-spending-on-modernization/
>> 
>> IBM is one contractor.
>> 
> 
> --
> 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: Firefox and HMC self-signed cert

"Private certificate"?

Issued certificates are signed by the CA's root private key. The root 
certificate is just a convenient means of packaging the corresponding public 
key. Certificates don't sign things. Private keys sign things.

If I have a CA's (any CA's: Tom Brennan's or DigiCert's) root private key, I 
can sign certificates and they are no different from any other certificate 
signed by that CA. That private key corresponds to the public key in their CA 
root certificate, and the digital signature will validate with no issue.

Yes, you need the CA's public key to validate the signature, but CA public keys 
are widely (publicly!) available.

True, you should not trust a purported CA certificate sent by e-mail. It could 
be a phony certificate with a public key that corresponded to a bad actor's 
private key.

My sole point is that trusting an ad hoc CA operated on some individual's PC 
carries a significant risk.

Charles

On Tue, 29 Aug 2023 16:57:25 +0100, Colin Paice  wrote:

> I thought that signing a certificate meant the CA encrypted the checksum
>of the certificate.  For me to validate the certificate I need the CAs
>public certificate to be able to decrypt the check sum, and compare it with
>what I calculated.  If I do not have the CA's public certificate I cannot
>do this.   You can take the CA's private certificate and create as many
>certificates as you like - but as I do not have the public certificate,
>they will not validate.
>If you send me the CA's public certificate, I could validate what it
>issued,  but I would be worried that a bad actor had intercepted my mail
>and substituted a different CA certificate.If your CA certificate has
>been certified by the standard CA companies, then I can validate it and
>quite happily use it.
>So no, you cannot create certificates, sign them and make me believe they
>came from a bona fida company - unless I do something stupid.
>Colin
>
>On Tue, 29 Aug 2023 at 16:46, Charles Mills  wrote:
>
>> Don't want to get into one of the peeing contests that have become all too
>> common here.
>>
>> Let me just say that never mind any enterprise PKI CA constraints, I think
>> Tom was talking about OpenSSL on a PC. OpenSSL stores private keys --
>> private keys -- in a pretty accessible format. If I can get into Tom's PC
>> -- perhaps while he is at lunch, or with a clever phish -- and get that
>> private key, then I can generate server certificates for any site in the
>> world and Tom's associates will trust those certificates.
>>
>> Not criticizing Tom or his processes here. Just pointing out to readers
>> that there are some significant risks in general to the approach of "oh, I
>> will just create an ad hoc CA and have my users trust it." Trusting a CA is
>> implicitly trusting everything that anyone does with its root private key.
>>
>> Yes, it is no different in some ways than trusting DigiCert. The
>> difference is that DigiCert has very rigorous protocols for protecting its
>> root private keys. OpenSSL does not.
>>
>> Charles
>>
>> On Tue, 29 Aug 2023 09:23:16 -0500, Grant Taylor <
>> gtay...@tnetconsulting.net> wrote:
>>
>> >On 8/29/23 8:31 AM, Charles Mills wrote:
>> >> Just being a security PITA here, but that solution makes the security
>> >> of their systems subject to whatever safeguards you do or do not put
>> >> on yours.
>> >
>> >Remember, Certificate Authorities can be constrained.  E.g. it's
>> >possible to create an Enterprise Certificate Authority that can only
>> >sign things in the enterprise.example.net domain and nothing outside of
>> >it.  Thereby significantly limiting exposure to things outside of the
>> >enterprise.
>> >
>> >> If I can extract the CA private key from your PC than it is trivial
>> >> for me to create a www.chase.com certificate that will be trusted by
>> >> their browsers without any question, and mount a man-in-the-middle
>> >> attack on their banking.
>> >
>> >I question the veracity of that statement.
>>
>> --
>> 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: Firefox and HMC self-signed cert

2023-08-29 Thread Colin Paice

 I thought that signing a certificate meant the CA encrypted the checksum
of the certificate.  For me to validate the certificate I need the CAs
public certificate to be able to decrypt the check sum, and compare it with
what I calculated.  If I do not have the CA's public certificate I cannot
do this.   You can take the CA's private certificate and create as many
certificates as you like - but as I do not have the public certificate,
they will not validate.
If you send me the CA's public certificate, I could validate what it
issued,  but I would be worried that a bad actor had intercepted my mail
and substituted a different CA certificate.If your CA certificate has
been certified by the standard CA companies, then I can validate it and
quite happily use it.
So no, you cannot create certificates, sign them and make me believe they
came from a bona fida company - unless I do something stupid.
Colin

On Tue, 29 Aug 2023 at 16:46, Charles Mills  wrote:

> Don't want to get into one of the peeing contests that have become all too
> common here.
>
> Let me just say that never mind any enterprise PKI CA constraints, I think
> Tom was talking about OpenSSL on a PC. OpenSSL stores private keys --
> private keys -- in a pretty accessible format. If I can get into Tom's PC
> -- perhaps while he is at lunch, or with a clever phish -- and get that
> private key, then I can generate server certificates for any site in the
> world and Tom's associates will trust those certificates.
>
> Not criticizing Tom or his processes here. Just pointing out to readers
> that there are some significant risks in general to the approach of "oh, I
> will just create an ad hoc CA and have my users trust it." Trusting a CA is
> implicitly trusting everything that anyone does with its root private key.
>
> Yes, it is no different in some ways than trusting DigiCert. The
> difference is that DigiCert has very rigorous protocols for protecting its
> root private keys. OpenSSL does not.
>
> Charles
>
> On Tue, 29 Aug 2023 09:23:16 -0500, Grant Taylor <
> gtay...@tnetconsulting.net> wrote:
>
> >On 8/29/23 8:31 AM, Charles Mills wrote:
> >> Just being a security PITA here, but that solution makes the security
> >> of their systems subject to whatever safeguards you do or do not put
> >> on yours.
> >
> >Remember, Certificate Authorities can be constrained.  E.g. it's
> >possible to create an Enterprise Certificate Authority that can only
> >sign things in the enterprise.example.net domain and nothing outside of
> >it.  Thereby significantly limiting exposure to things outside of the
> >enterprise.
> >
> >> If I can extract the CA private key from your PC than it is trivial
> >> for me to create a www.chase.com certificate that will be trusted by
> >> their browsers without any question, and mount a man-in-the-middle
> >> attack on their banking.
> >
> >I question the veracity of that statement.
>
> --
> 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: GAO recommends upgrades at IRS, Dept Defense Logistics

2023-08-29 Thread Rick Troth

"Nor is the watchdog happy about the tax agency’s continued use of
COBOL, which they note,
could lead to 'difficulty finding employees with such knowledge,' adding
that this
'shortage of expert personnel available to maintain a critical system
creates significant risk to an agency’s mission.'"

I'm not a COBOLer, but this is ignorance on part of the GAO as they
listen to popular marketeering from a number of voices in our industry.

COBOL is *not* a dead language. Dr. Cameron Seay has been teaching COBOL
to his students in Tennessee and Carolina for years, rewarding their
academic efforts with high paying jobs and a fair amount of renown.

To confirm the viability of COBOL, I ran a quick compile, link, and
execute this morning. This was on PC hardware running Linux and was done
via shell script rather than JCL. COBOL is not only alive and well but
works great on non-mainframe systems.

The most reliable code is code which you don't have to modify. Salesmen
calling for replacement of COBOL simply because of its age are trying to
sell you something. Beware their snake oil. Working COBOL is far better
than untested (even as yet unwritten) Java, or even C or Python.
Ditching COBOL because of its age as a language is illogical. It's
another gubmint mandate likely to ramp-up costs on the overburdened US
taxpayers but fail to deliver on promises.

A smarter direction is to ensure currency of supporting systems and then
integrate with the newfangled shiny things. Hopefully the IBM contract
will help the GAO see the light.

-- R; <><

On 8/28/23 18:48, Mike Schwab wrote:

https://planetmainframe.com/2023/08/mandates-and-talent-shortages-are-driving-big-spending-on-modernization/

IBM is one contractor.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LISTSERV Trivia: Deleting drafts?

2023-08-29 Thread Paul Gilmartin

On Tue, 29 Aug 2023 09:26:34 -0500, Grant Taylor wrote:
>> ...
>> 
>
>> &&   To identify a temporary data set name, for example,
>> &&TEMPDS, and, to identify an in-stream or sysout data set name,
>> for example, &&PAYOUT
>
>I would expect that to be "&&TEMPDS".
>
>Sadly, the way that IBM constructs their sight, using content
>dynamically loaded by JavaScript, makes it difficult to find the
>underlying HTML.
>
I used curl to fetch the page to which I'm replying and saw what
you expect.  The decoding command seems to be:
content = content.replace(/&/g,"&")

Whether IBM or L-Soft, the rendering bug has existed too long.
Could it be a bug in the Javascript engine itself?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert

Don't want to get into one of the peeing contests that have become all too 
common here.

Let me just say that never mind any enterprise PKI CA constraints, I think Tom 
was talking about OpenSSL on a PC. OpenSSL stores private keys -- private keys 
-- in a pretty accessible format. If I can get into Tom's PC -- perhaps while 
he is at lunch, or with a clever phish -- and get that private key, then I can 
generate server certificates for any site in the world and Tom's associates 
will trust those certificates.

Not criticizing Tom or his processes here. Just pointing out to readers that 
there are some significant risks in general to the approach of "oh, I will just 
create an ad hoc CA and have my users trust it." Trusting a CA is implicitly 
trusting everything that anyone does with its root private key.

Yes, it is no different in some ways than trusting DigiCert. The difference is 
that DigiCert has very rigorous protocols for protecting its root private keys. 
OpenSSL does not.

Charles

On Tue, 29 Aug 2023 09:23:16 -0500, Grant Taylor  
wrote:

>On 8/29/23 8:31 AM, Charles Mills wrote:
>> Just being a security PITA here, but that solution makes the security
>> of their systems subject to whatever safeguards you do or do not put
>> on yours.
>
>Remember, Certificate Authorities can be constrained.  E.g. it's
>possible to create an Enterprise Certificate Authority that can only
>sign things in the enterprise.example.net domain and nothing outside of
>it.  Thereby significantly limiting exposure to things outside of the
>enterprise.
>
>> If I can extract the CA private key from your PC than it is trivial
>> for me to create a www.chase.com certificate that will be trusted by
>> their browsers without any question, and mount a man-in-the-middle
>> attack on their banking.
>
>I question the veracity of that statement.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert


On 8/29/23 10:07 AM, Tom Brennan wrote:

And you can specify an expiration far in the future.


Remember, some web browsers are capping the limit on the lifetime of 
certificates they will work with.




--
Grant. . . .

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: z13s going EOS anytime soon?

2023-08-29 Thread Tom Marchant

On Tue, 29 Aug 2023 07:53:50 -0700, Ed Jaffe  
wrote:

>On 8/29/2023 5:46 AM, Pommier, Rex wrote:
>> What I found somewhat disheartening was that IBM is dropping support for 
>> both the z13 and z13s at the same time despite the fact the z13s was made 
>> available a year later than its big brother.
>
>That has always, Always, ALWAYS been true. When a hardware generation is
>dropped, it is dropped.

Jim Elliott's blog disagrees. 
https://jlelliotton.blogspot.com/p/cmos-processor-table.html

and, for example,
z9 EC https://www.ibm.com/docs/en/announcements/system-z9-enterprise-class
z9 BB https://www.ibm.com/docs/en/announcements/system-z9-business-class

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert

Remember Charles, this kludge of making my own CA and signing my own web 
cert is in lieu of something probably worse for security, saying yes to 
the red warning messages in Chrome and Firefox.  So in either case we're 
already open to a DNS spoof.  The home-made cert is simply to make it 
easier on the users without spending any money.  And you can specify an 
expiration far in the future.


But just so y'all know, I stopped doing this in 2021 and now spend $96 a 
year at zerossl.com for web certs.  For that I get three 1-year certs, 
and an unlimited number of 90-day certs.  Far cheaper than buying 
individual certs via Godaddy, etc.  Zerossl provides a pretty good set 
of API calls so the updates can be done automatically on the typical web 
server, but yeah, an HMC is not your typical web server so things would 
probably have to be done manually there.


On 8/29/2023 6:31 AM, Charles Mills wrote:

Just being a security PITA here, but that solution makes the security of their 
systems subject to whatever safeguards you do or do not put on yours.

If I can extract the CA private key from your PC than it is trivial for me to 
create a www.chase.com certificate that will be trusted by their browsers 
without any question, and mount a man-in-the-middle attack on their banking.

CM

On Mon, 28 Aug 2023 16:23:55 -0700, Tom Brennan  
wrote:


Does that work?  In the past when I created a self-signed cert (for
Apache on Linux), adding it to the trusted certs didn't work (at least
in Chrome).  I still got the evil warnings.  I ended up creating my own
CA, used that to sign the web cert, and then copied the CA to the
trusted certs in Chrome.  Then I gave out the CA to the folks I work
with who needed to access the web page, and they did the same.  That was
easy and cheap for a small group of known users.


--
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: [EXTERNAL] Re: z13s going EOS anytime soon?

2023-08-29 Thread Ed Jaffe


On 8/29/2023 5:46 AM, Pommier, Rex wrote:

What I found somewhat disheartening was that IBM is dropping support for both 
the z13 and z13s at the same time despite the fact the z13s was made available 
a year later than its big brother.


That has always, Always, ALWAYS been true. When a hardware generation is 
dropped, it is dropped.


The solution IBM has been working on is to try to shorten the window 
between the Enterprise-Class and Business-Class models being released...



--
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: LISTSERV Trivia: Deleting drafts?


On 8/28/23 6:35 PM, Paul Gilmartin wrote:

I'll copy/paste a couple lines from:

Let's see how what appears on the forum compares with
the original:


Thank you for the clarification Paul.

&&	To identify a temporary data set name, for example, 
&&TEMPDS, and, to identify an in-stream or sysout data set name, 
for example, &&PAYOUT


I would expect that to be "&&TEMPDS".

Sadly, the way that IBM constructs their sight, using content 
dynamically loaded by JavaScript, makes it difficult to find the 
underlying HTML.




--
Grant. . . .

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert


On 8/29/23 8:31 AM, Charles Mills wrote:
Just being a security PITA here, but that solution makes the security 
of their systems subject to whatever safeguards you do or do not put 
on yours.


Remember, Certificate Authorities can be constrained.  E.g. it's 
possible to create an Enterprise Certificate Authority that can only 
sign things in the enterprise.example.net domain and nothing outside of 
it.  Thereby significantly limiting exposure to things outside of the 
enterprise.


If I can extract the CA private key from your PC than it is trivial 
for me to create a www.chase.com certificate that will be trusted by 
their browsers without any question, and mount a man-in-the-middle 
attack on their banking.


I question the veracity of that statement.

I can't tell for sure if you are referring to extracting data (possibly 
the /public/ key) from communications in flight -or- speaking to the 
security of the CA and it's ecosystem by breaching the CA for it's 
signing key directly.


There is little difference in breaching an Enterprise CA's signing key 
than there is in breaching Verisign's CA signing key.  The effective 
difference is related to security around the key.  The concept is the 
same.  Just how many fences do you have to get through.


Thankfully, this can be largely mitigated by leveraging things like a 
YoubiKey and / or a Trusted Platform Module on the CA system wherein the 
YoubiKey / TPM / etc. hold the actual signing certificate and the main 
OS connected to them doesn't have access to and can't get access to the 
signing key.


This comes down to risk vs reward.  One system that must be tightly 
secured, possibly operated at physical console, vs many people ignoring 
~> defeating certificate security warnings on the regular.  Which is the 
lesser of the evils / better security posture?


If you are truly worried about the security of an Enterprise CA signing 
key, there are commercial solutions that can go a long way towards this. 
 But this is small potatoes to training users to defeat certificate 
warnings.




Grant. . . .

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LISTSERV Trivia: Deleting drafts?

2023-08-29 Thread Walt Farrell

On Mon, 28 Aug 2023 15:21:55 -0500, Paul Gilmartin  wrote:

>I use the WWW interface to post to IBM-MAIN.  At times it tells me I have
>lingering drafts.  Each shows a trashcan  icon.  Clicking it usually fails
>or causes a window hang.  Is there a trick?
>
>I may have just discovered  that it works better to delete in (reverse)
>chronological order.  Is that what I should do?

I have no problems clicking the trashcon icon in the Drafts list, and it does 
not matter what order I delete them in.

Firefox on Windows, fwiw.

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Firefox and HMC self-signed cert


On 8/28/23 6:23 PM, Tom Brennan wrote:
Does that work?  In the past when I created a self-signed cert (for 
Apache on Linux), adding it to the trusted certs didn't work (at least 
in Chrome).  I still got the evil warnings.


I've been running into this with many self-signed certs at work.

One of the primary problems is the use of a mixture of unqualified host 
names, qualified host names, and IP addresses.  Often, self-signed 
certificates that equipment generate only use one of the forms of 
identification.  They tend to not play well with a mixture of them.


This is where the Subject Alternate Name field comes into play in the 
certificate.


I ended up creating my own CA, used that to sign the web cert, and 
then copied the CA to the trusted certs in Chrome.  Then I gave out 
the CA to the folks I work with who needed to access the web page, 
and they did the same.  That was easy and cheap for a small group of 
known users.



This is the route that I'm doing background research about the 
environment (I've been there a few months and don't know all the 
history) before standing up a CA explicitly for this reason.


I want to do the following things:

1)  Create an Enterprise Certificate Authority.  (More comments about 
this in my forthcoming reply to Charles about trust.)
2)  Create Certificate Signing Requests which use the following forms of 
identification:

 - IP address
 - Fully Qualified Domain Name (full host name)
 - Short host name (no dots)
3)  Sign said CSRs to generate certificates
4)  Install said certificates in equipment.

Why am I planing on going this route?  I have (at least) 33 devices 
currently using self-signed certificates with a single name exclusive or 
IP address that we interact with which on the near weekly basis.  We are 
constantly dealing with should I use the FQDN, UQDN, or IP for this 
particular device type issues.  We have multiple people on our team.  We 
collectively use multiple jump servers.  This culminates in a lot of 
maintenance for each self-signed certificate to be able to consume it. 
Even with that maintenance, the FQDN vs UQDN vs IP tends to cause problems.


Ultimately we end up in what I think is a poor -- at best -- security 
posture that encourages, if not requires, that users push past security 
warnings from web browsers about untrusted certificates.


I think we will end up in a much better security posture if we (I) take 
the time to stand up an Enterprise Certificate Authority and install 
it's root (or chained) public certificate on client systems.


This should mean that we have much less maintenance to in that we only 
need to install the root public certificate on client systems and they 
will inherently trust what said ECA signs.  No need to install many 
self-signed certificates.  1 vs 33 type thing.


I also think the FQDN vs UQDN vs IP will help things considerably.



--
Grant. . . .

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: z13s going EOS anytime soon?

2023-08-29 Thread Mike Schwab

z13 is last version to IPL in S/390 mode.  Haven't started planning on
over 64 bit machine

On Tue, Aug 29, 2023 at 8:34 AM Pommier, Rex  wrote:
>
> Ahh, thanks.  Hopefully then, this is an anomaly and not future trends.  We 
> don't have a z13s but have a z14 and z15 "baby boxes" and we typically run 
> them until they fall off maintenance.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Mike Schwab
> Sent: Tuesday, August 29, 2023 8:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: z13s going EOS anytime soon?
>
> z/OS 3.1 won't run on it.
>
> On Tue, Aug 29, 2023 at 7:46 AM Pommier, Rex  wrote:
> >
> > What I found somewhat disheartening was that IBM is dropping support for 
> > both the z13 and z13s at the same time despite the fact the z13s was made 
> > available a year later than its big brother.
> >
> > Rex
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Eric D Rossman
> > Sent: Tuesday, August 29, 2023 7:06 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [EXTERNAL] Re: z13s going EOS anytime soon?
> >
> > Called it! Unfortunately, it was my worst case scenario.
> >
> > > Subject: Re: IBM Z13 and Z13s EOL
> > > From: Eric D Rossman 
> > > Date: Thu, 18 Aug 2022 19:44:39 +
> > >
> > > Long ago, the time from GA to EOS was shorter (like 9 years or so),
> > > then it slowly increased to 12-13 years (and even 14 for the z900
> > > GA1), but recent models has been slightly less (10-11 years), so my
> > > thinking (again I don't have any OFFICIAL insight):
> > >
> > > worst case: EOY 2024
> > > best case: EOY 2026
> >
> > Eric Rossman
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Joe Monk
> > Sent: Monday, August 28, 2023 3:02 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [EXTERNAL] Re: z13s going EOS anytime soon?
> >
> > https://urldefense.com/v3/__https://www.ibm.com/support/pages/system/f
> > iles/inline-files/IBM*20Mainframe*20Life*20Cycle*20History*20V2.13*20-
> > *20July*2011*202023.pdf__;JSUlJSUlJSUl!!KjMRP1Ixj6eLE0Fj!pjXVggP_Yq_EP
> > xjxDG2IH2PXBIou1D-KlUV7-ZZODnsaTkz3OZBGoi2_DQwARPQxq3kfxMW9mZAuRK5dfMV
> > _$
> > - slide 4
> >
> > z13s is EOS on 12/31/2024.
> >
> > Joe
> >
> > On Mon, Aug 28, 2023 at 1:58 PM Claude Richbourg < 
> > claude.richbo...@myfloridacfo.com> wrote:
> >
> > > Good afternoon,
> > >
> > > We are currently running on a z13s -2965 and I just started the
> > > planning process of going to a newer processor sometime soon.
> > >
> > > Has anyone heard when the official IBM EOS will be for the z13s?
> > > I have seen different dates 06-30-2026 and now 12-31-2024, so I am
> > > not sure what the real EOS is.
> > >
> > > If anyone knows what IBMs official stance is on the 2965, I would
> > > surely like to know.
> > >
> > > Thanks up front.
> > >
> > >
> > > Best Regards,
> > > Claude
> > >
> > > 
> > > -- 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
> >
> > --
> > The information contained in this message is confidential, protected from 
> > disclosure and may be legally privileged. If the reader of this message is 
> > not the intended recipient or an employee or agent responsible for 
> > delivering this message to the intended recipient, you are hereby notified 
> > that any disclosure, distribution, copying, or any action taken or action 
> > omitted in reliance on it, is strictly prohibited and may be unlawful. If 
> > you have received this communication in error, please notify us immediately 
> > by replying to this message and destroy the material in its entirety, 
> > whether in electronic or hard copy format. Thank you.
> >
> >
> > --
> > 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
>
> --
> The inf

Re: [EXTERNAL] Re: z13s going EOS anytime soon?

Ahh, thanks.  Hopefully then, this is an anomaly and not future trends.  We 
don't have a z13s but have a z14 and z15 "baby boxes" and we typically run them 
until they fall off maintenance.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Tuesday, August 29, 2023 8:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: z13s going EOS anytime soon?

z/OS 3.1 won't run on it.

On Tue, Aug 29, 2023 at 7:46 AM Pommier, Rex  wrote:
>
> What I found somewhat disheartening was that IBM is dropping support for both 
> the z13 and z13s at the same time despite the fact the z13s was made 
> available a year later than its big brother.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Eric D Rossman
> Sent: Tuesday, August 29, 2023 7:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: z13s going EOS anytime soon?
>
> Called it! Unfortunately, it was my worst case scenario.
>
> > Subject: Re: IBM Z13 and Z13s EOL
> > From: Eric D Rossman 
> > Date: Thu, 18 Aug 2022 19:44:39 +
> >
> > Long ago, the time from GA to EOS was shorter (like 9 years or so), 
> > then it slowly increased to 12-13 years (and even 14 for the z900 
> > GA1), but recent models has been slightly less (10-11 years), so my 
> > thinking (again I don't have any OFFICIAL insight):
> >
> > worst case: EOY 2024
> > best case: EOY 2026
>
> Eric Rossman
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Joe Monk
> Sent: Monday, August 28, 2023 3:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: z13s going EOS anytime soon?
>
> https://urldefense.com/v3/__https://www.ibm.com/support/pages/system/f
> iles/inline-files/IBM*20Mainframe*20Life*20Cycle*20History*20V2.13*20-
> *20July*2011*202023.pdf__;JSUlJSUlJSUl!!KjMRP1Ixj6eLE0Fj!pjXVggP_Yq_EP
> xjxDG2IH2PXBIou1D-KlUV7-ZZODnsaTkz3OZBGoi2_DQwARPQxq3kfxMW9mZAuRK5dfMV
> _$
> - slide 4
>
> z13s is EOS on 12/31/2024.
>
> Joe
>
> On Mon, Aug 28, 2023 at 1:58 PM Claude Richbourg < 
> claude.richbo...@myfloridacfo.com> wrote:
>
> > Good afternoon,
> >
> > We are currently running on a z13s -2965 and I just started the 
> > planning process of going to a newer processor sometime soon.
> >
> > Has anyone heard when the official IBM EOS will be for the z13s?
> > I have seen different dates 06-30-2026 and now 12-31-2024, so I am 
> > not sure what the real EOS is.
> >
> > If anyone knows what IBMs official stance is on the 2965, I would 
> > surely like to know.
> >
> > Thanks up front.
> >
> >
> > Best Regards,
> > Claude
> >
> > 
> > -- 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
>
> --
> The information contained in this message is confidential, protected from 
> disclosure and may be legally privileged. If the reader of this message is 
> not the intended recipient or an employee or agent responsible for delivering 
> this message to the intended recipient, you are hereby notified that any 
> disclosure, distribution, copying, or any action taken or action omitted in 
> reliance on it, is strictly prohibited and may be unlawful. If you have 
> received this communication in error, please notify us immediately by 
> replying to this message and destroy the material in its entirety, whether in 
> electronic or hard copy format. Thank you.
>
>
> --
> 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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in relian

Re: Firefox and HMC self-signed cert

Just being a security PITA here, but that solution makes the security of their 
systems subject to whatever safeguards you do or do not put on yours.

If I can extract the CA private key from your PC than it is trivial for me to 
create a www.chase.com certificate that will be trusted by their browsers 
without any question, and mount a man-in-the-middle attack on their banking.

CM

On Mon, 28 Aug 2023 16:23:55 -0700, Tom Brennan  
wrote:

>Does that work?  In the past when I created a self-signed cert (for
>Apache on Linux), adding it to the trusted certs didn't work (at least
>in Chrome).  I still got the evil warnings.  I ended up creating my own
>CA, used that to sign the web cert, and then copied the CA to the
>trusted certs in Chrome.  Then I gave out the CA to the folks I work
>with who needed to access the web page, and they did the same.  That was
>easy and cheap for a small group of known users.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: z13s going EOS anytime soon?

2023-08-29 Thread Mike Schwab

z/OS 3.1 won't run on it.

On Tue, Aug 29, 2023 at 7:46 AM Pommier, Rex  wrote:
>
> What I found somewhat disheartening was that IBM is dropping support for both 
> the z13 and z13s at the same time despite the fact the z13s was made 
> available a year later than its big brother.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Eric D Rossman
> Sent: Tuesday, August 29, 2023 7:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: z13s going EOS anytime soon?
>
> Called it! Unfortunately, it was my worst case scenario.
>
> > Subject: Re: IBM Z13 and Z13s EOL
> > From: Eric D Rossman 
> > Date: Thu, 18 Aug 2022 19:44:39 +
> >
> > Long ago, the time from GA to EOS was shorter (like 9 years or so),
> > then it slowly increased to 12-13 years (and even 14 for the z900
> > GA1), but recent models has been slightly less (10-11 years), so my
> > thinking (again I don't have any OFFICIAL insight):
> >
> > worst case: EOY 2024
> > best case: EOY 2026
>
> Eric Rossman
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Joe Monk
> Sent: Monday, August 28, 2023 3:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: z13s going EOS anytime soon?
>
> https://urldefense.com/v3/__https://www.ibm.com/support/pages/system/files/inline-files/IBM*20Mainframe*20Life*20Cycle*20History*20V2.13*20-*20July*2011*202023.pdf__;JSUlJSUlJSUl!!KjMRP1Ixj6eLE0Fj!pjXVggP_Yq_EPxjxDG2IH2PXBIou1D-KlUV7-ZZODnsaTkz3OZBGoi2_DQwARPQxq3kfxMW9mZAuRK5dfMV_$
> - slide 4
>
> z13s is EOS on 12/31/2024.
>
> Joe
>
> On Mon, Aug 28, 2023 at 1:58 PM Claude Richbourg < 
> claude.richbo...@myfloridacfo.com> wrote:
>
> > Good afternoon,
> >
> > We are currently running on a z13s -2965 and I just started the
> > planning process of going to a newer processor sometime soon.
> >
> > Has anyone heard when the official IBM EOS will be for the z13s?
> > I have seen different dates 06-30-2026 and now 12-31-2024, so I am not
> > sure what the real EOS is.
> >
> > If anyone knows what IBMs official stance is on the 2965, I would
> > surely like to know.
> >
> > Thanks up front.
> >
> >
> > Best Regards,
> > Claude
> >
> > --
> > 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
>
> --
> The information contained in this message is confidential, protected from 
> disclosure and may be legally privileged. If the reader of this message is 
> not the intended recipient or an employee or agent responsible for delivering 
> this message to the intended recipient, you are hereby notified that any 
> disclosure, distribution, copying, or any action taken or action omitted in 
> reliance on it, is strictly prohibited and may be unlawful. If you have 
> received this communication in error, please notify us immediately by 
> replying to this message and destroy the material in its entirety, whether in 
> electronic or hard copy format. Thank you.
>
>
> --
> 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: [EXTERNAL] Re: z13s going EOS anytime soon?