8 ms·

RHEL 6 ELS will be supported until 2024. My comments are not contradictory to your point about 2013. They are only meant to make people aware that there are s

by 1e-9 6y ago

RHEL 6 ELS will be supported until 2024. My comments are not contradictory to your point about 2013. They are only meant to make people aware that there are supported OS versions in use that have this issue.

ThA0x2 6y ago
RHEL 6 is end of life (product retirement) this November. ELS indeed extends out till 2024, but that's after the product has been officially retired/EOLed. Essentially, come November, there will not be a generally supported Linux OS that will have this issue.
- 1e-9 6y ago
  You seem to be arguing that there will be no need to use the --random-source option after November. If so, that is incorrect in my view. ELS versions receive critical security fixes and urgent bug fixes until the end of their support. They are used right up to end of support, or even beyond in some cases. RHEL 5 ELS will be supported thru November 30, 2020 and RHEL 6 ELS will be supported thru June 30, 2024. This implies there will be RHEL 5 ELS users for at least 5 more months and there will be RHEL 6 ELS users for at least 4 more years. So, for at least four more years, it appears there will be users who should use the --random-source option with shuf if they want to be cryptographically secure.
  - ThA0x2 6y ago
    >You seem to be arguing that there will be no need to use the --random-source option after November. If so, that is incorrect in my view. The argument is that if you're on a currently supported, non-EOL Linux OS, you will not have this issue after November (since at that point in time, the RHEL 6 will be past end of life). >ELS versions receive critical security fixes and urgent bug fixes until the end of their support. They are used right up to end of support, or even beyond in some cases, although that is certainly not recommended. ELS versions are considered past EOL, and past Maintenance Support I & II. They will not be supported for new installs, will be out of compliance for PCI DSS, HIPPA, almost all third party vendor software, will not be certified on new hardware, etc. They are past their ten year lifecycle. https://endoflife.software/operating-systems/linux/red-hat-enterprise-linux-rhel https://endoflife.software/operating-systems/linux/red-hat-e... https://access.redhat.com/support/policy/updates/errata/#Extended_Life_Cycle_Phase https://access.redhat.com/support/policy/updates/errata/#Ext... Of course the few people on RHEL 6 will have to use the additional --random-source option, but the amount of people that this affects is in the single percentage point, or less. Nothing is stopping someone from spinning up RHEL 5 three years from now and running my original command. My original statements and points stand true. You were originally wrong to think that shuf is cryptographically insecure. It's been cryptographically secure for quite a while now.
    - 1e-9 6y ago
      > The argument is that if you're on a currently supported, non-EOL Linux OS, you will not have this issue after November (since at that point in time, the RHEL 6 will be past end of life). Limiting to only non-EOL and to only future timelines after November are your own chosen statement limitations, not mine. My statement that the shuf default is insecure for certain versions is correct and I have provided specific examples. There may be other examples, but I only need one to establish truth. End of life dates have no bearing on my statement. You seem to be trying to change my statement into something else so you can say it is incorrect. You can narrow your own statements to only include versions and future timelines that you think are important, which is fine, but it doesn't help those who will still be using the affected versions for years to come. The ELS versions exist for a reason, which should be clear from the fact that Red Hat is a for-profit entity. There is a significant number of projects in areas such as industrial control, defense, and finance, that place a high value on stability and they want that extra timeline that extends far beyond end of life.
      - ThA0x2 6y ago
        >Limiting to only non-EOL and to only future timelines after November are your own chosen statement limitations, not mine. My statement was a Linux OS after 2013ish, which means RHEL 7 and Ubuntu 13.02. RHEL 6/5 are not from 2013 or later. >My statement that the shuf default is insecure for certain versions is correct and I have provided specific examples. There may be other examples, but I only need one to establish truth. There are certain default versions of the kernel, bash, etc. that are insecure for certain versions of Linux OS releases. Your statement is meaningless. You can go back in time and find an insecure version of a piece of software, that's almost always true, you established effectively nothing. Whether or not anyone is using that version is what's meaningful. You might as well be warning people not to visit https://correcthorse.pw/ https://correcthorse.pw/ on the default Firefox that ships with RHEL 5 because it had insecure defaults. >End of life dates have no bearing on my statement. You seem to be trying to change my statement into something else so you can say it is incorrect. It does, as I stated and proved above. Everything you've said is pretty much incorrect, which is the problem. >You can narrow your own statements to only include versions and future timelines that you think are important, which is fine, but it doesn't help those who will still be using the affected versions for years to come. Effectively no one is going to use the impacted versions for years to come. I doubt there are any users reading this comment thread who use RHEL 6 for password generation. >The ELS versions exist for a reason, which should be clear from the fact that Red Hat is a for-profit entity. They exist for the same reason Windows will sell you support for Windows XP, even though that product is also EOL. Are you going to warn the .x% of users that are using Windows XP to not even connect to the Internet? >There is a significant number of projects in areas such as industrial control, defense, and finance, that place a high value on stability and they want that extra timeline that extends far beyond end of life. Finance definitely places a high value on being on supported versions. As a matter of fact, it's against PCI DSS to be on EOL products. They have entire audit and compliance teams to ensure they're not on EOL products.

by 1e-9 6y ago

ThA0x2 6y ago

RHEL 6 is end of life (product retirement) this November. ELS indeed extends out till 2024, but that's after the product has been officially retired/EOLed. Essentially, come November, there will not be a generally supported Linux OS that will have this issue.

1e-9 6y ago
You seem to be arguing that there will be no need to use the --random-source option after November. If so, that is incorrect in my view. ELS versions receive critical security fixes and urgent bug fixes until the end of their support. They are used right up to end of support, or even beyond in some cases. RHEL 5 ELS will be supported thru November 30, 2020 and RHEL 6 ELS will be supported thru June 30, 2024. This implies there will be RHEL 5 ELS users for at least 5 more months and there will be RHEL 6 ELS users for at least 4 more years. So, for at least four more years, it appears there will be users who should use the --random-source option with shuf if they want to be cryptographically secure.
- ThA0x2 6y ago
  >You seem to be arguing that there will be no need to use the --random-source option after November. If so, that is incorrect in my view. The argument is that if you're on a currently supported, non-EOL Linux OS, you will not have this issue after November (since at that point in time, the RHEL 6 will be past end of life). >ELS versions receive critical security fixes and urgent bug fixes until the end of their support. They are used right up to end of support, or even beyond in some cases, although that is certainly not recommended. ELS versions are considered past EOL, and past Maintenance Support I & II. They will not be supported for new installs, will be out of compliance for PCI DSS, HIPPA, almost all third party vendor software, will not be certified on new hardware, etc. They are past their ten year lifecycle. https://endoflife.software/operating-systems/linux/red-hat-enterprise-linux-rhel https://endoflife.software/operating-systems/linux/red-hat-e... https://access.redhat.com/support/policy/updates/errata/#Extended_Life_Cycle_Phase https://access.redhat.com/support/policy/updates/errata/#Ext... Of course the few people on RHEL 6 will have to use the additional --random-source option, but the amount of people that this affects is in the single percentage point, or less. Nothing is stopping someone from spinning up RHEL 5 three years from now and running my original command. My original statements and points stand true. You were originally wrong to think that shuf is cryptographically insecure. It's been cryptographically secure for quite a while now.
  - 1e-9 6y ago
    > The argument is that if you're on a currently supported, non-EOL Linux OS, you will not have this issue after November (since at that point in time, the RHEL 6 will be past end of life). Limiting to only non-EOL and to only future timelines after November are your own chosen statement limitations, not mine. My statement that the shuf default is insecure for certain versions is correct and I have provided specific examples. There may be other examples, but I only need one to establish truth. End of life dates have no bearing on my statement. You seem to be trying to change my statement into something else so you can say it is incorrect. You can narrow your own statements to only include versions and future timelines that you think are important, which is fine, but it doesn't help those who will still be using the affected versions for years to come. The ELS versions exist for a reason, which should be clear from the fact that Red Hat is a for-profit entity. There is a significant number of projects in areas such as industrial control, defense, and finance, that place a high value on stability and they want that extra timeline that extends far beyond end of life.
    - ThA0x2 6y ago
      >Limiting to only non-EOL and to only future timelines after November are your own chosen statement limitations, not mine. My statement was a Linux OS after 2013ish, which means RHEL 7 and Ubuntu 13.02. RHEL 6/5 are not from 2013 or later. >My statement that the shuf default is insecure for certain versions is correct and I have provided specific examples. There may be other examples, but I only need one to establish truth. There are certain default versions of the kernel, bash, etc. that are insecure for certain versions of Linux OS releases. Your statement is meaningless. You can go back in time and find an insecure version of a piece of software, that's almost always true, you established effectively nothing. Whether or not anyone is using that version is what's meaningful. You might as well be warning people not to visit https://correcthorse.pw/ https://correcthorse.pw/ on the default Firefox that ships with RHEL 5 because it had insecure defaults. >End of life dates have no bearing on my statement. You seem to be trying to change my statement into something else so you can say it is incorrect. It does, as I stated and proved above. Everything you've said is pretty much incorrect, which is the problem. >You can narrow your own statements to only include versions and future timelines that you think are important, which is fine, but it doesn't help those who will still be using the affected versions for years to come. Effectively no one is going to use the impacted versions for years to come. I doubt there are any users reading this comment thread who use RHEL 6 for password generation. >The ELS versions exist for a reason, which should be clear from the fact that Red Hat is a for-profit entity. They exist for the same reason Windows will sell you support for Windows XP, even though that product is also EOL. Are you going to warn the .x% of users that are using Windows XP to not even connect to the Internet? >There is a significant number of projects in areas such as industrial control, defense, and finance, that place a high value on stability and they want that extra timeline that extends far beyond end of life. Finance definitely places a high value on being on supported versions. As a matter of fact, it's against PCI DSS to be on EOL products. They have entire audit and compliance teams to ensure they're not on EOL products.