Handle methods on non-struct source types about go-flow-levee HOT 2 OPEN

1. Mark all methods on non-structs as fieldpropagators.

+1 to marking all methods as producing sources for interface-type sources. For concretely named types like type Source string, an analyzer should still be able to distinguish methods which propagate taint from the underlying source, i.e.

type Source string

func (s Source) Safe() string {
  return "hello there"
}

func (s Source) Unsafe() string {
  return fmt.Sprintf("Taint should propagate here from s.  %v", string(s))
}

That could be a goal for future iteration, though.

I'd love to see a decision graph as part of our documentation, if we're going to have two or more different ways of defining what it means to be a source.

2. Rename the fieldpropagator analyzer to accurately reflect this behavior. Maybe something like methodpropagator.

As ever, I consider naming a very hard thing. If the intent of the analyzer is "Identify methods that produce Values that we will treat like a new source," I'm leaning away from the word "propagator." If Go were more verbose by convention, I'd suggest sourceproducermethodidentifier, but that might be letting my Java background show. sourceproducer might suffice? I don't really mind one way or t'other, though, as long as the analyzer's docstring is precise in what the produced result will contain.

Further discussion: [...]

Yeah, this feels like something that notes could handle. Implementation detail, but if and when we get into interprocedural work, I think the note granularity should probably be the ssa.Block, with method / function summaries built from those. But it would certainly alleviate some of these other issues.

from go-flow-levee.

All of that sounds good to me. I think I'll start by marking all methods on non-structs as source-producing, and look into refining that later. I think the cases in which a method on e.g. a string doesn't use the string are likely to be rare, but I don't actually know.

Thanks for the naming suggestions. Right now I'm thinking sourcemethod might fit the bill, but I'll keep thinking about it.

from go-flow-levee.