libnids, autolog and snoopy (Was: Re: Ask for review)

[Marcos Fouces]

Hi Raphaël and Lukas

El 05/07/17 a las 23:58, Lukas Schwaighofer escribió:
> Hi Marcos and Raphaël,
>
> from this thread three packages are still open.  I looked at them:
>
>
> 1. libnids
>
> I reverted the soname bump as suggested by Raphaël and bumped the
> Standards version to 4.0.0
>
> Raphaël also requested that we ensure that the dsniff version in the
> archive works with the updated libnids.  I have not done that yet.
> (Working on snoopy took me too long and it's too late now…)

I did rebuild and use dsniff and libnids repo versions and it seems to 
works well. So i believe that libnids could be uploaded.

>
> 2. autolog
>
> I see that Marcos worked on the improvements suggested by Raphaël.
> I've made a few changes on top of it:
> * changed debian/rules so that clean works also with patches unapplied
> * removed preinst file: It does a cleanup of wrongly leftover files from
>    that package, but the cleanup code has been present since a version
>    before o-o-stable.  It's my understanding that this can now be
>    dropped.  Please correct me if that's not the case.
> * simplified and corrected the removal of autolog's log files
> * minor beatification of postinst
> * correct errors in systemd service file (and make sure it's actually
>    installed…)
>
> I have a question regarding the systemd service file.  Marcos, you
> specified:
>
>    CapabilityBoundingSet=~CAP_SYS_PTRACE
>
> Is there a reason you just remove that specific capability?  I expect
> there are a lot more that could be removed and I was wondering why you
> exactly remove that one.
This is a capability that i judged unnecesary as i don't think that 
autolog should not help to debug any other process.
I did not remove more capacities due to lack of time to test the result.
In fact, i still not tested properly if the removal of CAP_SYS_PTRACE 
affect autolog.

I believe that more test is needed in order to upload this package

> 3. snoopy
>
> Raphaël, you wrote:
>>      # is snoopy already in $PRELOADFILE?
>>      test -f $PRELOAD && grep "$LIBNAME" $PRELOAD && exit 0
>>
>> That will fail if $PRELOAD does not exist or if it doesn't contain
>> $LIBNAME. Given "set -e" the whole postinst will fail... and thus
>> dpkg-reconfigure will never work to add or remove libsnoopy.so from
>> /etc/ld.so.preload.
> I don't think what you say is correct.  From dash(1) about errexit:
>
>      If not interactive, exit immediately if any untested command fails.
>      The exit status of a command is considered to be explicitly tested
>      if the command is used to control an if, elif, while, or until; or
>      if the command is the left hand operand of an “&&” or “||” operator.
>
> Both the test and the grep are left hand operands of "&&" here, so I
> don't see how this can fail.  However, since I dislike the `exit 0` (as
> it doesn't allow the #DEBHELPER# expanded code to run later), I have
> rewritten it anyways. I made all the other changes Raphaël proposed as
> well.
Good!
>
> During testing I found out that programs with the suid bit set cannot
> find the shared object unless the absolute path to the shared library
> is given in /etc/ld.so.preload.  I made a little stunt to have the
> DEB_HOST_MULTIARCH triplet available in postinst…
>
> Now the package is no longer Multiarch capable.  But to be honest, it
> never was, all the versions since the Multiarch was introduced have the
> problem explained above.  I've removed `Multiarch: same` from
> debian/control.
>
>
> Regards
> Lukas
If you tested properly the package (basically, check that produces 
proper log entries), i believe that it could be uploaded.

Good job! Thanks.

Marcos