`zencart/zencart` crashes the detail view

[Marco Pivetta]

Ref: Roave/SecurityAdvisoriesBuilder#735
Ref: https://packagist.org/packages/zencart/zencart

Package shows correctly in search, but crashes the detail page.

This may be related with its exotic versioning scheme, for example: https://github.com/zencart/zencart/releases/tag/v1.5.7d

[Marco Pivetta]

I actually verified that Roave/SecurityAdvisoriesBuilder#735 is because composer validate rejects the version constraint declared in this advisory:

STDERR:
    
    In VersionParser.php line 521:
                                                                                   
      Could not parse version constraint < 1.5.5e: Invalid version string "1.5.5e  
      "                                                                            
                                                                                   
    
    validate [--no-check-all] [--check-lock] [--no-check-lock] [--no-check-publish] [--no-check-version] [-A|--with-dependencies] [--strict] [--] [<file>]
    
     in /home/runner/work/SecurityAdvisoriesBuilder/SecurityAdvisoriesBuilder/vendor/azjezz/psl/src/Psl/Shell/execute.php:180
Stack trace:
#0 /home/runner/work/SecurityAdvisoriesBuilder/SecurityAdvisoriesBuilder/build-conflicts.php(152): Psl\Shell\execute()
#1 /home/runner/work/SecurityAdvisoriesBuilder/SecurityAdvisoriesBuilder/build-conflicts.php(225): Roave\SecurityAdvisories\{closure}()
#2 /home/runner/work/SecurityAdvisoriesBuilder/SecurityAdvisoriesBuilder/build-conflicts.php(232): Roave\SecurityAdvisories\{closure}()
#3 {main}

The question here is whether I should open the flood gates, and have such a version constraint as part of composer.json published at https://packagist.org/packages/roave/security-advisories, or whether I should somehow filter it out.

Right now, this sort of constraint crashes packagist.org, so I'm hesitant to let it through D:

[Chris Brown]

I'm one of the zencart/zencart owners.

Due to some legacy reasons semver was not embraced, nor switched to.
But it may be possible to switch to proper SemVer in the next month or so. We're working on that internally with the team.

Question: would releasing a version that does not have alphabetic suffixes "fix" the current packagist page? or would the historical tags still break things?

[Marco Pivetta]

Historical tags are still picked up: could publish the packagist version off a copy of the repo that doesn't have the problematic tags, but I'd wait to see if this is an issue that requires intervention in Composer / Packagist itself :D

[Chris Brown]

@Seldaek how best to fix this? https://packagist.org/packages/zencart/zencart

[Jordi Boggiano]

I deployed a hotfix for now that unbreaks the page by ignoring the version parsing errors, but I'll have to dig further into this because I don't know why it fails if the version parses enough to be added to packagist, why is it rejecting it as a constraint 🤷🏻‍♂️

Also the sorting of versions on the package page is definitely not optimal.. But then again this versioning scheme is hardly ever used so not super critical either.

Anyway leaving this open for now.

[Chris Brown]

Thanks!

[Jordi Boggiano]

Ah ok now I see what happened. 1.5.8a was parsed as 1.5.8.0-alpha and same for b it turned into beta. But then c/d/.. fail to parse and you can see the tags were ignored and do not show up on packagist. That also explains why 1.5.8a sorted below 1.5.8.

And as the security advisories contain an e version constraint that did not parse. So yes.. I guess I'll keep the error-suppression when parsing constraints from advisories as we do not (and probably cannot) validate them on import.

[Uladzimir Tsykun]

This still happens when clicking on the security advisor icon
https://packagist.org/packages/zencart/zencart/advisories?version=4673493

[Jordi Boggiano]

Ah yes thanks, I checked that page but not with a version 🤦🏻

Works as well now!