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?
On 7/19/24 1:04 PM, Arne Vajhøj wrote:
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?
Not me, but semi-related, the following helps a lot getting VB6
installed on current Windows:
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.
Interesting. I wonder if it is a retro thing or there are
still VB6 applications out there that need to be maintained.
On Sat, 20 Jul 2024 16:58:09 -0400, Arne Vajhøj wrote:
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?
In article <v7h8d1$3msj2$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj) wrote:
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.
On 7/21/2024 5:53 AM, John Dallman wrote:
In article <v7h8d1$3msj2$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
wrote:
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?
On 7/21/24 8:52 AM, Arne Vajhøj wrote:
On 7/21/2024 5:53 AM, John Dallman wrote:
In article <v7h8d1$3msj2$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj) >>> wrote:
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.
On Sat, 20 Jul 2024 16:58:09 -0400, Arne Vajhøj wrote:
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?
On 7/20/2024 11:31 PM, Lawrence D'Oliveiro wrote:
On Sat, 20 Jul 2024 16:58:09 -0400, Arne Vajhøj wrote:
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.
On 7/20/2024 11:31 PM, Lawrence D'Oliveiro wrote:
On Sat, 20 Jul 2024 16:58:09 -0400, Arne Vajhøj wrote:
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 ...
On 7/21/2024 5:53 AM, John Dallman wrote:
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?
On 7/20/2024 11:31 PM, Lawrence D'Oliveiro wrote:
On Sat, 20 Jul 2024 16:58:09 -0400, Arne Vajhøj wrote:
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.
On 7/20/2024 11:31 PM, Lawrence D'Oliveiro wrote:
On Sat, 20 Jul 2024 16:58:09 -0400, Arne Vajhj wrote:
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 ...
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.
Is security dependent upon apps, or on the environment?
Provide a secure environment, and perhaps many times the app is Ok. Not always.
Dave Froble <davef@tsoft-inc.com> wrote:
On 7/20/2024 11:31 PM, Lawrence D'Oliveiro wrote:
On Sat, 20 Jul 2024 16:58:09 -0400, Arne Vajhøj wrote:
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?
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
On 2024-07-21, Dave Froble <davef@tsoft-inc.com> wrote:
On 7/20/2024 11:31 PM, Lawrence D'Oliveiro wrote:
On Sat, 20 Jul 2024 16:58:09 -0400, Arne Vajhøj wrote:
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.
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 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.
Don't understand why anyone would question something that has been
running successfully for years with no problems ...
A secure environment can become an insecure environment over time without
any changes having been made to the secure environment.
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
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
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?
On Mon, 22 Jul 2024 22:00:21 +0100, David Wade wrote:
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.
I'll argue that the technical security of the data on the wire is the
same now as it was then.
So if for example it used the original AES encryption over IP then it
was secure, but it may not now be secure.
On Mon, 22 Jul 2024 21:17:57 -0500, Grant Taylor wrote:
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.
The difference is that we've gotten a lot better at breaking AES.
AES-128 is toast if/when they make a quantum computer with enough
qubits.
What advances have been made on that score?
On 7/22/24 21:41, Lawrence D'Oliveiro wrote:
On Mon, 22 Jul 2024 21:17:57 -0500, Grant Taylor wrote:
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?
On 7/22/24 23:31, Lawrence D'Oliveiro wrote:
And how has that translated to making us better at breaking AES?
It takes less wall clock time to attack it.
On Mon, 22 Jul 2024 23:52:19 -0500, Grant Taylor wrote:
On 7/22/24 23:31, Lawrence D'Oliveiro wrote:
And how has that translated to making us better at breaking AES?
It takes less wall clock time to attack it.
How much less?
On 23/07/2024 06:35, Lawrence D'Oliveiro wrote:
On Mon, 22 Jul 2024 23:52:19 -0500, Grant Taylor wrote:
On 7/22/24 23:31, Lawrence D'Oliveiro wrote:
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.
On 7/22/2024 10:41 PM, Lawrence D'Oliveiro wrote:
On Mon, 22 Jul 2024 21:17:57 -0500, Grant Taylor wrote:
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.
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
On 7/22/24 21:17, Grant Taylor wrote:
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.
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.
On 2024-07-22, Dave Froble <davef@tsoft-inc.com> wrote:
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.
On 2024-07-22, Dave Froble <davef@tsoft-inc.com> wrote:
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.
On 7/22/2024 1:39 PM, Dave Froble wrote:
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.
On 2024-07-22, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
On 7/22/24 21:17, Grant Taylor wrote:
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.
On Mon, 22 Jul 2024 22:55:35 -0400, Arne Vajhøj wrote:
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.
On 7/22/2024 11:08 PM, Lawrence D'Oliveiro wrote:
On Mon, 22 Jul 2024 22:55:35 -0400, Arne Vajhøj wrote:
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.
On Mon, 22 Jul 2024 22:55:35 -0400
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 7/22/2024 10:41 PM, Lawrence D'Oliveiro wrote:
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.
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.
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.
In article <v7n59g$11h0t$1@dont-email.me>, ldo@nz.invalid (Lawrence D'Oliveiro) wrote:
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.
On 7/22/2024 2:31 PM, Arne Vajhøj wrote:
On 7/22/2024 1:39 PM, Dave Froble wrote:
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())
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?
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.
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?
On Tue, 23 Jul 2024 20:06:00 -0400, Arne Vajhøj wrote:
On 7/22/2024 11:08 PM, Lawrence D'Oliveiro wrote:
On Mon, 22 Jul 2024 22:55:35 -0400, Arne Vajhøj wrote:
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.
On 7/23/2024 8:09 PM, Lawrence D'Oliveiro wrote:
On Tue, 23 Jul 2024 20:06:00 -0400, Arne Vajhøj wrote:
On 7/22/2024 11:08 PM, Lawrence D'Oliveiro wrote:
On Mon, 22 Jul 2024 22:55:35 -0400, Arne Vajhøj wrote:
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
On Tue, 23 Jul 2024 19:07 +0100 (BST), John Dallman wrote:
In article <v7n59g$11h0t$1@dont-email.me>, ldo@nz.invalid (Lawrence
D'Oliveiro) wrote:
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.
On 23/07/2024 13:25, Simon Clubley wrote:
On 2024-07-22, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
On 7/22/24 21:17, Grant Taylor wrote:
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...
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.
On 7/23/2024 3:16 PM, Dave Froble wrote:
On 7/22/2024 2:31 PM, Arne Vajhøj wrote:
On 7/22/2024 1:39 PM, Dave Froble wrote:
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())
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.
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.
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
On Tue, 23 Jul 2024 20:16:40 -0400, Arne Vajhj wrote:
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.
On 7/22/2024 1:47 PM, Simon Clubley wrote:
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?
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.
On 2024-07-23, Arne Vajhøj <arne@vajhoej.dk> wrote:
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.
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.
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.
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.
On Tue, 23 Jul 2024 20:16:40 -0400, Arne Vajhøj wrote:
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.
On 7/23/2024 9:59 PM, Lawrence D'Oliveiro wrote:
On Tue, 23 Jul 2024 20:16:40 -0400, Arne Vajhøj wrote:
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.
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.
On Wed, 24 Jul 2024 09:56:11 -0400, Arne Vajhøj wrote:
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.
On 2024-07-23, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 23 Jul 2024 20:16:40 -0400, Arne Vajhøj wrote:
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.
On Wed, 24 Jul 2024 10:00:55 -0400, Arne Vajhøj wrote:
On 7/23/2024 9:59 PM, Lawrence D'Oliveiro wrote:
On Tue, 23 Jul 2024 20:16:40 -0400, Arne Vajhøj wrote:
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.
On 7/23/2024 3:16 PM, Dave Froble wrote:
On 7/22/2024 2:31 PM, Arne Vajhøj wrote:
On 7/22/2024 1:39 PM, Dave Froble wrote:
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())
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.
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.
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
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?
We are talking about the case where something are stuck at an old unsafe version of SSL/TLS ...
On 7/24/2024 7:40 PM, Lawrence D'Oliveiro wrote:
On Wed, 24 Jul 2024 10:00:55 -0400, Arne Vajhøj wrote:
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 ...
On Wed, 24 Jul 2024 22:57:42 -0400, Arne Vajhøj wrote:
On 7/24/2024 7:40 PM, Lawrence D'Oliveiro wrote:
On Wed, 24 Jul 2024 10:00:55 -0400, Arne Vajhøj wrote:
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.
On 7/25/2024 1:51 AM, Lawrence D'Oliveiro wrote:
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.
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 ?
On 7/24/2024 7:41 PM, Lawrence D'Oliveiro wrote:
On Wed, 24 Jul 2024 09:56:11 -0400, Arne Vajhøj wrote:
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
On 7/24/2024 7:40 PM, Lawrence D'Oliveiro wrote:
On Wed, 24 Jul 2024 10:00:55 -0400, Arne Vajhøj wrote:
On 7/23/2024 9:59 PM, Lawrence D'Oliveiro wrote:
On Tue, 23 Jul 2024 20:16:40 -0400, Arne Vajhøj wrote:
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
On Thu, 25 Jul 2024 15:28:22 -0400, Arne Vajhøj wrote:
On 7/25/2024 1:51 AM, Lawrence D'Oliveiro wrote:
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?
On 7/24/2024 10:57 PM, Arne Vajhøj wrote:
On 7/24/2024 7:40 PM, Lawrence D'Oliveiro wrote:
On Wed, 24 Jul 2024 10:00:55 -0400, Arne Vajhøj wrote:
On 7/23/2024 9:59 PM, Lawrence D'Oliveiro wrote:
On Tue, 23 Jul 2024 20:16:40 -0400, Arne Vajhøj wrote:
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.
*From:* Lawrence D'Oliveiro <ldo@nz.invalid>
*Date:* Wed, 24 Jul 2024 01:59:49 -0000 (UTC)
On Tue, 23 Jul 2024 20:16:40 -0400, Arne Vajhj wrote:
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.
On 7/27/2024 6:00 PM, John Dallman wrote:
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.
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
.NET does support COM, but using COM for pure .NET solutions does not
make much sense.
WinRT is very much alive and well, being expanded over time, and
destined to replace Win32 entirely for any modern usage.
WinRT is very much alive and well, being expanded over time, and
destined to replace Win32 entirely for any modern usage.
Microsoft wanted us to produce libraries for use in Windows Store Apps.
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....
On 7/24/2024 7:41 PM, Lawrence D'Oliveiro wrote:
On Wed, 24 Jul 2024 09:56:11 -0400, Arne Vajhøj wrote:
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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 437 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 193:32:27 |
| Calls: | 9,135 |
| Calls today: | 2 |
| Files: | 13,432 |
| Messages: | 6,035,422 |