-
Notifications
You must be signed in to change notification settings - Fork 119
Conversation
Seems like the build failure has nothing to do with my code. |
I'll have to look into the test failure |
9f1dad6
to
019391e
Compare
@lavalamp Thanks for the help in this one. BTW, I'll be off the grid in the upcoming week. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great-- my comments are mostly cosmetic.
Thanks!
(p.s. can you edit the commit messages to e.g. not include the @
in front of lavalamp
? github sends people email every time anything is done with such commits :) )
A few more things:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can only find 2 tiny nits, sorry for the delay, I got busy.
I'm willing to take this as is, but I was thinking and I think we can improve on it a bit, and since we won't be able to change this after the fact except by introducing a new version of it, I'll say what I'm thinking and you can decide if it's worth changing.
The current version lets the fuzzer lock in the values of the first N random calls, but changing the length of the byte slice completely changes the random sequence for the rest of the calls, in two ways:
- Since the seed is padded, changing the length changes how much padding is needed, meaning only insertions/removals of 8 bytes keep the same sequence
- ...but an insertion (removal) of 8 bytes will delay (hasten) the first call to the fallback generator, meaning that although the sequence is the same, it's being called for different locations, which will change every site.
Here's an idea that solves these problems:
- Use the first 8 bytes as a seed.
- When returning a Uint64 directly from the data, also get a random Uint64 from the fallback source and throw it away.
I think this makes length changes much less consequential, which should let the fuzzer search with them much more effectively?
oh, and the questions:
|
Thanks! |
a9a49e9
to
e11177b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Final round of nits and it looks like you'll need to rebase, too, sorry...
bytesource/bytesource.go
Outdated
// New returns a new ByteSource from a given slice of bytes. | ||
func New(input []byte) *ByteSource { | ||
if len(input) == 0 { | ||
panic("ByteSource was initiated with empty input") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm, mention this in the function comment, or (my preference) use a seed of 0 in this case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice idea!
Before commiting this, I would like you to take a look at https://github.com/posener/fuzzing. |
Add a helper function that enables using gofuzz (this project) with go-fuzz (https://github.com/dvyukov/go-fuzz) for continuose fuzzing. Essentially, it enables translating the fuzzing bytes from go-fuzz to any Go object using this library. This change will enable using this project with fuzzing websites such as fuzzit.dev or fuzzbuzz.io. The underlying implementation was an idea of lavalamp, by which a random source is created that generates random numbers from the input bytes slice. In this way changes in the source result in logical changes in the random data, which enables the fuzzer to efficiently search the space of inputs. Fixes google#33
Sorry I've been super busy and that was a complicated question :) Do you have a specific spot in that repo I can look at? I don't think I found what you were talking about in a quick skim... |
It is a small repo, you can check the |
Ah, I understand now. Yes, I agree, that is nicer. I'm not sure of a way to do it without defining an interface that covers (sorry for the delay; busy few weeks!) |
Maybe it is better just to close this one. |
bytesource/bytesource.go
Outdated
func (s *ByteSource) consumeUint64() uint64 { | ||
var bytes [8]byte | ||
_, err := s.Read(bytes[:]) | ||
if err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need a test with data that's a length not divisible by 8-- this might return an EOF at some point?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is OK. https://play.golang.org/p/9uC8M9Nm5pE
But according to the io.Reader
interface definition, you are right, the implementation can return io.EOF
even when there were bytes that were read.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is however tested, when the input bytes are the numbers 1..9.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I do see that test now, sorry!
After more thought, I think this is still useful. Thanks for the idea! I did see one more thing that should probably be addressed though, if you still want to pursue this. |
Yes sure, lets continue with it. Why not |
Thanks! |
Thank for the review! It was a pleasure! |
Add a helper function that enables using gofuzz (this project) with go-fuzz for continuose fuzzing. Essentially, it enables translating the fuzzing bytes from go-fuzz to any Go object using this library.
This change will enable using this project with fuzzing websites such as fuzzit.dev or fuzzbuzz.io.
The underlying implementation was an idea of @lavalamp, by which a random source is created that generates random numbers from the input bytes slice. In this way changes in the source result in logical changes in the random data, which enables the fuzzer to efficiently search the space of inputs.
Fixes #33