Re: [Tails-dev] htpdate HS notification [Was: Tails 0.10 rel…

このメッセージを削除

このメッセージに返信
著者: anonym
日付:  
To: The Tails public development discussion list
題目: Re: [Tails-dev] htpdate HS notification [Was: Tails 0.10 release plan]
12/29/2011 07:37 PM, intrigeri:
> Hi,
>
> (splitting the thread)
>
> anonym wrote (29 Dec 2011 16:31:13 GMT) :
>> * A "fix" for bugs/Tails_0.9_doesn__39__t_open_.onion_sites_.
>> See branch feature/htpdate_hs_notification which basically
>> reintroduces a modified version of the htpdate notification we had
>> before (perl guru's please fix the notification script!).
>
> Seems great. Remarks bellow:
>
> 1. i18n
>
> Seems like the .po / .pot files were not brought back from the
> history. I guess a bunch of strings have probably not changed since
> the times we were shipping this script, have they?


Fixed (see commit cdc9b29).

> 2. chmod
>
>> +       chmod a+r ${PIDFILE}

>
> How's that it's needed? Doesn't start-stop-daemon use the default
> umask? Why not, but definetely weird.


It's all pretty weird. First of all, root's umask is 0077, so any files
created by root should not be world readable. However, the first time
htpdate is started the pid file is created with perms 644 (why?), so
that's good, but weird.

But what about restarting the htpdate init script (which we strictly
don't have to support, but I think it's good practice to still make it
possible)? Since the notification script uses htpdate's pid file to
identify which process to monitor, any residual pid file must be removed
when starting the htpdate init script (which is done). For whatever
reason the pid file is then re-created with the umask, so perms are 600,
which is bad.

> 3. debug mode
>
>> +### Enabling debug mode until the Squeeze regression is sorted out.
>> +$debug = 1;
> [...]
>> +sub debug { say STDERR $_[0] unless $debug; }
>
> "unless", really?


That's a left-over from the old script, so I'm not responsible :). Any
one remember what "Squeeze regression" the above is referring too?

Cheers!