Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk>
Newsgroups: comp.os.vms
Subject: Re: BridgeWorks
Date: Wed, 24 Jul 2024 23:11:41 -0400
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <v7sfpd$245e2$3@dont-email.me>
References: <v7e9qt$33dn4$1@dont-email.me> <v7edd2$33v6h$1@dont-email.me>
 <v7h8d1$3msj2$1@dont-email.me> <v7hveg$3u9vu$3@dont-email.me>
 <v7j76f$4mtj$1@dont-email.me> <v7lic0$ktou$1@dont-email.me>
 <v7m5g4$ogvf$1@dont-email.me> <v7m8hf$o37u$2@dont-email.me>
 <v7ovi5$1b5dr$1@dont-email.me> <v7ph58$1dmh2$3@dont-email.me>
 <v7sehl$244jr$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 25 Jul 2024 05:11:42 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="484c11458d39c7255a0f0758a8865d9d";
	logging-data="2233794"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Lv6TCxz9PG3wLcL4ODxEkafeMd4szbVQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:45PfmKEWtsqmdHXLxVsMS15RqqE=
In-Reply-To: <v7sehl$244jr$1@dont-email.me>
Content-Language: en-US
Bytes: 3921

On 7/24/2024 10:50 PM, Dave Froble wrote:
> On 7/23/2024 8:16 PM, Arne Vajhøj wrote:
>> On 7/23/2024 3:16 PM, Dave Froble wrote:
>>> On 7/22/2024 2:31 PM, Arne Vajhøj wrote:
>>>> Let us say that one has some code that use HTTPS. And
>>>> that programming language has a library that supports
>>>> TLS 1.3. Then in 5 years a vulnerability in TLS 1.3 is
>>>> found and TLS 1.4 is created. If a new version of the library
>>>> supporting TLS 1.4 becomes available then all fine - update the
>>>> library and the application is fine. But if not then the
>>>> application has a problem, because the available library is
>>>> not getting updated.
>>>
>>> How does that differ from some "supported" implementation languages?  
>>> Doesn't
>>> matter if TLS 1.4 doesn't exist now, does it?
>>
>> It is not like:
>>
>> supported language => guarantee for updated library
>> not supported language => guarantee for no updated library
>>
>> But the likelihood for an updated library is much higher
>> if the language is actively maintained, supported and
>> developed by the vendor, because there is an expectation that
>> there is a long term market for the library.
>>
>> If the language has been EOL, not supported and superseded
>> by another product from the vendor, then the market has shrunk
>> and are expected to continue to shrink. That is a situation that
>> make many libraries drop support as well.
>>
>> This is not just a theoretical thing.
>>
>> If you look at third party COM components used by VB6 and VBS back
>> in the late 90's and early 00's, then most of it are gone. The move
>> may be pretty slow, but after 22 years then the market is heavily
>> reduced.
> 
> You assume that such libraries are for specific environments, and some 
> may be. But isn't OpenSSL sort of generic, usable by just about 
> anything?  Should not most such things be that way.  If not, then why not?

OpenSSL is widely used for a certain type of languages in modern time.
If you have an application written in a native language within
the last two decades, then there is a pretty good chance that it uses
OpenSSL. JVM languages, CLR languages, script languages - no (at least
not directly). Something written 30 years ago - no (it would use
Bsafe or something else that had the proper RSA license).

VB6 is a bit in the middle. VB6 can call functions in regular
Win32 DLL's, but often a COM component will be preferred - OO API,
the choice between static and dynamic (dynamic only if a scriptable
COM component), usually nicer API with less hacking with data types.

Arne