[Info-vax] Compatibility, Porting, Migration

[Stephen Hoffman]

On 2018-01-29 21:43:05 +0000, DaveFroble said:

> Stephen Hoffman wrote:
>> 
>> TANSTAAFL
> 
> True
> 
> IIABDFI
> 
> (If It Ain't Broke, Don't Fix It)

"Ain't broke" is unfortunately a moving target.  It's a target that's 
seemingly moving faster in recent years, too.

More than a little not-broken code is really broken code whether that's 
on OpenVMS or otherwise.   The far-too-efficient-to-calculate Purdy 
Polynomial password hashes being an example de l'année.   There are 
plans to replace the Purdy hashes with Argon2 hashes after a migration 
period, but that'll break some existing apps and source code.  
Itemlists and the old calling standard only get you so far.  That's 
very part of why Microsoft started down the path toward .NET, too.   As 
for other related issues, there are no OpenVMS valgrind tools and no 
fuzzers — heap analyzer ain't all that and a bag of chips, 
unfortunately — and there are no tools to scan for synchronization 
coding errors in apps, and no standard way for the compilers to suggest 
better choices to developers for problematic or deprecated or insecure 
constructs.   Developers are expected to know all that.  Which often 
leads to a wonderful combination of increases costs and more holes.

Apps and operating systems get in trouble as end-user expectations 
change, and as security requirements change.

I've seen more than a few OpenVMS apps and servers headed out the door 
because the user interfaces are somewhere between poor and atrocious, 
too.  The app might be functioning as designed, but not as might be 
increasingly desirable.  Whether that's the user interface, 
manageability, deployment efficiency, security requirements, developer 
tools, whatever.  Or just an ugly terminal session window or an 
error-prone user interface; designs that are expensive to train folks 
for and/or hard to maintain and modify.

Dependencies cause problems, too.   I've seen more than a few audits 
fail due to TLS support requirements and down-revision Apache 
installations.  Or somebody's left a down-revision libxml2 somewhere 
deep in an externally-accessible part of the processing chain, and... 
surprise.

VB6 was very popular and quite effective for many folks.  But .NET was 
where Microsoft was investing.

More than a little existing commercial code just isn't sufficiently 
popular to be funded by and profitable to the vendor, and more than a 
little open source isn't sufficiently popular to be staffed and funded. 
  Or the vendor wants or needs to head in a different direction.  I'm 
soon to be separately dealing with the fallout of a vendor decision to 
focus their product offerings elsewhere, too.  It happens all over.

If you're a platform vendor, solving enough of these issues — really 
solving them — is a very hard problem.  Particularly if you're on 
OpenVMS and stuck with traditional OpenVMS APIs and itemlists.  It's 
impossible, if you're further saddled with a requirement for complete 
upward compatibility.

HAVGRFBC.

Have A Very Good Reason For Breaking Compatibility.   Once you do make 
that decision to break an API or framework, make certain you have a 
very good reason, and a migration plan, and a deprecation and removal 
plan.   Definitely don't dribble out breaking changes in the same areas 
of apps, too.   Re-do the whole of the hash-related security APIs all 
at once, and not just for the current password hashes but for other 
current and planned changes.   Move everybody to ACME or whatever might 
replace ACME, and make ACME far easier to use and far better 
documented, and provide simple routines for the common tasks.  Try to 
ensure that the next password hash migration to replace Argon2 will be 
transparent, for instance.




-- 
Pure Personal Opinion | HoffmanLabs LLC