[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ITP: php-recaptcha -- PHP interface to recaptcha.net



On Sun, 20 Jun 2010 21:47:55 +0800
Thomas Goirand <thomas@goirand.fr> wrote:

> I have tried to be as open minded as possible, and asking opinions of
> others, and I don't think I am re-interpreting the DFSG here. IMHO,
> the debate is all about how to consider the recaptcha service (eg: a
> service you connect to, or a remote procedure).

Remote procedures alone are not sufficient reason to consider a package
using the procedure as non-free - e.g. blog clients use a variety of
blog engines, some of which are non-free.
 
> Some made the comparison (like you just did) with IM clients, specific
> browsers (like youtube clients and others), but I don't believe this
> applies here. To my opinion, I believe this is a remotely executed
> procedure, stored on a non-free server that we wont ever control,
> which makes php-recaptcha a good candidate for contrib. This is a lot
> more complex debate than what you pretend.

Blog clients rely on remotely executed procedures. All blog engines are
*stored* on a non-free server because servers themselves (as machines)
are always non-free if they hope to be secure. ;-) I think what you
meant is connecting to a non-free *service* and there are a lot of
those which do not preclude packages using them being in main.

The difference here is that this procedure is server-to-server not
client-to-server. i.e. it is reasonable to expect the service could be
available within the one server, albeit with some configuration and
the recaptcha service precludes this because the code behind the
service is non-free.

Relying on one server should be avoided, where possible for obvious
SPOF reasons. There's also the potential security implication of
executing PHP code which is not within the control of the calling code.
If recaptcha.net suffers a cross-site-scripting attack, the reliance on
this one server will be a problem for all servers using this package.
That has no impact on DFSG but it should be clearly indicated by the
package itself (e.g. in the package description) and that the non-free
nature of the code on that one server is the reason why the package
prevents a fix for such an issue.

> writing that I don't think this matches the case of php-recaptcha. We
> are talking about a remote procedure on a software, that has no valid
> reason to be used as a service, and not embedded on the server that
> you use. If you believe that there's a valid reason, I welcome you to
> express yourself about it.

This argument, whilst a valid criticism of the package methodology,
does not impact on whether the package meets DFSG. That is to do with
design decisions rather than the status of the final code. Far better
would be if this package provided an alternative method which could
operate as a fallback.

IMHO if this package is to enter Debian at all, it should be in
contrib as it relies on a non-free component to operate (so non-free
that the component cannot even be packaged for Debian).

What happens to this package if recaptcha.net is unavailable or blocked
by a firewall?

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/

Attachment: pgpkayUEOMujG.pgp
Description: PGP signature


Reply to: