On Thu, Mar 21, 2019 at 12:15:15PM +0100, Phil Sutter wrote:
> On Thu, Mar 21, 2019 at 09:32:45AM +0100, Pablo Neira Ayuso wrote:
> > On Wed, Mar 20, 2019 at 02:46:54PM +0100, Phil Sutter wrote:
> > [...]
> > > Speaking of sets, it would be awesome if we could support something
> > > like:
> > >
> > > | osf genre { "Linux:2.4", "Windows" }
> >
> > We can support something like this:
> >
> > osf version { "Linux:2.4", "Windows\*" }
> >
> > where the wildcard specifies any Windows version.
> >
> > We need a new set type though, to deal with strings.
>
> Given that RHS for osf expression is a string in any option we discussed
> so far this is inevitable, right?
>
> > > i.e., having elements with varying "granularity". Do you think that's
> > > feasible? If so, how could we support that? Maybe using a concatenation
> > > like:
> > >
> > > | osf name . osf version { "Linux" . "2.4", "Windows" . "*" }
> >
> > Not sure we want this level of granularity. Matching the version
> > without no OS genre does not look useful when I look at how the osf
> > engine works. I'd prefer we go for the first approach you have
> > mentioned here above.
>
> I agree. It looks nice on paper, but without further optimization in
> background it leads to multiple fingerprint lookups for the same
> package.
Not if we have a set that implements Aho-Corasick.
