WindowsRegistryProfile requires grr

[the-exodus]

The artifact depends on grr's registry parser, it can't provide the expansions it declares without an artifact-specific parser.

The legacy-file contains definitions that provide the same tokens, but declaratively and encapsulated, and I'd suggest "un-deprecating" them back into windows.yaml.

I can do it and throw a PR, if you're good with my suggestion :)

Edit: it seems I was wrong, they're not in legacy. I'll add definitions for them and submit a PR.

[joachimmetz]

I can do it and throw a PR, if you're good with my suggestion :)

I recommend to explain your proposed changes in plain English first. First of all I have a hard time parsing what you are trying to tell me.

There is no WindowsRegistryProfile artifact definition. There is WindowsRegistryProfiles (with an s) did you mean that?

If so, I fail to see how does this "requires grr" ? FYI Plaso also uses it https://github.com/log2timeline/plaso/blob/master/plaso/preprocessors/windows.py#L448 without using GRR

[the-exodus]

Yeah sorry, I was kind of distracted when writing that.

I'm talking about the provides. It contains users.sid and username, which isn't what the registry value provides. My suggestion is adding separate artifact definitions for those.

[joachimmetz]

Ah that makes the original question more clear. Provides are basically a left overs from first artifacts implementation of GRR. Per #275 provides are used in interpolation dependency resolving. I recommend not to use them outside of GRR.

They've been on the to remove/change list for a while #275.

[the-exodus]

Ah, dependency resolving is actually precisely what I use them for. Do you intend to remove interpolations, or just remove the "value collection" from the artifact definitions and leave that up to the consumer?

[joachimmetz]

The idea of #275 is not to remove all interpolations values but remove the unused ones and document and clean up the remaining ones (e.g. #401).

So "dependency resolving" is dependent on how the artifact definition is used. For collection purposes it makes sense, but it will depend on the capabilities of the consumer. E.g. using WindowsRegistryProfiles by a consumer that just list sub key and value names might not be able to "provide" all specified "provides" types.

Could you elaborate a bit about your use case. As an additional data point to assess what maybe the best path forward for the "provides" definitions is.

[the-exodus]

The case is live collection in a mixed-platform environment. You create a list of which artifacts to collect, the dependencies are resolved, and the resulting list is baked into collector binaries for the different platforms.
So in this case, the WindowsRegistryProfiles-artifact is troublesome, since it's the only source of users.sid and users.username, and a "dumb" collector isn't capable of getting those. The artifact definition doesn't contain the complete definition :)
I absolutely understand there are use cases, and lots of them, where this isn't a problem. The reason I created the issue is that several other artifacts depend on users.sid, and there's no other source for it. I have solved it locally by adding artifacts providing sid and username separately, but it's not necessarily the right solution for a public release.

Unless there are cases that really require it, my (unasked for, admittedly) suggestion would be not allowing one artifact to provide multiple "symbols". I'd also add regex support, like provides: {"users.username":".*\\(.*)$"} or something to that effect.

This may not be the right forum for design proposals though 😅