Upstream changes?

[AlekSi]

Do you plan to upstream your changes?

[kevin-valerio]

Hi @AlekSi , I can't. The Go community would never accept that much changes, and the goal is just to be a (mainly) fuzzing-focused Go toolchain, not to produce production-ready code

[AlekSi]

Well, it is definitely possible, just time-consuming :)

Ok, then a smaller question: could a part that fills the struct from []byte be extracted into a separate library? Then it could be used with standard fuzzing, as a replacement for https://github.com/AdaLogics/go-fuzz-headers, etc. I actually worked on a very similar one, but, of course, would prefer to use an existing library.

[kevin-valerio]

Well, it is definitely possible, just time-consuming :)

Sadly, just one feature of gosentry, the integer overflow detection, is already blacklisted from the Go community (see this). So I can't imagine for the whole LibAFL integration, 22,733 additions and 532 deletions...

could a part that fills the struct from []byte be extracted into a separate library?

For sure it could! But I wonder what would be the benefits, since the point of gosentry is to replace Go's standard fuzzing without breaking its integration

[AlekSi]

The point is to lure people into a better tooling step-by-step :-)