Take the C argument. The issue is really again one of input validation, buffer over flows happen ultimately because of of problems with input validation.
Sometimes they do, sometimes they happen because a series of inputs while valid individually nevertheless result when combined in a value too big for an internal buffer.
There have been plenty of exploits and injects in software written in Java, perl, Python, Ruby, BASIC, etc. It almost always comes down to input validation, and that is because input validation is *HARD* for any non trivial range of allowed inputs.
So you have three options 1: write a validator and assume the validator produces "safe" output 2: don't validate the data and treat it as potentially hostile whereever it passes in your system 3: write a validator but neverthless treat the data as potentially hostile even after passing through the validator. That way you have to screw TWO things up to get a serious exploit.
Then start mixing other technologies and it gets even more fun. So your C program is on a system using UTF-8, how big a buffer do you need to handle data from the database server with a VARCHAR(128) field? What character encoding is it using? What else writes data to that field what character encoding do those things use?
So you have three options 1: try to work out what the maximum size is and use a fixed buffer of that size with no bounds checking 2: do the above but put in checking so that if you screw things up you get an error instead of memory corruption. 3: use a buffer allocated on demand of the size that is actually needed.
Sometimes what they do is set up in the US but in a different part of the US. This allows them to sidestep protectionist import restrictions while also drawing from a different labour pool and avoiding existing unions.
Toyota has a number of factories in the US but none in detroit or even in mitchagan.
Sure using a local design would be the ideal but that would require having a usable local design.
However local production has distinct advantages even if the design is imported. Firstly it makes it harder for other countries to cut off supply. Secondly it means that if a backdoor is to be slipped in it must be slipped in at a much earlier stage of the process making it harder to keep secret. Thirdly it means you are sending less money abroad.
On at least some boards the management port can also act as a regular network port.
So unless you take special steps to isolate the management interfaces from each other this sort of bug could easilly turn a single machine compromise into a much larger compromise.
Also from my understanding, if there is no wifi password then the data between your devices and the wifi isn't encrypted. Correct me if I'm wrong. This is why I won't use a free wifi without passwords.
Most public wifi services do not have useful encryption whether they have a password or not. Lets look at the wifi encryption/authentication options as they relate to public wifi.
open wifi: no encryption open wifi with a web based login required to unloc internet access: no encryption wep: encyrpted but everyone with the network password has the key and trivial to crack even if you don't have the network password wpa/wpa2 in PSK mode: encrypted but everyone with the network password has the key, with public deployments the network password is likely easilly available to an attacker and also likely short/simple enough to easilly bruteforce. wpa/wpa2 in enterprise mode: AIUI these theoretically give inter-user protection but I wouldn't like to place bets on how secure it is in practical deployments. Also has practical difficulties that make it tricky to use for public wifi.
The bottom line is that if you want security on public wifi you should route all your traffic over a VPN with strong authentication and encryption.
As I understand it, cellular data is good for 1. transit passengers, and 2. customers in shops that have chosen not to offer free Wi-Fi to customers in order to discourage loitering.
3: people working on client sites where the client is too paranoid to let outsiders on their network. 4: people staying in places which either don't bother to provide wifi, provide a terrible wifi service or charge through the nose for wifi. 5: people trying to find their way arround on foot in a new city (google maps is pretty good for this, there are probablly offline alternatives but they are nowhere near as ubiquitous)
Canada can not control what other people do in other countries.
All governments control what people do through their ability to hand out punishments.
It's not unheard of for a country to enforce punishments on personell or assets located outside their borders (see the guy who leaked israelli nuclear program) but it's pretty rare because it is diplomatically expensive and in extreme cases could be considered an act of war.
What they can more easilly do though is impose punishments for activities outside their border on personnel and assets that are within their borders. For example they can impose a fine on google, if google refuses to pay they can confiscate googles canadian assets.
Though the biggest problem on modern wireless networks is not "noise" in the traditional sense but interference between cells. The combination of such interference (which looks and acts similar to noise given modern modulation techniques) with the fading inherent in mobile microwave devices makes it very hard to achive more than a few bits/sec/hz on average across the celll.
Conventional MIMO helps a little but the close spacing of the antennas means the channels have low independence limiting the gains.
So that gives a couple of options. One is to move to higher frequencies where there is more bandwidth available and where signal strength tends to fall off quicker. Downsides are the cost of the hardware and if the signal falls off too quickly that limits the environments in which it can be delployed to very high density ones. The other one would be to implement cross-cell MIMO but that would require a heck of a lot of backhaul work.
Right, then you change ISP or your ISP decides to change your prefix, all your machines lose their v6 internet IPs and get a new set.
In an ideal world all your internal communications would be based on something else (names, link local or unique local IPs etc) and would keep working. In the real world what are the chances of internal services using internet IPs to talk to each other and breaking when those IPs change.
To move manufacturing requires you to either build a factory or find one with spare capacity, then you have to fit out that factory to do what you need to do, train the staff to make it with suffuicant reliability and so-on. For any non-trivial product this takes time, especially if lots of people are doing it at once and in the event of a country dropping off the supply map you would have to think about not only your factories but those of your suppliers and your suppliers' suppliers and so-on.
For beter or worse the world has become very interconnected. Taking out peices of that interconnectected puzzle would cause large shocks to the system not just "slight increases in price".
The "class E" space is marked as pasture on that XKCD map. It's unallocated in the sense that the powers that be haven't decided what if anything to do with it but it can't easilly be used because existing systems treat it as invalid. there have been proposals that it should be assigned to "large private intranets" (think: comcast's management network) but they never got approved (and given the need for upgrades to nearly all operating systems that work with the network it's questionable whether it would be better to just move to v6 for such networks).
The map also marks 10.0.0.0/8 (the largest block of private space) in green for some reason.
There also seems to have at least one error. The iana lists 7.0.0.0/8 as being administered by arin since 1995, yet the xkcd map marks it as pasture
In any case all the/8 unicast blocks are now allocated to either a RIR, a corporation or a special use.
Whats different is that in the v4 world NAT is the norm, in the v6 world NAT is strongly discouraged.
Nat has several impacts, one of them is obviously to conserve addresses but another is to make it so that the internal machines don't know or care what the outside IP is unless they go out of their way to look for it so they can do some tricks to make P2P work.
Whereas with v6 you are expected to assign public IPs to end machines (most likely via stateless autoconfiguration) In principle you can assign machines multiple IPs so that you can keep your local stuff in the same place when your ISP changes your global addresses. How well this works in practice I don't know, it's certainly something that would make me wary when deploying v6 on a small buisness network.
Windows 7 uses 6to4 and teredo by default under certain network conditions. I don't know if anythig has changed in newer versions.
For 6to4 iirc windows will enable it if it finds the machine has a public IPv4 address and no public ipv6 address, I don't think there are any other checks beyond that but few windows machines have public IPv4 addresses.
For teredo windows by default looks for a domain controller, if it doesn't find one it assumes it's on an "unamanged network" and enables teredo client behviour . If it finds one* it assumes it's on a "managed network" and disables teredo client (yes this behaviour can be overrideen but we are talking about default here). IIRC teredo client is only enabled if no other public v6 address (including 6to4) is available.
IIRC windows will also act as a teredo "host specific relay" by default if it has a non-teredo ipv6 address.
* Or something it thinks is one, i've had samba trigger it even though I wasn't using samba as a domain controller.
Afaict the result of trying to apply that policy to IPv6 was that people said "fuck you i'll stay with IPv4". The RIRs realised that the only way to get any chance of widespread IPv6 adoption was to make it at least as easy to get v6 PI space as it previously was to get v4 PI space.
If you control the network then one option is to use IPv6 addresess that are not so large and random. In particular avoiding autoconfiguration based on mac addresses or ramdom numbers and assigning addresses manually in the conventional way (possiblly to match the machines v4 address)
At the top level the major transit networks support IPv6 and most of them have for years. At the bottom level the end devices mostly support IPv6 though XP systems (which are still scarilly common) have it disabled by default
The problem comes in the middle, access providers and corporate network operators need to do the work to give the IPv6 capable devices they and their customers own access to the IPv6 internet. Many of them don't see doing so as a priority.
MS implemented a protocol called teredo to work arround this but it's fragile because it fights nat rather than working with it. It's also disabled by default on networks where a domain controller is detected (presumablly because MS didn't want to be accused of subverting corporate firewalls).
Most operating systems will preffer IPv6 when a native v6 connection is available and yet the ipv6 traffic as reported by the likes of google is in the single digit percentages.
Unfortunately I'm struggling to find good stats on how many users can access v6 only resources even though they preffer v4. Test-ipv6 has some stats but I don't consider them representitive of normal users. I remember seeing some stats a while back that said it was about half but I don't remember where
The last estimates I saw were that 50% of users were unable to access ipv6 only services. Many of the 50% who can will be using a fragile tunneling protocol that fights nat rather than working with it.
So services that need to be accessible to the general public need to be accessible on IPv4.
(I hate it when people say they're doing something because they were "forced" or "had no choice", when in reality, they had aa choice, they made a choice, and now don't want to take ownership of the outcome)
Of course sometimes there are no good choices, a growing hosting provider with an address shortage has to choose between grubbing together ipv4 addresses from whereever they can (causing routing table fragmentation, innaccurate gelocation and possiblly security problems) and watching their customers run off to someone who can give them the IPv4 addreses they require.
Where does one draw the line on "not having a choice"? is it where the other choices would be illegal? is it where all the other choices would be commercial suicide for the buisness division in question? is it somewhere else?
There are three types of IPv6 address you may see on a windows 7 machine on a network that does not provide native IPv6
1: a link local address (from the block fe80::/64), afaict you will always get this but as the name suggests it's only usable on the local link. 2: a 6to4 address (from the block 2002::/8), you will get this if you have a public IPv4 address and either no firewall or one that lets through the 6to4 packrs 3: a teredo address (from the block 2001::/16) , teredo is a nat traversing automatic tunneling system, it's enabled by default for home user machines but it's supposed to be disabled by default on corporate networks (defined as networks continaing a domain controller)
Both 6to4 and teredo should in theory allow communication with hosts on the ipv6 internet but in practice they can be somewhat flaky and said communication with the ipv6 internet largely reliant on relay servers run by a handful of altruistic providers.
It seems to vary but even if the filtering is present there is likely to be a range just above 20KHz where human hearing is poor but the filters in the soundcard are still passing enough signal to be useful.
Simple analog filters (that you coudl build with 10 cents worth of components) have a slow rolloff. You can't just say "pass everything up to 20KHz, reject everything above that" or even "pass everything up to 15KHZ reject everything over 25KHz" and design a simple analog circuit to do it.
This is one of the big reasons we use high sample rates and filter digitally nowadays. You can get arbiterally close to an ideal "brick wall" filter digitally (though you do pay a price in time delay and computing power) whereas in the analog world high order filters tend to have problems with stability and sensitivity to component tolerance.
Their response? Don't worry, we have plenty... Huh???
Think about it for a minuite, if they have allocated the addresses to you they can use it to "justify" requests for further allocations. Even when buying used IP addresses you still have to justify your use of the IPs to get them registered to you.
They can then reclaim those addresses from you (and other similar customers) when the shortage gets so acute that they really need them.
Y2K was never a legitimate problem. Computers have no problem going from Dec 31st, 1999 to Jan 1st 2000. The only problems are constructs of human representation of time, like seeing "1/1/00". Is that 1900 or 2000!? We have no clue!
The problem is that the humans who built many systems didn't just use their "human representation of time" as a display format. They used it as an entry format, a storage format, a calculation format, a transfer format.
But we do, actually, just like we knew '99' meant "1999" and not "1899".
Humans are good at making educated guesses, computers not so much so you have to go through ALL your code checking it is making the assumptions you want it to make. Further if you bake in an assumption like =nn means 20xx you are just postponing the problem.
The *real* legitimate problem with time will occur in 2038, and we've already made the solution to that.
Yes and no, we have certainly built systems that can handle dates beyond 2038
but afaict while the linux developers have noted that it is a problem for 32-bit linux they have not yet done the work to fix it and to be done sanely this work really needs to start from the bottom of the stack. There isn't much app developers can meaningfully and sanely do when their OS is broken.
Computers that are old enough to suffer that problem will hopefully not be maintaining some necessary piece of infrastructure.
Given that the problem hasn't been solved for many new systems being deployed now I can't share your optimism that systems with the problem will be phased out by 2038 and I would expect a lot of emergency patching.
Slashdot Mirror
Take the C argument. The issue is really again one of input validation, buffer over flows happen ultimately because of of problems with input validation.
Sometimes they do, sometimes they happen because a series of inputs while valid individually nevertheless result when combined in a value too big for an internal buffer.
There have been plenty of exploits and injects in software written in Java, perl, Python, Ruby, BASIC, etc. It almost always comes down to input validation, and that is because input validation is *HARD* for any non trivial range of allowed inputs.
So you have three options
1: write a validator and assume the validator produces "safe" output
2: don't validate the data and treat it as potentially hostile whereever it passes in your system
3: write a validator but neverthless treat the data as potentially hostile even after passing through the validator. That way you have to screw TWO things up to get a serious exploit.
Then start mixing other technologies and it gets even more fun. So your C program is on a system using UTF-8, how big a buffer do you need to handle data from the database server with a VARCHAR(128) field? What character encoding is it using? What else writes data to that field what character encoding do those things use?
So you have three options
1: try to work out what the maximum size is and use a fixed buffer of that size with no bounds checking
2: do the above but put in checking so that if you screw things up you get an error instead of memory corruption.
3: use a buffer allocated on demand of the size that is actually needed.
I presume by "lethal doses" they mean "doses that would have been lethal to mice not injected with the enzyme".
Sometimes what they do is set up in the US but in a different part of the US. This allows them to sidestep protectionist import restrictions while also drawing from a different labour pool and avoiding existing unions.
Toyota has a number of factories in the US but none in detroit or even in mitchagan.
Sure using a local design would be the ideal but that would require having a usable local design.
However local production has distinct advantages even if the design is imported. Firstly it makes it harder for other countries to cut off supply. Secondly it means that if a backdoor is to be slipped in it must be slipped in at a much earlier stage of the process making it harder to keep secret. Thirdly it means you are sending less money abroad.
On at least some boards the management port can also act as a regular network port.
So unless you take special steps to isolate the management interfaces from each other this sort of bug could easilly turn a single machine compromise into a much larger compromise.
Also from my understanding, if there is no wifi password then the data between your devices and the wifi isn't encrypted. Correct me if I'm wrong. This is why I won't use a free wifi without passwords.
Most public wifi services do not have useful encryption whether they have a password or not. Lets look at the wifi encryption/authentication options as they relate to public wifi.
open wifi: no encryption
open wifi with a web based login required to unloc internet access: no encryption
wep: encyrpted but everyone with the network password has the key and trivial to crack even if you don't have the network password
wpa/wpa2 in PSK mode: encrypted but everyone with the network password has the key, with public deployments the network password is likely easilly available to an attacker and also likely short/simple enough to easilly bruteforce.
wpa/wpa2 in enterprise mode: AIUI these theoretically give inter-user protection but I wouldn't like to place bets on how secure it is in practical deployments. Also has practical difficulties that make it tricky to use for public wifi.
The bottom line is that if you want security on public wifi you should route all your traffic over a VPN with strong authentication and encryption.
As I understand it, cellular data is good for 1. transit passengers, and 2. customers in shops that have chosen not to offer free Wi-Fi to customers in order to discourage loitering.
3: people working on client sites where the client is too paranoid to let outsiders on their network.
4: people staying in places which either don't bother to provide wifi, provide a terrible wifi service or charge through the nose for wifi.
5: people trying to find their way arround on foot in a new city (google maps is pretty good for this, there are probablly offline alternatives but they are nowhere near as ubiquitous)
Canada can not control what other people do in other countries.
All governments control what people do through their ability to hand out punishments.
It's not unheard of for a country to enforce punishments on personell or assets located outside their borders (see the guy who leaked israelli nuclear program) but it's pretty rare because it is diplomatically expensive and in extreme cases could be considered an act of war.
What they can more easilly do though is impose punishments for activities outside their border on personnel and assets that are within their borders. For example they can impose a fine on google, if google refuses to pay they can confiscate googles canadian assets.
Though the biggest problem on modern wireless networks is not "noise" in the traditional sense but interference between cells. The combination of such interference (which looks and acts similar to noise given modern modulation techniques) with the fading inherent in mobile microwave devices makes it very hard to achive more than a few bits/sec/hz on average across the celll.
Conventional MIMO helps a little but the close spacing of the antennas means the channels have low independence limiting the gains.
So that gives a couple of options. One is to move to higher frequencies where there is more bandwidth available and where signal strength tends to fall off quicker. Downsides are the cost of the hardware and if the signal falls off too quickly that limits the environments in which it can be delployed to very high density ones. The other one would be to implement cross-cell MIMO but that would require a heck of a lot of backhaul work.
Right, then you change ISP or your ISP decides to change your prefix, all your machines lose their v6 internet IPs and get a new set.
In an ideal world all your internal communications would be based on something else (names, link local or unique local IPs etc) and would keep working. In the real world what are the chances of internal services using internet IPs to talk to each other and breaking when those IPs change.
To move manufacturing requires you to either build a factory or find one with spare capacity, then you have to fit out that factory to do what you need to do, train the staff to make it with suffuicant reliability and so-on. For any non-trivial product this takes time, especially if lots of people are doing it at once and in the event of a country dropping off the supply map you would have to think about not only your factories but those of your suppliers and your suppliers' suppliers and so-on.
For beter or worse the world has become very interconnected. Taking out peices of that interconnectected puzzle would cause large shocks to the system not just "slight increases in price".
The "class E" space is marked as pasture on that XKCD map. It's unallocated in the sense that the powers that be haven't decided what if anything to do with it but it can't easilly be used because existing systems treat it as invalid. there have been proposals that it should be assigned to "large private intranets" (think: comcast's management network) but they never got approved (and given the need for upgrades to nearly all operating systems that work with the network it's questionable whether it would be better to just move to v6 for such networks).
The map also marks 10.0.0.0/8 (the largest block of private space) in green for some reason.
There also seems to have at least one error. The iana lists 7.0.0.0/8 as being administered by arin since 1995, yet the xkcd map marks it as pasture
In any case all the /8 unicast blocks are now allocated to either a RIR, a corporation or a special use.
Whats different is that in the v4 world NAT is the norm, in the v6 world NAT is strongly discouraged.
Nat has several impacts, one of them is obviously to conserve addresses but another is to make it so that the internal machines don't know or care what the outside IP is unless they go out of their way to look for it so they can do some tricks to make P2P work.
Whereas with v6 you are expected to assign public IPs to end machines (most likely via stateless autoconfiguration) In principle you can assign machines multiple IPs so that you can keep your local stuff in the same place when your ISP changes your global addresses. How well this works in practice I don't know, it's certainly something that would make me wary when deploying v6 on a small buisness network.
does Windows still set up v6 tunnels by default?
Windows 7 uses 6to4 and teredo by default under certain network conditions. I don't know if anythig has changed in newer versions.
For 6to4 iirc windows will enable it if it finds the machine has a public IPv4 address and no public ipv6 address, I don't think there are any other checks beyond that but few windows machines have public IPv4 addresses.
For teredo windows by default looks for a domain controller, if it doesn't find one it assumes it's on an "unamanged network" and enables teredo client behviour . If it finds one* it assumes it's on a "managed network" and disables teredo client (yes this behaviour can be overrideen but we are talking about default here). IIRC teredo client is only enabled if no other public v6 address (including 6to4) is available.
IIRC windows will also act as a teredo "host specific relay" by default if it has a non-teredo ipv6 address.
* Or something it thinks is one, i've had samba trigger it even though I wasn't using samba as a domain controller.
Afaict the result of trying to apply that policy to IPv6 was that people said "fuck you i'll stay with IPv4". The RIRs realised that the only way to get any chance of widespread IPv6 adoption was to make it at least as easy to get v6 PI space as it previously was to get v4 PI space.
If you control the network then one option is to use IPv6 addresess that are not so large and random. In particular avoiding autoconfiguration based on mac addresses or ramdom numbers and assigning addresses manually in the conventional way (possiblly to match the machines v4 address)
At the top level the major transit networks support IPv6 and most of them have for years.
At the bottom level the end devices mostly support IPv6 though XP systems (which are still scarilly common) have it disabled by default
The problem comes in the middle, access providers and corporate network operators need to do the work to give the IPv6 capable devices they and their customers own access to the IPv6 internet. Many of them don't see doing so as a priority.
MS implemented a protocol called teredo to work arround this but it's fragile because it fights nat rather than working with it. It's also disabled by default on networks where a domain controller is detected (presumablly because MS didn't want to be accused of subverting corporate firewalls).
Most operating systems will preffer IPv6 when a native v6 connection is available and yet the ipv6 traffic as reported by the likes of google is in the single digit percentages.
Unfortunately I'm struggling to find good stats on how many users can access v6 only resources even though they preffer v4. Test-ipv6 has some stats but I don't consider them representitive of normal users. I remember seeing some stats a while back that said it was about half but I don't remember where
OR they could migrate those services to IPv6??
The last estimates I saw were that 50% of users were unable to access ipv6 only services. Many of the 50% who can will be using a fragile tunneling protocol that fights nat rather than working with it.
So services that need to be accessible to the general public need to be accessible on IPv4.
(I hate it when people say they're doing something because they were "forced" or "had no choice", when in reality, they had aa choice, they made a choice, and now don't want to take ownership of the outcome)
Of course sometimes there are no good choices, a growing hosting provider with an address shortage has to choose between grubbing together ipv4 addresses from whereever they can (causing routing table fragmentation, innaccurate gelocation and possiblly security problems) and watching their customers run off to someone who can give them the IPv4 addreses they require.
Where does one draw the line on "not having a choice"? is it where the other choices would be illegal? is it where all the other choices would be commercial suicide for the buisness division in question? is it somewhere else?
Sorry I got the blocks sizes wrogn in that last post, 6to4 is 2002::/16 teredo is 2001::/32
There are three types of IPv6 address you may see on a windows 7 machine on a network that does not provide native IPv6
1: a link local address (from the block fe80::/64), afaict you will always get this but as the name suggests it's only usable on the local link.
2: a 6to4 address (from the block 2002::/8), you will get this if you have a public IPv4 address and either no firewall or one that lets through the 6to4 packrs
3: a teredo address (from the block 2001::/16) , teredo is a nat traversing automatic tunneling system, it's enabled by default for home user machines but it's supposed to be disabled by default on corporate networks (defined as networks continaing a domain controller)
Both 6to4 and teredo should in theory allow communication with hosts on the ipv6 internet but in practice they can be somewhat flaky and said communication with the ipv6 internet largely reliant on relay servers run by a handful of altruistic providers.
A quick googling found
http://www.clarisonus.com/Rese...
It seems to vary but even if the filtering is present there is likely to be a range just above 20KHz where human hearing is poor but the filters in the soundcard are still passing enough signal to be useful.
Simple analog filters (that you coudl build with 10 cents worth of components) have a slow rolloff. You can't just say "pass everything up to 20KHz, reject everything above that" or even "pass everything up to 15KHZ reject everything over 25KHz" and design a simple analog circuit to do it.
This is one of the big reasons we use high sample rates and filter digitally nowadays. You can get arbiterally close to an ideal "brick wall" filter digitally (though you do pay a price in time delay and computing power) whereas in the analog world high order filters tend to have problems with stability and sensitivity to component tolerance.
Traceroutes over ipv6 are often shorter than ipv4.
That's hardly surprising, using a tunnel hides all hops between you and the tunnel gateway from traceroute and similar tools.
Their response? Don't worry, we have plenty... Huh???
Think about it for a minuite, if they have allocated the addresses to you they can use it to "justify" requests for further allocations. Even when buying used IP addresses you still have to justify your use of the IPs to get them registered to you.
They can then reclaim those addresses from you (and other similar customers) when the shortage gets so acute that they really need them.
OOI who is the provider?
Y2K was never a legitimate problem. Computers have no problem going from Dec 31st, 1999 to Jan 1st 2000. The only problems are constructs of human representation of time, like seeing "1/1/00". Is that 1900 or 2000!? We have no clue!
The problem is that the humans who built many systems didn't just use their "human representation of time" as a display format. They used it as an entry format, a storage format, a calculation format, a transfer format.
But we do, actually, just like we knew '99' meant "1999" and not "1899".
Humans are good at making educated guesses, computers not so much so you have to go through ALL your code checking it is making the assumptions you want it to make. Further if you bake in an assumption like =nn means 20xx you are just postponing the problem.
The *real* legitimate problem with time will occur in 2038, and we've already made the solution to that.
Yes and no, we have certainly built systems that can handle dates beyond 2038
but afaict while the linux developers have noted that it is a problem for 32-bit linux they have not yet done the work to fix it and to be done sanely this work really needs to start from the bottom of the stack. There isn't much app developers can meaningfully and sanely do when their OS is broken.
Computers that are old enough to suffer that problem will hopefully not be maintaining some necessary piece of infrastructure.
Given that the problem hasn't been solved for many new systems being deployed now I can't share your optimism that systems with the problem will be phased out by 2038 and I would expect a lot of emergency patching.