-
Notifications
You must be signed in to change notification settings - Fork 697
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revert unintended spec change re version number syntax #5138
Comments
phadej
added a commit
that referenced
this issue
Mar 3, 2019
- #163 Also resolves #5138 Introduce PkgconfigVersion and PkgconfigVersionRange - `PkgconfigVersion` is compared with `rpmvercmp` - `PkgconfigVersionRange` is subset of `VersionRange` - with `cabal-version` before 3.0 it's parsed like `VersionRange`, where version digits are arbitrary integral (leading spaces allowed) - starting from cabal spec 3.0 `== x.y.*` and `^>=` (and set `{ .. }`) are disallowed. Yet, the version literals syntax is relaxed to accept alphanumerical + `-.` strings. E.g. openssl's `1.1.0h` is accepted. Lax `PkgconfigVersion` parser is also used to parse `pkg-config --modversion` output.
phadej
added a commit
that referenced
this issue
Mar 3, 2019
- Don't accept leading zeros in Version or VersionRange - Fixes #163 (pkg-config uses a more general version scheme) - Also resolves #5138 - `PkgconfigVersion` is compared with `rpmvercmp` - `PkgconfigVersionRange` is subset of `VersionRange` - with `cabal-version` before 3.0 it's parsed like `VersionRange`, where version digits are arbitrary integral (leading spaces allowed) - starting from cabal spec 3.0 `== x.y.*` and `^>=` (and set `{ .. }`) are disallowed. Yet, the version literals syntax is relaxed to accept alphanumerical + `-.` strings. E.g. openssl's `1.1.0h` is accepted. - Lax `PkgconfigVersion` parser is also used to parse `pkg-config --modversion` output.
phadej
added a commit
that referenced
this issue
Mar 3, 2019
- Don't accept leading zeros in Version or VersionRange - Fixes #163 (pkg-config uses a more general version scheme) - Also resolves #5138 - `PkgconfigVersion` is compared with `rpmvercmp` - `PkgconfigVersionRange` is subset of `VersionRange` - with `cabal-version` before 3.0 it's parsed like `VersionRange`, where version digits are arbitrary integral (leading spaces allowed) - starting from cabal spec 3.0 `== x.y.*` and `^>=` (and set `{ .. }`) are disallowed. Yet, the version literals syntax is relaxed to accept alphanumerical + `-.` strings. E.g. openssl's `1.1.0h` is accepted. - Lax `PkgconfigVersion` parser is also used to parse `pkg-config --modversion` output.
phadej
added a commit
that referenced
this issue
Mar 3, 2019
- Don't accept leading zeros in Version or VersionRange - Fixes #163 (pkg-config uses a more general version scheme) - Also resolves #5138 - `PkgconfigVersion` is compared with `rpmvercmp` - `PkgconfigVersionRange` is subset of `VersionRange` - with `cabal-version` before 3.0 it's parsed like `VersionRange`, where version digits are arbitrary integral (leading spaces allowed) - starting from cabal spec 3.0 `== x.y.*` and `^>=` (and set `{ .. }`) are disallowed. Yet, the version literals syntax is relaxed to accept alphanumerical + `-.` strings. E.g. openssl's `1.1.0h` is accepted. - Lax `PkgconfigVersion` parser is also used to parse `pkg-config --modversion` output.
phadej
added a commit
that referenced
this issue
Mar 3, 2019
- Don't accept leading zeros in Version or VersionRange - Fixes #163 (pkg-config uses a more general version scheme) - Also resolves #5138 - `PkgconfigVersion` is compared with `rpmvercmp` - `PkgconfigVersionRange` is subset of `VersionRange` - with `cabal-version` before 3.0 it's parsed like `VersionRange`, where version digits are arbitrary integral (leading spaces allowed) - starting from cabal spec 3.0 `== x.y.*` and `^>=` (and set `{ .. }`) are disallowed. Yet, the version literals syntax is relaxed to accept alphanumerical + `-.` strings. E.g. openssl's `1.1.0h` is accepted. - Lax `PkgconfigVersion` parser is also used to parse `pkg-config --modversion` output.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#5092 hghlighted an issue where a change in cabal 1.24 resulted in an unintended change to the cabal specification, specifically relaxing the version parser to unintentionally allow for denormalised version numbers (which are not isomorphic to
NonEmpty Natural
(where strictly speaking,Natural
has an upper bound)).Since there's little benefit to allow denormalisation, and it mostly causes subtly problems as e.g. it would violate an implicit assumption code may have head about version numbers round-tripping loss-free, causes trouble to older parsers, complicates the parser as it needs to support and keep track whether it encountered a denormalised version number, this may offer an opportunity for denial of service attacks and/or exploits (I've got more planned in this area, but I don't want to discuss this publicly before we don't have counter measures in place), but most importantly, this wasn't an intentional change to the spec to begin with, we shall consider this spec change to be a bug, and act accordingly.
Measures that were taken already
00-index.tar
index will not be exposed to the original revisions which featured the invalid.cabal
files.cabal check
complain about invalid.cabal
files.cabal
files with the invalid syntax to enter the index from now on.Next steps
Since
cabal > 1.24
currently happily tolerate denormal version numbers, and hackage now actively prevents from more invalid entries entering the package index, the next steps are not "urgent", and can be done whenever convenient:.cabal
revisions which have become part of the01-index.tar
index, as well as are included in the original.tar.gz
to cabal's parser quirk-DBcabal check
warnings).The text was updated successfully, but these errors were encountered: