Re: RFS: webhoneypot

["Christian Pohl" <whp@pohlcity.de>]

Ansgar Burchardt wrote:
> Hi,
>
> Christian Pohl <whp@pohlcity.de> writes:
>> ---snip---
>> Where does trunk/update/update-templates.php store updated files? Does
>> it overwrite files contained in the package with newer versions?
>> ---snap---
>> it will overwrite files in the templates dir if a new version of this
>> file is on the server (See README.debian)
>
> That is a policy violation: "/usr is the second major section of the
> filesystem. /usr is shareable, read-only data. That means that /usr
> should be shareable between various FHS-compliant hosts and must not be
> written to. Any information that is host-specific or varies with time is
> stored elsewhere."[1]
>
> You likely want to store the templates in /var. Also take care that
> updated templates are not overwritten when the package is updated.
>
>   [1] <file:///usr/share/doc/debian-policy/fhs/fhs-2.3.txt.gz>
>
That's interesting. I thinks there are some other webapps out there that
have a (web-called) config skript that writes a config.php (or similar) in
/usr/share/<mywebapp>.

But thanks, I've overseen that while going through the policy/FHS. I will
modify this to /var/webhoneypot/templates.

>> ---snip---
>> I see that update-templates.php does verify the integrity of the
>> update...
>> ---snap---
>> yes all files are verified (See README.debian)
>
> The code still doesn't seem to do so.

Okay, the output is a little bit confusing.
1. the main update information has a sha1-hash.
2. for all other files, only the filename (from 1.) is verified, that it
has the correct pathes in the templates directory, otherwise the file will
not be downloaded.
The content of the file is not verified, as it does not matter what is
inside these files - but it must be stored in the correct place, that
information is verified. There could be anything inside these directories,
it is simply served to the client, as a "plain" webserver would do. No
evaluation or similar (okay some very simple and not perfect string-regex
filter are inside to filter out javascript).

>
>> ---snip---
>> Please split the patch in debian/patches (if necessary) and give it a
>> sensible name.  New files (manpages, example configuration) can also be
>> shipped in debian/ instead of in a patch.
>> ---snap---
>> debian/patch is automatically build by debuild.
>> (e.g manpages are in debian/webhoneypot.manpages which is read by
>> dh_installman)
>
> You can still use quilt to create a patch with a sensible name.  Or
> follow my second suggestion.

I simply followed the mainatineres guide. And I see no vialation of any
policy there. But i will see, what I can do to quilt (to make you happy
;-).

Cu,

Chris

-- 
Christian Pohl
whp@pohlcity.de