On Thu 19/Oct/2017 21:10:58 +0200 Daniel Kahn Gillmor wrote:
> On Thu 2017-10-19 13:04:13 +0200, Alessandro Vesely wrote:
>>
>> What do you reckon?
>
> I'm not particularly interested in setting up cronjobs for people that
> (a) introduce new regular network activity and (b) have dubious
> cryptographic integrity and public transparency properties. Debian
> packages already solve problem (b) and they avoid (a) by piggypacking on
> the standard update channels that the operating system already performs.
Fine.
> Can you motivate your concern about daily updates a little more clearly?
> You seem to have a sense of urgency about them that i don't have. Maybe
> you're seeing some concern that i'm not seeing, though.
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.
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. Searching my
disk, for example, I get:
$ ls -lt `find /usr -type f | xargs grep -l traffic-contro`
-rw-r--r-- 1 root root 70512528 Sep 28 23:02 /usr/lib/firefox-esr/libxul.so
-rwxr-xr-x 1 root root 95541560 Sep 27 04:03 /usr/bin/chromium-shell
-rwxr-xr-x 1 root root 142386136 Sep 27 04:03 /usr/lib/chromium/chromium
-rw-r--r-- 1 root root 73807152 Sep 6 18:15 /usr/lib/thunderbird/libxul.so
-rw-r--r-- 1 root root 979152 Aug 9 16:31
/usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1.8.0
-rw-r--r-- 1 root root 64892640 Jul 23 14:12
/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar
-rw-r--r-- 1 root root 36269 Apr 24 09:17
/usr/share/publicsuffix/public_suffix_list.dafsa
-rw-r--r-- 1 root root 194948 Apr 24 09:17
/usr/share/publicsuffix/public_suffix_list.dat
-rw-r--r-- 1 root root 55136 Jan 24 2017
/usr/lib/x86_64-linux-gnu/libpsl.so.5.1.1
-rw-r--r-- 1 root root 5024184 Jan 11 2017
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.7.1
-rw------- 1 ale ale 1386614784 Nov 28 2016 /usr/lib/mailman/Mailman/core
-rw-r--r-- 1 root root 3090544 Nov 9 2016
/usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.7
-rw-r--r-- 1 root root 188997 Aug 8 2016
/usr/share/perl5/Domain/PublicSuffix/Default.pm
-rw-r--r-- 1 root root 190368 Jul 14 2016
/usr/share/perl5/IO/Socket/SSL/PublicSuffix.pm
-rw-r--r-- 1 root root 129891 Jun 14 2015
/usr/share/emacs/24.5/etc/publicsuffix.txt
Quite some, eh?
Some of them are old, some of them are new
Some of them will turn up when you least expect them to
And when they do, remember me, remember me.
[B. Eno]
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.
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?
Ciao
Ale
