[arch-dev-public] [objectives] Package triage on current + extra (archstats)

[Aaron Griffin]

On 5/7/07, Dan McGee <dpmcgee at gmail.com> wrote:
> On 5/7/07, Jürgen Hötzel <juergen at hoetzel.info> wrote:
> > On Mon, May 07, 2007 at 12:13:16PM -0400, Dan McGee wrote:
> > >
> > > I've managed to remove about 500 lines of code by moving repetition to
> > > functions (still more to be done, but that was 1/6 of the code). I
> > > also completely bypassed the MD5sum checking stuff, showing how that
> > > is worthless. Simo and I were trying to think of a better way to do
> > > client verification (Jürgen, any ideas?), and we came up with nothing.
> > >
> >
> > There is no solution, if users are anonymous. A simple workaround/hack:
> >
> > Prevent connects from the same IP (for a limited time period).
> >
> > This could limit the possibility to flood the database with multiple
> > machine entries from one user.
>
> I thought about this solution as well, but I realized it does carry
> with it a rather large negative. If a user has 4 Arch boxes behind a
> router with NAT, and they all run archstats as a cronjob at the same
> time, we would be excluding all but 1 of his boxes from updates.
>
> How essential is user anonymity on submission? Would users feel
> comfortable registering (which is a hurdle I think we should try to
> avoid) if their anonymous state was still preserved in any data
> presented to the user?

One thing cactus brought up recently is user ldap support.  Suppsoedly
mediawiki and punbb support ldap login.  If were were to use ldap for
user accounts, we could spread that to all aspects, such as the AUR
and archstats.

*Then* we could implement the "only one submission from this user
every X minutes" setup.