On OSX 10.6 (and probably 10.5 too) the built-in firewall asks whether to allow Serviio to accept incoming network connections on each start of Serviio. Before jumping to the solution, let me explain the cause of the problem.

On OSX 10.5 and upwards, application bundles can optionally be signed. The system uses these signatures to guard access to the network and to the keychains. Whenever the system asks whether to allow an application access to one of these services, it records the signature of the application along with the application itself. The next time the same application asks for access, the system checks if the application's signature matches the recorded one and that the signature matches the actual application. If both checks succeed (and the user hasn't manually revoked access to the application in the mean time) the application is granted access without further user intervention.

Whenever the system encounters an unsigned application that requests access to the keychain or network, the application is signed ad-hoc with some self-signed certificate (presumably created at system install time, not sure there).

Now, Serviio stores its Apache Derby database and the log in Serviio.app/Resources/Java/library and Serviio.app/Resources/Java/log respectively. Thus the signature created during the first launch of Serviio, after the user confirmed network access, does not mach the bundle's actual contents during the next launch, and the system reacts by making the user confirm network access again manually. Note that OSX never updated a bundle's signature, it only creates one if none exists. Thus, once the bundle is modified after the first launch, the dialog requesting network access pops up on every further start.

Luckily, however, the solution is quite simply. OSX does allow application to modify their own bundle, it just requires one to clearly seperate between volatile and non-volatile content. By default, only Files under Contents/MacOS and Contents/Resources/ are included in the bundle's signature. Thus, simply moving the Derby datbase and the log file out of Contents/Resources/Java, say into Contents/DynamicResources/Java, fixes the problem.

I've done so by simply modifying the properties serviio.home and derby.system.home in Serviio's Info.plist. Here's the relevant section of the file

<key>serviio.home</key>
<string>$APP_PACKAGE/Contents/DynamicResources/Java</string>
<key>derby.system.home</key>
<string>$APP_PACKAGE/Contents/DynamicResources/Java/library</string>

If you do that before launching Serviio.app for the first time (or after downloading a fresh copy) it ought to be enough to make the confirmation dialog appear just once. If you've launched Serviio previously, then it'll already carry an invalid signature and the system won't fix that signature. One way to fix that is to create your own code signing identity (certificate) using the Keychain Application and to use the codesign utility to forceably sign Serviio.app with that identity. (“CodeSigner” is the name of my code signing identity (certificate) )

codesign -s CodeSigner -v -f Serviio.app/