Re: [PATCH v3] gitweb: redacted e-mail addresses feature.
flat view
From: Georgios Kontaxis <hidden>
Date: 2021-03-21 23:24:33
"Georgios Kontaxis" [off-list ref] writes:quoted
quoted
... so I doubt the wisdom of munging the patch part at all. I may be sympathetic to the cause of the patch, but, I do not agree with its execution in this iteration of the patch.I see your point. It seems hiding e-mail addresses should be limited to the commit message, i.e., stop at the "---" line.I doubt it makes sense to redact anything in the 'patch' view at all, actually. What kind of URL does the crawler need to formulate and what pieces of information (like commit object names or branch names) does it need to fill in the URL to get a series of patches out of gitweb? As long as it takes more effort than running "git clone" against the repository, the crawler would not have much incentive to crawl and harvest addresses from the 'patch' pages, and even in the log message part, the downsides of butchering the payload would outweigh the "privacy benefit", I would have to say.
No effort at all I would say. E..g, somehow the web crawler gets to git.kernel.org. It then follows every link, eventually arriving at a commitdiff page. It then follows every link, which includes the URL for the patch output. See how "wget --mirror" behaves for instance. Just to clarify, my goal is not to stop someone who wants to extract e-mail address from git.kernel.org specifically. They can just "git clone" the repositories and grep through the logs. My goal is to stop generic crawlers (pretty much "wget --mirror | grep" scripts) from making their way to the logs.
Quite honestly, if a site claims to offer a 'patch' download UI but returns corrupt data back, I would say it is much worse than not offering the service at all. Perhaps disabling the 'patch' feature in repositories that enable 'privacy' feature may be a much better approach.
Good point. I think I'll try that.