Skip to content
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

Closed
hvr opened this issue Feb 12, 2018 · 0 comments
Closed

Revert unintended spec change re version number syntax #5138

hvr opened this issue Feb 12, 2018 · 0 comments

Comments

@hvr
Copy link
Member

hvr commented Feb 12, 2018

#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

  1. The 4 index entries on Hackage were revised (c.f. Invalid version number syntax for pre 1.24 spec versions haskell-infra/hackage-trustees#128); this means that clients which consume the 00-index.tar index will not be exposed to the original revisions which featured the invalid .cabal files.
  2. cabal 2.2's parser was extended to detect denormalisation in order to have cabal check complain about invalid .cabal files
  3. Hackage-server was retrofitted with an additional validation check which prevents new .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:

  • Add the 4 historic original .cabal revisions which have become part of the 01-index.tar index, as well as are included in the original .tar.gz to cabal's parser quirk-DB
  • Remove support from the parsec parser for parsing (the invalid) denormal version numbers, turning them into ordinary parser failures (rather than cabal check warnings).
@phadej phadej self-assigned this Feb 19, 2018
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.
@phadej phadej closed this as completed in 01df85e Mar 4, 2019
@hvr hvr added this to the 3.0 milestone Mar 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants