Composer version not always a string
While analyzer a composer.lock file we have the following error:
(extracting as composer.lock) could not extract from /app/composer.lock: json: cannot unmarshal number into Go struct field ComposerPackage.packages.version of type string
The version in this case is not a string:
➜ /tmp grep version composer.lock
"version": "5.9.1",
"version": "1.99",
"version": "0.1.1",
"version": "1.2.8",
"version": "v1.9.0",
"version": "4.6.2",
"version": "v2.11.0",
"version": "5.5.3",
"version": "5.5.3",
"version": "2.0.0",
"version": "v1.8.0",
"version": "v0.8.1",
"version": "1.8.2",
"version": "2.4.20.3",
"version": "2.6.1",
"version": "3.7.2",
"version": "1.4.3",
"version": "20190220",
"version": "1.11.5",
"version": "3.1",
"version": "1.5",
"version": "0.5.7",
Can you name the package(s) with the erroring versions? My understanding is that composer requires versions to be semantic
Thanks @G-Rath for the quick answer. The package name is wpackagist-plugin/block-bad-queries.
Cool thanks - if you can, it would be good if you could provide a small but complete lock file reproducing the error but otherwise now that I've got the name I can look into it tomorrow morning :)
Awesome thanks @G-Rath . Here is a link to the file.
@3asm could you speak more about how you generated this, including the composer version and json file?
I suspect this is technically invalid (or maybe not natural?) - using this composer.json:
{
"repositories": [
{
"type": "composer",
"url": "https://wpackagist.org",
"only": [
"wpackagist-plugin/*",
"wpackagist-theme/*"
]
}
],
"require": {
"wpackagist-plugin/block-bad-queries": "20190220"
},
"config": {
"allow-plugins": {
"composer/installers": true
}
}
}
Gives me a lockfile with that version but as a string rather than a number.
In saying that if I edit the lockfile to be a number, composer doesn't seem to complain...
It should be straightforward to support this case (we've having to do it in a couple of the other parsers), but interested in knowing more about it's real-world implications since this is the first time I've come across this
@3asm Friendly ping on if you know how this file is generated? :)
Sorry @another-rex I missed that. No, I don't, the file was collected during a vulnerability scan.
Déjate de pendejafad
Closing for now since it hasn't really popped up again.