google
- add conan.lock to the list
/cc @prince-chrismc
there are several formats of conan lockfile available in the wild (lockfiles are versioned separately from the conan client itself, as not every conan release changes the format of lockfile):
- initial, unversioned (
0.0) - added in conan 1.17 0.1added in conan 1.18, added versioning to the lockfile format0.2added in conan 1.21, added deterministic lockfiles0.3added in conan 1.22, changed how nodes reference each other0.4added in conan 1.28, the format mostly used currently in production and encountered most often0.5is used by conan 2.0+ (currently, as of December 2022, still in beta state, and not yet released)
formats 0.0 - 0.4 are mostly similar and use graph_lock with a list of nodes.
format 0.5 is a major overhaul, it's a completely new implementation developed from scratch.
some information about 0.0 - 0.4 lockfiles (current format used in production):
- doc: lockfiles
- doc: using recipe revisions and lockfiles
- Conan 1.34 : New lockfile feature "bundles", Resource shift to Conan V2.0, Merged Tribe Proposals
- Conan 1.32: New validate() Method, First configurable Generator (MSBuildDeps), Renamed Multiple Toolchains & Generators, 2 New Meson Classes, Improve Lockfile Support for Private Requirements, Support for build_requires to Affect package_id (Workaround)
- Conan 1.29: Updates to multiple generators, new tools.rename function, experimental toolchain for gnu make, lockfile bug fixes
- Conan 1.28: Lockfile improvements, Four new conanfile.py attributes, Improved Clang support on Windows, Support components in pkg_config generator, Define generator filenames
- Conan 1.17: The Conan user survey, lockfiles, new graph commands, package ID modes for revisions, apple-clang 11.0 support and usability improvements
more information about 0.5 lockfiles used in conan 2.0:
the format itself is not documented, but can be learnt by studying the source code graph_lock.py. as it's currently not expected lockfiles to be manually or automatically edited by users or tools, they are only generated by the conan client itself during the graph resolution process, and afterwards, lockfiles are fully immutable.
for the version comparison, conan client itself uses version ranges to compare versions, but it's only for packages that follow SemVer (a majority of C and C++ libraries don't follow SemVer, or even predate it). as different libraries use various versioning schemes, conan client cannot make any assumtions. however, lockfile represents a resolved graph state, with all the version ranges already computed. therefore, versions in lockfiles are compared as regular strings.
It needs to be implemented in https://github.com/google/osv-scanner/tree/main/pkg/lockfile 🙊
@SSE4 I've done an initial review and nothing huge has jumped out at me as needing to be changed - I'm not familiar with this ecosystem/tool at all; would you happen to have any references to the lockfile (ideally a spec would be great, but not all ecosystems have those).
It would also be good to know how the version comparison is actually done if you know that too.
@SSE4 I've done an initial review and nothing huge has jumped out at me as needing to be changed - I'm not familiar with this ecosystem/tool at all; would you happen to have any references to the lockfile (ideally a spec would be great, but not all ecosystems have those).
It would also be good to know how the version comparison is actually done if you know that too.
thanks, I've updated the PR description. lemme know if you have any further question.
@G-Rath how do we move this forward? please let me know if you need anything else from my side.
@SSE4 the main thing that needs addressing is this comment - otherwise everything looks ok
okay, I've changed ecosystem name conan.io to conan and added TODO you have suggested.
@G-Rath I think all concerns from reviews were addressed. btw, no idea what's wrong with CI, it doesn't show any useful log for me...
@SSE4 I might have missed it, but it looks like you don't have a test for when a package exists without a name? if so I think that is important to have, to close off the loop; otherwise LGTM 👍
@SSE4 I might have missed it, but it looks like you don't have a test for when a package exists without a name? if so I think that is important to have, to close off the loop; otherwise LGTM +1
I'll add some tests with synthetic lockfiles, as I can't generate such with client.
@SSE4 I might have missed it, but it looks like you don't have a test for when a package exists without a name? if so I think that is important to have, to close off the loop; otherwise LGTM +1
now all done
Looks good to me, just waiting for (ossf/osv-schema#101) to be accepted before merging this in.
it's merged now