[Info-vax] Python 2 support ends 1-Jan-2020

[Arne Vajhøj]

On 1/7/2019 10:34 AM, Stephen Hoffman wrote:
> On 2019-01-05 00:43:32 +0000, Dave Froble said:
>> On 1/4/2019 4:32 PM, Stephen Hoffman wrote:
>>> Ponder whether fixing stuff is utterly impossible with OpenVMS, for 
>>> those cases that cannot be fixed compatibly.
>>>
>>> The password hash length being a salient example.
>>
>> You've been dwelling on this point for too long maybe?  VSI has, I 
>> believe, made the improvements to this issue, or at least plans to in 
>> the x86 product.  Don't know, haven't been following it.
> 
> I've been dwelling on the point for far too long, yes.  Because there 
> are folks that thinks that changes can be made compatibly; that VSI can 
> promote an eight byte field to thirty-two or sixty-four, when that 
> buffer is embedded in app code.

>> Further, I don't believe this will break anything, because if anyone 
>> actually did anything with the data in any production apps, it was an 
>> improper and stupid move, and stupid doesn't deserve to be supported.
> 
> The APIs ($getuai, $setuai, $hash_password, $acm, etc) and the size of 
> this buffer (8) are all entirely documented.
> 
> This is the only supported way to verify a password.
> 
> Apps that are comparing hashed passwords are not particularly unusual.
> 
> Which means that buffer definition gets embedded in the apps.

There is compatibility and there is compatibility.

:-)

It is obvious that SYS$GETUAI can not store a 32 bit hash
in an 8 byte buffer.

So programs will be broken.

But a logic in SYS$GETUAI like:

if uaf[UAI$_ENCRYPT] = UAI$C_MODERN then
     if item.buflen < 32 then
         return SS$_BADPARAM
     else
         process
     end if
else
     if item.buflen < 8 then
         return SS$_BADPARAM
     else
         process
     end if
end if

would allow old programs to work as long as the user does not upgrade
password and would make it relative easy to update old programs.

>> At this time I doubt I'll be doing much outside Basic, and VAX Basic 
>> does not have formal OO stuff.  If it did, I'd use it when appropriate.
> 
> As I've mentioned before, BASIC would be an ideal candidate for OOP, 
> though that effort is likely in the distant future at VSI, at the very 
> earliest.

I would say Basic and Pascal would be easy to OOify.

We know it can be done - Microsoft and Apple/Borland did it.

Arne