Use the experimental one. The main one is out of date and broken wrt amd-64.

No workarounds needed for experimental.

Except, perhaps, this is likely to be a nightly build. If so, its no use to users wanting a stable released version.

Anyhow, according to http://martin.feuersaenger.de/2005/12/12/how-can-i-avoid-gpg-errors-with-apt-06-and-above/

If you just want to declare a repository as trusted just run:

gpg –recv-key KEY_ID && gpg -a –export KEY_ID | apt-key add -

where KEY_ID is a string after NO_PUBKEY.

So:

gpg –recv-key 3C0C33BB442B5BE9 && gpg -a –export 3C0C33BB442B5BE9 | apt-key add -

Issue 3:

Upon saving the configuration screen it reports that the LoginManager has changed.
The default setting as supplied is:

$TWiki::cfg{LoginManager} = ‘TWiki::Client::ApacheLogin’;

After the save it becomes:

$TWiki::cfg{LoginManager} = ‘TWiki::LoginManager::ApacheLogin’;

These appear to be the same thing, and the first one isn’t a choice in the drop down list in the configuration page. So I guess this variable should be changed in the default file that is supplied.

Issue 1.

Upon running the ‘configure’ script for the first time there are three warnings:

Warning 1:

In the “General Path Settings” section under the “WorkingDir” setting there is the following warning:

Warning: You have an existing {RCS}{WorkAreaDir} (/tmp/twiki), so I have copied the contents of that directory into the new /var/lib/twiki/working/work_areas. You should delete the old /tmp/twiki when you are happy with the upgrade.

It seems to be that in the /etc/twiki/LocalSite.cfg file, the default value for $TWiki::cfg{WorkingDir} is ‘/tmp/twiki’. But this has been changed to ‘/var/lib/twiki/working’ (which is fine). However there are also the variables $TWiki::cfg{RCS}{WorkAreaDir} and $TWiki::cfg{TempfileDir} that are still set to ‘/tmp/twiki’. Maybe these should be set to the following instead?

$TWiki::cfg{RCS}{WorkAreaDir} = ‘/var/lib/twiki/working/work_areas’;
$TWiki::cfg{TempfileDir} = ‘/var/lib/twiki/working/tmp’;

Does that look right?

Warning 2:

Under the “Security setup” section under the “SafeEnvPath” setting I get the following warning:

Warning: You should set a value for this path if there is any risk at all of your site being hacked.

I’m not sure if the SafeEnvPath setting should be left blank or not? Maybe we should have something like the following?:

$TWiki::cfg{SafeEnvPath} = ‘/usr/bin:/bin’;

Warning 3:

Under the “Mail and Proxies” section under the “WebMasterEmail” I get the following warning:

Warning: Please make sure you enter the e-mail address of the webmaster. This is required for registration to work.

The WebMasterEmail is blank, even though at install time I was asked to enter a value for this via debconf. Should the $TWiki::cfg{WebMasterEmail} variable be defined in the LocalSite.cfg file and set to what you specified at install time?

Issue 2.

When I go to save the changes in the configure script, I need to set a password first.

It could be fine as it is…
But should the $TWiki::cfg{Password} be set in the LocalSite.cfg file and set to the same password that you defined for the administrative user as asked by debconf?

That’s it for now.

mind you – there is also the real security concern that any packages that are automatically built should be considered more suspect than a set that have had some ‘intentional’ work done on them – so there might be the other option – make a unsafe_may_burn@your village.com gpg keyset with no passphrase and use that?

wrt distributedinformation.com vs fosiki.com, doesn’t really matter for now – I’m likely to keep both because lots of my contributions out in the wild will have the ‘omg thats long’ domain on them.

The gpgp instructions are for Sven to sign the Releases file with.
It is up to the repository maintainer to do this, not the end user.
All the end user needs to do is import the key using apt-key so that they trust the signatures.

Sven.

The passphrase thing is a pain.
I had a quick hunt around but didn’t find any brilliant answers.
Here are some dodgy ways that you could perhaps automate the passphrase entry but you’d want to really lock down the scripts and/or files (and/or system) involved. Storing your passphrase on the computer isn’t the best idea… But here we go anyway:

1. Pass in the passphrase on stdin (file descriptor 0):

# echo “passphrase” | gpg –passphrase-fd 0 –sign -ba Release.gpg Release

2. Store the passphrase in a file only readable by the user doing the signing and use that:

# gpg –passphrase-file /path/to/passphrase_file –sign -ba Release.gpg Release

3. Pass the passphrase in as a command line parameter:

# gpg –passphrase passphrase –sign -ba Release.gpg Release

4. Another possible option is to install and configure gnupg-agent and then use the –use-agent command line option of gpg when signing. But I’m not sure if you can get the gnupg-agent to indefinitely cache your passphrase or not, so it might not be a good option.

I’m not sure if anyone else knows a better approach?

Also I have a question.
Do we still use:

deb http://distributedinformation.com/debian/ blah…

Or should we convert over to the following?:

deb http://fosiki.com/debian/ blah… ]]> http://fosiki.com/blog/2007/04/22/debian-repository-for-twiki/comment-page-1/#comment-20 Sven Dowideit Mon, 08 Sep 2008 09:41:12 +0000 http://distributedinformation.com/blog/2007/10/06/debian-repository-for-twiki/#comment-20 Sorry guys, It turns out that because I rebuild the packages from twiki.org every night while I sleep, and automatically add them to the debian repository, the signing thing isn't going to work out in the short term - it requires me to type in my passkey - and so isn't suitable for unattended use. wrt amd64 - thats a bit weird, as they are built on an amd64 machine, and I _thought_ they were noarch. toss another stick on my todos :/ Sorry guys, It turns out that because I rebuild the packages from twiki.org every night while I sleep, and automatically add them to the debian repository, the signing thing isn’t going to work out in the short term – it requires me to type in my passkey – and so isn’t suitable for unattended use.

wrt amd64 – thats a bit weird, as they are built on an amd64 machine, and I _thought_ they were noarch. toss another stick on my todos :/

gpg –keyserver the.earth.li –recv-keys 3C0C33BB442B5BE9
apt-key add /root/.gnupg/pubring.gpg

Which didn’t work. So, I followed the advice at Jim Barber’s post:

gpg –sign -ba Release.gpg Release

Which returns this error:

gpg: no default secret key: secret key not available
gpg: signing failed: secret key not available

And with only the stable repos added, I’m stuck at this error after #sudo apt-get update

W: GPG error: http://distributedinformation.com stable Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 3C0C33BB442B5BE9
W: You may want to run apt-get update to correct these problems

The previous error was on an amd64 system, and there obviously aren’t any 64 bit binaries, so I’m on a 32 bit system now with one less error message.

W: GPG error: http://distributedinformation.com experimental Release: The following signatures were invalid: BADSIG 3C0C33BB442B5BE9 Sven Dowideit
W: Failed to fetch http://distributedinformation.com/debian/dists/stable/Release Unable to find expected entry main/binary-amd64/Packages in Meta-index file (malformed Release file?)

I’ve read through the comments and the link to SecureApt, but I’m still coming up short. Any advice would be appreciated.

So, I