Giters

knative / homebrew-client

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Archive or delete this repo

sebgoa opened this issue · comments

commented

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

@sameersbn what do you think

commented

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

commented

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.

commented

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.

commented

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.

commented

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.

commented

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.

commented

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

commented

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.

commented

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)

commented

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

commented

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

commented

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.

commented

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.

commented

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.

commented

Time to start testing pre-release Go versions 😅.

More seriously though, if there are tests we can add to the formula that would be good to have a pull request for. In either way, we likely won't be pulling the software from homebrew/core. So the best way would be to figure out together how to make the testing more robust.

Another solution is like the one we have with Hashicorp. They have tap for "stable tested" releases, and we have core where we have bleeding edge versions.

commented

More seriously though, if there are tests we can add to the formula that would be good to have a pull request for. In either way, we likely won't be pulling the software from homebrew/core. So the best way would be to figure out together how to make the testing more robust.

Completely understand your reasoning (and we don't ask for an exception for kn here if this is against the policy you point out in https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap#official-vendor-taps (although Knative is pure OpenSource with everything in the open), but I'm afraid that it would take a huge amount of efforts to mirror our testing in a Homebrew formula and this is probably out of scope. Running a unit test suite might still be feasible, but we have a comprehensive CI test suite where one run takes around 30 minutes and creates ad-hoc a Kubernetes cluster of a certain version, including the corresponding Knative backend installation (there are 2 runs, one against the nightly version, one against the latest released version). I wouldn't mind skipping those tests when packaging for brew when we could be confident that the binary produced by brew is 'sufficiently close' to the one we test in our upstream ci pipeline. But having two binaries compiled with two different go compilers (different in the minor version level) is not what I think will produce 'sufficient similar' binaries.

Another solution is like the one we have with Hashicorp. They have tap for "stable tested" releases, and we have core where we have bleeding edge versions.

This is definitely a route that we could consider. Another one would be to be faster wrt/ to update our golang versions, but that might become also difficult, as all Knative components (>10, not only the CLI) are aligned on the golang versions because they share certain code.

Thanks again for the feedback!

commented

I have read this thread, to keep it simple my point of view is that upstream homebrew is good enough for kubectl see:
https://kubernetes.io/docs/tasks/tools/install-kubectl-macos/#install-with-homebrew-on-macos

So it should be good enough for kn

If a vendor wants to maintain their own tap to provide a slightly different version on which they have more control then they can do it, but this open source community does not need to do this.