security review and patches for libpurple

[Mark Doliner]

(removing the EFF guys from this email thread)

The last important email on this thread was this one from Ethan:

On Sun, Jul 17, 2011 at 6:58 PM, Ethan Blanton <elb at pidgin.im> wrote:
> There are only two (I think?) strlcpy patches that I'm going to reject
> from this round, all of the others are applied (possibly with some
> changes or another to make them more robust in context).  The ones
> which I'm going to kick out for this round do hilight places we should
> fix, I just think we should factor the problem out differently to
> eliminate it.  I hope to have commentary on the patches I don't apply
> soon.  In fact, I may document this stuff before I finish all of the
> patches, just so they don't get lost in the shuffle.
>
> With that in mind, I'd like to ask again if there are any objections
> to my committing these patches to ipp without embargo or a coordinated
> release.  If not, I will land them some time tomorrow.  If anyone even
> simply thinks we should wait a few days or get additional input before
> landing them, that's fine, too.

I have no objections to this plan.  Embargoing stuff is a pain, so it
makes sense to only embargo things that actually need to be embargoed.
 Changes that we believe have no security implications should totally
be committed whenever.

That being said, I'm wondering how people feel about these changes?  I
feel like the EFF guys keep referring to strlcpy as "standard" and
"secure" and that they think of strcpy as deprecated and insecure.

But I don't know, I'm not feeling it.  Maybe I just haven't thought
about it enough.  I've only looked at maybe a third of their changes,
but do any of them actually deal with untrusted data?  I feel like
most of them deal with user-supplied data or stuff from the local
host.  Aka stuff that isn't remotely exploitable.

I feel like using strlcpy will hide problems that we would otherwise
fix.  Rather than crash with a helpful backtrace,  strings will
silently be truncated unless we check and verify the return value from
strlcpy.  That's certainly feasible... but if we're going to go to all
that work, couldn't we just check the code to make sure our buffers
are big enough?

I don't doubt that there are places where it makes sense to use
strlcpy, but I worry that it will make our code more complicated and
therefore more error prone.

--Mark