[Top][All Lists]

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

Re: [Bug-wget] Overly permissive hostname matching

From: Tim Ruehsen
Subject: Re: [Bug-wget] Overly permissive hostname matching
Date: Wed, 19 Mar 2014 11:19:54 +0100
User-agent: KMail/4.11.5 (Linux/3.13-1-amd64; KDE/4.11.5; x86_64; ; )

On Tuesday 18 March 2014 20:05:07 Daniel Kahn Gillmor wrote:
> On 03/18/2014 05:31 PM, Tim Rühsen wrote:
> > IHMO, the Public Suffix List (PSL) should not only be used to verify
> > cookies but also be used for certificate hostname checking.
> > 
> > Libraries as GnuTLS should offer an API for this kind of checking, best
> > would be having the PSL as a separate file, maintained by the
> > distribution maintainers (or the user, if he wants to to it). The SSL
> > library should load/unload the PSL under the applications control.
> that sounds really fiddly to me -- you want the application to know why
> the TLS stack needs to know about the public suffix list, and to be able
> to control it appropriately?
> I think we need good sensible defaults, and a locally-cached,
> frequently-updated copy of the public suffix list; then if we really
> really want the application to be able to control the use of an
> alternate suffix list we can provide an API for that, but i can't
> imagine we'd want to require the application to specify anything (even
> asking the application to load the default local PSL seems like too much
> to expect from most apps that just want "to layer in some TLS").

As a programmer, I want to have control. E.g. the option to load from a 
different file, or to switch off loading. Why ? e.g. for testing purposes, or 
simply imagine a "swiss army knife" client for experts - maybe they want to 
have control via CLI args. Or you are in a controlled environment and simply 
don't want to waste CPU cycles when downloading a single file from a trusted 
server. Just some examples.
And than, clients like Wget would like to have access, at least for checking 

> > Maybe it would be a good idea to provide a separate PSL library that could
> > be used by SSL libraries for hostname checking and HTTP(S) clients for
> > cookie verification.
> I maintain publicsuffix in debian, and i try to help on the gnutls side
> of things too (both upstream and a little bit of kibbitzing about the
> debian packaging).
> debian has php, python, perl, and haskell bindings for the public suffix
> list, but i don't think anyone has packaged a C library for it.
> I've got discussion in my mailbox that i haven't processed in ages with
> Florian Sager about packaging regdom-libs [0], though, and the library
> looks like it's been revived a bit since i gave up on it last [1].  Do
> you think this C interface would be a useful one or would you expect a
> different API?

I just took a quick look but I am not sure about the API (i did not have this 
'aha' effect). But what I don't like is the dependency on PHP which is used to 
'compile' the PSL before the C functions can use it. While the idea of 
compilation/preprocessing is a good one, it should at least be optional.

> [0] http://www.dkim-reputation.org/regdom-libs/
> [1] https://bugs.debian.org/683881
> > If of any interest, there is already some LGPLed code at
> > 
> >   https://github.com/rockdaboot/mget/blob/master/libmget/cookie.c
> > 
> > There are also some unit test routines in the project.
> hm, do you know if the libmget folks are willing to break that code out
> separately?  linking to all of libmget doesn't sound like a good idea,
> and it would be a shame to have to maintain separate copies of this
> codebase.

"the folks" it's me ;-)
I already thought of splitting libmget into several smaller libraries, like 
libmget-common, libmget-cookies, libmget-psl ... whatever is needed.

What exactly do you think of ? What can I do to make Debian packaging easy ?


reply via email to

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