[Top][All Lists]

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

Re: libidn2 support

From: Simon Josefsson
Subject: Re: libidn2 support
Date: Wed, 7 Dec 2016 08:59:39 +0100

Den Tue, 06 Dec 2016 17:03:04 +0100
skrev Re: libidn2 support:

> On Monday, December 5, 2016 10:00:32 AM CET Simon Josefsson wrote:
> > Hi again.  I have added you now.  There is no real work going on
> > with libidn2, but Hanno Böck said he may have found more
> > security vulnerabilities, so it would be nice to be able to do a
> > quick security release if needed.  Therefor, it appears preferrable
> > to push your stuff to a branch meanwhile.  I'm happy to review when
> > it is on a branch, and hopefully we can make test releases from the
> > branch too.
> Hi Simon,
> just put my stuff into 4 different branches within your Gitlab repo.

Hi Tim.  Yay!

> Please review/merge in this order:

Very good to split things up, thank you.  Let's try to do low-hanging
fruit one at a time.

> # branch 'fixes' 
> - fix two crashes in lookup and register functions
> - avoid tainting insertname/lookupname on error

Can you write self-tests that trigger these issues?  That makes it much
easier to evaluate the patches.

> - use binary search instead of linear search in idna table

How much do the table grow by adding UNASSIGNED code points to the
library size?  I like the patch in general, but I am concerned that it
adds a lot of static size to the library.  Is having the UNASSIGNED
code points in the idna_table array really necessary?  It seems your
search function results UNASSIGNED if result==NULL anyway?  I don't
recall if there is any semantic difference between a code point that is
UNASSIGNED and a code point that does not have any property at all.


Attachment: pgpflOs7ZWrWF.pgp
Description: OpenPGP digital signatur

reply via email to

[Prev in Thread] Current Thread [Next in Thread]