Publish cosign binaries to Sonatype OSSRH

[vlsi]

Description

I suggest adding a module to publish cosign binaries to Central.
That would enable consumers to download the needed binaries and execute cosign CLI.

See how protobuf plugin locates protoc binary: https://github.com/google/protobuf-gradle-plugin#locate-external-executables

An alternative option is to add publishing to cosign project itself.

[loosebazooka]

An alternative option is to add publishing to cosign project itself.

I think this makes the most sense. I wonder if we can write the action here and execute on cosign releases?

[vlsi]

I have not explored how cosign is released, however, I just assumed that publishing cosign-as-jar would be easier from Gradle-based project (it could include Gradle Metadata for easier usage by consumers), and adding Gradle build to cosign might sound strange

[loosebazooka]

Yeah I don't mind doing it here if we can trigger by watching for new "releases" from cosign

[vlsi]

I guess it implies the current project should becomes multi-module one

[loosebazooka]

It could also just be multiple projects (or a new repo)

[vlsi]

I'm inclined that co-locating into a single repo might be easier to manage.

For instance, what if people want to have rekor-api and fulcio-api as separate dependencies?
What if they want cosign-binary-wrapped-as-java-api as yet another dependency?
It looks like having a single repo makes it easier to slice the modules (e.g. to reduce the attack surface), and it would probably reduce the buildscript churn.

Frankly speaking, I think it might be fine to have both low-level Java libraries, Gradle, and maybe even Maven plugins within a single repository.

[vlsi]

It turns out cosign binaries are like 80-140 MiB, so I'm not sure we want to duplicate those releases to Central.
We might want to wait on the outcome of sigstore/cosign#1462 first.

https://github.com/sigstore/cosign/releases/tag/v1.12.0

88.5 MB cosign-darwin-amd64
82.1 MB cosign-linux-arm64
144 MB cosign-windows-amd64.exe

[loosebazooka]

probably not doing this in the near future