Comments (20)
Any update? This makes this infeasible to use for any testing using protobuf enums
from gofuzz.
BTW go has built-in fuzzing now: https://go.dev/doc/fuzz/
It does, but the fuzzing it does is limited, and I still rely on gofuzz. For instance, since Go 1.18's fuzzer doesn't fuzz struct
s, I still do:
func FuzzWithStruct(f *testing.F) {
f.Add([]byte("seed"))
f.Fuzz(func(t *testing.T, data []byte) {
// Set up
fuzzer := fuzz.NewFromGoFuzz(data)
testSet := map[PIIField]struct{}{}
fuzzer.Fuzz(&testSet)
t.Logf("Set: %+v", testSet)
// Test
_ = doThingWithSet(testSet)
// Verify
// The point of the fuzz is just to ensure method does not panic
})
}
from gofuzz.
Hi, sorry, I must have missed this in my email-- can you not register a custom fuzzing function for an interface{} type? Alternatively, register one for the enclosing struct. Let me know if that doesn't work.
from gofuzz.
It's unfortunately not generally possible to know what makes sense for interfaces, functions, or channels. :(
The panic message is not very helpful, though--that should be improved.
from gofuzz.
type Test struct {
ErrorType TestInterface
}
type TestInterface interface {
Size() int
}
func TestFuzzE(t *testing.T) {
x := Test{}
f := fuzz.New().NilChance(.5).Funcs(
func(e *TestInterface, c fuzz.Continue) {
})
f.Fuzz(&x)
f1 := fuzz.New().NilChance(.5).Funcs(
func(e *interface{}, c fuzz.Continue) {
})
f1.Fuzz(&x)
}
First one works, second one doesn't. It doesn't seem to get called as a custom function. I'll play around with it a bit more to see if I can get something to stick. Basically my plan was to have a function called for every type, and filter out the interfaces or similar
from gofuzz.
Yeah, I'd expect your second one to get called for this struct:
type Test struct {
ErrorType interface{}
}
It kinda has to work this way, since only you know how to construct reasonable random implementations of your interface.
from gofuzz.
Or are you asking for a second lookup so you can set the behavior for custom interfaces without a specific custom fuzzing function?
from gofuzz.
Basically my understanding is right now the presence of any interface type leads to a panic. The only way to avoid this is to define a custom function (which does work).
Ideally I would not need to define custom functions as I have a lot of interfaces and I would rather be lazy 🙂. Instead I would expect to basically be able to skip any interface types. So instead of panicking, we would just do nothing to that field. Then if you do want to add custom logic for that type, you can define your own function. This could be a configurable option if that is not generally desirable?
from gofuzz.
A goal is to not give false confidence, by e.g. silently not fuzzing things. I guess it makes sense to have an opt-out. A second, fallback call like I just suggested doesn't actually make sense, since the interfaces are of different types.
What if the panic message listed the types that are missing fuzzing functions, in a form that you could copy-paste that into your test file with your custom fuzzing functions?
from gofuzz.
A helpful error message + some doc on resolving it seems reasonable to me
from gofuzz.
OK, great. I'm totally open to a PR fixing this. I probably won't have time to write one anytime soon, though.
from gofuzz.
I was thinking about
It kinda has to work this way, since only you know how to construct reasonable random implementations of your interface.
a bit more. One common case for this to occur is using protobuf oneof
. I wonder if its feasible to implement awareness of protobuf and automatically handle these cases.
from gofuzz.
How could one programmatically identify that arrangement? E.g. is it represented in struct tags? I'm open to ideas.
from gofuzz.
// Types that are valid to be assigned to HealthCheckMethod:
// *ReadinessProbe_HttpGet
// *ReadinessProbe_TcpSocket
// *ReadinessProbe_Exec
HealthCheckMethod isReadinessProbe_HealthCheckMethod `protobuf_oneof:"health_check_method"`
this is the top level struct, it has a protobuf_oneof
tag.
Then there is a helper function:
func (*ReadinessProbe) XXX_OneofWrappers() []interface{} {
return []interface{}{
(*ReadinessProbe_HttpGet)(nil),
(*ReadinessProbe_TcpSocket)(nil),
(*ReadinessProbe_Exec)(nil),
}
}
which seems to return all possible types
I am not sure how much these are meant to be implementation details though, it might be better to use https://godoc.org/google.golang.org/protobuf/reflect/protoreflect
from gofuzz.
gofuzz operates strictly on go types, so doing something proto specific doesn't seem feasible.
Given the setup you posted, I can imagine a fuzz function that operates on interface types, looks at the name of the type, somehow looks for a corresponding XXX_something() []interface{}
method, calls it, picks one of the choices (or nil, according to the nil chance).
from gofuzz.
@lavalamp maybe I'm missing something, but I have the same issue with fuzzing proto oneof.
I can't do the suggested workaround to solve this, i.e I can't do a custom fuzz function on that interface because it is non-exported (i.e see the example posted above by @howardjohn , isReadinessProbe_HealthCheckMethod
is private).
I tried declaring my own interface with the same shape but that didn't work.
Any ideas?
from gofuzz.
I've just run into this without the protobuf problem, would a struct tag, say nofuzz
, feasible?
from gofuzz.
BTW go has built-in fuzzing now: https://go.dev/doc/fuzz/
from gofuzz.
@jackgene you are right, that's more limited than I realized.
@freman Yeah if there's a better idea than struct tags I'm not seeing it. Not sure what to do about e.g. map[string]interface{}
though.
from gofuzz.
Hi guys. Will there be a release on this?
from gofuzz.
Related Issues (20)
- Improve quality of integer output HOT 2
- Idea: Fuzzing with only non-zero values?
- Add golint to automated tests
- comparison with go-fuzz HOT 1
- issue building with go 1.11.3 and previous
- Is this repository still alive? HOT 1
- go mod checksum mismatch HOT 1
- Integrate with fuzzit?
- Add note to docs that private fields of structs cannot be fuzzed using this package HOT 2
- Generating blank strings even though nilChance is set to 0 HOT 2
- go-fuzz integration may give nil values despite NilChance(0) HOT 2
- New Release? HOT 2
- UnicodeRanges as shown in example cause `go vet` to fail
- Test failure on 32 bits arch
- NewFromGoFuzz doesn't work well with go-fuzz HOT 1
- Can we add support for unexported field? HOT 2
- Is / should gofuzz safe for concurrent use? HOT 2
- Tag a new release: 1.3.0
- Regarding newer versions
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gofuzz.