On Thu, Mar 21, 2019 at 12:18:18PM +0100, Pablo Neira Ayuso wrote:
> 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.
I was talking about the "osf name . osf version" part. If not optimized,
each osf expression would perform a database lookup and return different
parts of the fingerprint.
Or did I miss your point?
Cheers, Phil
