Provide easier ways of installing the client

[Okeanos]

It would be very cool if you could provide easier/more convenient ways of installing the sechub client binary.

Specifically, it would be very cool if you could provide a

• Homebrew formula for macOS
• winget manifest for Windows
• Snap for Ubuntu/Linux (or maybe a Flatpak version) or if it makes more sense a .deb or .rpm package.

This would greatly increase the developer experience around the sechub cli.

[sven-dmlr]

Hi @Okeanos Great idea! We already thought about building packages:

1. It's a high effort to learn each packaging system and to maintain the packages
2. Usually, for each you will have to create and handle signing keys and get them approved
3. A big question for some formats is: Where can we host the package?
4. Basically, the package only contains the sechub binary - so there's almost no additional gain besides the convenient installation.

I just have created #2337. This is relatively easy to add to our release workflow. We will implement this in the future.

Besides that: If you can contribute code for building one/more package formats locally, feel free to provide a PR with your solution. See CONTRIBUTING.MD for details.

If you have knowledge on how to build and publish one of the above mentioned package formats: We would be happy when you build and publish a SecHub client package. :-) Please inform us and we will mention it in our documentation.

[Okeanos]

At least for brew and winget the only thing that would have to be maintained additionally are the manifests/formula files – they usually refer to the official release binaries that are attached to the GitHub releases.

Snap/deb/rpm etc. – yeah that's gonna be tricky but I didn't want to leave the Linux fraction unmentioned here.

---

Manifest and formula refer to descriptions for winget and brew respectively that explain what sechub is and where it can be downloaded from.

See for example the Manifest for yq 4.33.3 and the formula for 4.34.1.

I believe in both cases you could maintain the formula independently from the official repositories by offering a source or a tap – I have no idea how hosting a source for winget would work. Brew "simply" consumes Git repositories.

[Jeeppler]

@Okeanos as a FOSS project we welcome you to contribute a brew and/or winget package. As @sven-dmlr already pointed out.

• The problem with brew: None of our developers has a macOS or experience with brew.
• The problem with winget: None of our developers has experience with winget. In addition, what is the difference between winget and Chocolatey?

Please feel free to open a pull request for brew and winget.

Regarding Snap and Flatpak. What would be the benefit of supporting those? We already provide the sechub binary as a single executable binary. Soon, we will provide a public docker image in addition to that: #2337.

I understand the benefit of .deb and .rpm packages, but how would you suggest should they be distributed? In case of Debian/Ubuntu as PPA? What about .rpm?

[Okeanos]

The difference between Chocolatey and Winget is easy: Winget is provided & maintained by Microsoft and part of Windows 10 and beyond by default. It even comes pre-installed on enterprise Windows (to my knowledge) and requires very little in terms of setup to get to work (even on enterprise editions). Whereas Chocolatey (and scoop) is a third party offering of a package manager and definitely has problems in enterprise environments – in the end they do very similar things, though.

I'll see whether I do have time to create a Manifest/Formula for winget and brew respectively. No promises, though. Before I can do that there's some input from you desired, though. Especially for winget a rather complete manifest is likely in your own interest, specifically with official input in the data that will go in there. Please have a look at e.g. yq, Eclipse Temurin or jq manifest files and tell me what would be respective values for sechub concerning stuff like "Publisher" or "PublisherSupportUrl". A lot can be omitted (see jq) but … eh, better you give input beforehand. For brew none of that is really required, they don't store these things in the formulae.

Snap and Flatpak (and to some degree .deb, .rpm) were merely mentioned by me for reference – as in: they are established distribution mechanisms for (pre-packaged) software in their respective Linux distributions (Ubuntu, Fedora, etc.) that facilitate better access to updates and more streamlined installation mechanisms. (Not necessarily better mind you).

The goal behind my issue is mainly making consuming the client binaries easier in some ways. I understand that "just download it and put it onto the $PATH" works wonders and is … as easy as it gets. There's just a few situations (updates for example or scripting a local development setup) where it's not as convenient as an established package manager.

I am perfectly fine with out-scoping Linux (in all its flavours) because of the inherent complexity, though. Especially once you also offer the docker image.