Build with the null codesigning identity so a certificate is not required #235

Closed
pchatsu opened this Issue Dec 22, 2014 · 18 comments

Comments

Projects
None yet
10 participants
@pchatsu

pchatsu commented Dec 22, 2014

I don't join iOS developer program yet, and only use iOS simulator.
I used carthage update , but failed and the build log said,

Check dependencies
Code Sign error: No code signing identities found: No valid signing identities (i.e. certificate and private key pair) matching the team ID “(null)” were found.
CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'

So I tried to regist the code sign with Xcode's suggestion, but it said "You need to add an apple ID account that is enrolled in Developer's program.".

Can't I use carthage without joining iOS developer program for xcodebuild?

@pchatsu pchatsu changed the title from Can I use `carthage update` without joining iOS developer program? to Can I use carthage update without joining iOS developer program? Dec 22, 2014

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 22, 2014

No, you can't.

Carthage builds a "fat" framework by design #45
You won't be able to submit an application to the store unless both the app binary and all its framework dependencies are signed with your provisioning profile.

dodikk commented Dec 22, 2014

No, you can't.

Carthage builds a "fat" framework by design #45
You won't be able to submit an application to the store unless both the app binary and all its framework dependencies are signed with your provisioning profile.

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 22, 2014

I think I prefer stripping invalids architectures as part of the copy process over having more specific build artifacts because the latter will only complicate matters with stuff like #6, where I assume the .framework we download will contain both x86 and arm code?

/by @robb in #188

As you can see, the maintainers of carthage prefer using "one artefact for both the device and a simulator" approach. And it really does not make sense supporting "I have no provisioning profile" use-cases since those are quite rare.

dodikk commented Dec 22, 2014

I think I prefer stripping invalids architectures as part of the copy process over having more specific build artifacts because the latter will only complicate matters with stuff like #6, where I assume the .framework we download will contain both x86 and arm code?

/by @robb in #188

As you can see, the maintainers of carthage prefer using "one artefact for both the device and a simulator" approach. And it really does not make sense supporting "I have no provisioning profile" use-cases since those are quite rare.

@robb

This comment has been minimized.

Show comment
Hide comment
@robb

robb Dec 22, 2014

Member

For what it's worth, since we're re-signing during copy-frameworks anyway, we could technically sign this with the null identity -.

Member

robb commented Dec 22, 2014

For what it's worth, since we're re-signing during copy-frameworks anyway, we could technically sign this with the null identity -.

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 22, 2014

we could technically sign this with the null identity -

@robb, if you decide adding this feature, whose responsibility will it be setting the "null identity" ?

  • Will maintainers have to do that while committing (publishing the framework).
  • Or carthage will modify the projects within the Carthage.checkout directory right before building?

dodikk commented Dec 22, 2014

we could technically sign this with the null identity -

@robb, if you decide adding this feature, whose responsibility will it be setting the "null identity" ?

  • Will maintainers have to do that while committing (publishing the framework).
  • Or carthage will modify the projects within the Carthage.checkout directory right before building?
@robb

This comment has been minimized.

Show comment
Hide comment
@robb

robb Dec 22, 2014

Member

No clue, just thinking out loud

Member

robb commented Dec 22, 2014

No clue, just thinking out loud

@jspahrsummers

This comment has been minimized.

Show comment
Hide comment
@jspahrsummers

jspahrsummers Dec 22, 2014

Member

If we force xcodebuild to build projects (or at least iOS targets) with a CODE_SIGN_IDENTITY set to -, that should work. They'll be codesigned upon copy even if we don't do it, because Xcode will.

Member

jspahrsummers commented Dec 22, 2014

If we force xcodebuild to build projects (or at least iOS targets) with a CODE_SIGN_IDENTITY set to -, that should work. They'll be codesigned upon copy even if we don't do it, because Xcode will.

@pchatsu

This comment has been minimized.

Show comment
Hide comment
@pchatsu

pchatsu Dec 23, 2014

Thank you for teaching me!

I understood Carthage's concept.

pchatsu commented Dec 23, 2014

Thank you for teaching me!

I understood Carthage's concept.

@yasuoza yasuoza referenced this issue in SwiftyJSON/SwiftyJSON Dec 23, 2014

Closed

Cannot install using Carthage #122

@jspahrsummers jspahrsummers changed the title from Can I use carthage update without joining iOS developer program? to Build with the null codesigning identity so a certificate is not required Dec 23, 2014

@jspahrsummers jspahrsummers added this to the 0.7: If You Build It… milestone Dec 23, 2014

@jspahrsummers jspahrsummers self-assigned this Dec 25, 2014

jspahrsummers added a commit that referenced this issue Dec 25, 2014

Remove codesigning stuff from CI builds
This should cause CI to fail until #235 is fixed.
@jspahrsummers

This comment has been minimized.

Show comment
Hide comment
@jspahrsummers

jspahrsummers Dec 25, 2014

Member

Turns out this is disallowed.

Testing with RAC:

$ xcodebuild -workspace ReactiveCocoa.xcworkspace -scheme 'ReactiveCocoa iOS' -sdk iphoneos build CODE_SIGN_IDENTITY=-
Build settings from command line:
    CODE_SIGN_IDENTITY = -
    SDKROOT = iphoneos8.1

=== BUILD TARGET LlamaKit-Mac OF PROJECT LlamaKit WITH CONFIGURATION Debug ===

Check dependencies
Code Sign error: ad hoc code signing not allowed with SDK 'iOS 8.1'
CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'

=== BUILD TARGET ReactiveCocoa-iOS OF PROJECT ReactiveCocoa WITH CONFIGURATION Debug ===

Check dependencies
Code Sign error: ad hoc code signing not allowed with SDK 'iOS 8.1'
CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'

** BUILD FAILED **


The following build commands failed:
    Check dependencies
    Check dependencies
(2 failures)

If building for the simulator, everything is fine, so this restriction must exist specifically for iOS device builds.

I don't know that we should support simulator-only builds—seems like a lot of effort for little gain. And for Mac-only developers, we can complete #127 so they don't need an iOS profile.

Member

jspahrsummers commented Dec 25, 2014

Turns out this is disallowed.

Testing with RAC:

$ xcodebuild -workspace ReactiveCocoa.xcworkspace -scheme 'ReactiveCocoa iOS' -sdk iphoneos build CODE_SIGN_IDENTITY=-
Build settings from command line:
    CODE_SIGN_IDENTITY = -
    SDKROOT = iphoneos8.1

=== BUILD TARGET LlamaKit-Mac OF PROJECT LlamaKit WITH CONFIGURATION Debug ===

Check dependencies
Code Sign error: ad hoc code signing not allowed with SDK 'iOS 8.1'
CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'

=== BUILD TARGET ReactiveCocoa-iOS OF PROJECT ReactiveCocoa WITH CONFIGURATION Debug ===

Check dependencies
Code Sign error: ad hoc code signing not allowed with SDK 'iOS 8.1'
CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'

** BUILD FAILED **


The following build commands failed:
    Check dependencies
    Check dependencies
(2 failures)

If building for the simulator, everything is fine, so this restriction must exist specifically for iOS device builds.

I don't know that we should support simulator-only builds—seems like a lot of effort for little gain. And for Mac-only developers, we can complete #127 so they don't need an iOS profile.

@robb

This comment has been minimized.

Show comment
Hide comment
@robb

robb Dec 25, 2014

Member

Bummer

Member

robb commented Dec 25, 2014

Bummer

@sebbean

This comment has been minimized.

Show comment
Hide comment
@sebbean

sebbean Jan 9, 2015

What about CI builds (Travis for instance)

I was hoping to use Carthage to pull in my private custom framework dependency. Works great locally, however breaks on Travis environment (presumably because of lack of code signing credentials)

Took me all day to track down this as the most likely culprit for this error:

carthage build --no-skip-current
*** xcodebuild output can be found in /var/folders/gw/_2jq29095y7b__wtby9dg_5h0000gn/T/carthage-xcodebuild.cnE6me.log
*** Building scheme "Gravy" in Gravy.xcodeproj
** BUILD FAILED **

The following build commands failed:
    Check dependencies
(1 failure)
The command "carthage build --no-skip-current" failed and exited with 1 during .

Side note: It may be helpful to have a flag that tail's the xcodebuild log during build, as Travis doesnt allow you to go in and examine the file system as far as I'm aware - makes it a bit tricky to debug this error.

sebbean commented Jan 9, 2015

What about CI builds (Travis for instance)

I was hoping to use Carthage to pull in my private custom framework dependency. Works great locally, however breaks on Travis environment (presumably because of lack of code signing credentials)

Took me all day to track down this as the most likely culprit for this error:

carthage build --no-skip-current
*** xcodebuild output can be found in /var/folders/gw/_2jq29095y7b__wtby9dg_5h0000gn/T/carthage-xcodebuild.cnE6me.log
*** Building scheme "Gravy" in Gravy.xcodeproj
** BUILD FAILED **

The following build commands failed:
    Check dependencies
(1 failure)
The command "carthage build --no-skip-current" failed and exited with 1 during .

Side note: It may be helpful to have a flag that tail's the xcodebuild log during build, as Travis doesnt allow you to go in and examine the file system as far as I'm aware - makes it a bit tricky to debug this error.

@jspahrsummers

This comment has been minimized.

Show comment
Hide comment
@jspahrsummers

jspahrsummers Jan 10, 2015

Member

@sebbean You'll have to ensure that Travis imports a code signing identity. You can see how Carthage itself does it in the cibuild script.

Side note: It may be helpful to have a flag that tail's the xcodebuild log during build, as Travis doesnt allow you to go in and examine the file system as far as I'm aware - makes it a bit tricky to debug this error.

Filed as #273.

Member

jspahrsummers commented Jan 10, 2015

@sebbean You'll have to ensure that Travis imports a code signing identity. You can see how Carthage itself does it in the cibuild script.

Side note: It may be helpful to have a flag that tail's the xcodebuild log during build, as Travis doesnt allow you to go in and examine the file system as far as I'm aware - makes it a bit tricky to debug this error.

Filed as #273.

@dwlnetnl

This comment has been minimized.

Show comment
Hide comment
@dwlnetnl

dwlnetnl Feb 9, 2015

I'd really like to option to build only for the simulator because I don't have a code signing identity yet. It keeps starting app developers from using Carthage.

dwlnetnl commented Feb 9, 2015

I'd really like to option to build only for the simulator because I don't have a code signing identity yet. It keeps starting app developers from using Carthage.

@jspahrsummers

This comment has been minimized.

Show comment
Hide comment
@jspahrsummers

jspahrsummers Feb 9, 2015

Member

@dwlnetnl Thanks for the suggestion! Unfortunately, that would add a significant amount of complexity. Right now, it's very clear that when Carthage builds for iOS, you'll get a universal framework that you can use in both device and simulator builds.

I'd like to keep that simplicity if possible. ☺️

Member

jspahrsummers commented Feb 9, 2015

@dwlnetnl Thanks for the suggestion! Unfortunately, that would add a significant amount of complexity. Right now, it's very clear that when Carthage builds for iOS, you'll get a universal framework that you can use in both device and simulator builds.

I'd like to keep that simplicity if possible. ☺️

@dwlnetnl

This comment has been minimized.

Show comment
Hide comment
@dwlnetnl

dwlnetnl Feb 9, 2015

@jspahrsummers You are absolutely right!

dwlnetnl commented Feb 9, 2015

@jspahrsummers You are absolutely right!

@mxcl mxcl referenced this issue in mxcl/OMGHTTPURLRQ Mar 3, 2015

Closed

Problem when installing via Carthage #6

@lbrndnr lbrndnr referenced this issue in lbrndnr/ImagePickerSheetController Apr 9, 2015

Closed

building with Carthage #11

@abbeycode

This comment has been minimized.

Show comment
Hide comment
@abbeycode

abbeycode Jun 18, 2015

Contributor

Any update on this or #281? I'm hitting this in Travis now

Contributor

abbeycode commented Jun 18, 2015

Any update on this or #281? I'm hitting this in Travis now

@drosenstark

This comment has been minimized.

Show comment
Hide comment
@drosenstark

drosenstark Apr 20, 2016

For those of us who got here from the Internet: try building only the platform you need. For iOS, for instance, use

carthage build --platform iOS

For those of us who got here from the Internet: try building only the platform you need. For iOS, for instance, use

carthage build --platform iOS

@midix

This comment has been minimized.

Show comment
Hide comment
@midix

midix Jan 18, 2017

Just curious, have Apple changed this? Because I just built Release-iphoneos "Cocoa Touch Framework" in XCode 8.2.1 (I used Build for profiling) with empty signing settings: http://i.imgur.com/S37J3HN.png So, is it signed or not? Maybe it's just using my default XCode "iOS developer" signing? I do not have Provisioning profile.
The only thing - my framework currently is Objective-C only. Not sure, if it affects the signing behavior though.

midix commented Jan 18, 2017

Just curious, have Apple changed this? Because I just built Release-iphoneos "Cocoa Touch Framework" in XCode 8.2.1 (I used Build for profiling) with empty signing settings: http://i.imgur.com/S37J3HN.png So, is it signed or not? Maybe it's just using my default XCode "iOS developer" signing? I do not have Provisioning profile.
The only thing - my framework currently is Objective-C only. Not sure, if it affects the signing behavior though.

@mdiep

This comment has been minimized.

Show comment
Hide comment
@mdiep

mdiep Jan 19, 2017

Member

Yes, signing is not longer required when building a framework—and Carthage turns it off.

Member

mdiep commented Jan 19, 2017

Yes, signing is not longer required when building a framework—and Carthage turns it off.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment