This ensures that `lib.platforms.darwin` doesn’t include
`x86_64-darwin` and that the unsupported platform check will trigger
even once the bespoke deprecation error is removed. It doesn’t break
`lib.systems.elaborate "x86_64-darwin"`.
This might be a nice way to use our reach to remind users to donate to
FLOSS projects that they use and love.
Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>
The previous claims are unsourced, since they are not supported by the
source given for CPEs.
Quoting from the 5.3.3.5 section of the NISTIR 7695 document:
> Values for this attribute SHOULD be vendor-specific alphanumeric
> strings characterizing the particular update, service pack, or
> point release of the product.
So, first, they should be ***vendor-specific***, and dare I say,
vendor-specified. But let's not trip on the carpet's flower pattern, and
instead look at evidence from data.
Using the data from `official-cpe-dictionary_v2.3.xml`, gently massaged
into a form that can be queried, we can list all known CPE expressions
for glibc.
There is only one known entry using the `update` field. It's:
```
cpe:2.3:a:gnu:glibc:2.0.5🅱️*:*:*:*:*:*
```
As such, the current example is plainly and demonstrably wrong.
```
SELECT * FROM cpe
WHERE cpe_update != ''
AND cpe_vendor = 'gnu'
AND cpe_product = 'glibc'
ORDER BY cpe_vendor, cpe_product, cpe_version
id |title |cpe_part|cpe_vendor|cpe_product|cpe_version|cpe_update|cpe_edition|cpe_language|cpe_sw_edition|cpe_target_sw|cpe_target_hw|cpe_other|
------+-----------------+--------+----------+-----------+-----------+----------+-----------+------------+--------------+-------------+-------------+---------+
460867|GNU glibc 2.0.5 B|a |gnu |glibc |2.0.5 |b | | | | | | |
```
Let's see good examples of `cpe_product` in contrast:
```
SELECT * FROM cpe
WHERE cpe_update != ''
AND cpe_vendor = 'gnu'
AND cpe_product = 'bash'
ORDER BY cpe_vendor, cpe_product, cpe_version DESC
LIMIT 10
id |title |cpe_part|cpe_vendor|cpe_product|cpe_version|cpe_update|cpe_edition|cpe_language|cpe_sw_edition|cpe_target_sw|cpe_target_hw|cpe_other|
------+--------------------------------------------------------------+--------+----------+-----------+-----------+----------+-----------+------------+--------------+-------------+-------------+---------+
460088|GNU Bourne-Again SHell bash (GNU Bash) 4.3.30 Beta 1 |a |gnu |bash |4.3.30 |beta1 | | | | | | |
460086|GNU Bourne-Again SHell bash (GNU Bash) 4.2.53 Beta 1 |a |gnu |bash |4.2.53 |beta1 | | | | | | |
460081|GNU Bourne-Again SHell bash (GNU Bash) 3.2.57 Beta 1 |a |gnu |bash |3.2.57 |beta1 | | | | | | |
460140|GNU Bourne-Again SHell bash (GNU Bash) 5.2 |a |gnu |bash |5.2 |- | | | | | | |
460141|GNU Bourne-Again SHell bash (GNU Bash) 5.2 Alpha |a |gnu |bash |5.2 |alpha | | | | | | |
460142|GNU Bourne-Again SHell bash (GNU Bash) 5.2 Beta |a |gnu |bash |5.2 |beta | | | | | | |
460143|GNU Bourne-Again SHell bash (GNU Bash) 5.2 Release Candidate 1|a |gnu |bash |5.2 |rc1 | | | | | | |
460144|GNU Bourne-Again SHell bash (GNU Bash) 5.2 Release Candidate 2|a |gnu |bash |5.2 |rc2 | | | | | | |
460145|GNU Bourne-Again SHell bash (GNU Bash) 5.2 Release Candidate 3|a |gnu |bash |5.2 |rc3 | | | | | | |
460146|GNU Bourne-Again SHell bash (GNU Bash) 5.2 Release Candidate 4|a |gnu |bash |5.2 |rc4 | | | | | | |
```
The field could have been simply removed from the list, as it is not
used, but it should be present in that form at least for *some
undefined* length of time to present as a correction for anyone using
the `edition` field mistakenly.
My claim comes from the literal source listed in the next paragraph
(NISTIR 7695), the first few words of `5.3.3.6` are:
> The edition attribute is considered deprecated
Thus we consider it deprecated.
Furthermore the section documents that it should be using the value
`ANY`. It could be considered debatable as `NA` should be used “when
there is no legal or meaningful value for that attribute, or when
that attribute is not used as part of the description”... But the spec
states that `ANY` should be used, so we state `ANY` should be used.
The original wording missed the *not meaningful* nuance, and adding an
`or` clause within the sentence would have made it hard to understand.
Instead, it is now split into a list, and ordered in the same order as
found in `5.3.1` in NISTIR 7695.
The logical name used by the specification (ANY/NA) was also added.
The line was in grammatical error or plain confusing, it has been revised to be grammatically correct, as well as revised to be a bit more technically correct, as well as useful to the reader.
Fixes#488258
Co-authored-by: Robert Hensing <robert@roberthensing.nl>
as with glibcxxassertions, we don't yet have a nice mechanism
for deferring support decisions to the c++ library in use, so
for now at least enabling this hardening flag will cause
_LIBCPP_HARDENING_MODE to be defined on all compilers
nixpkgs-ci[bot]