On Fri 2017-10-20 13:25:54 +0200, Alessandro Vesely wrote: > I don't really need daily updates, just automated ones. I use the > list for looking up DMARC policies, much like opendmarc. A missing > update may result in overlooking a domain's policy record. In that > case requested reports will not be sent. Most probably, that's not > the worst surprise one may expect after opening a mail site under a > new TLD. Since mail servers are not obliged to send DMARC reports, > nobody will ever notice that failure.
thanks for pointing out this use case, i'll add it to my list.
> Compare that with web usage. Web clients --not servers-- need to have
> fresh data, lest they miss new domains' cookies. Some Brazilian users
> would certainly have noticed such failure, and some of them would have
> complained. Packages which have a sense of urgency include their own
> PSL.
sure, but then those packages aren't updated either, and they get stale
:/
Thanks for the triage, looking for systems that seem likely to ship the
publicsuffix list. I'd appreciate help filing bug reports against
pacakges which duplicate the psl to encourage them to rely on the
version in the publicsuffix pacakge. For some packages, that might
never happen, but it'd be nice to have the outstanding reports so we can
track the situation.
If you report such a problem with another package, please mark it as
"affects" publicsuffix.
> -rw------- 1 ale ale 1386614784 Nov 28 2016 /usr/lib/mailman/Mailman/core
yikes, this is a coredump! :P
> -rw-r--r-- 1 root root 129891 Jun 14 2015
> /usr/share/emacs/24.5/etc/publicsuffix.txt
I've just opened a bug report against emacs25-common for this one.
> Packages which are updated less frequently than the PSL have to decide
> whether to (i) depend on publicsuffix, (ii) compile-in their own
> version, or (iii) install their own cron job. (ii) implies possibly
> issuing dummy updates when the list changes. (i)-to-(iii) are meant
> to be best-to-worst. However, one cannot depend on publicsuffix if it
> is not updated regularly, so shifting on the worse side becomes
> compulsory.
I agree with your description of the ordering. Having an explicit
dependency on the publicsuffix package will help to make it clearer that
updates to the publicsuffix package should be prioritized for the
-updates repository.
> For a minor point, packages which depend on publicsuffix may need to
> pre-process the list and cache their own version of the data. If the
> list gets updated via regular package upgrades, what kind of hook can
> be provided? Perhaps, /etc/default/publicsuffix could be included, if
> it exists, by the post-inst script? Hm... is that customary?
There are at least two variants shipped by publicsuffix already -- the
plain text form, and the dafsa representation used by chromium and
libpsl. They're built at package build time, and both are shipped in
the binary package.
If there were dozens of variant formats, i'd say that it might warrant a
post-inst approach. But if there's only a few other precompilation
formats needed by some users of the publicsuffix list, they should
request that the package produces that variant during package build.
Feel free to open a bug requesting this!
--dkg
signature.asc
Description: PGP signature
