https://github.com/osquery/osquery logo
Join Slack
Powered by
Hi thanks for updating <osquery.io> to show v5.0.1...
# general
m
Hi thanks for updating osquery.io to show v5.0.1 for download. Unfortunately the url https://pkg.osquery.io/windows/osquery.msi is still serving the older v4.9.0
s
I don’t see that. Browser caching?
Oh. I have no idea if we intentionally support that kind of link
Is it documented somewhere? As far as I know, it’s not part of any of the release scripts
m
Who did we used to rely on for updating the site, was it Teddy?
s
Website updates for the last long-time have been a mix of Teddy and me, and they’re pretty scripted.
pkg
server updates have mostly been Teddy, and only recently got automated.
Glancing at obvious looking common names, like 
osquery.pkg
osquery.msi
etc, the date stamps are all over. I don’t know if I want to support them, or not.
If there are docs, or we think it’s a good idea, we can add it to the release generation tooling pretty easily.
m
well how else can we automatically grab the lates release without putting a version number in the path?
There is no /latest endpoint or anything. so I just been using that url as it until now guaranteed to serve the newest .msi
Like there needs to be a way for script do just hit the same URL and receive the current version of the msi. If you have osquery-x.y.z.msi in the url then someone needs to change the script every time to alter x,y and z to download the latest msi. vendors typically have a /latest endpoint or something where you can be sure to fetch the latest msi from your script.
s
as it until now guaranteed to serve the newest .msi
Can you find a documented claim of that guarantee? I understand why you might want this, but I don’t think we’ve made that promise.
m
@seph it wasn't a promise, it just happened to be delivering the latest msi so I used it. But now it no longer gives the latest msi. So what options do we have to get the latest msi now? Or do we need to manually edit the path in our script any time there is an update? It would be nice if there was a /latest endpoint or something.
And anyone who uses it in their script now has a broken script that wont update. Seems like a bit of an "f you" to say "we never guaranteed it". If you make that URL available you should maintain it, explicit guarantee not necessary as the URL didn't make itself and therefore it obviously exists to be used. And now for whatever reason you don't want to use it anymore?
And if it no longer exists or is deprecated then 301 it to somewhere that does exist
m
@seph you have access to that S3 bucket? You were looking at file timestamps; does it look like those files got littered there by chance, maybe during a manual upload process that we have since automated?
@Mystery Incorporated I think it's a valid suggestion and I'll create a GitHub issue to either (a) disable that URL or (b) point it to 'current'. But I think there's a bigger problem we have which is automatic and frequent re-downloading of this installer, causing some massive bandwidth bills to the project. Encouraging automatic retrieval is probably not in our self-interest and I don't know how sustainable it is already
s
@Mike Myers No idea. I observe inconsistency, but cannot guess about causality.
m
s
@Mystery Incorporated I think it’s a find feature request, and if you’d like to make it, I think we can do it. But if you show up ranting about how it’s broken you’re not going to get a good response.
m
I guess I could just make my own endpoint and update it when osquery releases a new update if it's causing bandwidth bill problems then I can do it to assist with stopping that
m
How about this
Copy code
curl -s <https://api.github.com/repos/osquery/osquery/releases/latest> | grep "browser_download_url.*msi" | cut -d ":" -f 2,3 | tr -d \"
Open in Slack
PreviousNext
Powered by