Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Rafal Lukawiecki]

MC20 asks 'Do you want the application "Media Center 20.app" to accept incoming network connections?' every time it launches, even though I have added it to the Firewall list. This is inconvenient on a server.

When I tried to sudo codesign --force --sign /Applications/Media\ Center\ 20.app/ I get an error that there is no identity in the app.

Please help.

[JimH]

I think that's the OS asking, not MC.

[Rafal Lukawiecki]

Indeed, I am very sorry for my incorrect wording. Let me rephrase the problem I am encountering with the newly purchased MC20 for Mac.

Is this a known issue or expected behaviour that the Mac OS X 10.9.5 asks 'Do you want the application "Media Center 20.app" to accept incoming network connections?' every time MC launches, even though I have added MC to the OS X System Preferences/Security/Firewall list? This is inconvenient on a server.

For what it is worth, when I tried to sudo codesign --force --sign /Applications/Media\ Center\ 20.app/ I got an error that there was no identity in the MCN 20 app.

These issues did not affect MC19 trial, which I used before I paid for the license a few days ago.

Please help.

[JimH]

I'm sorry, but I believe the problem is with the configuration of the firewall, not with MC.  The firewall is still blocking MC.

[glynor]

This is because MC is not signed by JRiver and one of the behaviors of the OSX Firewall and Gatekeeper function is that the firewall preferences cannot be saved in some circumstances:

Some apps check their own integrity when they are opened without using code signing. If the firewall recognizes such an app it doesn't sign it. Instead, it the "Allow or Deny" dialog appears every time the app is opened. This can be avoided by upgrading to a version of the app that is signed by its developer.

To override this behavior, you can also sign the application yourself.  See the second answer (from user465139) in this StackExchange question:

http://apple.stackexchange.com/questions/3271/how-to-get-rid-of-firewall-accept-incoming-connections-dialog

It may actually be easier if you use codesign --force as described here:
https://couchpota.to/forum/viewtopic.php?f=5&p=20638&sid=eef141e24a99b3be43854fcb79974c10

Unfortunately, I think either option will require you to re-sign it each time MC is upgraded.  It may also be triggered when OSX itself is upgraded (though not every time).

Jim or John, can you comment on why you aren't signing MC with a Developer ID for the OSX version?  I realize you have to join the OSX Developer program (or, that's the easiest way, though there are other ways), but... Heck, it is only $100 per year, and you only need one account.  Plus, they actually give you some fairly decent resources in the program...

I mentioned this back when MC19 first came out.  It isn't that hard, and you should be able to automate it as part of your build process with the codesign utility.  More details in this guide:
https://developer.apple.com/library/mac/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40005929-CH1-SW1

[glynor]

You may also be able to work around this by opening the port used by MC in the firewall permanently.  Not sure about this, though I've read a number of places.

http://rolfje.wordpress.com/2014/05/10/open-a-port-in-osx-mavericks-firewall/

[JimH]

MC is signed by JRiver.

[glynor]

It isn't trusted by Gatekeeper on OSX, because each time I install and launch it, I have to do the right-click > Open trick or Gatekeeper blocks it on the first run.

Is it self-signed?

Do not ship applications signed by self-signed certificates. A self-signed certificate created with the Certificate Assistant is not recognized by users’ operating systems as a valid certificate for any purpose other than validating the designated requirement of your signed code. Because a self-signed certificate has not been signed by a recognized root certificate authority, the user can only verify that two versions of your application came from the same source; they cannot verify that your company is the true source of the code. For more information about root authorities, see “Security Concepts”.

[JimH]

Is it self-signed?

I don't have the details, but it's a valid certificate.

[glynor]

Okay.  Here's OSX is rejecting it:

Code: [Select]

tilo:Applications glynor$ spctl --assess --verbose=4 --type execute "Media Center 20.app"
Media Center 20.app: rejected
source=matched cdhash

[glynor]

Here's the raw output:

Code: [Select]

tilo:Applications glynor$ spctl --assess --raw --type execute "Media Center 20.app"
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>assessment:authority</key>
<dict>
<key>assessment:authority:source</key>
<string>allowed cdhash</string>
<key>assessment:authority:weak</key>
<true/>
</dict>
<key>assessment:cserror</key>
<integer>-67007</integer>
<key>assessment:remote</key>
<true/>
<key>assessment:verdict</key>
<true/>
</dict>
</plist>

[glynor]

Okay, I'm pretty sure this is because your signature needs to be updated.  OSX 10.9.5 (and Yosemite builds on or after this date) were changed and now require a version 2 type signature (if codesign is used to sign them, as you are probably doing).

http://www.imore.com/devs-may-need-resign-apps-satisfy-mavericks-1095s-gatekeeper-changes
http://www.xojonews.com/news/important-change-for-develo.html

Easy enough to check your signature...

Code: [Select]

tilo:Applications glynor$ codesign -dv "Media Center 20.app"
Executable=/Applications/Media Center 20.app/Contents/MacOS/Media Center 20
Identifier=com.jriver.MediaCenter20
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20100 size=150673 flags=0x0(none) hashes=7527+3 location=embedded
Signature size=8513
Timestamp=Sep 11, 2014, 3:44:58 PM
Info.plist entries=24
TeamIdentifier=not set
Sealed Resources version=1 rules=4 files=5
Internal requirements count=1 size=216
This is the line:
Sealed Resources version=1 rules=4 files=5

I think that's why it is failing the assessment:authority:weak test.  From Technical Note TN2206 Code Signing in Depth:

Changes in OS X 10.9.5 and Yosemite Developer Preview 5

Beginning with OS X version 10.9.5, there will be changes in how OS X recognizes signed apps. Version 1 signatures created with OS X versions prior to Mavericks will no longer be recognized by Gatekeeper and are considered obsolete.

Important: For your apps to run on updated versions of OS X they must be signed on OS X version 10.9 or later and thus have a version 2 signature.

If your team is using an older version of OS X to build your code, re-sign your app using OS X version 10.9 or later using the codesign tool to create version 2 signatures. Apps signed with version 2 signatures will work on older versions of OS X.

Structure your bundle according to the expectations for OS X version 10.9 or later:

    Only include signed code in directories that should contain signed code.

    Only include resources in directories that should contain resources.

    Do not use the --resource-rules flag or ResourceRules.plist. They have been obsoleted and will be rejected.

[glynor]

More details in some of the answers here:
http://stackoverflow.com/questions/25152451/are-mac-app-store-code-sign-resource-envelopes-always-version-1

[JimH]

Thanks.

[glynor]

By the way, Apple hasn't said, but I think it is reasonable to assume that this has something to do with the problems with SHA1 or with Heartbleed.  But, who knows, it could be some other security thing.  They're not saying.

More detailed information:

http://arstechnica.com/apple/2014/09/apple-releases-os-x-10-9-5-with-fixes-new-code-signing-requirements/

And some info on the process:

http://indiestack.com/2014/08/re-signing-code/
http://indiestack.com/2014/09/accepted-cdhash/

It seems like in some cases version 1 signatures will still work, but I'm guessing not in regards to the Firewall exception rules (or perhaps only when you sign it via an installer, or a Mac App Store app).  In any case, probably need to re-do it and it stands a good chance of fixing this issue.

[Rafal Lukawiecki]

I'm glad I have found what seems to be a fixable issue with the JRiver digital signature. May I ask if this is likely to be fixed during the lifetime of MC20 or not until MC21?

Many thanks, everyone.

[Rafal Lukawiecki]

Sorry to be bugging you, but could you let me know if this is likely to be fixed in an upcoming (soonish) release, or not until MC 21? Thanks.

[glynor]

I can't answer for sure because I don't work for JRiver, so don't consider this a promise.

But it won't be that long.  I'd guess it will be either the next build (probably in a week or something) or one of the near-future ones, unless fixing it becomes a much bigger thing.

[Rafal Lukawiecki]

Many thanks, Glynor. I will hold of with self-signing for a while, as it makes far more sense to have it signed by the developer than to break their signature and overlay mine on their code, just to make it work on 10.9.5 or later. Thanks for helping, very much, indeed.