Re: Language options: Objective-C, Swift, C or C++?

[Graham Cox]

> On 13 Jun 2015, at 1:31 pm, Quincey Morris 
>  wrote:
> 
> One of the biggest old-school reason is source duplication. You have to write 
> everything “twice”, once in @interface, once in @implementation. This has 
> been mitigated somewhat over the years, but Obj-C is literally twice the 
> number of files as Swift, and (in my experience so far) twice the number of 
> source lines to do the same thing.
> 


To me this is actually a good thing that I’ll be sorry to see go away in Swift.

With a separate header that only contains the public stuff, I can see at a 
glance what a class does without being overwhelmed by its implementation 
details. It’s like the table of contents for a text book, or a road map. If I 
have everything in the one file, that nice roadmap has gone, and I have to sift 
through lots of extraneous detail to get a sense of what a class does.

It’s also untrue that you have to write *everything* twice - you have to write 
the method definitions twice, which is a minor bit of work. In practice really 
not much, and it’s good discipline.

I assume Swift has a way to separate the publicly exposed interface from the 
private, but it’s still very handy to have it all gathered in one place. I 
won’t mind too much if there are tools that simply extract the public stuff and 
present it (in the browser view say), but then it’s making the language 
somewhat dependant on a graphical UI. I can live with that, but those brought 
up on makefiles and command-line compilers probably won’t like it.

—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

Scary Stuff!

[Dave]

Hi,

Has everyone seen this?

http://www.theregister.co.uk/2015/06/17/apple_hosed_boffins_drop_0day_mac_ios_research_blitzkrieg/
 


Scares the living daylights out of me!

Cheers
Dave

___

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: Language options: Objective-C, Swift, C or C++?

[Quincey Morris]

On Jun 17, 2015, at 00:56 , Graham Cox  wrote:
> 
> To me this is actually a good thing that I’ll be sorry to see go away in 
> Swift.
> 
> With a separate header that only contains the public stuff, I can see at a 
> glance what a class does without being overwhelmed by its implementation 
> details.

It’s already done in Swift 2. While you’re editing in the one pane, the 
Counterparts setting in the assistant pane (which in Obj-C shows the .h when 
you edit the .m) shows exactly this view, along with documentation (///) 
comments. It actually shows public and internal API within a module (basically 
the same thing), but I assume when used cross-module it shows only public API, 
but I haven’t had a chance to try that yet (though this is what Command-click 
on Cocoa APIs shows you, so I assume it works the same).

> It’s also untrue that you have to write *everything* twice - you have to 
> write the method definitions twice, which is a minor bit of work.

I was being a little bit facetious. It’s minor when you’re first writing the 
class, but if you’re creating a lot of classes at one time (say, converting 
code from another language), it gets very tedious very quickly. It’s also one 
of the “I can’t believe the IDE doesn’t do that for you” features that 
newcomers to Obj-C complained about in the dev forums *a lot*.



___

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: access modifiers in protocols

[Roland King]

> On 17 Jun 2015, at 14:12, Quincey Morris 
>  wrote:
> 
> On Jun 16, 2015, at 22:37 , Roland King  > wrote:
>> 
>> No - can’t have a stored property in an extension
> 
> (Someone just asked basically the same question in the dev forums, but with a 
> different example. Was that you?)
> 
> The following compiles for me without error:
> 
>> public protocol Foo {
>>  mutating func foo( Int )->Void
>> }
>> 
>> extension Foo {
>>  internal mutating func fooInternal( Int )->Void {}
>>  public mutating func foo( i: Int )->Void { fooInternal (i)}
>> }
>> 
>> internal protocol FooInternal: Foo {
>>  mutating func fooInternal( Int )->Void
>> }
>> 
>> internal protocol FooArray: FooInternal {
>>  var bar : Array { get set }
>> }
>> 
>> extension FooArray {
>>  mutating func fooInternal( i: Int )->Void { bar.append( i )}
>> }
>> 
>> public struct AFoo: Foo {
>>  public mutating func foo( Int )->Void { print ("cheers")}
>> }
>> 
>> public struct BFoo: Foo, FooArray {
>>  var bar : Array = []
>> }
> 
> I’m not absolutely sure it does what you want, and if it does I’m not sure 
> it’s the shortest possible sequence. But it compiles without error.
> 

Wasn’t me - how odd that two people were having the same thought at the same 
time. I find the new forum 2pt high pastel colours a bit hard to read so I’m 
not going there that often yet and having gone there I can’t find the question. 

That’s a bit ugly, it name switches foo to fooInternal and puts a stubbed out 
version in the Foo extension - which was one of the things pointed out as ‘code 
smell’ in that talk. However it did turn on a light bulb and you can do this 
using the where clause in the extension

public protocol Foo
{
mutating func foo( Int ) -> Void
}

internal protocol FooArray : Foo
{
var bar : Array { get set }
}

extension Foo where Self : FooArray
{
public mutating func foo( i : Int ) -> Void
{
bar.append( i )
}
}

public struct S1 : FooArray
{
internal var bar : Array = []
}

//public struct S2 : Foo// should be an error as foo() isn’t 
implemented here
//{
//
//}

The stubbed out piece at the end should give a compilation error because S2 
doesn’t implement Foo because it’s not a ‘FooArray’. However it just crashes 
the compiler. I’ll go file that one, I’ve found quite a few ways to crash it 
today, all doing things like this. 


___

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: Scary Stuff!

[Torsten Curdt]

Wow - and not fixed in those 6 months.
That does not sound good.
___

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

Why doesn't my Swift method get called.

[James Cicenia]

I added a swift file to my project. I wanted to use an open source sidebar.

I have checked my targets, etc.
Xcode compiles, builds and runs my code without a problem. But when
I debug it, it just goes over and never into the method.

Why would it do that? It builds and compiles, and even if I click the 
method it takes me to it so it is seeing it.

Is there an Xcode setting I am missing?

Thank you
James



___

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: Scary Stuff!

[Dave]

> On 17 Jun 2015, at 09:44, Torsten Curdt  wrote:
> 
> Wow - and not fixed in those 6 months.
> That does not sound good.

That’s the scariest part! I thought that Apple might have made an announcement 
about it after the article appeared on "The Register", but not seen anything 
yet!



___

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: Why doesn't my Swift method get called.

[Dave]

What happens when you put a breakpoint in the method, rather then trying to 
step into it?

> On 17 Jun 2015, at 14:47, James Cicenia  wrote:
> 
> I added a swift file to my project. I wanted to use an open source sidebar.
> 
> I have checked my targets, etc.
> Xcode compiles, builds and runs my code without a problem. But when
> I debug it, it just goes over and never into the method.
> 
> Why would it do that? It builds and compiles, and even if I click the 
> method it takes me to it so it is seeing it.
> 
> Is there an Xcode setting I am missing?
> 
> Thank you
> James


___

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

[OT] We appeared in Product Hunt

[Juanjo Conti]

Hey! Today we appeared in Product Hunt
http://www.producthunt.com/tech/screensaver-ninja

Yesterday we lunched our 1.0 version for Mac OS X. Thanks for all the
support in this mailing list!

-- 

Juanjo Conti http://goog_2023646312>@carouselapps.com
>

Software Engineer - Carousel Apps 

-- 
Carousel Apps Limited, registered in England & Wales with registered number 
7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket 
Street, London SE1 3HN. Any communication sent by or on behalf of Carousel 
App Ltd or any of its subsidiary, holding or affiliated companies or 
entities (together "Watu") is confidential and may be privileged or 
otherwise protected. If you receive it in error please inform us and then 
delete it from your system. You should not copy it or disclose its contents 
to anyone. Messages sent to and from Watu may be monitored to ensure 
compliance with our internal policies and to protect our business. Emails 
are not secure and cannot be guaranteed to be error free. Anyone who 
communicates with us by email is taken to accept these risks.
___

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: [OT] We appeared in Product Hunt

[Maxthon Chan]

Congratulations bro :)

Max

> On Jun 18, 2015, at 00:34, Juanjo Conti  wrote:
> 
> Hey! Today we appeared in Product Hunt
> http://www.producthunt.com/tech/screensaver-ninja
> 
> Yesterday we lunched our 1.0 version for Mac OS X. Thanks for all the
> support in this mailing list!
> 
> -- 
> 
> Juanjo Conti http://goog_2023646312>@carouselapps.com
> >
> 
> Software Engineer - Carousel Apps 
> 
> -- 
> Carousel Apps Limited, registered in England & Wales with registered number 
> 7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket 
> Street, London SE1 3HN. Any communication sent by or on behalf of Carousel 
> App Ltd or any of its subsidiary, holding or affiliated companies or 
> entities (together "Watu") is confidential and may be privileged or 
> otherwise protected. If you receive it in error please inform us and then 
> delete it from your system. You should not copy it or disclose its contents 
> to anyone. Messages sent to and from Watu may be monitored to ensure 
> compliance with our internal policies and to protect our business. Emails 
> are not secure and cannot be guaranteed to be error free. Anyone who 
> communicates with us by email is taken to accept these risks.
> ___
> 
> 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/max%40maxchan.info
> 
> This email sent to m...@maxchan.info



smime.p7s
Description: S/MIME cryptographic signature
___

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: Why doesn't my Swift method get called.

[James Cicenia]

Hmm, I had a bad UIImage(named: "menu-new”) should have been menu-news
as an array element in the parameter.

 



> On Jun 17, 2015, at 9:09 AM, Dave  wrote:
> 
> What happens when you put a breakpoint in the method, rather then trying to 
> step into it?
> 
>> On 17 Jun 2015, at 14:47, James Cicenia  wrote:
>> 
>> I added a swift file to my project. I wanted to use an open source sidebar.
>> 
>> I have checked my targets, etc.
>> Xcode compiles, builds and runs my code without a problem. But when
>> I debug it, it just goes over and never into the method.
>> 
>> Why would it do that? It builds and compiles, and even if I click the 
>> method it takes me to it so it is seeing it.
>> 
>> Is there an Xcode setting I am missing?
>> 
>> Thank you
>> James
> 
> 
> ___
> 
> 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/james%40jimijon.com
> 
> This email sent to ja...@jimijon.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

Re: Language options: Objective-C, Swift, C or C++?

[Ariel Feinerman]

Why just do not use some clone of Smalltalk for Mac OS X before inventing
new language?

On Wed, Jun 17, 2015 at 11:16 AM, Quincey Morris <
quinceymor...@rivergatesoftware.com> wrote:

> On Jun 17, 2015, at 00:56 , Graham Cox  wrote:
> >
> > To me this is actually a good thing that I’ll be sorry to see go away in
> Swift.
> >
> > With a separate header that only contains the public stuff, I can see at
> a glance what a class does without being overwhelmed by its implementation
> details.
>
> It’s already done in Swift 2. While you’re editing in the one pane, the
> Counterparts setting in the assistant pane (which in Obj-C shows the .h
> when you edit the .m) shows exactly this view, along with documentation
> (///) comments. It actually shows public and internal API within a module
> (basically the same thing), but I assume when used cross-module it shows
> only public API, but I haven’t had a chance to try that yet (though this is
> what Command-click on Cocoa APIs shows you, so I assume it works the same).
>
> > It’s also untrue that you have to write *everything* twice - you have to
> write the method definitions twice, which is a minor bit of work.
>
> I was being a little bit facetious. It’s minor when you’re first writing
> the class, but if you’re creating a lot of classes at one time (say,
> converting code from another language), it gets very tedious very quickly.
> It’s also one of the “I can’t believe the IDE doesn’t do that for you”
> features that newcomers to Obj-C complained about in the dev forums *a lot*.
>
>
>
> ___
>
> 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/arielfapple%40gmail.com
>
> This email sent to arielfap...@gmail.com
>



-- 
best regards
Ariel
___

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: Scary Stuff!

[Jens Alfke]

As usual, don’t put too much weight into the bite-size digests from the press, 
especially the Register, which has a track record of sensationalism. 
Unfortunately the actual truth is fairly bad. I recommend reading the paper:

https://drive.google.com/file/d/0BxxXk1d3yyuZOFlsdkNMSGswSGs/view 


Haven’t gotten all the way through it, but the security problems in the OS seem 
to be not about the fundamentals — the integrity of sandboxes and the Keychain 
are OK — but some slipshod security at the API level and in the ways these 
components get used. The two OS X attacks I’ve read about are:

1. Keychain ACLs control which apps are allowed to read which Keychain secrets. 
But it’s possible for a malicious app to create a blank Keychain password item 
for a secret it knows some other app will store there (like a login password), 
and give both itself and the real app access. Then the true app will store the 
secret in the existing Keychain item, which is readable by the malware so it 
can get the password from it.

2. Sandboxed apps are given private directories named after their bundle IDs. 
The Mac App Store submission process verifies that an app’s bundle ID is a 
valid one that’s registered to the developer … but it doesn’t verify the bundle 
IDs of embedded executables like plugins, which get their own sandboxes. So a 
malicious app can include a plugin with the bundle ID registered to a real app, 
and its plugin will be able to share the sandbox with the real app and 
read/write its data.

(I may have gotten details wrong. Don’t quote me on this, read the paper 
yourself.)

Both of these are pretty bad. I’m very disappointed that Apple didn’t address 
these during the six months’ advance notice that the security researchers gave 
before they went public.

—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: Language options: Objective-C, Swift, C or C++?

[Jens Alfke]

> On Jun 17, 2015, at 12:30 PM, Ariel Feinerman  wrote:
> 
> Why just do not use some clone of Smalltalk for Mac OS X before inventing
> new language?

Maybe because it wouldn’t achieve any of Apple’s stated goals, like high 
performance and type-safety?

I used Smalltalk-80 extensively back in the ‘80s (while working at Xerox no 
less) and it was a cool language for its time, but it’s a historical artifact 
now. (Yes, I’m aware of Squeak. It’s kind of an SCA of programming languages.) 
If Apple had wanted that sort of language they would have kept developing the 
MacRuby they were putting some resources into a few years ago. (Yeah, not the 
same language, but Ruby’s in the same general family and has a lot of ST-80 
influence.)

Guys, talking about Swift vs. Obj-C/C/C++ has a slight amount of use, but if we 
start dragging everyone’s pet language into the fray (Algol? Burroughs B5000 
assembly?) then this just becomes another boring language flame-war. Don’t do 
that.

—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: Scary Stuff!

[Doug Hill]

This is indeed some scary stuff. The problem with apps creating a local web 
server for Web Socket support also seems particularly worrisome. I second Jens’ 
suggestion to read the paper because it will cause eyes to bug out.

For most of the security problems, you could rewrite your app to opt-out of the 
insecure APIs, system services, etc. and use your own implementation. (see 
Google Chrome not storing passwords in the Keychain anymore) This is obviously 
it’s own set of security issues. Do you want to implement your own secure 
password store and ensure you don’t introduce other security holes? Good luck 
with that.

The one feature that I don’t know anyway to opt-out yet still keep 
functionality is the custom URL scheme registration on iOS. This gets used for 
IPC to open files in another app. Any app could register the same custom URL 
scheme for another app without the knowledge of the user or the original app. 
Users would Open In one of their files, thinking it will go to the original 
app, which gets hijacked by the malicious app. I don’t know if there’s even a 
way to know if another app has hijacked your scheme. Think about opening files 
with confidential/financial data and they suddenly get sent to a malicious app.

I’m looking forward to fixes and/or workarounds soon.

Doug Hill

> On Jun 17, 2015, at 12:44 PM, Jens Alfke  wrote:
> 
> As usual, don’t put too much weight into the bite-size digests from the 
> press, especially the Register, which has a track record of sensationalism. 
> Unfortunately the actual truth is fairly bad. I recommend reading the paper:
> 
> https://drive.google.com/file/d/0BxxXk1d3yyuZOFlsdkNMSGswSGs/view 
> 
> 
> Haven’t gotten all the way through it, but the security problems in the OS 
> seem to be not about the fundamentals — the integrity of sandboxes and the 
> Keychain are OK — but some slipshod security at the API level and in the ways 
> these components get used. The two OS X attacks I’ve read about are:
> 
> 1. Keychain ACLs control which apps are allowed to read which Keychain 
> secrets. But it’s possible for a malicious app to create a blank Keychain 
> password item for a secret it knows some other app will store there (like a 
> login password), and give both itself and the real app access. Then the true 
> app will store the secret in the existing Keychain item, which is readable by 
> the malware so it can get the password from it.
> 
> 2. Sandboxed apps are given private directories named after their bundle IDs. 
> The Mac App Store submission process verifies that an app’s bundle ID is a 
> valid one that’s registered to the developer … but it doesn’t verify the 
> bundle IDs of embedded executables like plugins, which get their own 
> sandboxes. So a malicious app can include a plugin with the bundle ID 
> registered to a real app, and its plugin will be able to share the sandbox 
> with the real app and read/write its data.
> 
> (I may have gotten details wrong. Don’t quote me on this, read the paper 
> yourself.)
> 
> Both of these are pretty bad. I’m very disappointed that Apple didn’t address 
> these during the six months’ advance notice that the security researchers 
> gave before they went public.
> 
> —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: Language options: Objective-C, Swift, C or C++?

[Scott Ribe]

On Jun 17, 2015, at 2:04 PM, Jens Alfke  wrote:
> 
> Guys, talking about Swift vs. Obj-C/C/C++ has a slight amount of use, but if 
> we start dragging everyone’s pet language into the fray (Algol? Burroughs 
> B5000 assembly?)

Dylan, dammit ;-)

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice






___

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: Scary Stuff!

[Michael David Crawford]

I was a "Debug Meister" for Apple in the mid-90s.  It was fascinating
work but I applied for an internal transfer because I had the sense
that my work would never be finished.

That is, we will never run out of bugs.  It gets me down sometimes.
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/

   Available for Software Development in the Portland, Oregon Metropolitan
Area.


On Wed, Jun 17, 2015 at 1:17 PM, Doug Hill  wrote:
> This is indeed some scary stuff. The problem with apps creating a local web 
> server for Web Socket support also seems particularly worrisome. I second 
> Jens’ suggestion to read the paper because it will cause eyes to bug out.
>
> For most of the security problems, you could rewrite your app to opt-out of 
> the insecure APIs, system services, etc. and use your own implementation. 
> (see Google Chrome not storing passwords in the Keychain anymore) This is 
> obviously it’s own set of security issues. Do you want to implement your own 
> secure password store and ensure you don’t introduce other security holes? 
> Good luck with that.
>
> The one feature that I don’t know anyway to opt-out yet still keep 
> functionality is the custom URL scheme registration on iOS. This gets used 
> for IPC to open files in another app. Any app could register the same custom 
> URL scheme for another app without the knowledge of the user or the original 
> app. Users would Open In one of their files, thinking it will go to the 
> original app, which gets hijacked by the malicious app. I don’t know if 
> there’s even a way to know if another app has hijacked your scheme. Think 
> about opening files with confidential/financial data and they suddenly get 
> sent to a malicious app.
>
> I’m looking forward to fixes and/or workarounds soon.
>
> Doug Hill
>
>> On Jun 17, 2015, at 12:44 PM, Jens Alfke  wrote:
>>
>> As usual, don’t put too much weight into the bite-size digests from the 
>> press, especially the Register, which has a track record of sensationalism. 
>> Unfortunately the actual truth is fairly bad. I recommend reading the paper:
>>
>> https://drive.google.com/file/d/0BxxXk1d3yyuZOFlsdkNMSGswSGs/view 
>> 
>>
>> Haven’t gotten all the way through it, but the security problems in the OS 
>> seem to be not about the fundamentals — the integrity of sandboxes and the 
>> Keychain are OK — but some slipshod security at the API level and in the 
>> ways these components get used. The two OS X attacks I’ve read about are:
>>
>> 1. Keychain ACLs control which apps are allowed to read which Keychain 
>> secrets. But it’s possible for a malicious app to create a blank Keychain 
>> password item for a secret it knows some other app will store there (like a 
>> login password), and give both itself and the real app access. Then the true 
>> app will store the secret in the existing Keychain item, which is readable 
>> by the malware so it can get the password from it.
>>
>> 2. Sandboxed apps are given private directories named after their bundle 
>> IDs. The Mac App Store submission process verifies that an app’s bundle ID 
>> is a valid one that’s registered to the developer … but it doesn’t verify 
>> the bundle IDs of embedded executables like plugins, which get their own 
>> sandboxes. So a malicious app can include a plugin with the bundle ID 
>> registered to a real app, and its plugin will be able to share the sandbox 
>> with the real app and read/write its data.
>>
>> (I may have gotten details wrong. Don’t quote me on this, read the paper 
>> yourself.)
>>
>> Both of these are pretty bad. I’m very disappointed that Apple didn’t 
>> address these during the six months’ advance notice that the security 
>> researchers gave before they went public.
>>
>> —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/mdcrawford%40gmail.com
>
> This email sent to mdcrawf...@gmail.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

Re: Scary Stuff!

[Jens Alfke]

> On Jun 17, 2015, at 1:17 PM, Doug Hill  wrote:
> 
> For most of the security problems, you could rewrite your app to opt-out of 
> the insecure APIs, system services, etc. and use your own implementation. 
> (see Google Chrome not storing passwords in the Keychain anymore)

Does it? I’m using Chrome on Mac OS and it uses the Keychain. (I just opened 
Keychain Access and verified that a password I’d added in Chrome this morning 
shows up there.) Annoyingly, though, it doesn’t recognize Keychain items 
created by Safari, which means I have to keep looking up passwords in Keychain 
Access the first time I visit a site in Chrome.

> This is obviously it’s own set of security issues.

Totally. It would be a bad idea for developers to respond to this research by 
creating their own secure storage. (“I know! I’ll write the passwords to a 
plist and XOR the bytes with a 32-bit secret number I hardcode in my app!”)

It does sound like there are some best practices that would defeat some of 
these attacks — like making sure to always create new Keychain items instead of 
re-using existing ones. Hopefully people with the expertise will publish some. 
(Maybe there are some in the paper? I haven’t had time to finish it yet.)

—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: Scary Stuff!

[Britt Durbrow]

I’ve skimmed the paper; and it seems to me that there is no API/system-level 
solution possible.

I’m not familiar with the Keychain API; owing to not having needed to use it, 
but it seems to me that a best practices approach can solve that issue: check 
that the keychain item’s properties (ACL most importantly) are what you expect 
before using it. However, the OS can’t know ahead-of-time what those ACLs 
should be; consequently it must fall to the app to provide that logic.

Likewise, some containers are supposed to be shared; and others aren’t. The OS 
can’t know what that is; it must fall upon the App Store to validate that. An 
automated heuristics approach backed up by actual human validation of edge 
cases is probably the way to go for this:

1) Bundle identifiers that belong to the developer submitting the app 
automatically get passed.
2) Bundle identifiers that are known to be shared automatically get 
passed.
3) All others get human review.

URL schemes should require registration with Apple; collisions should cause a 
store submission to fail.

And lastly, if you have malware on your system; you are pretty much toast: 
despite all that we do to try to prevent it, no system of this level of 
complexity is perfect, and the good guys have to be right 100% of the time, 
while the bad guys only have to be right once in order for it to worm it’s way 
into the machine.

> On Jun 17, 2015, at 2:07 PM, Jens Alfke  wrote:
> 
> 
> (“I know! I’ll write the passwords to a plist and XOR the bytes with a 32-bit 
> secret number I hardcode in my app!”)

WHAT?!?! No! You gotta use ROT13! ;-P
___

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: Scary Stuff!

[Doug Hill]

> On Jun 17, 2015, at 2:07 PM, Jens Alfke  wrote:
> 
>> On Jun 17, 2015, at 1:17 PM, Doug Hill > > wrote:
>> 
>> For most of the security problems, you could rewrite your app to opt-out of 
>> the insecure APIs, system services, etc. and use your own implementation. 
>> (see Google Chrome not storing passwords in the Keychain anymore)
> 
> Does it? I’m using Chrome on Mac OS and it uses the Keychain. (I just opened 
> Keychain Access and verified that a password I’d added in Chrome this morning 
> shows up there.) Annoyingly, though, it doesn’t recognize Keychain items 
> created by Safari, which means I have to keep looking up passwords in 
> Keychain Access the first time I visit a site in Chrome.

From The Register article:

"Google's Chromium security team was more responsive, and removed keychain 
integration for Chrome, noting that it could likely not be solved at the 
application level.”

Take this as you will from a Register article.

> It does sound like there are some best practices that would defeat some of 
> these attacks — like making sure to always create new Keychain items instead 
> of re-using existing ones.

Also to show how hard it is to handle security issues, from the researchers’ 
paper:

“For Google Gmail, which delete their current keychain items and create new 
ones before updating their data (sic). Note that this practice (deleting an 
existing item) is actually discouraged by Apple, which suggests to modify the 
item instead.”

Even going by Apple’s suggestions it’s hard to get all this right.

Doug

___

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

recycleURLs with authorization

[sqwarqDev]

Hi list

I'm trying to move some files to the trash with my app, but I need OS X to 
throw an authentication dialog when the requested file needs permission to be 
moved. 

I need a solution that will work from 10.6 onwards, so I've been looking at 
NSWorkspace's recycleURLs rather than NSFileManager's trashItemAtURL (not 
available pre 10.8).

My problem is that recycleURLs doesn't appear to offer an option to ask the 
user for a password if it's needed. Is there another method I can use that 
will, or a way to make recycleURLs throw the dialog? I know I could probably 
run an NSTask and call "rm" but that's a bit more brutal than what I'm looking 
for. I'd like the user to actually see the file in the Trash and to know that 
they've authorised its removal.


TIA


Phil
___

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: recycleURLs with authorization

[Sean McBride]

On Thu, 18 Jun 2015 08:16:48 +0700, sqwarqDev said:

>Hi list
>
>I'm trying to move some files to the trash with my app, but I need OS X
>to throw an authentication dialog when the requested file needs
>permission to be moved. 
>
>I need a solution that will work from 10.6 onwards, so I've been looking
>at NSWorkspace's recycleURLs rather than NSFileManager's trashItemAtURL
>(not available pre 10.8).
>
>My problem is that recycleURLs doesn't appear to offer an option to ask
>the user for a password if it's needed. Is there another method I can
>use that will, or a way to make recycleURLs throw the dialog? I know I
>could probably run an NSTask and call "rm" but that's a bit more brutal
>than what I'm looking for. I'd like the user to actually see the file in
>the Trash and to know that they've authorised its removal.

You should look at the SMJobBless sample code, which I think is the current way 
to do things:



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

[OT] We also appeared in Product Hunt

[Sal Conigliaro]

We also made it onto Product Hunt!
http://www.producthunt.com/tech/fresh-air-2

It's an app for the Watch and iPhone that provides real-time air quality
info from the U.S. EPA

-- 
Sal Conigliaro,
e design
http://www.erinedesign.com
@sconig
___

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: recycleURLs with authorization

[sqwarqDev]

Thanks Sean

That's certainly interesting, but seems like overkill in my case. SMJobBless 
seems to be addressing a bigger problem - how to let an app run privileged 
tasks without authorizing the entire app and without repeatedly asking the user 
for a password.

That's not quite what I want. I actually want the user to be prompted for the 
password whenever it's needed just in the same way that Finder does. 

I don't see that as quite the same thing. All I'm trying to do is to get the 
system to not fail the move with a permission denied error and to seek that 
permission from the user. I can achieve this simply enough with applescript, 
but I was hoping there was a Cocoa solution.


Best

Phil
 
> On 18 Jun 2015, at 09:13, Sean McBride  wrote:
> 
> On Thu, 18 Jun 2015 08:16:48 +0700, sqwarqDev said:
> 
>> Hi list
>> 
>> I'm trying to move some files to the trash with my app, but I need OS X
>> to throw an authentication dialog when the requested file needs
>> permission to be moved.
>> 
>> I need a solution that will work from 10.6 onwards, so I've been looking
>> at NSWorkspace's recycleURLs rather than NSFileManager's trashItemAtURL
>> (not available pre 10.8).
>> 
>> My problem is that recycleURLs doesn't appear to offer an option to ask
>> the user for a password if it's needed. Is there another method I can
>> use that will, or a way to make recycleURLs throw the dialog? I know I
>> could probably run an NSTask and call "rm" but that's a bit more brutal
>> than what I'm looking for. I'd like the user to actually see the file in
>> the Trash and to know that they've authorised its removal.
> 
> You should look at the SMJobBless sample code, which I think is the current 
> way to do things:
> 
> 
> 
> 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

Re: [OT] We also appeared in Product Hunt

[Maxthon Chan]

Congratulations :-)

BTW, if your app have the ability to scrape similar data for China it will be 
VERY welcomed. Chinese are very concerned about air quality now.

> On Jun 18, 2015, at 10:37, Sal Conigliaro  wrote:
> 
> We also made it onto Product Hunt!
> http://www.producthunt.com/tech/fresh-air-2
> 
> It's an app for the Watch and iPhone that provides real-time air quality
> info from the U.S. EPA
> 
> -- 
> Sal Conigliaro,
> e design
> http://www.erinedesign.com
> @sconig
> ___
> 
> 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/max%40maxchan.info
> 
> This email sent to m...@maxchan.info



smime.p7s
Description: S/MIME cryptographic signature
___

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