Re: kCFStreamPropertySSLSettings
> On 23 Jul 2016, at 00:41, Jens Alfke wrote: > > >> On Jul 22, 2016, at 2:46 AM, Gerriet M. Denkmann >> wrote: >> >> When it gets some streams it will show a panel: >> “MyApp wants to sign using key “something” in your keychain” / “Allow” “Deny” > > Presumably this app is either acting as an SSL server, or is sending SSL > clients. Either of those roles involves signing data using the private key > associated with the certificate, to prove you own it. If the app hasn’t > previously used that private key, the Keychain will ask your permission to > let the app use it. That’s the alert. Then it updates the key’s access > control list to remember your app has access. But this access is (usually) > invalidated when the app binary is modified, so you’ll (usually) see the > alert again if you modify the app and run it again. Unless, of course, the application is signed with a suitable certificate, in which case the access will be maintained, *provided* the application’s signature remains valid (which it won’t on some subset of machines because of people using badly written language stripping software that breaks the signature on your bundle by tampering with it---particularly MacKeeper’s implementation which appears to be automatic). I’d make sure that your application is code signed. It makes it very much less tedious to develop or use. Kind regards, Alastair. -- http://alastairs-place.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: kCFStreamPropertySSLSettingC
> On 25 Jul 2016, at 15:30, Alastair Houghton > wrote: > > >> On 23 Jul 2016, at 00:41, Jens Alfke wrote: >> >> >>> On Jul 22, 2016, at 2:46 AM, Gerriet M. Denkmann >>> wrote: >>> >>> When it gets some streams it will show a panel: >>> “MyApp wants to sign using key “something” in your keychain” / “Allow” >>> “Deny” >> >> Presumably this app is either acting as an SSL server, or is sending SSL >> clients. Either of those roles involves signing data using the private key >> associated with the certificate, to prove you own it. If the app hasn’t >> previously used that private key, the Keychain will ask your permission to >> let the app use it. That’s the alert. Then it updates the key’s access >> control list to remember your app has access. But this access is (usually) >> invalidated when the app binary is modified, so you’ll (usually) see the >> alert again if you modify the app and run it again. > > Unless, of course, the application is signed with a suitable certificate, in > which case the access will be maintained, *provided* the application’s > signature remains valid (which it won’t on some subset of machines because of > people using badly written language stripping software that breaks the > signature on your bundle by tampering with it---particularly MacKeeper’s > implementation which appears to be automatic). > > I’d make sure that your application is code signed. It makes it very much > less tedious to develop or use. This sounds like very good advice. I looked at “Code Signing Identity” and found the following choices: Don’t Code Sign (currently selected) Automatic Mac Developer Mac Distribution Developer ID: * Identities in Keychain Gerriet M. Denkmann iPhone Developer Gerriet …. (Zxyz…) Mac Developer Gerriet…(Zxyz…) Other… What would be the right thing to choose? Kind regards, Gerriet. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
awakeFromFetch behaviour change in 10.12?
Hi all, I'm observing that in 10.12 my awakeFromFetch methods are being called more than in 10.11 and earlier. Specifically, it's called more than once for an object that's already been fetched previously. Perhaps I have misunderstood the method's semantics all these years, but I expected that awakeFromFetch would only be called once, when an object is first awaken from the persistent store. Now I'm seeing that if I execute a fetch request where returnsObjectsAsFaults=YES awakeFromFetch will be invoked on all the resulting objects, even if it'd been invoked before. Does that seem correct to you? Thanks, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: kCFStreamPropertySSLSettingC
> On Jul 25, 2016, at 6:47 AM, Gerriet M. Denkmann wrote: > > What would be the right thing to choose? “Mac Developer” while you’re developing, I.e. for your regular build-and-run cycle. “Mac Distribution” is for Release builds you’re going to submit to the Mac App Store. “Developer ID” is for Release builds you distribute yourself (i.e. not through the store.) Apple has pretty decent documentation of all this, and there’s also a lot of information online since every iOS developer has to deal with this. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: awakeFromFetch behaviour change in 10.12?
On Mon, Jul 25, 2016, at 09:14 AM, Sean McBride wrote: > Hi all, > > I'm observing that in 10.12 my awakeFromFetch methods are being called > more than in 10.11 and earlier. Specifically, it's called more than once > for an object that's already been fetched previously. > > Perhaps I have misunderstood the method's semantics all these years, but > I expected that awakeFromFetch would only be called once, when an object > is first awaken from the persistent store. > > Now I'm seeing that if I execute a fetch request where > returnsObjectsAsFaults=YES awakeFromFetch will be invoked on all the > resulting objects, even if it'd been invoked before. > > Does that seem correct to you? This does not sound like expected behavior. Could you please file a bug report at https://bugreport.apple.com and attach a sample project if at all possible? Thanks, --Kyle Sluder > > Thanks, > > -- > > Sean McBride, B. Eng s...@rogue-research.com > Rogue Researchwww.rogue-research.com > Mac Software Developer Montréal, Québec, Canada > > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/kyle%40ksluder.com > > This email sent to k...@ksluder.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSFileHandle and thread safety
Hello list, I find Apple’s documentation on this unclear. It says: "NSFileHandle, NSData, Cocoa streams: Most of the Foundation objects you use to read and write file data can be used from any single thread but should not be used from multiple threads simultaneously." For example I would like to know: 1. Can I write to two different files using two NSFIleHandles from two threads at the same time? 2. Can I read from a single file using two NSFileHandles on two threads at the same time? TIA, Jan E. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSFileHandle and thread safety
1. Can I write to two different files using two NSFIleHandles from two threads at the same time? Yes. 2. Can I read from a single file using two NSFileHandles on two threads at the same time? Why would you need to do that in the first place? Unless you’re reading a single byte at a time, it sounds like a sure-fire way to get corrupted data, regardless of whether you’re using NSFileHandle or good old POSIX methods. I don’t think there’s inherently dangerous about the operation itself, but the resulting data buffers are probably going to be gibberish. Dan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSFileHandle and thread safety
> On 26 Jul 2016, at 5:37 AM, Daniel Stenmark wrote: > > 2. Can I read from a single file using two NSFileHandles on two threads at > the same time? > > Why would you need to do that in the first place? Unless you’re reading a > single byte at a time, it sounds like a sure-fire way to get corrupted data, > regardless of whether you’re using NSFileHandle or good old POSIX methods. I > don’t think there’s inherently dangerous about the operation itself, but the > resulting data buffers are probably going to be gibberish. Aren’t accesses to the file system serialised anyway? Use multiple threads to read a single file isn’t going to gain you anything, even if there wasn’t this coherency issue. —Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSFileHandle and thread safety
> On Jul 25, 2016, at 12:37 PM, Daniel Stenmark wrote: > > 2. Can I read from a single file using two NSFileHandles on two threads at > the same time? > > Why would you need to do that in the first place? To get multithreaded access to the file contents. This is pretty common when using databases like SQLite or Realm. > Unless you’re reading a single byte at a time, it sounds like a sure-fire way > to get corrupted data, regardless of whether you’re using NSFileHandle or > good old POSIX methods. I don’t think there’s inherently dangerous about the > operation itself, but the resulting data buffers are probably going to be > gibberish. That’s not true. As long as each thread has a separate file handle, they’re independent of each other, since each file handle remembers its own offset in the file. (Now, if something else is writing to the file at the same time, then yes, you can get corrupted data unless you use higher-level synchronization like file locking.) —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSFileHandle and thread safety
> As long as each thread has a separate file handle, they’re independent of > each other, since each file handle remembers its own offset in the file. Ah, durr, you’re right. Apologies, I once had the displeasure of debugging an ancient codebase that used the same Unix file descriptor with unlocked reads and writes across at least half a dozen threads. The original query brought some memories I had long suppressed. J.E., please disregard my original answer. Jens is right, two independent file handles reading from the same file on their own threads should be A-okay! Dan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: awakeFromFetch behaviour change in 10.12?
On Mon, 25 Jul 2016 14:12:42 -0500, Kyle Sluder said: >On Mon, Jul 25, 2016, at 09:14 AM, Sean McBride wrote: >> Hi all, >> >> I'm observing that in 10.12 my awakeFromFetch methods are being called >> more than in 10.11 and earlier. Specifically, it's called more than once >> for an object that's already been fetched previously. >> >> Perhaps I have misunderstood the method's semantics all these years, but >> I expected that awakeFromFetch would only be called once, when an object >> is first awaken from the persistent store. >> >> Now I'm seeing that if I execute a fetch request where >> returnsObjectsAsFaults=YES awakeFromFetch will be invoked on all the >> resulting objects, even if it'd been invoked before. >> >> Does that seem correct to you? > >This does not sound like expected behavior. Could you please file a bug >report at https://bugreport.apple.com and attach a sample project if at >all possible? Kyle, Thanks for agreeing that it seems wrong. I filed but haven't reduced to a test app yet. Also, for the archives: I got something backwards in my post: the problem happens if I fetch with returnsObjectsAsFaults=NO (not YES). Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Codesign assumes folder structure, fails.
Hi all, I’m getting an error from codesign when it tries to sign a third-party embedded framework. The error is: /Users/grahamcox/Library/Developer/Xcode/DerivedData/Drawkit-hlbdxcwqkoiqzlesbkfsrobctzke/Build/Products/Debug/Ortelius 2.app/Contents/Frameworks/GEOS.framework/Versions/A: No such file or directory Command /usr/bin/codesign failed with exit code 1 The problem is that GEOS.framework/Versions/A doesn’t exist. That’s true - the alias ‘Current’ points to a folder called ‘3’ within Versions which contains the executable. ‘A’ doesn’t exist. (i.e. the path is GEOS.framework/Versions/3, and this is where GEOS.framework/Versions/Current points to) Isn’t this a serious bad assumtion on the part of codesign? Surely the bundle folder structure for executables has always allowed the ‘current’ version to be changed, and ‘A’ is merely the conventional name for version 1, followed by ‘B’, etc? In this case it seems to be using ‘3’ in a sequence which may once have held ‘1’, ‘2’… This is a 3rd party framework, I have not built it myself, and I’d rather not have to if I can help it. Renaming the folders is easy enough, but nevertheless I would expect codesign to understand the long-standing versioning schema within a bundle. Bug or reasonable assumption? —Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
