title: How do you codesign framework bundles for the Mac App Store?
body: <p>After a recent submission I have gotten the following error:</p>
  
  <blockquote>
    <p>Invalid Signature - the nested app bundle (FooBar.app/Contents/Frameworks/GData.framework) is not signed, the signature is invalid, or it is not signed with an Apple submission certificate. Refer to the Code Signing and Application Sandboxing Guide for more information.</p>
    
    <p>Invalid Signature - the nested app bundle (FooBar.app/Contents/Frameworks/Growl.framework) is not signed, the signature is invalid, or it is not signed with an Apple submission certificate. Refer to the Code Signing and Application Sandboxing Guide for more information.</p>
    
    <p>Invalid Signature - the nested app bundle libcurl (FooBar.app/Contents/Frameworks/libcurl.framework) is not signed, the signature is invalid, or it is not signed with an Apple submission certificate. Refer to the Code Signing and Application Sandboxing Guide for more information.</p>
  </blockquote>
  
  <p>So I signed all the framework bundles per <a href="http://developer.apple.com/library/mac/#technotes/tn2206/_index.html">Technote 2206</a>:</p>
  
  <pre><code>codesign -f -v -s "3rd Party Mac Developer Application: Name" ./libcurl.framework/Versions/A/libcurl
  codesign -f -v -s "3rd Party Mac Developer Application: Name" ./libcurl.framework/Versions/A/libssh2.1.dylib
  codesign -f -v -s "3rd Party Mac Developer Application: Name" ./Growl.framework/Versions/A/Growl
  codesign -f -v -s "3rd Party Mac Developer Application: Name" ./GData.framework/Versions/A/GData
  </code></pre>
  
  <p>Technote 2206 says:</p>
  
  <blockquote>
    <p>Signing Frameworks</p>
    
    <p>Seeing as frameworks are bundles it would seem logical to conclude that you can sign a framework directly. However, this is not the case. To avoid problems when signing frameworks make sure that you sign a specific version as opposed to the whole framework:</p>
    
    <p># This is the wrong way:</p>
    
    <p>codesign -s my-signing-identity ../FooBarBaz.framework</p>
    
    <p># This is the right way:</p>
    
    <p>codesign -s my-signing-identity ../FooBarBaz.framework/Versions/A</p>
  </blockquote>
  
  <p>And when I try to verify the results, it looks good to me:</p>
  
  <pre><code>% codesign -vvv FooBar.app/Contents/Frameworks/libcurl.framework
  FooBar.app/Contents/Frameworks/libcurl.framework: valid on disk
  FooBar.app/Contents/Frameworks/libcurl.framework: satisfies its Designated Requirement
  % codesign -vvv FooBar.app/Contents/Frameworks/Growl.framework
  FooBar.app/Contents/Frameworks/Growl.framework: valid on disk
  FooBar.app/Contents/Frameworks/Growl.framework: satisfies its Designated Requirement
  </code></pre>
  
  <p>For fun, I did try signing the framework bundle directly and it was still rejected. But that is exactly what the documentation said not to do.</p>
  
  <p>Any guesses why that would be considered invalid? I am using the same cert that I use to code sign my app -- the one that has worked in the past.</p>
  
  <p>My only guess would be something to do with the existing plists (do I need to own the identifiers in the framework's Info.plists?) or entitlements -- any suggestions?</p>