Archive or delete this repo

[sebgoa]

Now that we have a formulae in Homebrew core Homebrew/homebrew-core#83053 we can stop using this tap.

@sameersbn what do you think

[sameersbn]

I agree. Once the doc changes are in place this repository can be archieved

[rhuss]

Actually, I still would like to keep it and add some automation for updating the upstream tap as well as the tap here in case of a release.

The idea is to have arelease.sh that will:

• Update directly the formulas in this direct by picking up the checksums from the binary release of kn repos
• Create a PR request on the Homebre repo to update the formulas there.

@sameersbn do you know whether we can easily create formulas also for older versions of kn on the homebrew main repo ? I guess this is not well accepted (e.g. when we have more than one older release that we want to keep).

So for installing older kn I'd recommend still keeping this repo. Old (supported) version's of kn might be needed when running against older installation of Knative that have not been updated to the latest knative release.

[sameersbn]

add some automation for updating the upstream tap

Actually this is not required. Homebrew automatically tracks the releases on github and updates the formula for the new release. f.e. I had submitted the formula with v0.24.0 and the kn version currently available in homebrew is v0.25.1.

easily create formulas also for older versions

For every kn release series we want updated, we'd have to duplicate the formula similar to https://github.com/Homebrew/homebrew-core/blob/master/Formula/ruby%402.6.rb. I couldn't find any acceptance criteria for having multiple versions of the same tool in homebrew. So we could definitely try.

[rhuss]

I see.

While we are at it, I think the formula need to be updated for 0.27 as we just have merged knative/client#1462 that allows for some automation of the dependency versions shown in kn version. I guess we would need a similar parsing of go.mod like in our build script.

I wonder whether we could reuse hack/build.sh for building the binary on the Homebrew site ? This is easier than to track any change in the build process for kn. Also, if some special compilation is needed we could add it with an extra flag to build.sh.

[sameersbn]

I wonder whether we could reuse hack/build.sh for building the binary on the Homebrew site ?

originally i used build.sh and they didn't really like it, so we'd have to update the formula instead.

[rhuss]

originally i used build.sh and they didn't really like it, so we'd have to update the formula instead.

ok, so we probably have to live with the fact the binaries that you can download from the web page and the one created by brew might differ (so probably they will differ anyway).

I wonder how they deal with Golang CVEs. Are they tracked individually and rebuild the binaries for the same version? I hope not. Actually, we go a lot of golang CVEs recently that forced us to create new patch releases. I wonder how we can deal with this, is there a way to specify the very exact golang version to use for creating the binary?

From that POV I'm not so super happy anymore to have two different binaries that potentially differ because of different build processes and they both would have to monitor.

[rhuss]

I can't really see where we specify the go version in the formula.

[sameersbn]

I can't really see where we specify the go version in the formula.

I may be wrong, but from what I can tell there is a version field that can be specified. when not specified, this field is auto detected from the url. Since we're using the git repo url for the builds, i'd need to check how it would work in our case.

Are they tracked individually and rebuild the binaries for the same version?

I am not really sure about this. But if I had to guess: they won't build the same version again.

is there a way to specify the very exact golang version to use for creating the binary?

yes, we can pin go versions like so depends_on "go@1.16" => :build. But if we pin the current go version, then they will ask us to unpin the version.

[rhuss]

I see. To not have full control over the golang version (down to the patch level) will give us some headaches in the future. I find it even more critical that we even don't know which exact golang version is used to create the binary.

See for example the following golang related CVEs that caused us at Red Hat to create a new kn version by just respinning a new build with an updated version of golang:

• CVE-2021-29923 net: incorrect parsing of extraneous zero characters at the beginning of an IP address octet (fixed since go 1.17)
• CVE-2021-36221 golang: net/http/httputil: panic due to racy read of persistConn after handler panic (fixed in golang v1.15.15)
• CVE-2021-39293 golang: archive/zip: malformed archive may cause panic or memory exhaustion (incomplete fix of CVE-2021-33196)

These are only some examples, not necessarily blocking CVEs, but you get the idea. If you don't have control over the exact go compiler used for compiling kn we can't fix those issues in core brew when they arise (even when they would be supercritical)

I wonder whether the slight comfort win between brew install kn and brew install knative/client/kn would be worth this trouble to keep two brew setups alive? (alone because of the issues above I would not give up this repository)

[rhuss]

Let me ask on the homebrew repo how they would tackle such situations.

[rhuss]

I started a discussion over there to find out how we could fix this in homebrew-core --> Homebrew/discussions#2185

[SMillerDev]

ok, so we probably have to live with the fact the binaries that you can download from the web page and the one created by brew might differ (so probably they will differ anyway).

https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap#official-vendor-taps touches a bit on this.

[rhuss]

Thanks for the pointer, this clarifies the philosophy a bit.

Besides the concern that I have wrt/ respins and specific golang versions to build, I also wonder whether we might run into issue the homebrew uses a new compiler than the one that we have tested. E.g. currently homebrew/kn is compiled with golang 1.17.1 while our binaries (like the rest of Knative) is compiled and tested with golang 1.16. This can cause all kinds of troubles for user of the core homebrew kn when using a kn that has not been tested for the specific golang version that it is compiled with.

[rhuss]

From the clarification in Homebrew/discussions#2185

No, for homebrew-core the Formula will always be build with the newest possible Go version. As upstream you have just as much control as everyone else, you can make a PR to fix things if they're broken.

I think we should go back to this repo to keep full control over the golang compiler to use (and the build process in general)

@sebgoa @sameersbn @omerbensaadon what is your opinion on this issue ? @sameersbn know, you invested quite a bit in that change and your help to get this to homebrew-core is highly appreciated, but I'm really concerned about the stability and supportability of a binary that has been produced with a newer golang compiler than what we are using for our unit and integration tests.

If you don't mind I would like to bring this topic to the TOC for the next working group meeting.