Add GitLab cataloger

[RyanHopkins7]

Adds a cataloger for GitLab installations meant to close #1904
I ran into a couple questions and problems while developing my new cataloger. I was hoping to get some help/direction in order to get this PR into a finalized state. It seems like some of the documentation about adding new catalogers might be a little bit outdated. Also, I just wanted to mention that I'm fairly new to open source. :)

• The documentation mentions adding catalogers to the global list of catalogers, but it looks like this was removed by Replace core SBOM-creation API with builder pattern #1383. What should be the new process for adding a cataloger?
• I'm a little unsure about the correct package URL format for GitLab. The PURL documentation mentions GitHub packages, and I tried to base my code off of that, but I'm not certain if that is correct or not.

Thank you!

[spiffcs]

👋 Hey @RyanHopkins7 thanks so much for the PR here!

The documentation mentions adding catalogers to the global list of catalogers, but it looks like this was removed by #1383. What should be the new process for adding a cataloger?

Great catch! I'll get that updated. In the meantime you can find catalogers initialized here:

syft/internal/task/package_tasks.go

Line 38 in e7b6284

newSimplePackageTaskFactory(arch.NewDBCataloger, pkgcataloging.DirectoryTag, pkgcataloging.InstalledTag, pkgcataloging.ImageTag, pkgcataloging.OSTag, "linux", "alpm", "archlinux"),

Which is called here:

syft/cmd/syft/internal/commands/cataloger_list.go

Line 56 in e7b6284

factories := task.DefaultPackageTaskFactories()

You're right this needs a comprehensive update in the documentation. I'll get on that as soon as I have some time.

I'm a little unsure about the correct package URL format for GitLab. The PURL documentation mentions GitHub packages, and I tried to base my code off of that, but I'm not certain if that is correct or not.

Types to Define

It looks like they still have to define this. You're initial assumption seems good, but I would reach out and file an issue on their repo just to be sure =)

I ran the PR actions to show where we are as far as CI goes.

As to getting this into a final state. Let me see if I can take some time this week to help push this along for you.

[wagoodman]

@RyanHopkins7 would you like help getting this across the finishline?

[willmurphyscode]

I've added some research questions here: #1904 (comment)

We probably want to figure out the answers to these as part of getting this change in.

[wagoodman]

Bringing the conversation back from the issue to here again... I think we should make the following changes:

• explicitly list package types as unknown pkg.UnknownPkg
• drop adding PURLs as what is being crafted now is not in spec
• add a new metadata type in the pkg package that represents a GitlabVersionManifestEntry with all of the discovered information
• there are raw license material that could be correlated to the new packages being raised up

Something we could consider is a relationships-task update where any know package types (say the debian gitlab-ce package) that has file ownership overlap with other files owned by packages with an unknown type (in this case all version-manifest packages) automatically get a dependency-of relationship between the two packages.

This would mean we could drop the RELEASE file parsing altogether.

What do folks think @willmurphyscode @RyanHopkins7 ? (I'm happy to help with the changes)