On Fri, Mar 06, 2026 at 12:17:44PM +0200, ????????? wrote: > A bit off topic, but what about putting the ole CVSWEB behind some form of > anonymous registration
Why? What problem would this solve? If there are bugs or missing functionality in the new cvsweb, then the logical thing to do would be to fix them there. If you're suggesting to run both old and new in parallel, have you considered the additional admin burden that would put on Nick? > (maybe even send your self signed client certificate > per mail), and refuse all who are not registered? So then you have to deal with 'bug reports' flooding in from people who let their certs expire and didn't realise it, or just don't know how to configure them propperly in the browser. And from a practical point of view, the client certificate idea makes little sense - one of the uses of cvsweb is that it's a way of looking at the codebase from _any_ convenient web browser. If you've got to make sure that your personal client cert is installed in advance, the utility of the service drops considerably. > That would be a small > wall which robots can't easily climb. The original problem was the load on the server from badly designed bots, not outright prevention of bots accessing the codebase. The most correct solution to an overloaded server is either to make it more efficient, (for which there was plenty of scope to do that in this case), or to upgrade the server hardware, (which has a direct monetary cost and also the risk of downtime and maintenance burden due to unexpected hardware issues, etc, etc). Trying to fix an overloaded server by restricting the number of users who can connect to it is a rubbish solution in general. Maybe as a temporary fix, but long term it's not a professional approach.
