Now to the fun part. Connecting all parts together according to the wiring on the left. The Entrelec relay is directly connected to the garage opener board. The control supply is provided by the Homematic relay. The switch input of the Homematic relay is provided by the hardware button and finally some 230V to feed the relay. That’s it.
If your iOS code signing fails today, it may be due to an expired Apple Intermediate Certificate.
What you need for code signing beside your valid developer or distribution certificate is the
Apple Worldwide Developer Relations Certification Authority. It expired yesterday and there’s probably already a new one side by side in your keychain. (If not, download and install the new one here: WWDR Certificate (Expiring 02/07/23)) Alas, the expired one interferes with the chain of trust and as a result you get a
„This certificate has an invalid issuer.“
To get rid of this error, you simply have to delete the expired one
in three easy steps:
- Open the Keychain Access utility
In the menu, select View -> Show Expired Certificates
Make sure to delete the expired “Apple Worldwide Developer Relations*” certificates from all keychains (probably login and system).
Now everything should work like a charm again 😉
Recently I updated xcode on our CI server and additionally provide the option to use older xcode versions per project.
To verify that the option works I wanted to find out the iOS SDK version from the provided ipa.
Here we go:
Assuming the app is named APPNAME and the ipa my-app.ipa.
- rename my-app.ipa to my-app.ipa.zip
- unzip my-app.ipa.zip (Now we’ve got a folder named Payload)
- execute the following bash command:
otool -l Payload/APPNAME.app/APPNAME | fgrep --after-context=3 LC_VERSION_MIN_IPHONEOS
plutil -p Payload/APPNAME.app/Info.plist | grep DTSDKName
The output is something similar to:
cmd LC_VERSION_MIN_IPHONEOS cmdsize 16 version 7.0 sdk 8.4 -- cmd LC_VERSION_MIN_IPHONEOS cmdsize 16 version 7.0 sdk 8.4
When integrating UIWebViews you have to pay attention to how the desired webpage is being loaded.
That’s why Apple lately added the following lines to the documentation of UIWebView:
To help you avoid being vulnerable to security attacks, be sure to use this method [-loadHTMLString:baseURL:] to load local HTML files; don’t use loadRequest:.
Loading a website via
loadRequest: bears the risk of Cross Site Scripting, since it does not enforce the Same Origin Policy, i.e., access to resources of other websites or within the bundle container of the app is possible.
Example Attack Scenario
Applying a Man-in-the-middle attack I could pass a primed website off as the desired app’s imprint website. An attacker could now prompt for sensitive data and capture it.
Furthermore, the attacker could access sqlite cache files or other sensitive resources inside the bundle container. But since this attack requires guessing the id of the sandbox, which is part of the required URL, this is not very likely to happen.
A solution is to use the methods
loadData:MIMEType:textEncodingName:baseURL: to load external websites and specifying the
baseURL property to point to the host of the desired website, preventing access to resources on different hosts.
Alternatively you could implement
webView:shouldStartLoadWithRequest:navigationType: of the UIWebViewDelegate protocol, inspecting every request’s host address and whitelisting which to allow.