Dmitry Vyukov

> Android and modules may be the problem here. How do modules affect this? They are mostly build/runtime artifacts. On source code level it's not even possible to say if...

Overall, custom GCS solution looks like lots of new custom code written specifically for this (we will need to upload all files to GCS, add downloading code, extract last modification...

> Send to dashboard - no. Dashboard will read it directly from gcs when needed. I though what you propose still includes the "What we really need is a commit...

> It looks dangerous to make this repo accessible from the internet. Why? It looks like the least valuable information we have. If fact, we already downloaded contents from public...

Once we have git repo with all commits, ideally we fix web links as well. For example, looking at "WARNING in vfs_removexattr (2)": https://syzkaller.appspot.com/bug?extid=ad9ca5fa6f83171e3bb9 source links point to: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/tree/fs/xattr.c?id=df54f4a16f82b1722593ff8ec2451fdefa467cd0#n577 which...

I think for comparisons copying won't have lots of overhead. Comparisons are not used too often in the first place. So, yes, we probably can just remove that cover_reset call...

cc @eepeep @glpesk @mvanotti but I think Zircon fuzzing is mostly dead by now

Do you consider doing just raw export, or something that does regression testing out-of-the-box? I would assume that raw export won't be too useful for most users. They won't be...

For filtering purposes we could also annotate exported reproducers with some metadata (subsystem, expected running time, bug type, etc). There will be lots of reproducers (tens of thousands), so users...

> What do you mean? I want every syz-reprolist call to create the latest snapshot. Is it OK to export tens of thousands of reproducers each time? I was thinking...