About feedback to users and helping them avoid problems:
So in order to avoid problems in the immediate short run, we should inform
users to turn off automatic software updates and update checks with a
current version and also tell them how they can find out which apps use
Sparkle??
Once an updat
On Feb 9, 2016, at 11:45 PM, sqwarqDev wrote:
>
>
>> On 10 Feb 2016, at 09:08, Charles Srstka wrote:
>>
>> If your app is accessing your appcast via HTTP, that could be intercepted
>> just the same as your relnotes, and then the attacker could set the relnotes
>> URL to whatever s/he wants.
> On 10 Feb 2016, at 13:45, sqwarqDev wrote:
>
>
>> On 10 Feb 2016, at 09:08, Charles Srstka wrote:
>>
>> If your app is accessing your appcast via HTTP, that could be intercepted
>> just the same as your relnotes, and then the attacker could set the relnotes
>> URL to whatever s/he wants.
> On 10 Feb 2016, at 09:08, Charles Srstka wrote:
>
> If your app is accessing your appcast via HTTP, that could be intercepted
> just the same as your relnotes, and then the attacker could set the relnotes
> URL to whatever s/he wants.
Can I just double-check my understanding here:
1. If t
AWS Certificate Manager provides multi-domain certificates (up to 100, I think)
for free. You can serve an S3 bucket using CloudFront with a custom domain and
SSL, and costs for this will be pretty minimal (probably well under $10 a
month?).
> On Feb 9, 2016, at 8:48 PM, Trygve Inda wrote:
>
> If your hosting provider still charges an arm and a leg for SSL, switch.
I need SSL for multiple subdomains. My host (Pair Networks) charges $449/yr
for such a certificate. That seems really expensive. What are others paying
for this? I have been very happy with Pair as we run a complex server s
On Feb 9, 2016, at 3:37 PM, Jens Alfke wrote:
>
>> On Feb 9, 2016, at 10:38 AM, Alex Zavatone wrote:
>>
>> Simply put, if we can detect that this user is has turned off Airplane mode,
>> we can respond in a more cautious manner.
>
> But you can run into the same behaviors if the user has tu
> On 10 Feb 2016, at 1:08 PM, Charles Srstka wrote:
>
> If your app is accessing your appcast via HTTP, that could be intercepted
> just the same as your relnotes, and then the attacker could set the relnotes
> URL to whatever s/he wants.
Yep, I see that. Bugger.
—G.
___
If your app is accessing your appcast via HTTP, that could be intercepted just
the same as your relnotes, and then the attacker could set the relnotes URL to
whatever s/he wants.
Charles
> On Feb 9, 2016, at 7:53 PM, Graham Cox wrote:
>
> Wait a sec, I think I see an easy solution to this.
>
On Feb 9, 2016, at 17:53 , Graham Cox wrote:
>
> The appcast supplies the URL for the release notes, so that can be updated to
> https without having to republish the app itself. That makes this a lot less
> trouble than it seems.
Yes, but the appcast itself is vulnerable to separate attack, i
Wait a sec, I think I see an easy solution to this.
The appcast supplies the URL for the release notes, so that can be updated to
https without having to republish the app itself. That makes this a lot less
trouble than it seems.
Am I right?
—Graham
> On 10 Feb 2016, at 12:49 PM, Graham C
> On 10 Feb 2016, at 12:22 PM, Jens Alfke wrote:
>
> It’s to display the release notes, which come from an RSS entry in the feed
> and are in HTML format. And Sparkle had a couple of bugs relating to that:
> (a) the WebView was configured to allow JavaScript, and (b) their delegate
> handled
> On Feb 9, 2016, at 2:22 PM, Graham Cox wrote:
>
> Is it enough to change the SUFeedURL to https (if your server supports it,
> which ours does), or does it also require the library to be updated?
Using HTTPS for the appcast RSS feed should be sufficient, because it prevents
an attacker from
OK. I did watch the POC and it appears this is not in the update process, but
in the check for update that the attack occurs.
> Le 9 févr. 2016 à 23:27, Jean-Daniel Dupas a écrit :
>
> I agree. I can’t see how that can work with a properly configured Sparkle,
> that is an App that accepts only
I agree. I can’t see how that can work with a properly configured Sparkle, that
is an App that accepts only properly signed update.
> Le 9 févr. 2016 à 23:22, Graham Cox a écrit :
>
> Thanks for the heads-up Jens.
>
> Is it enough to change the SUFeedURL to https (if your server supports it,
Thanks for the heads-up Jens.
Is it enough to change the SUFeedURL to https (if your server supports it,
which ours does), or does it also require the library to be updated? The
comment you link doesn’t clarify it for me - it mentions WebView, but I’m not
clear about how Sparkle is using Webvie
Yes, this is very important -- don't ignore this message!
On Tuesday, February 9, 2016, Jens Alfke wrote:
> Ars Technica has an article today about a vulnerability in the Sparkle
> auto-update framework, which can allow an attacker to hijack an app update
> check to install malware on the user’s
Ars Technica has an article today about a vulnerability in the Sparkle
auto-update framework, which can allow an attacker to hijack an app update
check to install malware on the user’s Mac:
http://arstechnica.com/security/2016/02/huge-number-of-mac-apps-vulnerable-to-hijacking-and-a-fix-
> On Feb 9, 2016, at 10:38 AM, Alex Zavatone wrote:
>
> Simply put, if we can detect that this user is has turned off Airplane mode,
> we can respond in a more cautious manner.
But you can run into the same behaviors if the user has turned WiFi and/or
cellular off and then back on. The Airpla
On Feb 9, 2016, at 12:15 PM, Jens Alfke wrote:
>
>> On Feb 9, 2016, at 4:17 AM, Alex Zavatone wrote:
>>
>> I’ve created multiple tests using reachability and it would be REALLY EASY
>> if we could simply respond to changes in the Airplane Mode switch.
>
> This triggers changes in network int
> On Feb 9, 2016, at 4:17 AM, Alex Zavatone wrote:
>
> I’ve created multiple tests using reachability and it would be REALLY EASY if
> we could simply respond to changes in the Airplane Mode switch.
This triggers changes in network interfaces that you can detect using the
SystemConfiguration
On Feb 8, 2016, at 5:10 PM, Jens Alfke wrote:
>
>> On Feb 8, 2016, at 1:47 PM, Alex Zavatone wrote:
>>
>> if ( [myIVar respondsToSelector:@selector(someMethod)] {
>> EXC_BAD_ACCESS (code=1, address=0x143545358)
>> I did a po on myiVar and I get an address or 0x00014f05ee00
>
> 0x143545358
On Feb 8, 2016, at 5:13 PM, Jens Alfke wrote:
>
>> On Feb 8, 2016, at 1:55 PM, Alex Zavatone wrote:
>>
>> I'm using reachability classes to determine if we can reach our web services
>> IP and monitoring all reachability enums, but would be "really nice™" is if
>> there is a published API t
> On Feb 9, 2016, at 4:02 PM, Jens Alfke wrote:
>
>
>> On Feb 8, 2016, at 9:45 PM, Glenn L. Austin wrote:
>>
>> According to the docs on Reachability (possibly lost in the mists of
>> time...), Reachability isn't really designed to tell you whether your net
>> access *will* succeed, but
24 matches
Mail list logo
