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 cookies. > > 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 ? Tim
