Would it be possible to enable tagged version releases on https://github.com/osquery/osquery-go? Would be nice to be able to append something like

<http://github.com/osquery/osquery-go|github.com/osquery/osquery-go> v1.0.0

to my

go.mod

hrm. My gut sense is that adding the overhead of managing module releases for the little that changes isn’t worth it. Do you think that would be a substantial improvement over

v0.0.0-20220317165851-954ac78f381f

which is what it looks like today? And the

v0

pattern is pretty common for go modules.

(My general assumption is that if we ever break the API we’ll need to think harder. But api hasn’t changed yet)

I know with golang, version numbers can be used as a communication method for changes. For example, major version increases indicates breaking changes. Minor version increases indicates small updates. I personally prefer version numbers over

v0.0.0-20220317165851-954ac78f381f

. Also I like when the osquery project does releases, it includes the changes between releases which is nice. I understand if it’s a big lift for a small change but just something I wanted to ask about.

Lastly per the golang docs the

v0.0.0-*

notation can signal that a golang module is still in development. Is osquery-go still considered in development?

Seems reasonable to me to release a 1.0 of osquery-go. Maybe after @seph merges the mutex PR?

To be honest, I feel somewhat opposed, but I’m trying to keep an open mind.

I’m not sure I understand the problem it solves. You’ve said: • looks nicer • can signal not in development • provides a place to hang a changelog.

But I’m not sure those hold up in practice for a project that small, with that infrequent changes. When I work with similarly sized projects, I see 2 common patterns emerging. Either they cut a release on every change, or they never cut a release and anyone who cares just uses HEAD. And in those cases versioning adds overhead for negative value.

I’ve also read some reasonable criticism of go’s versioning choices. It only half stuck in my head, but there seems to be a lot of weirdness in the ecosystem about whether or not versions are git tags, or directories in source code, or ???.,

And for a project that sees a comment every month or two, that feels like a lot of overhead.

From where I sit (which I grant is not universal) the implicit pin-to-sha (almost TOFU style) is reasonable compromise. You get the version you started with. Upgrading works as long as we don’t change the API, and if we change the API then either you change the callers or don’t upgrade. Which is practically the same as you’d get with versions.

And as a side note, semver is not universal for go modules. several of them just use integers.

I’ve been revisiting the idea of mutexes, and I think they’re the wrong approach. They don’t have any kind of timeout behavior. Instead, I found some recommendations to use go channels as a form of interruptible mutex. PR up at https://github.com/osquery/osquery-go/pull/108

I propose we need more maintainers. https://github.com/osquery/foundation/issues/87

We’re thinking about adding otel traces. Feedback / buyin welcome. https://github.com/osquery/osquery-go/pull/110

Hi folks! @seph @Rebecca Mahany-Horton I can see Github CI automation that runs on every PR/push (

.github/workflows/go.yml

), any reason there's a failed CircleCI link in the repository README?

made a small update to the otel traces: https://github.com/osquery/osquery-go/pull/114

thanks for the review, Lucas!

👋 We stumbled upon what seems to be an issue with the long running queries and osquery Thrift RPC. We set the 1 minute timeout when we create Go client. The expensive query takes about 3 minutes to complete. So we get the context deadline exceeded, then for subsequent queries it either fails with context deadline, or

*osquery.ExtensionManagerQueryArgs.sql (1) field write error: i/o timeout

, or

query: out of order sequence response

As far as I remember the timeout at RPC level doesn’t stop the running query. Would appreciate some advice in case if somebody already saw that or have some suggestions how to handle this better. @seph maybe you have some insight?

I’ve put together the sample code that shows the problem, using the curl table and local http server (in order to emulate long running queries) https://github.com/aleksmaus/osqlong/blob/main/main.go README.md has more info and steps https://github.com/aleksmaus/osqlong/blob/main/README.md

@Aleksandr Maus Hrm. That’s a good point. I think we probably don’t have a way to kill a long running osquery query.

But, reviewing the locker code — https://github.com/osquery/osquery-go/blob/master/locker.go Does anything timeout a lock?

I saw distributed queries include a

messages

key we weren't currently extracting in osquery-go, so I've updated to include: https://github.com/osquery/osquery-go/pull/115

Hi folks! https://github.com/osquery/osquery-go/pull/117 fixes a nil dereference panic caused when calling

ExtensionManagerServer.Shutdown

more than once (I believe this was introduced here).

@Ronald Cardoso has left the channel

Hi all, we are working on creating custom plugins (currently loggers and tables) that we would like to run from an existing background daemon we have (instead of autoloading a

.ext

binary). We have successfully managed to get the plugins to communicate with

osqueryd

using

extensions_require

and not specifying the

extensions_autoload

flag. However, we have noticed that before

osqueryd

sets up the scheduler, it still waits the

extensions_timeout

interval and then prints that it was unable to load the required extension (however, it does not crash because it was registered via connection to the socket from our process). Is there a way to disable the autoload behavior and only attempt to connect the plugins from the extension manager creation?

Hi everyone, I'm currently learning osquery and have some questions about how it schedules and executes queries. Specifically, I have several queries within packs that all have the same interval. Here are my questions: 1. Behavior with Same Interval: If all queries have the same interval, what will be the behavior? 2. Execution Order: Does osquery execute the queries sequentially or in parallel? 3. Default Flag for Small/Same Intervals: Is the

schedule_splay_percent

flag enabled by default when using small or identical intervals? My Observations: 1. When queries have the same interval, they are executed within that interval. For example, with a 30-second interval, execution happens within 30 seconds, and with a 60-second interval, it happens within 60 seconds. However, I've noticed that the execution time increases as the interval increases. Why does this happen? 2. It seems like osquery executes the queries sequentially. 3. I couldn't find any information about the

schedule_splay_percent

flag. Any insights or clarifications would be greatly appreciated. Thanks for your help!

With the use of golang binding, is it possible to specify a timeout for a query added thru config plugin?

I made a small improvement to the traces in the table plugin: https://github.com/osquery/osquery-go/pull/125