BridgeWorks

[Arne Vajhøj]

Anybody remember BridgeWorks - nifty product for integrating
new stuff with traditional VMS stuff.

Basically:

Java/VC++/VB6 client-->BWX lib--(network)-->BWX application-->VMS code

I think it was available for VAX and Alpha, which reveals the age.

I am trying to see if I can get it to work with Win 10 & VMS 8.4 Alpha.

No luck so far. But I could be doing something wrong.

Has anybody used Bridgeworks with "newer" Windows like 10 or 11
and "newer VMS" like 8.4?

Arne

[Craig A. Berry]

Post by Arne Vajhøj
Anybody remember BridgeWorks - nifty product for integrating
new stuff with traditional VMS stuff.
Java/VC++/VB6 client-->BWX lib--(network)-->BWX application-->VMS code
I think it was available for VAX and Alpha, which reveals the age.
I am trying to see if I can get it to work with Win 10 & VMS 8.4 Alpha.
No luck so far. But I could be doing something wrong.
Has anybody used Bridgeworks with "newer" Windows like 10 or 11
and "newer VMS" like 8.4?

Not me, but semi-related, the following helps a lot getting VB6
installed on current Windows:

https://github.com/gdsestimating/vb6-install-recipe

[Arne Vajhøj]

Post by Craig A. Berry

Post by Arne Vajhøj
Anybody remember BridgeWorks - nifty product for integrating
new stuff with traditional VMS stuff.
Java/VC++/VB6 client-->BWX lib--(network)-->BWX application-->VMS code
I think it was available for VAX and Alpha, which reveals the age.
I am trying to see if I can get it to work with Win 10 & VMS 8.4 Alpha.
No luck so far. But I could be doing something wrong.
Has anybody used Bridgeworks with "newer" Windows like 10 or 11
and "newer VMS" like 8.4?

Not me, but semi-related, the following helps a lot getting VB6
https://github.com/gdsestimating/vb6-install-recipe

Interesting. I wonder if it is a retro thing or there are
still VB6 applications out there that need to be maintained.

For this I tested with a Java client.

But note that what is generated for VB6 is actually a
COM interface, so I could test with VB.NET if I were
in the VB mood.

Arne

[Lawrence D'Oliveiro]

Interesting. I wonder if it is a retro thing or there are still VB6
applications out there that need to be maintained.

Would you entrust mission-critical business functions to obsolete,
unsupported software?

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Interesting. I wonder if it is a retro thing or there are still VB6
applications out there that need to be maintained.

Would you entrust mission-critical business functions to obsolete,
unsupported software?

Doesn't matter what I like or don't like.

Fact is a lot of EOL stuff is used out in the real world.

Arne

[Scott Dorsey]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Interesting. I wonder if it is a retro thing or there are still VB6
applications out there that need to be maintained.

Would you entrust mission-critical business functions to obsolete,
unsupported software?

Doesn't matter what I like or don't like.
Fact is a lot of EOL stuff is used out in the real world.

This is why it's important to look at software and consider the whole
software life cycle before standardizing on it. Because you know you
are probably going to be using it after it is EOLed, and you want to
standardize on software that will still be usable and reliable after
that happens. (Hint: Visual Basic is probably not that software.)
--scott

[Lawrence D'Oliveiro]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Interesting. I wonder if it is a retro thing or there are still VB6
applications out there that need to be maintained.

Would you entrust mission-critical business functions to obsolete,
unsupported software?

Doesn't matter what I like or don't like.
Fact is a lot of EOL stuff is used out in the real world.

It is also a fact that the real world tends not to be kind to a business
that is just one crash away from bankruptcy.

[Scott Dorsey]

Post by Lawrence D'Oliveiro
It is also a fact that the real world tends not to be kind to a business
that is just one crash away from bankruptcy.

Unless they are a bank or a church or a defense contractor or an airline
or...
--scott

[Dave Froble]

Post by Lawrence D'Oliveiro

Interesting. I wonder if it is a retro thing or there are still VB6
applications out there that need to be maintained.

Would you entrust mission-critical business functions to obsolete,
unsupported software?

Would you entrust mission-critical business functions to today's supported
software? ???CloudStrike???

Don't understand why anyone would question something that has been running
successfully for years with no problems ...

[Scott Dorsey]

Post by Dave Froble

Post by Lawrence D'Oliveiro

Interesting. I wonder if it is a retro thing or there are still VB6
applications out there that need to be maintained.

Would you entrust mission-critical business functions to obsolete,
unsupported software?

Would you entrust mission-critical business functions to today's supported
software? ???CloudStrike???

You mean like VMS or OS/360... err.. I mean MVS... err.. I mean z/OS?

Post by Dave Froble
Don't understand why anyone would question something that has been running
successfully for years with no problems ...

When you're on an isolated system you can do that, but when you're having
to function in a public environment where you don't have control over the
end terminals, this is no longer enough. Which is why you want reliable
software that has been running for many years successfully but is also
supported.
--scott

[Dave Froble]

Post by Scott Dorsey

Post by Dave Froble

Post by Lawrence D'Oliveiro

Interesting. I wonder if it is a retro thing or there are still VB6
applications out there that need to be maintained.

Would you entrust mission-critical business functions to obsolete,
unsupported software?

Would you entrust mission-critical business functions to today's supported
software? ???CloudStrike???

You mean like VMS or OS/360... err.. I mean MVS... err.. I mean z/OS?

Post by Dave Froble
Don't understand why anyone would question something that has been running
successfully for years with no problems ...

When you're on an isolated system you can do that, but when you're having
to function in a public environment where you don't have control over the
end terminals, this is no longer enough. Which is why you want reliable
software that has been running for many years successfully but is also
supported.
--scott

I understand what you're saying.

But!

Is security dependent upon apps, or on the environment?

Provide a secure environment, and perhaps many times the app is Ok. Not always.

[Simon Clubley]

Post by Dave Froble
Is security dependent upon apps, or on the environment?
Provide a secure environment, and perhaps many times the app is Ok. Not always.

You still don't get it David. :-)

A secure environment can become an insecure environment over time without
any changes having been made to the secure environment.

Simon.

[Scott Dorsey]

Post by Simon Clubley
A secure environment can become an insecure environment over time without
any changes having been made to the secure environment.

I disagree. That does not happen when you control the whole environment,
and there are dedicated applications where you can.

But as soon as you need to interact with systems that you don't control,
you no longer have control of the environment, and that is usually a fact
of life in the modern world where everybody wants everything integrated.
--scott

[David Wade]

Post by Scott Dorsey

Post by Simon Clubley
A secure environment can become an insecure environment over time without
any changes having been made to the secure environment.

I disagree. That does not happen when you control the whole environment,
and there are dedicated applications where you can.

That can still happen, if the environment has any way to access it
externally. So if for example it used the original AES encryption over
IP then it was secure, but it may not now be secure. When installed it
was secure against wire sniffing now it isn't.

I know in for example a military setting you can control every port,
make sure no one brings in a Wifi sniffer, but in a typical commercial
setting?

Post by Scott Dorsey
But as soon as you need to interact with systems that you don't control,
you no longer have control of the environment, and that is usually a fact
of life in the modern world where everybody wants everything integrated.

Very true..

Post by Scott Dorsey
--scott

[Lawrence D'Oliveiro]

Post by David Wade
I know in for example a military setting you can control every port,
make sure no one brings in a Wifi sniffer, but in a typical commercial
setting?

In a “typical commercial setting”, you are supposed to be able to do
whatever it takes to keep the business running successfully. That includes
keeping up with changing security requirements. Particularly if there are
Government regulators breathing down your neck.

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro

Post by David Wade
I know in for example a military setting you can control every port,
make sure no one brings in a Wifi sniffer, but in a typical commercial
setting?

In a “typical commercial setting”, you are supposed to be able to do
whatever it takes to keep the business running successfully. That
includes keeping up with changing security requirements. Particularly if
there are Government regulators breathing down your neck.

Not just Government regulators, but if your insurance company either
raises your premiums exorbitantly or threatens to cancel your policy
altogether if you don’t take certain actions, that can have quite a
stimulating effect.

[Grant Taylor]

So if for example it used the original AES encryption over IP then it
was secure, but it may not now be secure.

I'll argue that the technical security of the data on the wire is the
same now as it was then.

The difference is that we've gotten a lot better at breaking AES.

So the effective security has dropped proportionately.

[Grant Taylor]

Post by Grant Taylor
I'll argue that the technical security of the data on the wire is the
same now as it was then.

The math has not changed.

How fast we compute the math has changed considerably.

I don't recall -- after a very long day -- if there have been any attack
vulnerabilities in AES or if it's just chasing the number of bits to
stay ahead of computation power.

[Simon Clubley]

Post by Grant Taylor

Post by Grant Taylor
I'll argue that the technical security of the data on the wire is the
same now as it was then.

The math has not changed.

As far as you know. :-)

Simon.

[David Wade]

Post by Simon Clubley

Post by Grant Taylor

Post by Grant Taylor
I'll argue that the technical security of the data on the wire is the
same now as it was then.

The math has not changed.

No but the power available to crack it has changed. I seem to remember
reading somewhere that encrypted data was being captured and saved with
the expectation that it could be decrypted later, perhaps revealing
passwords...

Post by Simon Clubley
As far as you know. :-)
Simon.

[Arne Vajhøj]

Post by David Wade

Post by Simon Clubley

Post by Grant Taylor

Post by Grant Taylor
I'll argue that the technical security of the data on the wire is the
same now as it was then.

The math has not changed.

As far as you know. :-)

No but the power available to crack it has changed. I seem to remember
reading somewhere that encrypted data was being captured and saved with
the expectation that it could be decrypted later, perhaps revealing
passwords...

That is one of the big problems in encryption.

For a lot of data it is not enough that the encryption is secure for
1 day or 1 week or 1 month - it may be required to be secure for
10 years or 50 years or 100 years.

If encrypted traffic get captured today it can be attempted
decrypted in N years.

And some data are still sensitive after N years.

Name, SSN and DOB does not change.

Email address, phone number, bank account, passwords
may change or they may not change over N years.

Arne

[Simon Clubley]

Post by Arne Vajhøj
And some data are still sensitive after N years.
Name, SSN and DOB does not change.

The only reason why SSN is important is because someone does not know
the difference between identification versus authentication.

Post by Arne Vajhøj
Email address, phone number, bank account, passwords
may change or they may not change over N years.

This is why 2FA exists, so that an attacker needs access to something
you control.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Arne Vajhøj
And some data are still sensitive after N years.
Name, SSN and DOB does not change.

The only reason why SSN is important is because someone does not know
the difference between identification versus authentication.

Post by Arne Vajhøj
Email address, phone number, bank account, passwords
may change or they may not change over N years.

This is why 2FA exists, so that an attacker needs access to something
you control.

Gathering personal information is first step in identity theft.

And email address and phone number can be utilized
by attackers in case of MFA.

Arne

[Lawrence D'Oliveiro]

Post by Grant Taylor
The difference is that we've gotten a lot better at breaking AES.

What advances have been made on that score?

The original recommendation was to stick with AES-128, and not bother with
AES-192 or AES-256; as far as I know that hasn’t changed.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Grant Taylor
The difference is that we've gotten a lot better at breaking AES.

What advances have been made on that score?

I think it was a hypothetical scenario.

Post by Lawrence D'Oliveiro
The original recommendation was to stick with AES-128, and not bother with
AES-192 or AES-256; as far as I know that hasn’t changed.

People should use AES-256 today - not AES-128.

AES-128 is toast if/when they make a quantum computer with
enough qubits. AES-256 is good.

Arne

[Lawrence D'Oliveiro]

AES-128 is toast if/when they make a quantum computer with enough
qubits.

So far progress on getting quantum computers to perform any kind of
number-theoretic computation has been precisely ... zero.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

AES-128 is toast if/when they make a quantum computer with enough
qubits.

So far progress on getting quantum computers to perform any kind of
number-theoretic computation has been precisely ... zero.

Basing ones choices of cryptographic algorithms on a belief/hope
that it will continue that ways is not good engineering.

Arne

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro

AES-128 is toast if/when they make a quantum computer with enough
qubits.

So far progress on getting quantum computers to perform any kind of
number-theoretic computation has been precisely ... zero.

Basing ones choices of cryptographic algorithms on a belief/hope that it
will continue that ways is not good engineering.

Evidence: it’s been about 30 years since Shor’s algorithm came out. The
“belief/hope” is on the side of those who still think “quantum” computing
will somehow, magically, any day now, fulfil that long-overdue promise.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Lawrence D'Oliveiro

AES-128 is toast if/when they make a quantum computer with enough
qubits.

So far progress on getting quantum computers to perform any kind of
number-theoretic computation has been precisely ... zero.

Basing ones choices of cryptographic algorithms on a belief/hope that it
will continue that ways is not good engineering.

Evidence: it’s been about 30 years since Shor’s algorithm came out. The
“belief/hope” is on the side of those who still think “quantum” computing
will somehow, magically, any day now, fulfil that long-overdue promise.

You don't think logical. It is pretty simple:

quantum computers quantum computers
do not materialize do materialize
using non-quantum-secure algorithms OK toast
switch to quantum-secure algorithms OK OK

Arne

[Lawrence D'Oliveiro]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Lawrence D'Oliveiro

AES-128 is toast if/when they make a quantum computer with enough
qubits.

So far progress on getting quantum computers to perform any kind of
number-theoretic computation has been precisely ... zero.

Basing ones choices of cryptographic algorithms on a belief/hope that
it will continue that ways is not good engineering.

Evidence: it’s been about 30 years since Shor’s algorithm came out. The
“belief/hope” is on the side of those who still think “quantum”
computing will somehow, magically, any day now, fulfil that
long-overdue promise.

quantum computers quantum
computers do not materialize do
materialize
using non-quantum-secure algorithms OK toast switch
to quantum-secure algorithms OK OK

That’s still based on a promise of vapourware.

[Michael S]

On Mon, 22 Jul 2024 22:55:35 -0400

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Grant Taylor
The difference is that we've gotten a lot better at breaking AES.

What advances have been made on that score?

I think it was a hypothetical scenario.

Post by Lawrence D'Oliveiro
The original recommendation was to stick with AES-128, and not
bother with AES-192 or AES-256; as far as I know that hasn’t
changed.

People should use AES-256 today - not AES-128.
AES-128 is toast if/when they make a quantum computer with
enough qubits. AES-256 is good.
Arne

It does not sound right.
We can be sufficiently sure that quantum computer capable of breaking
AES128 in, say, less than 10 years of compute time is not going to be
built in the next 50 years.
On the other hand, there exist non-negligible chance that quantum
computer capable of breaking at least one of today's popular key
exchange algorithms will be built in next 20-25 years. And that would
affect all protocols that use broken key exchange regardless of
robustness of underlying symmetric cipher - AES256 would fair no better
than ancient DES.
If you believe in quantum threat, you should care first and foremost
about key exchange part of your solution. The symmetric part, assuming
that it's AES128 or better is safe.

[Arne Vajhøj]

Post by Michael S
On Mon, 22 Jul 2024 22:55:35 -0400

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro
The original recommendation was to stick with AES-128, and not
bother with AES-192 or AES-256; as far as I know that hasn’t
changed.

People should use AES-256 today - not AES-128.
AES-128 is toast if/when they make a quantum computer with
enough qubits. AES-256 is good.

It does not sound right.
We can be sufficiently sure that quantum computer capable of breaking
AES128 in, say, less than 10 years of compute time is not going to be
built in the next 50 years.

"toast" was not a correct description.

Maybe "very thin margin" is more accurate.

Quantum computers and Grovers algorithm reduce complexity from
n bit to n/2 bit.

So AES-256 change from 256 bit to 128 bit and AES-128 change from 128
bit to 64 bit.

64 bit is generally not considered secure.

But there is one important detail - Grovers algorithm is not
parallelizable.

Many experts consider 64 bit non-parallelizable to be god enough.

I don't know.

With classic computers then minimum is usually considered to
be 112 bit. If we assume that max. number of VCPU to allocate to
bruteforcing is 1 billion, then those 112 bit parallel is
parallel is equivalent to 82 bit non-parallel. Or the other
way around 64 bit non-parallel is 94 bit parallel.

Given the relative small cost of switching from AES-128 to AES-256,
then I can not recommend anyone to use AES-128.

I have no idea how quantum computers will evolved the next 5
years and definitely not the next 50 years.

But I believe in preparing for the worst.

Post by Michael S
On the other hand, there exist non-negligible chance that quantum
computer capable of breaking at least one of today's popular key
exchange algorithms will be built in next 20-25 years. And that would
affect all protocols that use broken key exchange regardless of
robustness of underlying symmetric cipher - AES256 would fair no better
than ancient DES.
If you believe in quantum threat, you should care first and foremost
about key exchange part of your solution. The symmetric part, assuming
that it's AES128 or better is safe.

The problem for asymmetric is much bigger. RSA, ECC etc. are definitely
toast when quantum computers become available with Shors algorithm.

But nothing one can do about it right now. The quantum secure
asymmetric algorithms are still in development. When they have
been approved/verified, then one should uset them.

And I will not ignore the AES-128 problem that has a very easy
solution today, just because there are other worse problems.

Arne

[Lawrence D'Oliveiro]

Post by Michael S
On the other hand, there exist non-negligible chance that quantum
computer capable of breaking at least one of today's popular key
exchange algorithms will be built in next 20-25 years.

I’m not sure on what basis you say that. Certainly not on the evidence of
current developments, or lack of them.

[Grant Taylor]

Post by Lawrence D'Oliveiro
What advances have been made on that score?

Faster computation.

Parallel computation.

GPUs.

Basically we've gotten better at crunching the numbers.

[Lawrence D'Oliveiro]

Post by Grant Taylor

Post by Lawrence D'Oliveiro

Post by Grant Taylor
The difference is that we've gotten a lot better at breaking AES.

What advances have been made on that score?

Faster computation.
Parallel computation.
GPUs.
Basically we've gotten better at crunching the numbers.

And how has that translated to making us better at breaking AES?

[Grant Taylor]

Post by Lawrence D'Oliveiro
And how has that translated to making us better at breaking AES?

It takes less wall clock time to attack it.

But I digress.

[Lawrence D'Oliveiro]

Post by Grant Taylor

Post by Lawrence D'Oliveiro
And how has that translated to making us better at breaking AES?

It takes less wall clock time to attack it.

How much less?

[David Wade]

Post by Lawrence D'Oliveiro

Post by Grant Taylor

Post by Lawrence D'Oliveiro
And how has that translated to making us better at breaking AES?

It takes less wall clock time to attack it.

How much less?

The "specifics" are not important. The original statement was once
secure always secure. I practice this is not so true as long as its
possible to gain access the system by force.

For example something using NTLM was once considered secure, thats no
longer the case.

Dave

[Lawrence D'Oliveiro]

Post by David Wade

Post by Lawrence D'Oliveiro

Post by Grant Taylor

Post by Lawrence D'Oliveiro
And how has that translated to making us better at breaking AES?

It takes less wall clock time to attack it.

How much less?

The "specifics" are not important.

The numbers are most certainly important.

[John Dallman]

Post by Lawrence D'Oliveiro
The original recommendation was to stick with AES-128, and not
bother with AES-192 or AES-256; as far as I know that hasn't
changed.

That very definitely depends on your use case. My first one, back in
about 2012, was protecting archives of source code that would still be
valuable now. AES-256 was a no-brainer.

John

[Lawrence D'Oliveiro]

Post by John Dallman

Post by Lawrence D'Oliveiro
The original recommendation was to stick with AES-128, and not bother
with AES-192 or AES-256; as far as I know that hasn't changed.

That very definitely depends on your use case. My first one, back in
about 2012, was protecting archives of source code that would still be
valuable now. AES-256 was a no-brainer.

The thing is, AES-256 showed signs of some weaknesses (some kind of
collisions/congestion in the bit-swizzling somewhere) that AES-128 does
not suffer from.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by John Dallman

Post by Lawrence D'Oliveiro
The original recommendation was to stick with AES-128, and not bother
with AES-192 or AES-256; as far as I know that hasn't changed.

That very definitely depends on your use case. My first one, back in
about 2012, was protecting archives of source code that would still be
valuable now. AES-256 was a no-brainer.

The thing is, AES-256 showed signs of some weaknesses (some kind of
collisions/congestion in the bit-swizzling somewhere) that AES-128 does
not suffer from.

The related key attack published in 2009 only impacted AES-192 and
AES-256.

Related key attacks are interesting among cryptologists, but their
practical impact are not big - we are not supposed to use related
keys.

Arne

[Dave Froble]

Post by Simon Clubley

Post by Dave Froble
Is security dependent upon apps, or on the environment?
Provide a secure environment, and perhaps many times the app is Ok. Not always.

You still don't get it David. :-)
A secure environment can become an insecure environment over time without
any changes having been made to the secure environment.
Simon.

Simon, I still don't see where that has anything to do with say, a VB6 app.

[Simon Clubley]

Post by Dave Froble

Post by Lawrence D'Oliveiro

Interesting. I wonder if it is a retro thing or there are still VB6
applications out there that need to be maintained.

Would you entrust mission-critical business functions to obsolete,
unsupported software?

Would you entrust mission-critical business functions to today's supported
software? ???CloudStrike???
Don't understand why anyone would question something that has been running
successfully for years with no problems ...

TLS 1.0 was running just fine for many years before advances declared
it to be obsolete and insecure.

Same for MD5 and SHA-1.

Same for Intel processors until the side-channel attacks emerged.

Any comments David ? :-)

Simon.

[Dave Froble]

Post by Simon Clubley

Post by Dave Froble

Post by Lawrence D'Oliveiro

Interesting. I wonder if it is a retro thing or there are still VB6
applications out there that need to be maintained.

Would you entrust mission-critical business functions to obsolete,
unsupported software?

Would you entrust mission-critical business functions to today's supported
software? ???CloudStrike???
Don't understand why anyone would question something that has been running
successfully for years with no problems ...

TLS 1.0 was running just fine for many years before advances declared
it to be obsolete and insecure.
Same for MD5 and SHA-1.
Same for Intel processors until the side-channel attacks emerged.
Any comments David ? :-)
Simon.

Well, yeah, Simon ...

I would not consider SSL, TLS, MD5, Sha-1, and such applications. They are more
environment protection, the way I see it. And you are correct, some no longer
protect the environment for the real apps.

Please explain to me how an application, for example an inventory application
that tracks on hand product, would ever be involved in security? It is the
environment that must provide the security, and the apps the actual work.
Things get a bit grey when an application communicates outside the environment,
but even then, it is the available security that is used, not the apps.

So, your comments are not relevant to whether or not the apps written in say VB6
need support, at least from a security perspective.

[Simon Clubley]

Post by Dave Froble
I would not consider SSL, TLS, MD5, Sha-1, and such applications. They are more
environment protection, the way I see it. And you are correct, some no longer
protect the environment for the real apps.
Please explain to me how an application, for example an inventory application
that tracks on hand product, would ever be involved in security? It is the
environment that must provide the security, and the apps the actual work.
Things get a bit grey when an application communicates outside the environment,
but even then, it is the available security that is used, not the apps.
So, your comments are not relevant to whether or not the apps written in say VB6
need support, at least from a security perspective.

Actually, they very well could be.

One simple example would be that a new form of injection attack is
discovered and it is discovered the old applications do not handle
it correctly. In addition, and making the problem far worse, the
problem may not be in the application code itself, but in one of
the language libraries that the application uses.

Simon.

[Dave Froble]

Post by Simon Clubley

Post by Dave Froble
I would not consider SSL, TLS, MD5, Sha-1, and such applications. They are more
environment protection, the way I see it. And you are correct, some no longer
protect the environment for the real apps.
Please explain to me how an application, for example an inventory application
that tracks on hand product, would ever be involved in security? It is the
environment that must provide the security, and the apps the actual work.
Things get a bit grey when an application communicates outside the environment,
but even then, it is the available security that is used, not the apps.
So, your comments are not relevant to whether or not the apps written in say VB6
need support, at least from a security perspective.

Actually, they very well could be.
One simple example would be that a new form of injection attack is
discovered and it is discovered the old applications do not handle
it correctly. In addition, and making the problem far worse, the
problem may not be in the application code itself, but in one of
the language libraries that the application uses.

Ah, Simon, how does any of what you mention get through a secure environment,
and if it cannot, what does anything matter to what is behind that secure
environment.

The real question: is the environment secure?

If the environment is not secure, what difference is there about whether the app
implementation is supported, whatever that means?

[Simon Clubley]

Post by Dave Froble

Post by Simon Clubley
One simple example would be that a new form of injection attack is
discovered and it is discovered the old applications do not handle
it correctly. In addition, and making the problem far worse, the
problem may not be in the application code itself, but in one of
the language libraries that the application uses.

Ah, Simon, how does any of what you mention get through a secure environment,
and if it cannot, what does anything matter to what is behind that secure
environment.

The injection attack is usually buried within the data that the "secure"
system processes.

Post by Dave Froble
The real question: is the environment secure?

No. You only think it is. There is no such thing as a secure environment.
There is only such a thing as a more-secure environment.

Post by Dave Froble
If the environment is not secure, what difference is there about whether the app
implementation is supported, whatever that means?

Because when it is shown to be insecure, you no longer have the means
to fix the problem, especially if the insecurity is within a language
RTL, or in generated code that you have no direct control over.

Simon.

[Arne Vajhøj]

I would not consider SSL, TLS, MD5, Sha-1, and such applications.  They
are more environment protection, the way I see it.  And you are correct,
some no longer protect the environment for the real apps.
Please explain to me how an application, for example an inventory
application that tracks on hand product, would ever be involved in
security?  It is the environment that must provide the security, and the
apps the actual work. Things get a bit grey when an application
communicates outside the environment, but even then, it is the available
security that is used, not the apps.
So, your comments are not relevant to whether or not the apps written in
say VB6 need support, at least from a security perspective.

I don't think it is good description of such stuff to call it
environment that are independent of applications.

Sometimes application code directly specify algorithms.

This one line of VB.NET code:

Test("SHA-2 256 bit (managed)", New SHA256Managed())

use SHA-256. An no environment change will make it use a different
algorithm (unless one did some really dirty hacking of the
.NET libraries).

Sometimes newer libraries are not available.

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.

Arne

[Dave Froble]

Post by Arne Vajhøj

Post by Dave Froble
I would not consider SSL, TLS, MD5, Sha-1, and such applications. They are
more environment protection, the way I see it. And you are correct, some no
longer protect the environment for the real apps.
Please explain to me how an application, for example an inventory application
that tracks on hand product, would ever be involved in security? It is the
environment that must provide the security, and the apps the actual work.
Things get a bit grey when an application communicates outside the
environment, but even then, it is the available security that is used, not the
apps.
So, your comments are not relevant to whether or not the apps written in say
VB6 need support, at least from a security perspective.

I don't think it is good description of such stuff to call it
environment that are independent of applications.
Sometimes application code directly specify algorithms.

So now the discussion ignores the previous discussion, in this case VB6? As far
as I know VB6 does not have what you mention below?

Post by Arne Vajhøj
Test("SHA-2 256 bit (managed)", New SHA256Managed())
use SHA-256. An no environment change will make it use a different
algorithm (unless one did some really dirty hacking of the
.NET libraries).
Sometimes newer libraries are not available.

In my limited experience, encryption and such are separate code/libraries. So
linking them into an existing app would still provide protection.

But we all know Dave doesn't get out much, so perhaps not.

Post by Arne Vajhøj
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?

[Arne Vajhøj]

Post by Dave Froble

Post by Arne Vajhøj

Post by Dave Froble
I would not consider SSL, TLS, MD5, Sha-1, and such applications.
They are
more environment protection, the way I see it.  And you are correct,
some no
longer protect the environment for the real apps.
Please explain to me how an application, for example an inventory application
that tracks on hand product, would ever be involved in security?  It
is the
environment that must provide the security, and the apps the actual work.
Things get a bit grey when an application communicates outside the
environment, but even then, it is the available security that is used, not the
apps.
So, your comments are not relevant to whether or not the apps written in say
VB6 need support, at least from a security perspective.

I don't think it is good description of such stuff to call it
environment that are independent of applications.
Sometimes application code directly specify algorithms.
Test("SHA-2 256 bit (managed)", New SHA256Managed())

So now the discussion ignores the previous discussion, in this case
VB6?  As far as I know VB6 does not have what you mention below?

True.

But the concept of program code directly specifying algorithms
is generic.

That can also happen in VB6.

I just happened to have some VB.NET code but not any VB6 code.

Post by Dave Froble

Post by Arne Vajhøj
use SHA-256. An no environment change will make it use a different
algorithm (unless one did some really dirty hacking of the
.NET libraries).
Sometimes newer libraries are not available.

In my limited experience, encryption and such are separate
code/libraries.  So linking them into an existing app would still
provide protection.

Usually an external library.

But no guarantee that new versions will show up for a
library.

If the technology is generally considered obsolete then the
likelihood of new version may even be small.

Post by Dave Froble

Post by Arne Vajhøj
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.

Arne

[Lawrence D'Oliveiro]

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.

If they were open-source, at least someone else could take over
development/maintenance after the original creators have gone bust/given
up.

Of course, trying to do open-source on top of an inherently proprietary
platform does pose its own challenges.

[Simon Clubley]

Post by Lawrence D'Oliveiro

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.

If they were open-source, at least someone else could take over
development/maintenance after the original creators have gone bust/given
up.

How does that work for the original XUL-based version of Firefox so
that you can get back the functionality you used to have ?

How many people are trying to maintain the old XUL version of Firefox,
especially on Android, while trying to keep it moving forward with all
the other changes happening in the (new) mainstream Firefox ?

I picked this example because I am writing an extension for current
Firefox on Android and this Web Extensions is a complete and utter
bloody joke compared to what you could do in the old Firefox for Android.

Hell, they don't even support context menus on Android in the current
Firefox:

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/menus#browser_compatibility

This was absolutely standard functionality in the original Firefox for
Android. I know this because I wrote extensions in the past that used it :-(

And BTW, the bloody control freaks at Mozilla no longer allow you to
load your own extensions into Firefox without having to upload it to
Mozilla for signing. You had to work to turn signing off in the older
versions (which was OK because a user could not easily load an unsigned
extension without having to go through some non-obvious steps) but if
you were a developer, you could do it.

You can sideload Android applications, so I wonder why the bloody control
freaks at Mozilla think its OK to stop you from sideloading your own
extensions that you wrote.

IOW Lawrence, you picked a really bad week to bring that up. :-)

Simon.

[Dave Froble]

Post by Simon Clubley

Post by Lawrence D'Oliveiro

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.

If they were open-source, at least someone else could take over
development/maintenance after the original creators have gone bust/given
up.

How does that work for the original XUL-based version of Firefox so
that you can get back the functionality you used to have ?
How many people are trying to maintain the old XUL version of Firefox,
especially on Android, while trying to keep it moving forward with all
the other changes happening in the (new) mainstream Firefox ?
I picked this example because I am writing an extension for current
Firefox on Android and this Web Extensions is a complete and utter
bloody joke compared to what you could do in the old Firefox for Android.
Hell, they don't even support context menus on Android in the current
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/menus#browser_compatibility
This was absolutely standard functionality in the original Firefox for
Android. I know this because I wrote extensions in the past that used it :-(
And BTW, the bloody control freaks at Mozilla no longer allow you to
load your own extensions into Firefox without having to upload it to
Mozilla for signing. You had to work to turn signing off in the older
versions (which was OK because a user could not easily load an unsigned
extension without having to go through some non-obvious steps) but if
you were a developer, you could do it.
You can sideload Android applications, so I wonder why the bloody control
freaks at Mozilla think its OK to stop you from sideloading your own
extensions that you wrote.
IOW Lawrence, you picked a really bad week to bring that up. :-)
Simon.

Perhaps they learned at (you'll go where we want you to go today) Microsoft?

One could guess they get away with such since you get what you paid for, and
there is no leverage, such as sales, on such people.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

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.

If they were open-source, at least someone else could take over
development/maintenance after the original creators have gone bust/given
up.

In theory yes.

But most companies has no interest in going into the
software library business. They switch to a technology
where they don't have to take on library maintenance
themselves.

Arne

[Lawrence D'Oliveiro]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

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.

If they were open-source, at least someone else could take over
development/maintenance after the original creators have gone
bust/given up.

In theory yes.
But most companies has no interest in going into the software library
business.

So hire somebody who is in that business.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

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.

If they were open-source, at least someone else could take over
development/maintenance after the original creators have gone
bust/given up.

In theory yes.
But most companies has no interest in going into the software library
business.

So hire somebody who is in that business.

That doesn't change the fundamental problem - they would still
be in the software library business - they just change from
paying monthly salaries for a fixed number of employees to
an hourly rate for a variable number of hours.

Arne

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
But most companies has no interest in going into the software library
business.

So hire somebody who is in that business.

That doesn't change the fundamental problem - they would still be in the
software library business ...

It’s called “division of labour”. It’s fundamental to the way a modern
economy works.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
But most companies has no interest in going into the software library
business.

So hire somebody who is in that business.

That doesn't change the fundamental problem - they would still be in the
software library business ...

It’s called “division of labour”. It’s fundamental to the way a modern
economy works.

But it does not fit with "economies of scale", which is another
fundamental concept.

Sometimes it can be an interesting thought to convert
an IT problem to a non-IT problem.

So if you like a specific Ford car and Ford stops production
of that car but releases the drawings what would you do:
A) hire a team to produce that car
B) hire a custom car shop to produce that car
C) switch to another car from GM/Toyota/Honda/Hyundai/whoever
?

Arne

[Lawrence D'Oliveiro]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro
It’s called “division of labour”. It’s fundamental to the way a modern
economy works.

But it does not fit with "economies of scale", which is another
fundamental concept.

It does indeed fit with that. Particularly software, which can be written
once and copied and distributed over and over. If that’s not “scale”, what
is?

Post by Arne Vajhøj
So if you like a specific Ford car and Ford stops production of that car
A) hire a team to produce that car B) hire a custom car shop to produce
that car C) switch to another car from GM/Toyota/Honda/Hyundai/whoever ?

What if the car had a proprietary power and transmission system and
controls, and could only run on roads made by Ford?

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro
It’s called “division of labour”. It’s fundamental to the way a modern
economy works.

But it does not fit with "economies of scale", which is another
fundamental concept.

It does indeed fit with that. Particularly software, which can be written
once and copied and distributed over and over. If that’s not “scale”, what
is?

Windows, MS Office, Linux kernel, GCC etc. definitely have economies of
scale.

Custom software development does not.

Arne

[Dave Froble]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

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.

If they were open-source, at least someone else could take over
development/maintenance after the original creators have gone
bust/given up.

In theory yes.
But most companies has no interest in going into the software library
business.

So hire somebody who is in that business.

That doesn't change the fundamental problem - they would still
be in the software library business - they just change from
paying monthly salaries for a fixed number of employees to
an hourly rate for a variable number of hours.
Arne

Regardless of what they do, they are still in the software business. If you're
using it, you're paying for it, one way or another.

People can be so blind ...

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

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.

If they were open-source, at least someone else could take over
development/maintenance after the original creators have gone
bust/given up.

In theory yes.
But most companies has no interest in going into the software library
business.

So hire somebody who is in that business.

That doesn't change the fundamental problem - they would still
be in the software library business - they just change from
paying monthly salaries for a fixed number of employees to
an hourly rate for a variable number of hours.

Regardless of what they do, they are still in the software business.  If
you're using it, you're paying for it, one way or another.

The question is not whether they are in the "software business" but
whether they are in the "software library business".

And it takes hours to maintain a software library no matter
what, but there are advantages of the library having tens
of thousands of users compared to just one or a few users.

Arne

[John Dallman]

*Date:* Wed, 24 Jul 2024 01:59:49 -0000 (UTC)

Post by Arne Vajhøj
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.

If they were open-source, at least someone else could take over
development/maintenance after the original creators have gone
bust/given up.
Of course, trying to do open-source on top of an inherently
proprietary platform does pose its own challenges.

Sure does. As an Intel engineer said to me: "COM is not only a weird
meta-API designed to contort your code into forms where you'd have to
re-write from scratch to run it on anything else. It does that job fine,
but it also has positive features."

Writing COM components was a /lot/ harder than consuming them. Microsoft
decided to replace it with .NET, over twenty years ago. They tried to
bring it back in WinRT, but that did not achieve significant acceptance
or market share, and is dead.

John

[Arne Vajhøj]

Post by John Dallman
Sure does. As an Intel engineer said to me: "COM is not only a weird
meta-API designed to contort your code into forms where you'd have to
re-write from scratch to run it on anything else. It does that job fine,
but it also has positive features."

Classic joke: how can one rely on a technology build upon IUnknown.

Post by John Dallman
Writing COM components was a /lot/ harder than consuming them. Microsoft
decided to replace it with .NET, over twenty years ago. They tried to
bring it back in WinRT, but that did not achieve significant acceptance
or market share, and is dead.

So true.

Using COM components in any language but C++ is super easy. Writing
COM components in C++ requires an expert. I don't know how it was
in VB6.

.NET does support COM, but using COM for pure .NET solutions does
not make much sense. Plain CLR & CTS provides a good replacement
for inproc COM. And various remoting/WCF provides a good replacement
for remote server COM.

Arne

[Chris Townley]

Post by Arne Vajhøj

Post by John Dallman
Sure does. As an Intel engineer said to me: "COM is not only a weird
meta-API designed to contort your code into forms where you'd have to
re-write from scratch to run it on anything else. It does that job fine,
but it also has positive features."

Classic joke: how can one rely on a technology build upon IUnknown.

Post by John Dallman
Writing COM components was a /lot/ harder than consuming them. Microsoft
decided to replace it with .NET, over twenty years ago. They tried to
bring it back in WinRT, but that did not achieve significant acceptance
or market share, and is dead.

So true.
Using COM components in any language but C++ is super easy. Writing
COM components in C++ requires an expert. I don't know how it was
in VB6.
.NET does support COM, but using COM for pure .NET solutions does
not make much sense. Plain CLR & CTS provides a good replacement
for inproc COM. And various remoting/WCF provides a good replacement
for remote server COM.
Arne

I always worried about copying DCL .com files onto a PC, as the
antivirus software would always class them as 'dodgy'

[Lawrence D'Oliveiro]

.NET does support COM, but using COM for pure .NET solutions does not
make much sense.

Nothing Microsoft-proprietary makes sense any more, thank goodness. The
world is very much built around cross-platform APIs nowadays, and nothing
Microsoft-specific need apply.

[Gary Sparkes]

Post by John Dallman

*Date:* Wed, 24 Jul 2024 01:59:49 -0000 (UTC)

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.

If they were open-source, at least someone else could take over
development/maintenance after the original creators have gone
bust/given up.
Of course, trying to do open-source on top of an inherently proprietary
platform does pose its own challenges.

Sure does. As an Intel engineer said to me: "COM is not only a weird
meta-API designed to contort your code into forms where you'd have to
re-write from scratch to run it on anything else. It does that job fine,
but it also has positive features."
Writing COM components was a /lot/ harder than consuming them. Microsoft
decided to replace it with .NET, over twenty years ago. They tried to
bring it back in WinRT, but that did not achieve significant acceptance
or market share, and is dead.
John

*Windows RT* is dead.

WinRT is very much alive and well, being expanded over time, and destined
to replace Win32 entirely for any modern usage.

Of course, the naming scheme is ..... not the best, as all the confusion
you've probably seen around the two drastically different things. Windows
RT == ARM build of windows locked down ala S-mode on W10/11, WinRT =
runtime system libraries consumable by "Metro" apps on 8/8.1 and all
applications and languages from 10 on up.

https://en.wikipedia.org/wiki/Windows_Runtime

Almost all my new development makes WinRT calls and consumes a ton of new
APIs. Yes, it is COM based, but it is *so much nicer* and i'm no longer
having to drop into COM/DCOM to control a PTZ camera, for example.

I'd say that usage of WinRT functionality is *far* more widespread than
you may realize, especially now with Win10 being the baseline minimum of
currently supported OSes, so you don't have to question if it will be
present or not. Along with what I stated above, WinRT API calls have
*greatly* reduced the size of my codebases as well. It's absolutely
painful sometimes when I have to work "before WinRT" and implement things
like IPv6 support in XP applications....

[Lawrence D'Oliveiro]

Post by Gary Sparkes
WinRT is very much alive and well, being expanded over time, and
destined to replace Win32 entirely for any modern usage.

Seems like C++/WinRT has entered “maintenance mode”
<https://github.com/microsoft/cppwinrt/issues/1289#issuecomment-1481303844>.

[John Dallman]

Post by Gary Sparkes
WinRT is very much alive and well, being expanded over time, and
destined to replace Win32 entirely for any modern usage.

I think "destined" should be "once intended", since it is in maintenance
mode, and was never able to replace all usages.

I produce mathematical modelling libraries for many platforms, written in
a domain-specific language that is transpiled into C, and then compiled
with each platform's compiler.

Microsoft wanted us to produce libraries for use in Windows Store Apps.
The special compiler mode for that doesn't seem to be able to compile C
code. They insisted that it could, but were never able to come up with a
set of compiler options that made it work. After a while they gave up and
allowed Win32 DLLs in Windows Store Apps. The restriction had always been
artificial.

John

[Lawrence D'Oliveiro]

Post by John Dallman
Microsoft wanted us to produce libraries for use in Windows Store Apps.

I once heard the Windows Store described as a “wasteland”.

[Arne Vajhøj]

Post by Gary Sparkes
WinRT is very much alive and well, being expanded over time, and destined
to replace Win32 entirely for any modern usage.
Almost all my new development makes WinRT calls and consumes a ton of new
APIs. Yes, it is COM based, but it is *so much nicer* and i'm no longer
having to drop into COM/DCOM to control a PTZ camera, for example.
I'd say that usage of WinRT functionality is *far* more widespread than
you may realize, especially now with Win10 being the baseline minimum of
currently supported OSes, so you don't have to question if it will be
present or not. Along with what I stated above, WinRT API calls have
*greatly* reduced the size of my codebases as well. It's absolutely
painful sometimes when I have to work "before WinRT" and implement things
like IPv6 support in XP applications....

I don't see much future for WinRT.

It never took off market wise. And Microsoft is not putting
resources in it any more.

I believe it was a huge step forward for Windows C++
desktop apps - a nice modern consistent somewhat complete
OO API instead of a big mess created piecemeal over decades.

But:
* Windows C++ desktop apps is turning into a niche
for new apps
* When Windows Phone was killed then .NET (Xamarin/MAUI)
"replaced" WinRT as solution for that segment
* Windows Store never took off

Arne

[Dave Froble]

Post by Arne Vajhøj

Post by Dave Froble

Post by Arne Vajhøj

Post by Dave Froble
I would not consider SSL, TLS, MD5, Sha-1, and such applications. They are
more environment protection, the way I see it. And you are correct, some no
longer protect the environment for the real apps.
Please explain to me how an application, for example an inventory application
that tracks on hand product, would ever be involved in security? It is the
environment that must provide the security, and the apps the actual work.
Things get a bit grey when an application communicates outside the
environment, but even then, it is the available security that is used, not the
apps.
So, your comments are not relevant to whether or not the apps written in say
VB6 need support, at least from a security perspective.

I don't think it is good description of such stuff to call it
environment that are independent of applications.
Sometimes application code directly specify algorithms.
Test("SHA-2 256 bit (managed)", New SHA256Managed())

So now the discussion ignores the previous discussion, in this case VB6? As
far as I know VB6 does not have what you mention below?

True.
But the concept of program code directly specifying algorithms
is generic.
That can also happen in VB6.
I just happened to have some VB.NET code but not any VB6 code.

Post by Dave Froble

Post by Arne Vajhøj
use SHA-256. An no environment change will make it use a different
algorithm (unless one did some really dirty hacking of the
.NET libraries).
Sometimes newer libraries are not available.

In my limited experience, encryption and such are separate code/libraries. So
linking them into an existing app would still provide protection.

Usually an external library.
But no guarantee that new versions will show up for a
library.
If the technology is generally considered obsolete then the
likelihood of new version may even be small.

Post by Dave Froble

Post by Arne Vajhøj
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?

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.
Arne

Well, if the issue is external communications, and it isn't always so, then
there is always "Tunnel" (or whatever it is called).

The original claims were that one could not use old apps that were implemented
in a currently unsupported language. That argument is full of holes. Trying to
introduce communications into the discussion is just FUD.

[Arne Vajhøj]

Post by Dave Froble

Post by Arne Vajhøj

Post by Dave Froble

Post by Arne Vajhøj
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?

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.

Well, if the issue is external communications, and it isn't always so,
then there is always "Tunnel" (or whatever it is called).

In some cases an encrypted tunnel can be used to mitigate the
problem of unencrypted or weakly encrypted traffic.

But it is not always possible. Like in B2C scenarios.

And strictly speaking it does not provide the same
as app-to-app encryption.

Post by Dave Froble
The original claims were that one could not use old apps that were
implemented in a currently unsupported language.  That argument is full
of holes.  Trying to introduce communications into the discussion is
just FUD.

The communication part is one possible part of what the old stuff would
be missing.

Arne

[Lawrence D'Oliveiro]

In some cases an encrypted tunnel can be used to mitigate the problem
of unencrypted or weakly encrypted traffic.
But it is not always possible. Like in B2C scenarios.

SSL/TLS does the job in that situation.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

In some cases an encrypted tunnel can be used to mitigate the problem
of unencrypted or weakly encrypted traffic.
But it is not always possible. Like in B2C scenarios.

SSL/TLS does the job in that situation.

Read the thread.

We are talking about the case where something are stuck at
an old unsafe version of SSL/TLS, so no - SSL/TLS does not do the job
in that situation.

Arne

[Lawrence D'Oliveiro]

We are talking about the case where something are stuck at an old unsafe
version of SSL/TLS ...

Actually, it is possible to add another layer of opportunistic encryption
on top of, or instead of that. This guards against passive eavesdropping
attacks.

[Dave Froble]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

In some cases an encrypted tunnel can be used to mitigate the problem
of unencrypted or weakly encrypted traffic.
But it is not always possible. Like in B2C scenarios.

SSL/TLS does the job in that situation.

Read the thread.
We are talking about the case where something are stuck at
an old unsafe version of SSL/TLS, so no - SSL/TLS does not do the job
in that situation.
Arne

You can always modify and link against the newest SSL stuff, and if you can't
then yeah, you got bad software, and practices ...

[Dave Froble]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

In some cases an encrypted tunnel can be used to mitigate the problem
of unencrypted or weakly encrypted traffic.
But it is not always possible. Like in B2C scenarios.

SSL/TLS does the job in that situation.

Read the thread.
We are talking about the case where something are stuck at
an old unsafe version of SSL/TLS, so no - SSL/TLS does not do the job
in that situation.
Arne

No, we were discussing apps implemented in an older and currently unsupported
programming language. It's possible that such apps could call the latest SSL/TLS.

[Dave Froble]

Post by Arne Vajhøj

Post by Dave Froble

Post by Arne Vajhøj

Post by Dave Froble
I would not consider SSL, TLS, MD5, Sha-1, and such applications. They are
more environment protection, the way I see it. And you are correct, some no
longer protect the environment for the real apps.
Please explain to me how an application, for example an inventory application
that tracks on hand product, would ever be involved in security? It is the
environment that must provide the security, and the apps the actual work.
Things get a bit grey when an application communicates outside the
environment, but even then, it is the available security that is used, not the
apps.
So, your comments are not relevant to whether or not the apps written in say
VB6 need support, at least from a security perspective.

I don't think it is good description of such stuff to call it
environment that are independent of applications.
Sometimes application code directly specify algorithms.
Test("SHA-2 256 bit (managed)", New SHA256Managed())

So now the discussion ignores the previous discussion, in this case VB6? As
far as I know VB6 does not have what you mention below?

True.
But the concept of program code directly specifying algorithms
is generic.
That can also happen in VB6.
I just happened to have some VB.NET code but not any VB6 code.

Post by Dave Froble

Post by Arne Vajhøj
use SHA-256. An no environment change will make it use a different
algorithm (unless one did some really dirty hacking of the
.NET libraries).
Sometimes newer libraries are not available.

In my limited experience, encryption and such are separate code/libraries. So
linking them into an existing app would still provide protection.

Usually an external library.
But no guarantee that new versions will show up for a
library.
If the technology is generally considered obsolete then the
likelihood of new version may even be small.

Post by Dave Froble

Post by Arne Vajhøj
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?

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.
Arne

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?

[Arne Vajhøj]

Post by Dave Froble

Post by Arne Vajhøj

Post by Dave Froble

Post by Arne Vajhøj
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?

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

[Arne Vajhøj]

Post by Dave Froble
Don't understand why anyone would question something that has been
running successfully for years with no problems ...

There is a difference between security related problems and
other problems.

Security related problems can arise due to events totally
external:
- some researcher in China break an encryption algorithm and
suddenly the encrypted comm is no longer secure
- after 20 years hardware has become so much faster that
what could not be brute forced before now suddenly can be
brute forced

Other problems happen when something change internally. If
absolutely nothing changed then the app would still work as
it has always worked. But things tend to change:
- hardware get updated
- OS get updated
- a requirement to use a newer version of a protocol
- a requirement for a new integration with XYZ

Arne

[Gary Sparkes]

Post by Lawrence D'Oliveiro

Interesting. I wonder if it is a retro thing or there are still VB6
applications out there that need to be maintained.

Would you entrust mission-critical business functions to obsolete,
unsupported software?

Oddly enough, VB6 runtime is fully supported on the "latest and greatest"
as a core OS shipping feature. The IDE and compiler etc aren't, but VB6
runtimes themselves have a support guarantee from microsoft so that old
software can continue to function.

https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-
basic-6/visual-basic-6-support-policy

[John Dallman]

Post by Arne Vajhøj
Interesting. I wonder if it is a retro thing or there are
still VB6 applications out there that need to be maintained.

Yes, there are. It got too deep into too many industries to be got rid of
in a mere couple of decades.

John

[Arne Vajhøj]

Post by John Dallman

Post by Arne Vajhøj
Interesting. I wonder if it is a retro thing or there are
still VB6 applications out there that need to be maintained.

Yes, there are. It got too deep into too many industries to be got rid of
in a mere couple of decades.

Not so surprised.

GUI's running on general office PC's or mostly dedicated
"PC's" only running the GUI in question?

Arne

[Craig A. Berry]

Post by Arne Vajhøj

Post by John Dallman

Post by Arne Vajhøj
Interesting. I wonder if it is a retro thing or there are
still VB6 applications out there that need to be maintained.

Yes, there are. It got too deep into too many industries to be got rid of
in a mere couple of decades.

Not so surprised.
GUI's running on general office PC's or mostly dedicated
"PC's" only running the GUI in question?

Or web DLLs running in the context of IIS for classic API applications.

[Craig A. Berry]

Post by Craig A. Berry

Post by Arne Vajhøj

Post by John Dallman

Post by Arne Vajhøj
Interesting. I wonder if it is a retro thing or there are
still VB6 applications out there that need to be maintained.

Yes, there are. It got too deep into too many industries to be got rid of
in a mere couple of decades.

Not so surprised.
GUI's running on general office PC's or mostly dedicated
"PC's" only running the GUI in question?

Or web DLLs running in the context of IIS for classic API applications.

Bah, that was supposed to be "class ASP."

[John Dallman]

Post by Arne Vajhøj

Post by John Dallman
Yes, there are. It got too deep into too many industries to be
got rid of in a mere couple of decades.

Not so surprised.
GUI's running on general office PC's or mostly dedicated
"PC's" only running the GUI in question?

Some of both, I expect.

John