Now that i see it in print, i recall that MicroMatTech3 did pass that information along in a (mid-September?) thread, but -- since i've haven't entered the Snowy landscape yet -- i totally forgot the fact.
I had forgotten too, actually, until you nudged me. I've given up on DURP as a (for the time being) lost cause. I don't think I've ever run it under Snow Leopard.
My guess is (obvious i suppose) that some subsequent update (prolly 10.6.2) installed a tweaked version of ARDAgent, and (as with 10.5) it simply didn't put the latest digest value somewhere that DURP could "see" it. But why not?
It does seem that -- despite the relocated receipt info -- the exact same problem has followed along from 10.5 to 10.6 . . . so then it's probably something they have in common.
And that's why I've given up on DURP. It's on my "just don't do that" list.
Some output you may find of interest:
VT_BOLD=$'\E[1m'
VT_NORMAL=$'\E[0m'
find /var/db/receipts -name '*.bom' | while read x; do lsbom "$x" | grep MacOS/ARDAgent && echo $VT_BOLD$x$VT_NORMAL; done
./System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent 104755 0/0 1676800 4158722535
/var/db/receipts/com.apple.pkg.Essentials.bom
codesign -vvv /System/Library/CoreServices/RemoteManagement/ARDAgent.app
/System/Library/CoreServices/RemoteManagement/ARDAgent.app: valid on disk
/System/Library/CoreServices/RemoteManagement/ARDAgent.app: satisfies its Designated Requirement
openssl sha1 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
SHA1(/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent)= e5af66d28074b92ea70f4154339ece31e905e64b
ls -lOe /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
-rwsr-xr-x 1 root wheel - 2528064 Aug 10 18:04 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
Notice that the modify date (Aug 10) predates the day I installed Snow Leopard (Sep 9).
