[Info-vax] Viewing SSH users on VMS

[Craig A. Berry]

On 7/27/24 6:20 PM, Arne Vajhøj wrote:
> On 7/27/2024 7:13 PM, Chris Townley wrote:
>> On 28/07/2024 00:03, Arne Vajhøj wrote:
>>> On 7/27/2024 6:36 PM, Lawrence D'Oliveiro wrote:
>>>> On Sat, 27 Jul 2024 16:58:34 -0400, Arne Vajhøj wrote:
>>>>> VSI obvious can and probably should add it to the VMS port.
>>>>
>>>> For “port” read “fork”.
>>>>
>>>> Unless these sorts of changes get accepted upstream, you end up with 
>>>> the
>>>> burden of maintaining your own parallel version, and keeping up with
>>>> upstream developments.
>>>>
>>>> Somehow, I don’t think they have the resources for that.

It takes a lot more resources to have ongoing involvement with upstream
than it does to do a drive-by port that gets updated in a year or three
(or longer).  The latter is how all of DEC/Compaq/HP(E)/VSI have usually
done things, and it has led to some awfully stale products being the
best available.

>>> For a product that is important security wise it makes
>>> sense to keep up.
>>>
>>> And I don't think it should be that bad. 30 years ago one
>>> would create and reapply diffs. Today I believe Git can handle
>>> it.
>>
>> It does worry me a bit that VSI are making their own versions of these 
>> packages, rather than putting them back into the packages as VMS 
>> variants, that they will maintain within the package. Surely that 
>> would imply commitment to the package, as well as the platform
> 
> It makes sense for VSI to provide builds of something like
> OpenSSH and ship with VMS. It is expected functionality
> and "go get something from the internet" may not work well
> for all VMS customers.
> 
> Ideally the VMS changes should be sent upstream so that VMS
> is an out-of-the-box supported platform.
> 
> But there can be many reasons why that may not have happened.
> Maybe VSI did not prioritize it. Maybe the upstream
> project rejected the VMS changes.
> 
> My understanding is that VMS support and upstream projects
> are not always easy. Sometimes it requires diplomacy at a
> high level.
> 
> But VSI should definitely try.

I believe they have said (unofficially) they will do that for LLVM and
have had good interactions with the upstream developers at conferences
and what-not.  I haven't seen statements for other products.  For
security-related things like OpenSSL and OpenSSH they do need to be able
to incorporate and release updates quickly, which would be a lot easier
if they stayed up-to-date and had continuous builds running so
everything was already ready-to-go when a critical fix comes along.