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-2...@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.kna...@coredump.us _______________________________________________ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel