In this case you would want to turn off the "Strip Debug Symbols
During Copy" option in your Xcode target's build settings. Since the
framework has already been stripped and signed its warning you so that
you know its not going to attempt to strip the framework. It does
this because stripping the framework modifies the bundle and
invalidates the code signature.
The other option you have, if this binary is destined for the Mac App
Store, is to remove the code signature from the framework and allow it
to pass through the strip debug symbols during copy phase. Ultimately
then signing the framework out the other end of your build process
using your 3rd Party Developer Application certificate. Apple is only
using the code signature in this manner to verify that the person
submitting the binary is the person that they've previously exchanged
certificate signing requests for. The code signature is immediately
overwritten when they receive the binary and it never ships to the
user with the certificate they issue you.
That said, if you're targeting the end user with a Developer ID
certificate it would be the same situation, since the certificate
Chris signed the Growl framework with wasn't a Developer ID
certificate there is a good chance at this point that gatekeeper would
detect this and tell the user they can't run your binary under the
AppStore+KnownDeveloper option on Mountain Lion. Ultimately you're
the one shipping the framework(s) in your binary and that signature
that each gets wrapped in tells the user that you're taking ownership
of what you're shipping.
-rudy