9 ms·

Interesting. They stopped using /dev/urandom as the default random file in version 7.3, which created the insecure default situation. Later, in version 8.6, the

by 1e-9 6y ago

Interesting. They stopped using /dev/urandom as the default random file in version 7.3, which created the insecure default situation. Later, in version 8.6, they updated to use a default nonce from /dev/urandom. It's odd that the documentation has not be updated. Perhaps it's because the latest version will still default to an insecure nonce if there is no /dev/urandom?

ThA0x2 6y ago
If you're on a Linux OS that's from ~2013 or later, then you're most likely on a version of coreutils that will default to /dev/urandom. The master branch of coreutils is using getrandom(2). It will continue to draw entropy from the urandom source by default.
- 1e-9 6y ago
  The latest versions of RHEL/CentOS 6 use coreutils version 8.4, so I assume their shuf defaults to insecure. I imagine that RHEL 5 ELS must have the same issue. I don't know of any other currently-supported Linux or BSD versions that might be a problem.
  - ThA0x2 6y ago
    RHEL 5 is from 2007, and is already past end of life (end of extended support is this November). RHEL 6 is from 2009, and it's end of life is this November. Both of those OS are not from 2013 or later. They may have minor versions that were released later, but minor versions typically don't make significant changes to core packages. RHEL 7 (2014) and Ubuntu 13.04 both have coreutils 8.20 or newer.
    - 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.

by 1e-9 6y ago

ThA0x2 6y ago

If you're on a Linux OS that's from ~2013 or later, then you're most likely on a version of coreutils that will default to /dev/urandom. The master branch of coreutils is using getrandom(2). It will continue to draw entropy from the urandom source by default.

1e-9 6y ago
The latest versions of RHEL/CentOS 6 use coreutils version 8.4, so I assume their shuf defaults to insecure. I imagine that RHEL 5 ELS must have the same issue. I don't know of any other currently-supported Linux or BSD versions that might be a problem.
- ThA0x2 6y ago
  RHEL 5 is from 2007, and is already past end of life (end of extended support is this November). RHEL 6 is from 2009, and it's end of life is this November. Both of those OS are not from 2013 or later. They may have minor versions that were released later, but minor versions typically don't make significant changes to core packages. RHEL 7 (2014) and Ubuntu 13.04 both have coreutils 8.20 or newer.
  - 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.