Here are the results so far...

Voting goes through Saturday 8am PDT.

My review

View all my reviews.

Example process flow...

1. Identify a valid vulnerability report from some source ... (freshports is your friend here as it will help identify the exact FreeBSD port name and whether the vulnerability has already been reported.

2. Complete the form

3. Save the resulting XML, for example /tmp/portname.vuxml

4. send-pr -a /tmp/portname.vuxml

5. Complete the problem report and send.

I'm also considering an option to have the submission sent to me (or some sort of queue) instead of just producing the raw output, that way it can find it's way to the vuxml input stream with even less effort.

I've been do this for a while now and have most of the wrinkles ironed out.

Here is the software I use.

• Internet Browser such as Firefox
• tivodecode
• winff or HandBrake
• iTunes (optional)

Here are the steps.

1. My TiVo has a webserver so just visit https://192.168.1.249/ (replace with proper IP address) and login using U: tivo P: <your-Media-Access-Key>. Hint: The Media Access Key (MAK) can be found on your TiVo menus under settings. Find the show you want to put on your iPod. Download "Some Title.TiVo" to /share2/video/fromtivo/

2. On dogma (my FreeBSD file server) run

cd /share2/video/fromtivo/
tivodecode -m 1234567890 -o outfile.mpg "Some Title.tivo"

This produces the MPEG video. Note that the aspect looks funky in totem a.k.a. Movie Player but it gets fixed in next step.

3. On my Ubuntu laptop, run winff Application. (Note: HandBrake also works fine for this step).
. Add the .mpg file created in step 2. Specify output for iPod and Xvid 4:3. Click options and specify 320x240 in the size. Specify /share2/video/4itunes as the output folder.

4. Back in iTunes, import the resulting outfile.mp4 file and copy to iPod.

To make things like this easier I run a file server with NFS and Samba. Video files are shared across the network from the /share2/video mount point on Linux which is same as V:\ drive mapping on the windows desktops for the iTunes library import.

However this new incarnation is based on the much more recent svn releases which bundles in support for OGG Vorbis (.ogg) and FLAC transcoding which is great if you chose, like me, to encode your digital audio in those alternative formats. Nearly 90% of my collection is in ogg vorbis.

Links:

• http://www.freshports.org/audio/firefly/
  
• http://conshell.net/wiki/index.php/User:Fostermarkd/Firefly
  

Future plans: Notifying Last.fm (a.k.a audioscrobbling) on listen, making it an non-default OPTION on build.

The vulnerabilities identified by portaudit via vuxml is built by volunteer submission, so users submit patches to /usr/ports/security/vuxml/vuln.xml to describe newly-discovered vulnerabilities. So I consider this a negative in a way since vulnerabilities are frequently falling through the cracks. Can port-maintainers be held responsible for updating vuxml when their ports are listed? I think this would be a reasonable compromise.

Otherwise we need a delegation of responsibilities to ensure vulns DON'T fall through the cracks. Perhaps a team of volunteers who focus on CVEs, non-CVEs (e.g. SecurityFocus or FrSIRT but not CVE-listed) and strictly vendor identified vulns would be able to provide better coverage.

There's also the learning curve of generating vuxml entries, which I describe here. The process is a bit cumbersome and could use some help, so I've begun working on a "wizard" HTML form for vuxml submission (Note:non-functioning as of yet) which could make this a little easier esp. for newbies.

I'd also love to see portaudit ported to Linux distros (both RPM and DEB) as it should be fairly easy to do.

The symptom is that the carp0 interface appears but cannot be communicate, and failover does not happen. Reason being, the vmnet driver is silently dropping the packets on the floor!

To get it working requires a patch (on the host) to vmnet-only/driver.c and recompile.

Here is the patch for vmware-server-1.0.7 for Linux. Save it into /tmp/driver.c.patch

--- vmnet-only/driver.c.orig 2008-10-08 15:37:23.000000000 -0500+++ vmnet-only/driver.c 2008-10-08 15:44:50.000000000 -0500@@ -1284,6 +1284,9 @@     return ((flags & IFF_PROMISC) || MAC_EQ(destAddr, ifAddr) ||      ((flags & IFF_BROADCAST) && MAC_EQ(destAddr, broadcast)) || +  ((destAddr[0] == 0) && (destAddr[1] == 0) &&+   (destAddr[2] == 0x5e) && (destAddr[3] == 0) &&+   (destAddr[4] == 1)) ||     ((destAddr[0] & 0x1) && (flags & IFF_ALLMULTI ||        (flags & IFF_MULTICAST &&         VNetMulticastFilter(destAddr, ladrf)))));

The file is a little hard to find, being hidden in a vmnet.tar below /usr/lib/vmware/modules/source/ ...

cd /usr/lib/vmware/modules/sourcetar xvf vmnet.tarpatch < /tmp/driver.c.patchtar cvf vmnet.tar vmnet-onlyvmware-config.pl

Then, choose the option to recompile the kernel drivers, specifically vmnet.

The one other addl. need (I'm not 100% sure on this) is that it may be necessary to allow promiscous on the ethernet device, in the .vmx file...

ethernet0.nopromisc = "false"

References...

• VRRP & CARP with VMware Server
  
• CARP problem with VMWare Server
  

root@sonar:/tmp>/usr/local/libexec/nagios/check_smtp -H sonar/libexec/ld-elf.so.1: Shared object "libssl.so.4" not found, required by "check_smtp"

Here's the deal, whenever FreeBSD releases a new version they bump the library version numbers as a matter of course. So there may be little to no fundamental difference between libcrypto.so.4 libcrypto.so.5. Or maybe there is. That's why this is risky... but what have I got to lose?

Cut to the chase... if ldd /path/to/binary reveals one or more libraries that aren't found, it can be time for entries in /etc/libmap.conf (instead of the safer/slower choice of rebuilding the port providing said binary).

/usr/local/libexec/nagios/check_smtp:        libssl.so.4 => not found (0x0)        libcrypto.so.4 => not found (0x0)        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x40746000)        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x40852000)        libc.so.6 => not found (0x0)        libc.so.7 => /lib/libc.so.7 (0x40956000)

By using `locate libssl.so` and variants I was able to see that the libraries were in fact available, only the versions had been incremented. Here are the libmap.conf entries I created.

libssl.so.4     libssl.so.5libcrypto.so.4  libcrypto.so.5libc.so.6       libc.so.7

Now my program is fixed.

root@sonar:/tmp>/usr/local/libexec/nagios/check_smtp -H sonarSMTP OK - 0.072 sec. response time|time=0.071886s;;;0.000000

pfSense has openvpn capability. You can provide SSL CA and server certificate + key.
It also wants the Diffie Helman (DH) parameters. Generating these is described by the openvpn documentation as running ./build-dh script.

Not really an option within pfSense. So you need the "other" command that works on pfSense.

Here's what I did.
1. SSH to pfsense system (ssh admin@pfsense)
2. Choose 8) Shell from menu
3. Run # openssl dhparam -out dh1024.pem 1024
4. cat dh1024.pem
5. Paste contents into pfsense web form.

Here is what the parameters should look like.
-----BEGIN DH PARAMETERS-----
MIGHAoGBAJe656S7xrtxwiQbL/hQ6POKhywl8avqLw2ZxMux5YsQnEQJIHr0sCm1
...RANDOM GIBBERISH...
k963XupLUOCM893va70qdpCjEZFapXZsm7nlFfsDMafOWFRyyY4bAgEC
-----END DH PARAMETERS-----

Richard Bejtlich gave it a nice review, which is a good sign.

Of course I've got to finish Absolute FreeBSD 2nd Edition first.