Officially deprecate?
josharian opened this issue · 15 comments
Agreed, as long as the deprecation is clear that it only applies to Go 1.18 or later. We could perhaps also link to https://pkg.go.dev/golang.org/dl/gotip for testing native fuzzing, and the equivalent for 1.18beta1 or 1.18rc1 as they come out.
Well, we have a number of unfixed non-trivial bugs that apply to 1.17. The deprecation would be more an acceptance of facts than a statement of policy.
That's fair. What I mean is that we need to mention 1.18+ when it comes to switching to native fuzzing as a replacement.
I don't mind. We could add some bold header, issue template and link them to native fuzzing page.
I have a modest counter proposal, including a couple of quick comments on some of the recent bugs reported against go-fuzz, but I won’t be able to circle back here until this evening…
Is there an alternative fuzzer that operates the same way as go-fuzz?
@huornlmj the built-in toolchain fuzzer is based on go-fuzz. To get it started they imported much of go-fuzz wholesale. I can't say it's exactly the same, but it is similar.
Hi all, some quick comments.
Josh's proposal will very likely be the ultimate outcome here, and that has been the goal... However, I'd like to suggest "maybe not quite yet".
In particular, I'd like to volunteer my time to keep go-fuzz operating for a bit longer, such as maybe another 5-6 months.
As to why:
- Based on my experience so far with cmd/go fuzzing and given what is not yet implemented, I think cmd/go has not yet caught up to go-fuzz in terms of fuzzing effectiveness. A plausible guess is that won't happen until maybe ~mid Go 1.19 dev cycle (including because we are in the 1.18 freeze now).
- Comparing go-fuzz vs. cmd/go fuzzing has been helpful for me personally, but more importantly, that comparison I think will help cmd/go mature faster, including likely with concrete issues filed against cmd/go that highlight areas where go-fuzz might be doing better.
- I think go-fuzz is still "mostly working" rather than "mostly broken".
- I have a personal interest in seeing go-fuzz continue to work with Go 1.17 and 1.18 ;-)
If we were to adopt "not quite yet" for archiving this repo:
- I think it still makes sense to update the README (to indicate go-fuzz will ultimately be deprecated in favor of cmd/go, and encourage migration with some links to cmd/go fuzzing and gotip, etc.).
- In terms of new issues that might come in over the next several months, I think I could hit an SLA of 24-48 hours on replying (which is maybe not as fast as Josh ;-)
- If something is worthy of a fix, a +2 from someone like Josh and/or Dmitry would be valuable of course.
- That said, hopefully the +2 burden would be very light in practice, including:
- There might be only ~2-3 total more fixes in the future before deprecating/archiving.
- There is not much benefit in aggressively fixing corner cases or making invasive changes at this point.
Finally, sorry for the delayed response. (One thing is I wanted to first send PR #330).
Yes, I think "Archiving' in the github sense is early (and unnecessary, at least at this point).
There seems to be agreement on adding some note to the readme to manage expectations.
If you want to fix some bugs that's obviously welcome. Thanks.
The go-fuzz is compatible with libfuzzer, which is supported by oss-fuzz.
AFAIK the go 1.18 fuzzer doesn't have support for external fuzzer formats yet which is an issue.
I've been using both go-fuzz and gofuzzbeta, and the results seemed sometimes wildly different, in ways that I mentally bookmarked as reminiscent of golang/go#47090
I plan on continuing to use dvyukov/go-fuzz for a while longer; +1 for "don't officially deprecate just yet, please".
@naveensrinivasan The Go compiler natively supports coverage instrumentation for libfuzzer since 1.14.
Please do not deprecate this project.
Native go fuzzer does not support coverage collection while fuzzing.
Also, as other users have mentioned, it has no support for binary samples, hence no synchronization with other fuzzers and corpus libraries.
@fuzzah Are there feature requests filed for these things for the standard Go fuzzing? It makes sense to do so.
Whether we officially mark go-fuzz as deprecated or not does not change the fact that it is already effectively deprecated and not stuffed. Next time it breaks, nobody fixes it.