[pmwiki-devel] PmWiki Debian package

[Chris Knadle]

Hey, Petko.

On Thursday, May 01, 2014 00:13:01 Petko Yotov wrote:
> Chris Knadle writes:
> > The tarball currently contains an empty directory "pub/css" which the
> > Debian package checker (Lintian) complains about, specifically because
> > it's empty. I'm assuming pub/css is a "placeholder" directory to give a
> > PmWiki user a hint
> > as to where to place their own CSS files if desired.  Is that correct?
> 
> Yes, in that directory you can have files local.css, Group.css and
> Group.Page.css which are loaded automatically and let people override the
> skin's CSS instructions, see http://pmwiki.org/GroupCustomizations

Ah okay -- I should probably mention that in the README.Debian file (as it 
will explain why the directory is created there).

> But in case of a WikiFarm, PmWiki doesn't use the farm's pub/css directory,
> it uses the field's pub/css directory: where you install index.php, uploads/
> and local/ of the field, also create pub/css/ .

Yes, that's what I expected.  So since Lintian is complaining about the empty 
directory, I think what I can do is have the pmwiki-newfield script do that, 
and also document that for setting a new "field" up manually and what that 
directory is for (i.e. mention what you've listed above).

I think that's the last thing I "knew I should tweak" but didn't have the 
reasoning to fully explain.

Cool... thanks.

> > Lintian also complains that the pmwiki tarball is not GPG/PGP signed. 
> > This isn't a requirement, but if the tarball were GPG/PGP signed there'd
> > be a way of verifying that the tarball had not been modified (and this
> > can be set up in the Debian package to be done automatically), so I'm
> > mentioning it as "something for future consideration".
> 
> We publish MD5 sums of the released files, see the download page. They can
> be used to test the integrity of the tarball.

That's good but of course not the same thing.  First because the MD5 algorithm 
is weak enough that it's possible to alter a file to make the MD5 checksum 
what you want it to be.  [IIRC there are automated exploits for this.  It 
might be slightly tricker to do with a .gz but I wouldn't count on it.]  But 
also a "fake site" that looks like the PmWiki site (let's just say -- I would 
hope this is theoretical) could then publish their own .md5 checksum files for 
"modified" PmWiki tarballs, and then it wouldn't be easy to distinguish the 
difference.

> About GPG signing, maybe Pm will have some ideas - he owns the server, I
> edit the source in SVN and pack the new versions using sripts on the server,
> so tricky.

Well I can give you an example of how I see this being done.  Another package 
I work on is the Mumble package in Debian.  If you look at the home page

    http://mumble.sourceforge.net/

under "Get Mumble" they've got a link, "GPG signatures" that points here:

   http://mumble.info/gpg/gpg.txt

The actual GPG key they're currently using to sign tarballs is this one:

   http://mumble.info/gpg/mumble-auto-build-2014.asc

And the fingerprint of that GPG key looks like this:

   $ gpg --fingerprint mumble
   pub   4096R/0xADD011045FEF3A9A 2014-01-04 [expires: 2015-01-01]
         Key fingerprint = D32E 5D9E 01D2 FAF5 9D09  F62C ADD0 1104 5FEF 3A9A
   uid   Mumble Automatic Build Infrastructure 2014 \
         <mumble-auto-build-2014 at mumbleapp.com>
   sub   4096R/0xCD3714E104DA1296 2014-01-04 [expires: 2015-01-01]

So in this case it's not a direct person's identity that signs the released 
tarballs, but a GPG created for the specific purpose of doing detached 
signatures on releases that in this case has a 1-year expiration date.  
[Expiration dates are changeable -- supposedly even if they're expired.]

Thus, the GPG key doesn't necessarily need to be yours nor PM's, rather it 
might a dedicated GPG key for this purpose.  

  -- Chris

--
Chris Knadle
Chris.Knadle at coredump.us