The problem has to do with OpenOffice.org throwing out the following error when trying to boot in Hardened Gentoo:

terminate called after throwing an instance of ‘std::bad_alloc’
what(): std::bad_alloc

Turns out this has to do with the way OpenOffice.org tries to work against the mprotect restrictions. You can lift those restrictions by using paxctl (emerge -av paxctl) in the following way:

# check for current PaX settings:
paxctl -v /usr/lib/openoffice/program/soffice.bin
# disable mprotect:
paxctl -m /usr/lib/openoffice/program/soffice.bin

Now OOo should finally launch. This enables you to write a polite letter to the OOo team asking them to allow us to run OOo with mprotect.

First problem was not that hard to figure out: caff is not called caff in most packagemanagers. So, as I use Gentoo, I typed
emerge -av signing-party
and was on my way.

Caff stores it’s configuration in a user specific file called ~/.caffrc which can just be kept default to be honest. All you need to do is enter your full name, your email address, your keyid (see the config itself for instructions) and optionally customize the message to be sent. The real trick comes when editing some customizations for gpg.

For example, I wanted to define a default signing level. As you may or may not know, PGP keysigning can be fine-tuned by defining your level of confidence in establishing the key owner’s identity. All in all, as there was some checking of ID’s and confirming those, but doing this outside and using only one ID of variable quality, I felt level 2 would be the most appropriate (I’ll write a personal key signing policy in the near future). After some searching around I discovered that it was indeed not the right place to set this in caffrc, as the gpg-sign-args option was not meant to be used like that. To set this default I would normally have to add this preference to ~/.gnupg/gpg.conf, however, caff uses it’s own gnupg homedir, so nano -w ~/.caff/gnupghome/gpg.conf and add the following:
default-cert-level 2
(and any other customizations you feel that are needed, such as “charset utf-8″, and did you switch to SHA256 already btw?)

You may, however, use gpg-sign-args to avoid having to manually save the changes after signing each key, if you like. Insert the following in ~/.caffrc:
$CONFIG{'gpg-sign-args'} = 'save';

After this, the signing of specific keys with caff should work just fine. But there’s still the issue of being able to actually send out those keys by email to the owner. For that purpose we can use the very basic sSMTP, which is most likely already present on your system. If not, and when using Gentoo Linux:
emerge -av ssmtp

sSMTP comes with two config-files, which both need to be edited to work with my provider’s TLS enabled mailserver (just like Google’s Gmail for that matter). I’ll provide you with both the files (stripped of comments) the way I have them functioning properly:

/etc/ssmtp/ssmtp.conf
root=postmaster
mailhub=mail.provider.tld:587
AuthUser=username
AuthPass=password
rewriteDomain=
hostname=email@domain.tld
FromLineOverride=YES
UseSTARTTLS=YES

/etc/ssmtp/revaliases
root:email@domain.tld:mail.provider.tld:587
defaultuser:email@domain.tld:mail.provider.tld:587

Finally, this enabled me to send out the signed keys using caff. The current version of caff does add an invalid Sender header consisting of username@hostname unfortunately, though this has reportedly been solved recently. I solved it myself by inserting the Sender line which was added in the patch mentioned above. Feel free to propose other enhancements in the comments.

Update, 16 February 2010: I now have a personal keysigning policy! For automatically adding the policy URL to signatures, I use the following option in gpg.conf:
set-policy-url http://url/to/policy

Fine, now, on your local machine (LOCAL), generate an IdentityFile to be used for mounting the remote filesystem. I suggest that, while root, you execute the following:
ssh-keygen -f /root/.ssh/YOURKEYFILE
Assure that permissions are set accordingly:
chmod -R 700 /root/.ssh
Now, get the /root/.ssh/YOURKEYFILE.pub file. Yes, the one ending in .pub, not your secret one. Now, on the machine REMOTE, I suggest you add a new user, to be used solely for mounting with sshfs. Give it a catchy name like REMOTEUSER:
useradd -m REMOTEUSER
password REMOTEUSER #do not leave this blank!
Now make sure that the contents of YOURKEYFILE.pub get appended or added to /home/REMOTEUSER/.ssh/authorized_keys (which is of course on REMOTE, not on LOCAL). I don’t know (or care) how, use scp, use another machine, use an USB stick, you’ll figure it out.

After all this, you should be able to log into REMOTEUSER from LOCAL by executing the following as root:
ssh -i /root/.ssh/YOURKEYFILE -p REMOTEPORTNUMBER REMOTEUSER@REMOTE
If this does not work, check logfiles or use debugmodes.

From here it’s not that much work to get to mounting disks or folders which are physically on REMOTE to LOCAL. First, make sure you have sshfs installed. In Gentoo you can simply emerge:
emerge -av sshfs-fuse
Do this.

Now, make sure you know your LOCALMOUNTPOINT (and ensure the empty folder exists by using mkdir) on LOCAL and know which REMOTEMOUNTPOINT you want to mount (located on REMOTE). Try mounting it by executing the following as root:
sshfs REMOTEUSER@REMOTE:REMOTEMOUNTPOINT LOCALMOUNTPOINT -pREMOTEPORTNUMBER -o uid=LOCALUSERID -o gid=DESIREDGROUPID -o idmap=user -o IdentityFile=/root/.ssh/YOURKEYFILE -o allow_other
Please pay close attention to which value is entered where, and, if in doubt, read man sshfs. The values for LOCALUSERID and DESIREDGROUPID determine with what ownership the REMOTEMOUNTPOINT is mounted on LOCAL. The numbers entered represent uid and gid numbers residing on LOCAL.

If this works as expected, it is a simple matter of reformatting the above command, so /etc/fstab is able to automatically mount your REMOTEMOUNTPOINT at (LOCAL)boot. Or so I thought. Turns out it was slightly more complicated, but after some trial and error and some more searching the web I came up with the following working line for fstab:
sshfs#REMOTEUSER@REMOTE:REMOTEMOUNTPOINT LOCALMOUNTPOINT fuse port=REMOTEPORTNUMBER,uid=LOCALUSERID,gid=DESIREDGROUPID,idmap=user,IdentityFile=/root/.ssh/YOURKEYFILE,allow_other 0 0
That should do the trick! You can test this by ensuring you have not mounted your REMOTEMOUNTPOINT on LOCAL at this moment (try fusermount -u LOCALMOUNTPOINT) and then simply entering:
mount LOCALMOUNTPOINT #Yes, the one you just entered in /etc/fstab
That’s it! Any comments or questions can be directed to the comments below and I will attempt to adjust the above as needed.

But it failed.

nmap: unrecognized option '--script'
[snip: followed by regular nmap --help output]

Eh?

As my thinking was suspended, I went for Google to find me the culprit responsible for this error. No results. What? Ah, well, this is just why I wanted my own blog: to enhance Google with yet unknown knowledge (or knowledge previously only available in obscure languages). Now only to find the solution…

Turns out it was actually rather simple: compile Nmap with the lua USE flag. Yes, that’s all.

OPEN PACKAGE.USE
nano /etc/portage/package.use
AND INSERT
net-analyzer/nmap lua
OR ON A TERMINAL ENTER
echo "net-analyzer/nmap lua" >> /etc/portage/package.use

After this you’re good to go.

While I’m at it, let’s leave you with the recommended scan options at the moment of writing:

#Source: Nmap changelog
o Recommended command for a fast Conficker scan (combine into 1 line):
nmap -p139,445 --script p2p-conficker,smb-os-discovery,smb-check-vulns
--script-args checkconficker=1,safe=1 -T4 [target networks]
o Recommended command for a more comprehensive (but slower) scan:
nmap --script p2p-conficker,smb-os-discovery,smb-check-vulns -p-
--script-args checkall=1,safe=1 -T4 [target networks]