[Info-vax] list.h porting question

[Stephen Hoffman]

On 2018-02-25 23:43:35 +0000, seasoned_geek said:

> On Saturday, February 24, 2018 at 5:44:32 PM UTC-6, Stephen Hoffman wrote:
>> On 2018-02-24 20:47:04 +0000, seasoned_geek said:
>> 
>>> Thanks Hoff. I was looking in the manuals, not the customer letters.
>> 
>> As I've commented on various previous occasions, the OpenVMS manuals> 
>> were good for their time but have become pretty badly dated.  They're> 
>> missing content from release notes and new features and from what> 
>> enhancements were shipped in patches, the content navigation and the> 
>> tool integration is stuck in the 1990s or older, and they're missing a> 
>> whole lot of what's happened in the last twenty years around networks> 
>> and security and authentication, and frameworks and protocols.
> 
> And people looking to move to the platform look to the manuals, not 
> obscure customer emails and patch notifications. If they are coming 
> from the Linux or Windows world such things don't exist.

It's good that you believe that.  Alas, I don't.  I'm working with 
another platform with vastly better support for accessing the 
documentation, and with documentation that's rather more current.  And 
that's pretty good.   The IDE integration is far more advantageous than 
a wall of out-of-date and incomplete documentation, and documentation 
that's unfortunately not task-oriented.   The platform also makes it 
less likely that I'll have to deal with a lot of the stuff that OpenVMS 
folks have to, too.  Documentation is inherently part of the product 
user interface, and it's becoming more difficult for products to be 
successful with documentation-centric user interfaces.  Sure, for 
developers and such, and for internal folks, but that doesn't work for 
end-users.

("Enterprise software" is effectively a euphemism for software that's 
purchased by folks other than the folks that are and will be using it.  
A euphemism for the developers making design and implementation 
trade-offs and short-cuts that are against the end-user.   For 
documenting their way out of having to actually fix design or 
implementation problems.  That approach can work, too.  For a while.  
At least until some competitor arrives that's providing a better 
experience for the end-users.  But I digress.)

In this particular case, SSL and network security is an area of the 
OpenVMS documentation that really isn't covered all that well.  It 
isn't really even covered in the OpenVMS docs, and what's in the main 
docs around certificates and security with CDSA has been deprecated 
pretty much everywhere, including by HPE and VSI for the sorts of stuff 
that they care about getting right.

The OpenVMS docs themselves variously weren't upgraded; changes and new 
features were documented in the release notes, customer letters and — 
for a number of years — into UPDATE patch notices.  That'll take some 
time to sort out.

It's really easy to blame the end-users for making mistakes with this 
stuff, too.   Security is hard to get right.  Whether for the platform 
developer folks, or for the apps developers, or for the end-users.   
You're in the middle of that mess right now.


>>> I have what I have for this machine. If I'm not using it, it's not 
>>> running. Much of its life is/was spent on an internal network which 
>>> has> > no access to the outside world. I live on a farm and they have 
>>> to be within range of the 12 gauge to get access.
>> 
>> So?   You're going to want to test with current software,
> That would be a false assumption. I only need to get the TLS working 
> within this local loop. The real testers will build it on there own, 
> more current platform. I have never heard of cleanly compiling code 
> from my own time not compiling with newer compilers.

You might be in for a surprise here, then.  There are API differences 
here between the SSL and SSL1 kits, and there are build-time 
differences between SSL and SSL1, and there are different sequences of 
calls, and the connection security requirements have changed.

OpenSSL is also not easy to get the sequences for verifying 
certificates correct, too; where you're not only getting and checking 
for a valid certificate chain, but a chain that you expect and not some 
proxy server, for instance.  This is part of the reason why I've been 
requesting a transport API here, too.   OpenSSL and verification, and 
allowing both IPv4 and IPv6, and related operations...  More than a few 
developer folks have gotten parts of that right, and then run into 
trouble.  And the APIs underneath can and have changed in incompatible 
fashions, or in ways that apps might not reflect; upgrades in 
connection security recommendations, for instance.  A stable API here — 
particularly one that can be silently upgraded to more newer 
connections and deprecate insecure connections, and preferably with 
little or no developer intervention in the application source code — 
would be really nice to have.

>>> Is there really much difference between V7.3-20 and what I have? I mean 
>>> other than perceived security issues.
>> 
>> Not perceived.  Actual security issues.  You're far enough back that 
>> you'll have connectivity issues with secure protocols.  As well as 
>> known security vulnerabilities, some of which have been addressed in 
>> patches after OpenVMS V8.3 and the associated TCP/IP Services version.
>> 
> If I was reaching out to some worthless x86 platform I would expect 
> that. Going out one nic card on my DS-10 in its local net and coming 
> back in the other via TLS should have no issues.

I've had more than a few problems with initiating and receiving SSL 
connections from older OpenVMS configurations.     Irrespective of the 
platform.   The default SSL in V8.4 won't connect to much, much less 
the default SSL kit that was used as far back as V8.3.  The SSL1 kit is 
getting old, but it and the approach being used on V8.4-2L1 and -2L2 is 
the best that's available for OpenVMS from the vendors.

>> We've already had discussions of folks with compilation problems from 
>> -19 fixed in -20.
> 
> But not discussions about the reverse. Code which cleanly compiled on 
> an earlier version suddenly not compiling on the latest version.

Yes, there've been cases of that, too.  Those usually don't ship.  Not 
as often, but it happens.   But in this area, it's differences in the 
APIs and differences in the target environment that tend to cause folks 
problems establishing connections.  I've had to make code changes to 
move forward to and compile on newer SSL releases, and I've had to make 
other code changes to use newer versions of TLS for the connections and 
away from the older and increasingly-insecure connections.


>> 
>> OpenVMS has a 2057 pivot, and testing for 2038 bugs was outside of the> 
>> Y2K testing range, and installation-related software checks will fail> 
>> after midnight on 31-Dec-2028 UTC.  Etc.
> 
>> 
>>> http://www.logikalsolutions.com/wordpress/information-technology/and-still-we-learn-nothing/> 
>>> >>> Ayup.  Some of those pesky kids today.   They never learn, do they.
>> Some of them are still running software that's from the same era as> 
>> Windows XP, and they can't be bothered to upgrade even once or twice a> 
>> decade, and they don't test with current software.  Darned kids.
> 
> I don't know about the 2028 issue, but 2038 was due to a C issue. This 
> __FOOL__ in __VERY RECENT__ history deliberately coded a Y2K99 bug. 
> Why? Because he believed it saved him a few clock cycles. It will also 
> fail in 2038 when compiled for 32-bit because the values after that in 
> the array will go negative.
> 
> Please don't confuse using what you already have with deliberately 
> (&)(&*)(ing up. Obviously the dude went to Arnie's college and most 
> likely graduated Summa Cum Laude.
> 
> What I'm running now __is__ this decade's update. I don't even remember 
> the name of the first Alpha I bought then got a bunch of parts from 
> David to make run VMS. It was that dual console thing which ran Windows 
> NT or OpenVMS. Had it a long time. It wasn't that long ago I got this 
> DS-10. (Although if David is reading that he probably spit coffee, or 
> beer, depending on the time of day, all over his keyboard...<Grin>) But 
> I still have one more 120MEG IDE drive sitting on a shelf to put in it. 
> When that last drive dies, I'll consider moving to a newer and 
> __QUIETER__ alpha. Not going to buy another one until I hear their fans 
> for myself.
> 
> I will _NEVER_ own an ITANIC. Nobody ever should have paid money for 
> that bastard child.
> 
> I'm not the final test of this. The __source__ will be delivered to a 
> different entity. They will compile it on their own machine(s). Test it 
> per their own test plan and contact me if something hiccups during 
> their testing. As long as there are no compilation issues, whether the 
> stuff in my possession can talk to a wanna be x86 computer running a 
> wanna be OS, isn't relevant.
> 
> Now that you've pointed out known connectivity issues, even in the 
> current stuff, I will forward that bit of info to them so they can be 
> prepared.
> 
> Thanks again,
> Roland

Please upgrade your testing configurations to current OpenVMS Alpha 
software, including to the current HPE SSL1 environment or (better, 
preferably) the current VSI SSL1 / V8.4-2L2 environment.

As for your well-known dislike of Itanium and of x86-64 and your 
fondness for running OpenVMS software that was released back while 
Windows XP was still the current release, your choices here are to 
start using the platform, or a new career path or a new platform or 
retirement, as those are the current and upcoming platforms for 
OpenVMS.   There's no reason to assume that the folks at VSI will be 
back-porting much in the way of updates and new features to OpenVMS 
Alpha, after all.






-- 
Pure Personal Opinion | HoffmanLabs LLC