does your critique also apply to the previous message in this thread whose
author suggested using anubis?

On Fri 6. Mar 2026 at 13:14, Crystal Kolipe <[email protected]>
wrote:

> 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.
>

Reply via email to