Image building schedule?

[Starttoaster]

We've been running Trickster for years now, and we're starting to get to a point of being more mature about monitoring the lifecycles of applications running in containerized environments (namely Kubernetes.) We've noticed that even the :latest tag of tricksterproxy/trickster hasn't been pushed to with updates in around 3 years, and is currently built on top of a 3 year old release of Alpine linux. This triggers vulnerability scanners looking for system packages inside containers to notice that there are incredibly outdated packages with critical-level CVEs that have been patched in more recent versions of those packages.

The request for this Issue is that images (at least like, :latest and maybe a short list of supported versions) be rebuilt on a schedule, so that updates to the alpine image this gets based on get pulled into the tricksterproxy/trickster image.

If that is something you'd be interested in and don't currently have the maintenance bandwidth, I could assist with making a scheduled workflow for this even.

[Starttoaster]

@trickstercache/maintainers been a minute, figured I'd add a ping here in case the Maintainers aren't watching :)

edit: Ah, the distro here doesn't seem to work?

edit2: Maybe via UN then? @jranson @jnichols-git @crandles @LimitlessEarth I'd just like to get some feedback on the idea of rebuilding these extremely stale docker images.

[Starttoaster]

Communication is a bit tight around here... It would be nice to get a bit of insight into the internal thought processes of the maintainers here about the idea of rebuilding these images every once in a while, rather than leave me hanging on an eyes emoji after begging for a bit of contact after a month... I'm pretty patient, I just generally expect like a "we'll discuss it in the next maintainers meeting, which happens next year around this time." Or "yeah, that sounds good, would you like to make the workflow for us, as it would be likely to be done quicker?" Rather than utter silence. The current level of communication could lead people who are external to the maintainers team to imagine that this utility has maybe become abandoned.

I know repo maintainership is often a thankless job, so I get it. And I wanted to make sure to thank you all for this tool. But my impression of CNCF sponsored projects was that they usually have a bit more maintainer activity. I'm sorry if my perception misaligned with reality and confused my expectations around feedback. My intention here is sincerely to help, not to harp on comms all day.

[jnichols-git]

@Starttoaster You sound like you've heard the personal/common answers before, so I'll spare you those--I'm just not in a position to sign off on changes (especially build/actions related) myself, and I'm waiting to hear back from another maintainer regarding making an effective change to the build process. Our schedules don't regularly align and are usually full, so sometimes this takes a second. I'm hearing that this is a pain point for your team, so I'll push to get it resolved sooner rather than later. I'll respond here by next Friday with an update.

[Starttoaster]

Thanks so much for taking the time to post an update @jnichols-git . You're correct that this is a bit of a pain point for my team and I, but it's okay if the timeline you gave slides a bit. I mostly just wanted to know if I had a red or green light on trying to solve this pain point myself, but we can wait for you and fellow maintainer's calendars to align before then. Have a great weekend.

[jnichols-git]

@Starttoaster Happy Friday! I'm going to get to work this weekend on releasing builds with updated images and dependencies for v1.0.x and v1.1.x. Hopefully that'll give your team what it needs as a stopgap while regular builds are in progress. Workflows aren't my specialty and you sound pretty comfortable--if you would like, your contribution on that front would be greatly appreciated. I'm around to assist however you need.

[Starttoaster]

Thanks for the update! I would be happy to take a stab at a CI PR for this

[Starttoaster]

As mentioned in the PR, my fault on my timeline slipping so drastically. Projects building up at work, the usual suspects for being in a general state of busy-ness. But hopefully that pull request gives something useful to the trickster maintainers?

On another note, was there still a plan to release updated images for trickster in a new release? That will be pretty neat in and of itself, looking over at some output from Trivy scanner, there's at least 4 Critical severity vulnerabilities with patch versions likely already in alpine:latest But it would probably be even more ideal to switch to scratch or a distroless image if possible. Especially given the span of time users could probably expect to not have updates, or might elect to stay on a specific image themselves.

[Starttoaster]

I think this should still be done, so I'm going to leave the Issue open. But I think there were some fundamental flaws in my CI looking back on this, where I investigated some of these branches further. In particular the v1.0.x and v1.1.x branches are very out-of-date with what is seen in main, so much so that it's difficult to write CI for those legacy branches in my opinion. I've mostly resolved to just owning my own opinionated fork of Trickster proxy that just rebuilds off of the default branch, but feel free to close as not planned or action this Issue at your discretion :)

I could probably stay involved with providing any guidance as needed. But I don't think my PR fully solved for the issue here, and it might take a series of PRs to standardize the build process between the legacy branches and what's in the default branch today a bit more.