Security – Xojo Programming Blog

Web Apps Denial of Service

Ricardo Cruz — Wed, 29 Apr 2026 22:39:52 +0000

Last week we got a report of a critical bug affecting Xojo Web apps. A malformed percent-encoded URL was enough to crash the web app server. Something as small as ?x=% in a query string was all it took. We shipped a fix in 2026r1.2, and Xojo Cloud has been patched at the platform level to cover users who can’t upgrade right away. Here’s what happened, what we did about it, and what you should do depending on how your apps are deployed.

Am I affected? What do I do?

If you only read one section, read this one.

On Xojo Cloud (Web 1 or Web 2)? You’re covered. Nothing to do.
Using Lifeboat? Update Lifeboat and redeploy.
Self-hosted behind Apache or Nginx? Drop in the filtering rule below. If you’re on Web 2, also upgrade to 2026r1.2 if possible.
Self-hosted with the Xojo app exposed directly? On Web 2, upgrade to 2026r1.2 if possible, otherwise put a reverse proxy in front. On Web 1, put a reverse proxy in front (which is what we’d recommend either way).

The full details follow.

Timeline

Thursday, the 23rd. A public issue and a private message landed on the same day, both pointing at the same bug.
Thursday through Monday. We tracked down the root cause, wrote the fix, and tested it.
Tuesday, the 28th. 2026r1.2 shipped with the patch.
Wednesday, the 29th. Xojo Cloud patched at the platform level.

Under a week from the report to a patched release, with the platform-level mitigation following the next day.

What Happened

A request with a malformed percent-encoded sequence in a query parameter could crash a running Xojo Web app. The smallest reproducer is something like ?x=%. That’s a % not followed by two hex digits, which is invalid percent-encoding and isn’t decodable.

The bug lives in DecodeURLComponent. When the method ran into invalid input, it raised an exception instead of handling the input gracefully. Because the framework calls this method while parsing incoming requests, anyone could crash a web app by sending a single malformed URL. No authentication, no special headers, no payload. Just a bad query string.

A few things worth being upfront about:

The bug has probably been there since DecodeURLComponent was introduced. Every Xojo release that ships the method might be affected.
Both Web 1 and Web 2 are known to be affected. The Web framework has been calling this method on incoming requests across both generations.
It’s not just a Web problem. DecodeURLComponent is a general-purpose method, and the same crash can happen in Desktop and other project types if you call it on attacker-controlled input. Web is the obvious target because requests arrive from the network, but the underlying issue isn’t Web-specific.

The Fix

In 2026r1.2, DecodeURLComponent no longer crashes on invalid input. Instead, it returns an empty String when the input contains a malformed percent-encoded sequence.

We thought about a few approaches and went with this one on purpose, for being consistent with the other sanity checks we do on this method. An empty return value lets existing code keep running rather than letting an exception bubble up through request handling, which is what you want from a method that’s frequently called on untrusted input. If your code already wraps DecodeURLComponent with its own validation, the new behavior gives you a clean signal to act on (an empty result) instead of an exception to catch.

Xojo 2026r1.2 is the only release with the fix. Web 1 won’t be getting a backported patch. What that means in practice is covered below.

What Xojo has already done for you

Xojo Cloud has been patched at the platform level. As of Wednesday 29th, Xojo Cloud rejects requests with malformed percent-encoding before they ever reach your app, returning a 400 Bad Request from the front-end web server. This protection doesn’t care which Xojo version your app was built with, and it covers Web 1 and Web 2 the same way.

If your app runs on Xojo Cloud, you don’t need to redeploy, upgrade, or change anything. We rolled this out specifically so that users who can’t upgrade right away are covered, including Web 1 users who can’t upgrade to a fixed version at all.

What you should do

The right move depends on which Web version you’re on and where your app runs.

If you’re on Web 2

Upgrade to 2026r1.2 and redeploy if you can. That’s the cleanest fix and it addresses the issue at the source.

We know “just upgrade” isn’t always realistic. You might be on an older version because your license has expired, because a third-party plugin you rely on hasn’t caught up yet, because a newer Xojo release introduced a regression you can’t ship around, or for any number of other reasons. If that’s you, the hosting-based mitigations below will protect your app in the meantime, and they work regardless of which Xojo version you built with.

If you’re on Web 1

There’s no Xojo release that patches DecodeURLComponent for Web 1, so the fix has to live outside your app. The good news is that if you follow Xojo’s standard hosting recommendations, you’re fully covered against this specific issue:

Stay on Xojo Cloud. You’re already protected.
Use Lifeboat. Tim Parnell shipped a Lifeboat update that catches malformed percent-encoding before it reaches your app. Update Lifeboat and redeploy.
Run behind Apache or Nginx with the rules in the next section.

Separately, and on a longer horizon: Web 1 isn’t receiving framework patches anymore in general, so if you’re still on it, this is a reasonable moment to start thinking about a migration to Web 2. That’s a much bigger conversation than this post, but worth flagging.

Hosting-level mitigations

These rules reject malformed percent-encoded URLs at the web server, before the request reaches your Xojo app at all. They work for Web 1 and Web 2, and they don’t depend on the Xojo version you built with.

Apache:

# Reject malformed percent-encoding in the URI.
RewriteCond %{THE_REQUEST} %(?![0-9A-Fa-f]{2})
RewriteRule .* - [R=400,L]

Nginx:

# Reject malformed percent-encoding in the URI.
if ($request_uri ~ "%(?![0-9A-Fa-f]{2})") {
  return 400;
}

Reload your web server after updating the config (apachectl graceful or nginx -s reload) and check that a request like https://yourapp.example.com/?x=% comes back as 400 Bad Request.

These two snippets aren’t the only way to handle this. The goal is just to block malformed URLs before they reach your app, however you do it. If you’re running mod_security, for example, a rule that rejects URIs containing invalid percent-encoding will get you the same result. Same idea for any WAF, edge filter, CDN, or load balancer in front of your stack: catch the bad request, return a 400, move on.

If your Xojo app is exposed directly to the internet

If your Web app is talking to the internet without a reverse proxy in front of it, your options are narrower. On Web 2, upgrade to 2026r1.2 if you can. On Web 1, or on Web 2 if upgrading isn’t an option, you’ll need to put Apache, Nginx, or Lifeboat in front of your app, or move to Xojo Cloud, our managed hosting solution.

This is also a good moment to revisit the setup more broadly. Xojo recommends always serving Web apps behind a web server, both for performance and as a defense-in-depth measure against bugs like this one. A reverse proxy would have neutralized this specific issue before it reached the framework, and it’ll do the same for the next class of issue too.

If you use `DecodeURLComponent` in a non-Web project

The crash isn’t unique to Web. If you’re calling DecodeURLComponent on input you don’t control (anything coming from a user, a file, a network response, a clipboard), the same bug can hit a Desktop, Console, or other project type.

Upgrade to 2026r1.2 if you can; that’s the proper fix.

If you can’t upgrade, you’ll need to sanitize the input yourself before calling DecodeURLComponent. The check is simple in principle: every % in the string must be followed by exactly two hexadecimal characters (0-9, A-F, a-f). If any % doesn’t meet that condition, treat the input as invalid and don’t pass it to DecodeURLComponent. A small helper that validates the string up front and either returns early or substitutes an empty value will keep your app from crashing on the same kind of malformed input that triggers the Web bug.

Acknowledgments

Thanks to the user who reported this through both public and private channels. That’s exactly the kind of disclosure that lets us turn a fix around in under a week. Thanks also to Tim Parnell for the fast Lifeboat update, which gave self-hosted users a drop-in mitigation almost immediately.

If you find a security issue in Xojo, please report it privately. You can email support@xojo.com or file a confidential issue on the issue tracker. Both reach us, and either one lets us get a fix out before the details become public, protecting the rest of the users.

References

Release notes for 2026r1.2

Ricardo has always been curious about how things work. Growing up surrounded by computers he became interested in web technologies in the dial-up connections era. Xojo has been his secret weapon and language of preference since 2018. When he’s not online, chances are he will be scuba diving … or crocheting amigurumis. Find Ricardo on Twitter @piradoiv.

Code Signing on macOS: What Developers Need to Know, Part 4

Javier Menendez — Tue, 07 Apr 2026 19:00:00 +0000

In the previous article, we saw how signing a macOS app is more than just handling certificates. Other factors come into play based on the distribution method you choose and the features it will offer.

Now, that we already know all the pieces involved in this particular puzzle (certificates, sandboxing, notarization, hardened runtime, etc.), the question to answer is…

What kind of macOS code signing do you want to do today?

Apple developer certificates installed on your Mac determine the kind of code signing and, thus, the distribution options available for your macOS app. They can also support certain macOS security requirements that distribution methods or features may impose, such as entitlements or provisioning profiles.

This diagram can help determine these based on the certificate used when signing the app, so you can get a better idea:

As a practical summary:

Ad-Hoc signing / None: This option makes sense primarily when you’re developing and running or debugging the app on your Mac or on the same computer, since it typically doesn’t require special entitlements or provisioning profiles.
Apple Developer / Development. Using this certificate enables sandboxing, hardened runtime, entitlements and provisioning profiles even when debugging from the IDE or testing the build on your own computer. It offers a better experience, but you won’t be able to notarize it or bypass the Gatekeeper barrier if distributed to other users.
Developer ID Application / Direct Distribution. With this certificate, you can notarize your app so Gatekeeper won’t block distribution outside the Mac App Store. When debugging from the IDE, entitlements and provisioning profiles (if needed) are applied as well, along with optional sandboxing.
Apple Distribution / App Store. Use this certificate when the app has been tested and it is ready to be sent to App Store Connect… or even when you’re planning to send it to the App Store Connect so a group of beta-testers can test it using Apple’s TestFlight.

How the Xojo IDE helps with all of this?

We have been adding features to the Xojo IDE to make code signing and distributing your macOS apps an easier and leaner process; most of these are available under Build Settings > macOS > Sign:

Developer ID – Build For

This is the most recent addition to better deal with the first, and most important, piece of the puzzle: handling certificates! Instead of having to go back and forth between the Keychain Access and the Xojo IDE to copy/paste the expected data from the certificates for the kind of build or distribution you plan for the app, you can now find under the Developer ID field all the available Developer Teams (usually just yours) and, when a Developer Team is selected, the “Build For” popup menu will be populated with the available options for builds/distributions based on the installed developer certificates for that team.

When all the Apple developer certificates are properly installed for a given Developer Team, the available options will be: Development, Direct Distribution and App Store (plus None, meaning Ad-Hoc signing).

If you find that some of these options are missing from the “Build For” popup menu, that means the corresponding certificate is not installed or there is some kind of issue with that certificate (maybe it has expired or has its private key missing). In those cases, we included the “Inspect…” option under the “Developer ID” popup menu. Selecting Inspect lets you gain a better picture about everything related to your Apple developer certificates and even get advice about how to fix the most common issues.

Sandboxing

Enable this feature if you plan to debug, build, or distribute your app as a sandboxed app. In that case, the associated editor will make it even easier to enable the sandboxing features that may apply to your particular app. The IDE will take care of all the rest. Note that, while sandboxing was previously only applied to built/distributed macOS apps in previous Xojo releases, starting with Xojo 2026r1 it is also applied when the app is being debugged from the IDE.

Hardened Runtime

Enable this option mainly for apps meant to be built and/or distributed using Direct Distribution or the App Store options. While this is optional when distributing it via the Mac App Store, it is still highly recommended to enable it for that scenario.

When the app is debugged from the IDE, the hardened runtime won’t be applied even if it is enabled… mainly so you can debug it!

As with sandboxing, the hardened runtime option also includes its own editor to make your app-specific selections easier. The IDE will take care of the under the hood processing when the app is built.

Notarization

If you haven’t started notarizing your macOS apps yet, now is the time! This will be possible only with the Direct Distribution option (equivalent to the Developer ID Application Certificate) and implies enabling hardened runtime. When you enable notarization, the associated hardened runtime will be enabled for you, even if you don’t select additional option from its editor.

Notarization requires the use of what Apple calls an App-Specific Password, which you can set up by following the steps found in the window that appears when the associated Setup button is clicked.

Once everything has been setup, the notarization process will happen the next time the app is built. Note, the notarization process will not take place when the app is debugged from the IDE (as with hardened runtime); you don’t need to specifically disable that option.

Entitlements

The combination of certain certificates, build, and distribution options you choose for your app may require you to set a series of entitlements; for example, when enabling sandboxing and/or hardened runtime. Additionally, with Xojo 2026r1 it is possible to attach your built or debugged apps to Xcode Instruments for further inspections beyond the current capabilities of Xojo’s debugger.

In all of the above scenarios, Xojo will take care of the required entitlements without you needing to notice it; but if your app also makes use of some features that require adding extra entitlements (and probably a matching provisioning profile), as happens with most of the Apple specific services such as iCloud, Keychain, In-App Purchases, etc., you will need to craft the corresponding .plist file for them and add it using the User Entitlements option. These entitlements will be combined with the ones automatically generated by Xojo and included in the app during the code signing process.

Provisioning Profiles

On macOS, provisioning profiles are supported by a Copy Files build step, which requires selecting Contents as the destination folder. Not ideal, but that way you can select what kind of provisioning profile you want to apply to builds or when debugging your project (this is a new feature starting with Xojo 2026r1).

Property List Editor

The ability to add your own property list entries to the compiled/distributed macOS app is enhanced by a complete Property List Editor available under Build Settings > macOS since Xojo 2025. It makes it easier to create these entries and even save them for reuse in other projects.

The entries you add with the Property List Editor will be combined with those automatically generated by the IDE, or with entries that may have been added to the project using previous methods (such as adding an external .plist file to the Project Navigator sidebar).

Publishing to the Mac App Store

While there are some steps that need to be done both at Apple’s Developers Portal and App Store Connect Website, you will be able to set your app category directly from the IDE under Build Settings > macOS.

In addition, the Publish feature (responsible for sending your app to App Store Connect) will be in charge of verifying that the project meets everything that Apple requires prior to send it for reviewing or making available through TestFlight.

In order for the Publish button to be enabled, you need to select the App Store option for the selected “Developer ID” Team from the “Build For” popup menu under Build Settings > macOS > Sign.

Dealing with Certificates Issues

It doesn’t matter if your app requires entitlements, provisioning profiles, or if you are going to notarize it or enable sandboxing plus hardened runtime. All of this is based on the signing of your developer certificates, so let’s go back and see how to deal with the most common issues related with these.

Backup Your Certificates

Once you have installed your certificates, the first thing you should do is export them from Keychain Access to a secure place (ideally, not in your computer but an external USB key or drive). Why? Here’s why:

Apple only allows you to create certificates a maximum of five times per year (mostly because they expire after one year, as we did see in a previous entry). Every time you install certificates, whether on the same computer or a different Mac you own, they count as new certificates, with different serial numbers and SHA1/SHA256 data. In practice, this reduces the number of installations available per year.
In addition, some features, like provisioning profiles, rely on the specific certificates selected during their creation. You will get a signing error if you build the app on a Mac with different certificates.
If you need to restore your Mac or migrate to a new Mac, your certificates won’t be restored using the usual tools from Apple. Having a backup of your developer certificates will make easier to restore them in Keychain Access after restoring your computer or when you change to a new Mac.

Instead of using Xcode to install new certificates on every Mac you intend to use for code signing, install them on just one Mac, export them from that Mac, and import them into the Keychain Access app on your other Macs. This ensures all of your Macs will use the same certificates.

Review Pending Apple Developer Agreements

This is one of the most common issues related to code signing: it just stops working and you don’t know why and even the returned error messages doesn’t reveal why. If you’re sure you have the required developer certificates installed, they are valid (not expired), and don’t have any other issues then it is time to sign-in into the Apple Developer and App Store Connect portals to check if there are some pending agreements you need to accept.

Missing and Expired Certificates

This is another very common issue. Starting with Xojo 2026r1, we made easier to detect this situation. If a given certificate for your team is not installed, then you won’t be able to select the signing option from the “Build For” popup menu under Build Settings > macOS > Sign. You can further dig into it selecting the “Inspect…” option from the “Developer ID” popup menu, and even receive some advice on how to fix it!

Certificates are all good… but the signing throws errors

When using the Direct Distribution or App Store options, the code signing process uses Apple Time Servers to add the date and time as part of the signing. That means that the computer requires an active Internet connection, and that such time servers must be reachable from Apple’s side (it’s very rare for them to be down).

Other operations such as notarization and publish also require an active Internet connection, and the corresponding Apple services must be up and running. Some times these can be down.

When these issues occur, it is a good idea to check the Apple Services status webpage.

In summary

It’s been a long four-article ride with the aim of giving you a clearer understanding of what happens under the hood when you code sign your macOS apps, what kind of certificate you need for a given distribution, and which macOS security features are supported by Development, Developer ID Application or Apple Distribution certificates; and, most importantly, how Xojo helps you with all of it!

I’d love to hear about your experience with macOS code signing, the rough corners you still need to tackle, and other improvements you would welcome. The Xojo forums are a great place to keep the conversation going!

Happy macOS code signing with Xojo!

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

Code Signing on macOS: What Developers Need to Know

Team-based Signing Arrives to macOS

Javier Menendez — Tue, 31 Mar 2026 13:21:00 +0000

In Xojo 2026r1 we revised the macOS Developer ID field and replaced it with a Team-based popup menu that aligns with the style found in iOS projects. This change aims to offer a cleaner, more intuitive way to manage developer certificates for the distribution of your built macOS app.

The Developer ID field was introduced in Xojo 2022r1, allowing you to fill in the developer certificate information needed for signing built macOS apps; however, it could be confusing to know exactly what information was expected.

Developer ID Application
Developer ID Application: Francisco Javier Rodriguez Menendez
Developer ID Application: Francisco Javier Rodriguez Menendez (BW7PU32485)
7D767DB917A45A8976BEB5B92F04E8C18D09501A

And… which certificate should be used for Development builds, Direct Distribution, or Mac App Store publishing? That may not be obvious for someone new to all this.

Additionally, what happens if the entered data comes from an expired certificate or if the certificate isn’t in the Keychain?

The new approach: How it works

The Team-based signing chooser for the Mac Developer ID field follows these steps:

Collects all the developer certificates found under the user Keychain.
Groups the valid certificates by Team (what Apple designates as the TeamID).
Based on the previous information, the new popup menu “Build For” will offer only the code-signing options available for the current selected Team:
- Development. This is the equivalent to using the Apple Development certificate.
- Direct Distribution. This is the equivalent to using the Developer ID Application certificate.
- App Store. This is the equivalent to using the Apple Distribution certificate. In addition, the Publish feature will be enabled if, for the selected Team, there is also a valid 3rd‑party Mac Developer Installer certificate available.

If None is selected in the Developer ID popup menu, the macOS app will be built/debugged using Ad-Hoc signing.

Both menus update on the fly, so if new certificates are added (or removed) from the keychain, or if any have expired since last opened, both the Developer ID and Build For popup menus will reflect those changes.

macOS Certificates Inspector Window

Under the Teams popup menu, there is also an Inspect… option. When selected, it opens a new window where you can view and gather additional information for:

Installed / Missing Apple Intermediate Certificates.
Installed / Missing / Expired Developer Certificates, grouped by Team.

At a glance, you’ll see useful details for each certificate, such as:

The expiration date
The keychain where it is stored.
Serial number, useful for identifying same-kind developer / intermediate certificates under different Macs.
Issuer specific information.

Clicking any certificate provides more detailed information about the role it plays in the macOS signing process.

This Inspector is also useful in order to identify some of the most common issues related with the handling of certificates such as:

Missing certificates for a given Team, determining thus the options that are available under the “Build For” popup menu.
Expired certificates. These also determine the options that are available under the “Build For” popup menu for a given Team. In addition, if you want to do some cleanup, it is possible to delete these expired certificates directly from the Inspector without needing to open the Keychain Access app.
About to expire certificates, so you are aware of it and the impact it could have on apps close to be distributed or on already created Provisioning Profiles, for example.
Certificates with their private key missing. These can’t be used for signing purposes, so you will be able to re-install them in the keychain (if you have a backup) or install a new certificate.
Developer Certificates where some of the required intermediate certificate is missing. You will be able to install the missing Intermediate (active Internet connection required).

Improvements to macOS Builds and Debugged apps

Although Sandboxing, Entitlements, and Provisioning Profiles have been part of macOS app development, this release brings several enhancements in these areas:

Now it is possible debug Sandboxed apps directly from the IDE.
Entitlements and Provisioning Profile are applied when the app is debugged from the IDE.
Improvements in how the required Entitlements are added and signed when the macOS app is built; and also a better handling of the user-added entitlements and provisioning profile files (if required).
Debugged and Built apps can be attached to the Instruments app. Among other things, Instruments can be used to detect issues such as memory leaks in the executed app. The IDE now automatically adds the required entitlement for this when: the app is debugged/built using the “None” (Ad-Hoc signing) from the Team popup menu, or, 2) when the app is built for Development (Build For) for a given Team.

When Build For is set to Direct Distribution or App Store, the required entitlement for Instruments to attach to the app, will be added only when the app is debugged from the IDE. If you want to use Instruments with a built app signed using these certificates, then you need to add that entitlement explicitly.

This decision is because when get-tasks-allow is set to True (the entitlement required in order Instrument being able to function), there are some well documented vulnerabilities that could be used to escalate privileges or inject code into your app. That’s not desirable for your distributed apps for sure (whether using Direct Distribution or if your app is installed through the Mac App Store).

Looking forward

We know there are still some areas to improve regarding code signing on macOS (and iOS) and we are working on some of them already. In the meantime, you’ll likely find the new Team-based Developer ID option more approachable, especially if this is your first experience dealing with certificates, signing, and distributing your freshly built macOS app.

A big THANK YOU to Richard Grafl for all his help and feedback during the beta-testing cycle of this feature.

Happy macOS code-signing!

Learn more about Code Signing in our recent series:

Code Signing on macOS: What Developers Need to Know

Code Signing on macOS: What Developers Need to Know, Part 3

Javier Menendez — Tue, 24 Mar 2026 16:00:00 +0000

If you followed the previous two articles in this series, you should be set up properly now, right? Your Mac developer certificates are stored in Keychain Access, so you only need to fill in the Developer ID field under Build Settings > macOS > Sign with the appropriate certificate value, click Build (or Publish), and distribute your new amazing app worldwide. Well, not quite. There are still other pieces to consider when signing and distributing your macOS app.

For the past 20 years, Apple has increasingly tightened security measures when it comes to running apps distributed by third parties. Let’s take a look at this summarized timeline of code-signing and security measures added by Apple over years:

The most notable developments happened in 2011, 2012 and 2018, when terms like Sandbox and, especially, Containers, Gatekeeper, Hardened Runtime and Notarization were introduced and began to impact other pieces of the puzzle to consider when signing macOS apps. In fact, we could say that technologies such as code-signing, Sandboxing, Entitlements or Provisioning Profiles were among the first iOS technologies to make their way to macOS.

So here is an broad overview what these technologies mean:

Sandboxing– When used, Sandboxing confines applications to a restricted, designated area of the system (its own “container”), preventing them from accessing user data, hardware or other apps without explicit permission. The system requires apps to ask for permission to use hardware resources or access user files. Sandboxing is mandatory for apps distributed through the Mac App Store.
Gatekeeper- This technology is the primary security layer that checks whether a downloaded app comes from a verified/known developer, especially when the application has been Notarized by Apple.
Hardened Runtime– Acts as a proactive, system-enforced shield that protects applications while they run, preventing malicious code from exploiting legitimate software. Enabling Hardened Runtime is required for Notarization.
Notarization– Notarization is an automated security screening process run by Apple that scans software distributed outside the Mac App Store for malicious components and known security issues. Today, notarization is required for software distributed outside the Mac App Store that has been signed with the Developer ID application certificate. As a result of the process, notarization generates and staples a ticket, signed by an Apple certificate, to the app so Gatekeeper can trust it when executed.

So, basically, while Sandboxing is still optional for apps distributed outside the Mac App Store (i.e., signed with your Developer ID certificate), Notarization and Hardened Runtime are the recommended defaults. Enabling Sandboxing for your app is something you should consider based on the needs (features) and the privacy balance you want to offer your users.

If you plan to distribute the app through the Mac App Store as well, it will need to be Sandboxed and signed with your Apple Distribution certificate, while enabling Hardened Runtime is optional.

Entitlements and Provisioning Profiles

Entitlements and Provisioning Profiles are also required for many of these security measures, depending on the features and services your app uses, and they come into play during building and signing.

If you decide to go the Sandboxing route, then using Entitlements is mandatory. The good news is that Sandboxing entitlements are free to use (they don’t require creating or adding a Provisioning Profile to the project). However, if your app needs special access to the Keychain or uses iCloud, Apple Pay, or other services, you’ll need to create a Provisioning Profile in the Apple Developer portal.

Wait—what are Entitlements and Provisioning Profiles, and how do they relate to macOS app code signing?

Entitlements

Entitlements are XML-based .plist files (not unlike the app’s Info.plist) containing a set of key-value pairs. They are embedded directly into the app’s binary as part of the code signing process, typically using your Developer ID Application or Apple Distribution certificates.

Provisioning Profiles

While Entitlements are just a file, Provisioning Profiles are a different beast:

Provisioning Profiles must be created in the Apple Developer Portal. When you create one, you specify the App ID (the combination of your Team ID and the app bundle identifier which are case sensitive so pay attention). Even if you don’t plan to distribute your macOS app via the Mac App Store, you still need a Provisioning Profile, which requires creating an App ID first in the Developer Portal.

There are two kinds of Provisioning Profiles: Development and Distribution. As part of the provisioning profile creation, you must choose which type you will use.

Development Provisioning Profiles are used while you’re developing your app; the app is signed with an Apple Development certificate and is intended to run on a set of Mac computers you’ve registered. During creation, you can add as many Apple Development certificates as you have under your Team ID.
Distribution Provisioning Profiles are used when distributing your app. For direct distribution, sign with the same Developer ID certificate you’ll use for signing the app; for Mac App Store distribution, sign with the Apple Distribution certificate.
Development and Distribution Provisioning Profiles do expire. This is something to keep in mind, especially when deploying new or updated versions of your app, because you may need to create new profiles.
Development and Distribution Profiles are editable. If you make a mistake, note that both types can be edited in the Apple Developer portal, but only for certain fields: the App ID, the profile name, the selected certificate, and (for Development profiles) the included testing devices.

When Certificates and/or Provisioning Profiles expire…

We’ve already noted in previous articles that Apple Developer certificates expire one year after they’re created. We’ve also learned that if your app relies on a Distribution Provisioning Profile, that profile can expire as well. So, what does this mean for your already deployed apps?

No worries. Let’s focus first on directly distributed macOS apps (those signed with the Developer ID certificate) and pull one screenshot from the previous article:

Observe the highlighted Timestamp line. When the app is signed, the date is added automatically (retrieved from Apple’s servers). So, when a user runs an app whose embedded Developer ID Certificate has expired since its release, Gatekeeper will rely on that timestamp, compare it to the embedded certificate’s expiration date, and if everything matches—meaning it was signed before the certificate expired—the app will continue to work, provided the embedded certificate has not been revoked by the developer. In addition, if the app was Notarized, that helps a lot, because the stapled ticket includes its own timestamp and was signed with a longer-lasting Apple Certificate.

If the app is distributed through the Mac App Store, there’s good news. After you submit the app for distribution via App Store Connect and it passes Apple’s review, the app’s signing with your Apple Distribution certificate is replaced by Apple’s own signing. This means that users who install the app from the Mac App Store can continue to run it even if your original Apple Distribution certificate expired long ago.

Distribution Provisioning Profiles behave differently from others: once they expire, the app containing such a Distribution Profile will fail to execute.

The good news is that a Distribution Profile lasts for a very long time (around 18 years) so you’ll likely have ample time to create new distribution provisioning profiles and deploy updates that use renewed profiles well before users are affected.

Of course, as soon as any of your Apple Developer certificates expire, you already know how to request and install new ones in your Mac keychain.

Nearly Concluded

In the next, and last article, we will see how Xojo helps with everything related to signing and distributing your macOS apps. I’ll also show you how to deal with some of the most common issues related with certificates.

Code Signing on macOS: What Developers Need to Know

Code Signing on macOS: What Developers Need to Know, Part 2

Javier Menendez — Wed, 18 Mar 2026 14:00:00 +0000

On the Apple side of code signing with developer certificates, we already know that the required root certificate, acting as the base anchor of the trust chain, is installed already on our Macs under the System Roots keychain.

But before we can reach our leaf developer certificates, we also need to have the Apple Development Intermediate certificates installed in our keychain. These are typically found in the Login keychain, though they can also be found in the System Roots or System keychains.

Installing Apple Developer Intermediate Certificates

Since Xcode 11.4.1 and later, these can be automatically downloaded and installed in the keychain, but if not, they can also can be downloaded from the Apple PKI webpage. The ones we are interested in are:

Developer ID – G2
Worldwide Developer Relations – G2
Worldwide Developer Relations – G3
Worldwide Developer Relations – G4
Worldwide Developer Relations – G5
Worldwide Developer Relations – G6

Note: The Developer ID – G2 certificate corresponds to the Developer ID Certification Authority. The WWDR certificates (G2–G6) correspond to the Apple Worldwide Developer Relations Certification Authority.

As you can see from the list, there are several versions (or generations) for the WWDR Intermediate certificate; so, which one should you download? The short answer: it depends.

On February, 7, 2023 the previous WWDR intermediate certificate expired; so Apple decided to rollout a new renewed version that will expire on February 20, 2030. As part of that update Apple issued additional Intermediate certificates to better segment the purpose of different certificates:

G2: ECDSA signing for Apple Pay.
G3: Software signing and Services.
G4: Features supported by Apple Push Notification Service.
G5: App Store Signing and Services.
G6: ECDSA signing of Software and Services.

In practice, G3, G4, and G5 are sufficient for most scenarios.

Developer Certificates: The final goal!

To focus on the subject, what kind of leaf developer certificates are created from these two types of Intermediate certificates? This scheme will help:

As you can see from the above diagram, there are four main leaf certificates we will use to sign our macOS apps, based on their prefix:

Developer ID Application. Use this one to code sign a macOS app distributed outside the Mac App Store.
Developer ID Installer. Use this one to code sign the Installer, DMG or .pgk file of a macOS app distributed outside the Mac App Store.
Apple Distribution. This certificate is required to code sign a macOS app sent to the AppStore Connect for its distribution through the Mac App Store.
3rd Party Mac Developer Installer. This Certificate is required to code sign the package of the app sent to the AppStore Connect. For example, when using the Publish feature from the Xojo IDE.

Creating and Installing the Developer Certificates

As stated in the first article of this series, you need a paid Apple Developer Program membership. Once that’s in place, the easiest way to install these required certificates in your macOS Keychain is through Xcode.

So, if it is the first time you need to install them on a Mac computer:

Go to Xcode > Preferences.
Select Apple Accounts.
Use your developer credentials to login into your developer account, or select it from the list if you are already logged.
Select the Team from the list.
Click the “Manage Certificates…” button.
Click the “+” popup menu in the lower-left corner of the resulting window, and select the developer certificate you want to install (all of these if it is the first time you install them).

Note: Under the hood, Xcode follows the same process described for installing the developer certificates manually.

If you prefer to go through the manual process instead:

Access the Apple Developer website.
In Certificates, Identifiers & Profiles, click Certificates in the sidebar.
On the top left, click the add button (+).
Under Software, select Developer ID, then click Continue.
- Developer ID Application: This certificate is used to code sign your app for distribution outside of the Mac App Store Connect.
- Developer ID Installer: This certificate is used to sign your app’s installer Package for distribution outside of the Mac App Store Connect.
- Apple Development: Used to run and debug apps on macOS during development.
- Apple Distribution: Used to sign apps for submission to App Store Connect.
- Mac App Distribution: Used to sign macOS apps intended to be distributed through the Mac App Store.
- Mac Installer Distribution: Used to send the macOS app to the App Store Connect for TestFlight or distribution through the Mac App Store.
Follow the instructions to create a certificate signing request.
Click Choose File.
In the dialog that appears, select the certificate request file (a file with a .certSigningRequest file extension), then click Choose.
Click Continue.
Click Download.
The certificate file (a file with a .cer file extension) appears in your Downloads folder.
To install the certificate in your keychain, double-click the downloaded certificate file. The certificate appears in the My Certificates category in Keychain Access.

It’s All About Identities

While Intermediate and Root certificates only have the Public Key on them, so they can verify other (leaf) certificates, the leaf certificates installed on your macOS Login keychain behave a bit different. Let’s see how.

Both if you use Xcode or create the CSR request manually to generate the developer certificates, using the Keychain Access app for that, in both of these scenarios a Private Key will be created and stored locally on your keychain as part of the process. Only the public key section of that private key is sent to the Apple servers so it can be included in the generated developer certificate. Once any of the possible developer certificates is downloaded and installed in the keychain, such certificate will have its private key associated with it:

The pair of the developer certificate and the associated private key is what is called an Identity.

Code signing With Developer Certificates

In fact, while we often say or hear “code signing with certificates,” the real signing of the app is done with the private key associated with that certificate. The certificate itself (and thus the public key portion of that key pair) is included in the signing process. This allows macOS to verify the signature each time the user runs the app

Do you remember the diagram showing how the “Ad-Hoc” code signing process works? Let’s compare it when the same process is done using a “Developer ID Application” Certificate… and, most important, the associated private key:

As you can see, in this case the data is cyphered using the private key from the developer certificate and, then, the certificate itself is stored as part of the app itself. So, if for example we build this time an empty Desktop app for macOS using the Developer ID Application, and open the resulting CodeResources file in a text editor we will see something different compared with the Ad-Hoc signed version:

In this case the field requirement associated with each file and hash value is significantly more strict. In fact, it makes reference to the Chain of Trust Gatekeeper is required to follow and validate. In plain English, the highlighted lines come to say something like:

Hey! make sure there is a Developer ID Application certificate (Apple Extension attribute —OID— 1.2.840.113635.100.6.1.13 for the X.509 certificate), for the developer with a TeamID BW7PU32485.
Next, verify such certificate is issued by the “Apple Developer ID Certificate Authority” (other of the Apple-specific X.509 extension, attribute or OID. In this case: 1.2.840.113635.100.6.2.6).
And finally, go down through the Chain of Trust and verify the previous one with the Anchor certificate (Apple Root CA, do you remember?)

So far so good. But how we can know if the app meets these requirements; and what about the certificates themselves? Well, it’s easy to check both using the codesign tool.

Open a Terminal window and type the following command:

codesign --verify -vvv "MyApp.app"

The output will be something similar to this:

As you can see in the highlighted lines, yes, it satisfies the Designated Requirements we saw in our CodeResources file! Also, the previous line states that it is valid on disk. That means:

All of the expected files are present.
There are no extra files.
None of the files have been modified.
A basic trust evaluation of the leaf certificate was successful.
And it satisfies its own Designated Requirements (DR).

It is even possible to see the Chain of Trust for the code signature issuing:

codesign --display -vv "MyApp.app"

And if you are curious enough, it is even possible to extract the embedded certificates stored in the CMS structure within the code signature:

codesign --display --extract-certificates "MyApp.app"

As result it will, usually, create three files. Take a closer look at the “Issuer” and “Subject” lines; specially on the Subject line for the OU value (Organizative Unit or, using Apple wording, the TeamID) for the codesign0 file. Do you remember the “leaf[subject.OU=BW7PU32485]” data from the CodeResources file? :

codesign0. This is the file for the Leaf certificate; in our example “Developer ID Application”.

codesign1. This one is for the Intermediate Certificate; in our example “Apple Developer ID Certificate Authority”.

codesign2. This one is for the Anchor Certificate; in our example “Apple Root CA”

As shown by the Issuer line in the codesign0 file for our “Developer ID Application,” it points to the previous certificate in the trust chain—the Developer ID Certification Authority. The codesign1 file for the extracted Developer ID Certification Authority points to the Apple Certification Authority in its Issuer field. Finally, the codesign1 certificate points to itself because, as the Root Certificate, it serves as the anchor for the trust chain.

Wrapping up

In this second article, we delved deeper into how Apple Developer certificates work, how a macOS app is signed (Ad-Hoc or with a specific developer certificate), and how the OS’s security features validate the signing when a user tries to run the app.

In the next article, we will cover more details about signing apps for the two main distribution types: Direct distribution and Mac App Store. We will also discuss what happens when certificates expire and how to troubleshoot the most common issues related to development certificates.

Code Signing on macOS: What Developers Need to Know

Code Signing on macOS: What Developers Need to Know, Part 1

Javier Menendez — Wed, 04 Mar 2026 16:00:00 +0000

Your macOS app is finished and ready to go. But unless you plan to run it only on your own machine, there’s one essential step before sharing it with others: code signing with certificates.

This blog series provides a clear, practical overview of how certificates work, with a focus on signing and distributing macOS applications. Some concepts apply to digital certificates in general, while others are specific to the macOS code signing process. By the end of the series, you’ll understand what certificates are, why they matter, and the role they play when building and distributing a macOS app.

The Developer ID field in the Build Settings > macOS > Sign Inspector Panel is our starting point:

By default, this field is empty. When you click Build, the app bundle (and its contents) is signed using a more relaxed security configuration. This does not require an explicit developer certificate and does not verify that the app comes from a known, trusted developer.

This type of signing is called Ad-Hoc signing. It is perfectly fine when debugging from the IDE or when building apps you intend to run locally.

In earlier versions of macOS, it was even possible to distribute and run Ad-Hoc–signed apps on other Macs, as long as the user explicitly chose to trust them. While this is still technically possible on recent versions of macOS, Apple has continued to tighten security, making it increasingly difficult for users to launch Ad-Hoc–signed applications.

In most cases, Gatekeeper will intervene and prevent the app from launching. Since the system cannot verify the identity of a trusted developer, it treats the app as unverified. With Ad-Hoc signing, macOS can only confirm that the app has not been modified since it was signed, it cannot validate who created it.

Under the hood: How “Ad-Hoc” signing works

Every time an app is signed (including all the contents inside its bundle) macOS uses Apple’s codesign tool. When Ad-Hoc signing is applied, the simplified process works roughly like this:

A hash value (a unique digital fingerprint) is calculated for every file in the app bundle, whether it is executable or not, as well as for the bundle itself.
These hash values are stored inside the app bundle, in the _CodeSignature folder.
If the app contains multiple architectures (for example, x86 and ARM), the process is repeated for each supported architecture.

When a user double-clicks the app to launch it, macOS performs a similar verification process:

It recalculates the hash value for every file in the bundle.
It compares the newly calculated values with those stored in the _CodeSignature folder and if any hash differs from the stored value, macOS determines that the bundle has been modified since it was signed and it will refuse to launch the app.

Want to see this in action? Create a new Desktop project in the Xojo IDE, save it to your Documents folder, and build it for macOS.

Next, locate the built app in Finder. Control-click it and choose “Show Package Contents.” Then open the Contents > _CodeSignature folder and inspect the CodeResources file using your favorite text editor. You’ll see a list of hash values and digests corresponding to every file in the app bundle.

Apple Developer Certificates: Establishing Trust on macOS

What must you do so your apps are recognized as first-class citizens on macOS and can be distributed without Gatekeeper intervening? The answer is likely familiar: enroll in the Apple Developer Program (currently US $99 per year).

Among its many benefits, membership in the Apple Developer Program allows you to create your own Developer ID certificates. When you use these certificates to sign your apps, macOS can validate the signature and identify you as the verified developer distributing the software.

But how is this trust established and verified? To answer that, we need to start at the very root, literally!

Every computer, smartphone, tablet, and many other devices come with preinstalled Root Certificates. These certificates are issued by trusted organizations known as Root Certificate Authorities (CAs), including Apple. They serve as the foundation of a chain of trust, allowing other certificates issued by those authorities to be verified.

Technically speaking, a Root Certificate Authority (CA) is the top-level trusted entity in a public key infrastructure (PKI). It issues self-signed root certificates that act as the trust anchor for verifying other digital certificates. In other words, it is the foundation upon which the entire certificate trust model is built.

It is easy to take a look to these installed on your Mac:

Open Keychain Access.
Select Certificates at the top of the window.
In the sidebar, choose System Roots.
You will then see the complete list of root certificates trusted by macOS.

You’ll notice that there are three different Apple Root CA certificates. Why?

Each X.509 certificate contains detailed metadata defining its cryptographic properties and permitted usage. This includes the key type (such as RSA or ECDSA), the public key length, and the signature algorithm used.

Apple Root CA: Is a RSA type, with a public key length of 2048 bits that uses the SHA-1 algorithm.
Apple Root CA-G2: Is a RSA type, with a public key length of 4096 bits that uses the SHA-384 algorithm.
Apple Root CA-G3: Is a ECDSA type, with a public key length of 384 bits that uses the SHA-384 algorithm.

Intermediate Certificates and the Chain of Trust

Root certificates are highly valuable and sensitive, so they are rarely used directly to sign end-user certificates (also called “Leaf” certificates). In the case of macOS app development, the developer’s certificate is the Leaf. This is where Intermediate Certificates come into play.

In simple terms, Intermediate Certificates are signed by Root Certificates and, in turn, are used to sign Leaf certificates. This protects the Root certificate from direct exposure. Together, the Root, Intermediate, and Leaf certificates form what is called the “Chain of Trust.”

The Chain of Trust verification starts with the Leaf certificate and works upward through the Intermediate to the Root. This same process occurs whenever you visit a secure website, make an online payment, or transmit sensitive data securely.

For example, the Leaf certificate is validated against its Intermediate certificate. If the Intermediate certificate is missing or expired, the Leaf certificate is considered invalid. Similarly, the Intermediate certificate itself must be validated against the Root certificate. If the Root certificate is missing or expired, the Intermediate is invalid, and all Leaf certificates signed by it are also invalid.

The same process happens when you sign your macOS apps: macOS validates the entire certificate chain before allowing the app to run.

Finally, certificates closer to the Root generally have longer validity periods. Leaf certificates must be renewed more frequently, while Root certificates are valid for many years.

Wrapping up

In this first article, we covered the fundamentals of digital certificates and their role in macOS app security. In the next article, we will focus specifically on Apple Developer certificates and how they enable trusted app distribution.

Code Signing on macOS: What Developers Need to Know

New WebUserAuthentication Control: Look, Mom, No Passwords!

Ricardo Cruz — Tue, 09 Dec 2025 16:30:29 +0000

The web framework has a new control available in the Library, WebUserAuthentication. Now that Passkeys have arrived, let’s explore this feature!

Passkeys Demo

In this demo, we will be creating a new account using just our email. Using a platform authenticator, like Apple Passkeys or Windows Hello will make this pretty easy. They are integrated in the operating system and synced across devices. I will be using macOS with the integrated Passwords app, but this is supported in Windows through Windows Hello, or you could store, sync and use Passkeys using a Google Chrome Profile.

As you can see, there is no intermediate step. No need to use a separate app to store your passwords securely. A Passkey will be generated and stored in the authenticator in one simple step. This Passkey will be automatically synced across devices and available on my iPhone.

Opening the Password application, I already can confirm my new Passkey has been stored for “localhost”. Notice the user name is also there, meaning you won’t need to fill it during the login process.

The username isn’t important or even required, it’s just to display a friendly name for this user. A Passkey will include the user ID, which can be any arbitrary String you want. In my example, I’ve used the new Random.UUID method, but this is completely up to you. And this is transparent for the end user.

Now, let’s try to login:

That’s it!

Another thing to notice is, while I have several Passkeys for different websites, only the relevant Passkey can be used. This makes Phishing attacks useless. End users won’t be able to use a Passkey anywhere else, just on the website where it has been created. And also, users won’t be able to send their password by mistake to an attacker because … they can’t!

For web application developers, another interesting thing to note is that you won’t be able to store a Passkey insecurely. Even if your database gets compromised, a hacker won’t be able to use the stored public keys to authenticate those users with another service. To make it easier to understand, you will be storing a lock, not the key used to open it.

Other User Journeys

My demo is just the classic email / password sign up / sign in workflow, but without using a password. Passkeys is based on WebAuthn (part of FIDO2) and there are several ways you can use this technology in your web application. For example, you could use a shared computer and still be able to securely log in using your mobile. The platform will display a QR code you can read with your phone camera, and grant the access from your personal device.

In my example application, the user can sign up using different emails. If the Passwords app encounters more than one for my domain it will allow the user to specify the Passkey to use:

Xojo will take care of preparing the WebAuthn steps, verifying signatures and doing the common busy work for you. You will have to decide which workflow makes sense for your application and perform any further verifications, like sending a verification email on register, to ensure this user owns that account.

Multi-Factor Authentication

If you already require your users to authenticate with a username (or email) and a password, you could use WebUserAuthentication as a second factor. That means the user will need to provide something this person knows (a username and password combination) in addition to something the user has (the authenticator device)

Other common multi-factor authentication schemes are email magic links and time-based one-time passwords, “TOTP”.

More factors equal better security, of course. But as usual when it comes to security, you’ll have to find the sweet spot between secure and comfortable.

Usernameless + Passwordless Authentication … Wait, What?!?

“How can I authenticate without providing my username or email?”. This is where real new possibilities arise. When you use a username with a password that only Chuck Norris and you know, this becomes a “proof of identity” (at least in theory, in practice a hacker could compromise an account using a weak password)

When using an authenticator without a username or password, it becomes a “proof of possession” of the authenticator device.

Again, think about it as a locker’s lock and a key. Everyone can see the lock, but only people with the correct key can open it. The public key would be the door’s lock, while the authenticator device would be the key. You can share the key with another person you trust to grant this person access to the contents behind that door. The difference with a real-life lock is that we will be using a really secure one, with a security key.

As long as you can proof you have a valid “key” to authenticate, you are granted to continue.

Consider the following scenario. The company could have a web application that uses a traditional username + password authentication but, for really special activities, the user needs to authenticate with a physical USB key authenticator device that is shared by everyone in the office.

Other use cases are obviously when privacy is involved. A private journal, or a private blogging service, voting. The inconvenience in this case is the user won’t be able to recover the account if they lose access to the authenticator. In this case, you might want to offer a different recovery solution, like printing a very long recovery code. If they also lose the recovery code, they will permanently lose the account.

How To Use The New Control

As you do with any other non-visual control, like a WebTimer, you can just drop the new WebUserAuthentication control into your WebPage.

Then configure its properties. The most important one is the Domain field. It must match the domain name where your application will be deployed. If you want to test it locally without using HTTPS, it must be “localhost” (“127.0.0.1” won’t work)

There are four events available:

You can use RegistrationSucceeded and AuthenticationSucceeded to interact with your Database, store the details and redirect the user to their dashboard.

In RegistrationSucceeded, a WebAuthenticationCredential will be given to you. This is a data transfer object with the following properties you need to store in your database:

ID
PublicKey
AuthenticationAttempts
DisplayName

Error will be fired when something goes wrong. A message will also show with the details about what happened, but it isn’t meant to be shared with the end user. During the sign up and sign in processes, you should display generic messages for security, to avoid letting bad actors know what’s going on. If you need to inform the user something related to these messages, you can send them an automated email instead.

CredentialRequested will be fired during the authentication ceremony. A userId and a credentialId will be given to you, and you should return a new WebAuthenticationCredential instance with the details coming from the RegistrationSucceededEvent.

Also, when AuthenticationSucceeded happens, the event will come with an authenticationAttempts parameter. This will be an incremental value used to update your credentials. This is part of the WebAuthn protocol sign in ceremony used to detect cloned authenticators, which is supported by Xojo. Please notice this value might come always as “0” when using Safari, for example, but Google Chrome will increase its value each time.

You can initiate a Registration or Authentication ceremony by calling Register or Authenticate, respectively.

Register(userId As String, username As String = “”, displayName As String = “”)
The parameter userId is required, the new credential will be built specifically for it. It can be anything that makes sense in your application, like an auto-incremental number or a random UUID . The other parameters are meant for giving the credential a friendly name. The username could be a nickname, or an email. In workflows where you allow the user to store more than one passkey, the displayName could be something like “Backup key”.
Authenticate(Optional allowCredentials() As String)
This will initiate the authentication ceremony. You can optionally pass an array of credential IDs, allowed for the user trying to get access to the protected resource.

Adoption and Compatibility

Not every user may know they even exist, what they are, how they work or if they will be more secure than using their pet’s name and birthdate. This can cause some friction. Other users that adopted the usage from day one might have at least two physical USB keys. They expect your application to allow them to enter more than one, just in case they lose their main USB key.

Passkeys are here to stay and their adoption will continue growing on web services. That said, depending on the combination of operating system and browser, there are some gotchas. Google Chrome or Firefox should work on every operating system. Apple users will probably obtain the best user experience if they’re tied to this ecosystem. Linux users using alternative browsers could experience some challenges.

If compatibility is a must for your application, you should still offer an alternative to Passkeys. For example, legacy passwords, or “magic login links” sent by email.

Wrapping Up

We are sure Passkeys will be the norm in the coming years. Read more in the Xojo Docs. Xojo is ready to embrace them and you can start adopting them in your Xojo Web application today!

macOS Apps: From Sandboxing to Notarization, The Basics

Javier Menendez — Thu, 22 Aug 2024 15:45:28 +0000

You are likely already familiar with terms like Sandboxing, hardened runtime and Notarization. After all, these are required if you plan to distribute your macOS apps through the Mac App Store. But, starting with macOS Sequoia 15 (expected in the fall of 2024), Apple has tightened the runtime security protections even more. For example, it was common to Control + click on any downloaded macOS app from Internet that has not been signed and simply choose the Open option from the contextual menu to open it. That won’t be an option under Sequoia (although it still possible to run the unsigned app).

In fact, Apple recommends to Notarize the software even if you are going to distribute it from your own website, outside of the Mac App Store. But, don’t be scared! Currently there are good third parties options available that ease the path, like App Wrapper from Ohanaware, or some OpenSource options as for example Xojo2DMG; and through this article you will see how to enable Sandboxing, runtime hardening and even Notarizing on a simple example app. Of course, this will touch only the basics and it is up to you to read the related Apple Documentation to add the entries, both the Entitlements and additional keys/values in the app Info.plist file, required by the purposes of your particular app, for example file access, camera or mic access, network access, etc.

A Bit of Common Ground

At this point, your head may be spinning if you are unfamiliar with these app security terms; so, what do Sandbox, hardened runtime and Notarizing mean when they are applied to macOS apps?

Sandboxing

When a macOS app is sandboxed, that means that macOS will create an exclusive container for everything related to the app the first time it is launched. This is what happens when installing an iOS app, too! Such a container will have its own structure to access things like documents, pictures, downloads, etc. Think about it as the own private execution space for the app:

Of course, there are entitlements waiting for you so your sandboxed app can access the files created by other apps (including the Desktop, Downloads, Movies, Music and Picture folders), among other things.

Hardened Runtime

When enabled for your macOS app, hardened runtime adds an extra layer of protection to the running code itself. For example, it prevents certain classes of exploits, like code injection, dynamically linked library (DLL) hijacking, and process memory space tampering. This kind of protection is also enhanced by the System Integrity Protection (SIP).

Notarization

In brief, this is a third layer of confidence for the potential users of your macOS app. When the app is notarized, that ensures to the user that the Developer ID-signed software you distribute has been checked by Apple for malicious components. This is not related with the Apple Review process of your app when it is submitted to the Mac App Store, it’s related to the macOS Gatekeeper technology. So, when a Notarized app is downloaded from Internet, for example, Gatekeeper will use the notarization ticket attached to your app/DMG file to provide more meaningful information about the origin of the app, including if it is safe for the user to open it.

Preparation

In order to follow this article, you will need:

Xojo. Download it for macOS if you have not done yet.
macOS 11.3 or later.
Xcode 13 or later. Run it at least one time and make sure that all its required components and SDKs are installed.
Apple Developer ID. This needs to be a paid Apple Developer membership. Also, make sure you have your Developer certificates installed in the Mac.
A working Internet connection.

With all of this in place, open Xojo to create a macOS Desktop project and do some basic layout in the by default window. It is not required to add any functionality to keep the focus in the task at hand. Then, use Build Settings > macOS > Mac App Name to give an appropriate name to the built application (for this example I named it “SandboxedApp”).

Lastly, save the project (for example into the Documents folder) and click the Build button to build the app! It is not required at this point to assign the Developer ID in the Build Settings > macOS > Sign section, because we are going to sign it (again) in the next steps.

Creating the Entitlements File

The entitlements file is pretty similar to the Info.plist file you probably already know that is in charge of storing the required keys and values for the app to properly work. Both of these are in XML format, and the only difference is that while the Info.plist file is created for you by Xojo, the Entitlements file needs to be, currently, manually created for you.

So, open your text editor of choice (there a lot of there out there, both free and paid ones; personally I tend to use BBEdit from BareBones Software). Add the following lines to the text document and save it with the name “Entitlements.plist” (if you keep it next to the saved built macOS app, the better). This is the file where you will probably want to add more entitlement entries as your app requires them:





  com.apple.security.app-sandbox

Sandbox Your App

With the compiled app and the entitlements file in place, open the Terminal app and type the following command and press the return key:

> codesign --force --deep --timestamp --entitlements  -s "Developer ID Application: "

Once executed, run the “SandboxedApp”, open the Activity Monitor app and make sure that the Sandbox option is enabled under the View > Columns options. Then, use the search box of the main window to filter the displayed processes so it only displays your app. Take a look to the value under the Sandbox column and you will see that the app is now Sandboxed, and the Container for it has been created under the Library/Containers path. Quit the app when you are done.

Hardened Runtime

With our app already sandboxed, let’s look how to add the hardened option to it. Once again, type the following command in the Terminal prompt:

> codesign --force --deep --options runtime --timestamp --entitlements  -s "Developer ID Application: "

As you can see, it doesn’t vary much from the previous command. All it adds is the “–options runtime” text in charge of enabling the runtime hardening. Also, as you might guess, using this command will enable the Sandboxing of the app and also the runtime hardening, at all once.

Do you want to check if it worked? Well, type the following command at the Terminal prompt:

> codesign --display --verbose

It will produce an output similar to this one:

Executable=
Identifier=com.xojo.sandboxedapp
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=43297 flags=0x10000(runtime) hashes=1342+7 location=embedded
Signature size=9100
Timestamp=13 Aug 2024 at 12:51:28 PM
Info.plist entries=15
TeamIdentifier=************
Runtime Version=11.1.0
Sealed Resources version=2 rules=13 files=4
Internal requirements count=1 size=184

It is the “flags=0x1000(runtime)” which shows that, in fact, the app runtime is hardened. Congrats!

Notarizing the App

This is the final step, but is going to require an extra step from your side. Because the notarytool command line tool, used for notarizing the app, is going to require the ID and password from your Apple ID account, plus the fact that it uses 2FA authentication, it is very convenient to create an app specific password for it.

Creating an App-Specific Password

In order to create the password used by the notarytool process, follow this steps:

Sign in to appleid.apple.com
In the Sign-in and Security section, select the App-Specific Passwords option:

The previous action will bring a new dialog displaying all the app-specific passwords already created. Click the “+” button to add a new one:

Type a meaningful name for as the “Title” or description for your new password in the presented dialog (notarytool could be a good one):

Once you click the Create button it is possible that you will be asked to authenticate again using your Apple ID. Once done, a new dialog will present the generated password to you. Copy it and write it down (or paste it) into a safe place, because we are going to need it in the next step.

Adding the notarytool specific password to the Keychain

Because this app-specific password is going to be used by the notarytool command line tool, it would be very convenient to have it stored in the macOS Keychain. To do so, type the following command at the Terminal prompt, and press the Return key:

> xcrun notarytool store-credentials "notarytool-password" --apple-id "" --team-id  --password

Once executed, you will be able to see the password added to the Keychain app under the name of “notarytool-password”:

Creating a Zip file for your app

The notarization process is handled by the Apple notary service running in the Internet, what means that notarytool needs to send (upload) the bundle of your app in an appropriate format. There are two options: as a DMG file (that needs to be signed before submitting), or as a zipped file, what is even faster and easier (Trivia: Did you know how easy it is to create Zip files in Xojo code?)

So, in order to upload our app for notarization, we need to create a Zip file first. Once again, it is time to type a new command at the Terminal prompt:

> /usr/bin/ditto -c -k --keepParent

Uploading the app for Notarization

With our Zip file in place, we now have all the pieces to send it to the notarization process. The time spent by that process may (and will) vary depending of several factors.

In order to send the file, type the following command at the Terminal prompt:

> xcrun notarytool submit  --keychain-profile "notarytool-password" --wait

After pressing the Return key, the process will start and the Terminal will output information about the progress; something similar to this:

Conducting pre-submission checks for  and initiating connection to the Apple notary service...
Submission ID received
  id: 
Upload progress: 100.00% (8.65 MB of 8.65 MB)   
Successfully uploaded file
  id: 
  path: 
Waiting for processing to complete.
Current status: Accepted........
Processing complete
  id: 
  status: Accepted

Have you seen the last line? The “status: Accepted” means that everything worked OK, and the notarization process has been successful, but it’s better if we check! Type the following command at the Terminal prompt. This one will ask the notarytool command to download the log file in JSON format to be saved at the desired path. It is a good habit to do it, because such a log file will include some eventual error and explanation about possible errors during the notarization process, including those related to the app itself:

> xcrun notarytool log  --keychain-profile "notarytool-password"

Staple the Ticket!

Assuming that everything worked OK, it is time to staple the notarization ticket to the app itself. It is not required, but is convenient to avoid online checks when the user runs the app, or Gatekeeper inspects it.

Yeah, that means using a new command from Terminal on the already signed, sandboxed and runtime hardened app bundle (not the Zip file you created for submitting using notarytool):

> xcrun stapler staple ""

After that, you can check that everything went OK using the following command:

> spctl -a -vvv -t install

And you should get something similar to this as the output:

source=Notarized Developer ID
origin=

App Distribution

That’s fine, but you will probably want to distribute your app from the Internet using a DMG container. In that case, follow these steps:

Create a DMG container (file).
Copy your already notarized app bundle into it.
Notarize the DMG file.
Staple the ticket to the DMG file.

That way the DMG container will be Notarized along with the app bundle inside it.

In Summary

As we did see, all the process of sandboxing, runtime hardening and Notarization involves a bunch of commands from the terminal, including the creation of the Zip file. But the good news is that all the process could be automated using Xojo itself! (take a look to the Shell class and the Zip method from the FolderItem class if you are not familiar with them).

As I said before, this article only on touches the basics and doesn’t dig into Provisioning Profile creation (associated with Capabilities required by the app), the Entitlements your app may need to properly work, among other topics; so you may find these Apple Developer Documentation of interest:

– Provisioning profiles.
– macOS Entitlements.
– macOS Sandbox.
– macOS Hardened Runtime.
– macOS Notarization.

Happy Xojo Coding!

More in this series on distributing Mac apps:

Simplicity and Security, Xojo Cloud is Ideal Hosting for Xojo Web Apps

Xojo — Mon, 30 Oct 2023 16:00:00 +0000

Xojo Cloud is the premier hosting solution for developers looking for a reliable, secure and high-performance hosting environment for Xojo web applications. Xojo Cloud is developed specifically for Xojo web applications and offers a range of benefits for you and your applications that make it worth the investment.

Xojo Cloud is optimized for Xojo applications. It is specifically designed to provide the best possible performance and stability for Xojo web applications. We optimize Xojo Cloud for performance, so your web apps will run smoothly and seamlessly. You can even monitor server stats from within the Xojo IDE.

Xojo Cloud is focused on simplicity and ease of use and requires zero configuration. Designed with the Xojo developer in mind, Xojo Cloud’s Control Panel makes it easy to deploy and manage web applications. Purchase a server, open a web project in Xojo and click Deploy to upload and install to Xojo Cloud. Not just for web apps, Xojo Cloud includes Apple Push Notification server (APNs) support for your iOS apps. Set up SSL, PostrgeSQL, MySQL, SFTP and a SSH Tunnel with a click in the Xojo Cloud Control Panel (the Control Panel itself is a Xojo web app). The administration of a web server is a significant and constant task; Xojo Cloud allows you to leave that behind and focus on your projects.

We take security very seriously. Xojo Cloud offers advanced security features to protect your data from cyberthreats, including a smart firewall, intrusion and hacking detection and Security-Enhanced Linux. Unlike most hosting solutions that provide little to no security, each Xojo Cloud server is built with our state-of-the-art, industrial-strength, multi-tiered security system woven into its very core.

Additional features and benefits include daily automatic backups, load balancing and support from the Xojo team. With nine global hosting locations, you are able to host your Xojo web applications close to your users, for speed and an ideal overall experience.

In addition to the standard options, Xojo Cloud servers with more RAM, storage and Virtual CPUs are available. Contact customer support for details about personalized plans.

Whether you are a seasoned Xojo developer or just getting started, Xojo Cloud provides an intuitive and user-friendly hosting solution for Xojo web applications. Today is a good day to start using Xojo Cloud, visit our website to learn more or see the Xojo Store to pick your package and location.

PDFDocument: How To Encrypt PDFs

Javier Menendez — Mon, 25 Jul 2022 13:54:00 +0000

One of the PDFDocument features added in Xojo 2022r2 is the ability to encrypt PDF files created with Xojo. Continue reading and I will show you how.

Encrypting PDF files with PDFDocument is based in the use of the PDFPermissions class. You’ll need to create a new instance of the class passing along the “Owner” and “User” passwords. For example:

Var d As New PDFDocument
Var g As Graphics = d.Graphics

Var p As New PDFPermissions("OwnerPassword","UserPassword")

In addition, you can set other properties for the PDFPermissions instance; all of them are read/write and will be applied by the PDF viewer app for when the document is opened using the “user” password.

AllowCopyingContents is set to False by default. When set to True it will allow copying contents from the PDF, as for example the selected text or image.
AllowModifyingContents is set to False by default. When set to True it will all to modify the contents of the protected PDF document.
AllowPrinting is se to False by default. When it is set to True it will be possible to print the PDF.

Once the PDFPermissions instance has been created and the desired properties had been set, all you need to do is to assign such instance to the Permissions property for the PDFDocument instance you want to encrypt:

d.Permissions = p

Then, when it’s saving the document to a file, PDFDocument will encrypt all the streams of data containing sensitive information, as it can be the text or Images rendered on every one of the PDF pages plus the metadata information itself. The used encryption algorithm is AES 128 bits.

That’s all! You can distinguish an encrypted PDF file from an unencrypted one because, usually, the first one will be displayed with the image of a Lock in the icon. When you open an encrypted PDF in the viewer app you’ll be asked to type a password. If you enter the passord set to the “Owner” user, you’ll be able to do all the kind of operations allowed by the viewer app, while if you enter the “User” password, then the kind of options available will be determined by those set using the PDFPermissions properties.

My Thoughts on the WWDC 2022 Keynote

Geoff Perlman — Mon, 06 Jun 2022 21:45:33 +0000

I’ve learned over the years not to have any specific expectations from Apple’s WWDC keynote. Some years they introduce something big and new that we were pretty much expecting. Other years they blindside us. As the CEO of a company that creates tools for building apps for most of Apple’s ecosystem and given Apple’s history of secrecy, I’m understandably curious just how blindsided I might be each June. Fortunately, this year’s keynote was filled with features that ranged from mildly interesting to really awesome but all incremental improvements across Apple’s software line.

There’s a lot of neat new features coming in iOS 16. The kinds of customizations Apple is adding to the Lock Screen are quite nice both aesthetically and practically. While I’m personally not prone to sending text messages I later regret, being able to edit messages and more importantly unsend them, is going to save many relationships. That you can easily switch between dictation and the keyboard means I will probably use dictation a lot more than I have in the past. I have a friend that uses it constantly and I can’t tell you how many times a second text message arrives to explain the incomprehensible message that had arrived moments earlier. That it now adds punctuation will make me want to use it more as dictating punctuation has always felt awkward to me. It will however likely infuriate my kids who think punctuation in text messages is rude. That ApplePay is going to have integrated order tracking is really nice. I have been using an app for that and sadly quite recently several of the companies it allows you to track have dramatically reduced the functionality of their APIs making the app almost useless. That you will be able to easily share photos amongst family members via an iCloud Shared Photo Library is a feature my family will definitely be using. It’s very cool that you can have it automatically share photos that were taken when family members were close by or when they are in the photo itself. It’s a very nice use of Apple Neural Engine.

That Apple announcing a feature to help people escaping abuse says a lot about what they value and how important privacy is to one’s personal safety. It goes right along with features they have added in the past that allow you to reach into your pocket and dial 911 should you need to do that in secret. I’m big into making my home smarter so I was happy to see the Home app getting a facelift as well as Apple working with other companies on smart home interoperability. I’m also a huge fan of CarPlay and seeing Apple’s vision for it becoming nearly the entire way in which you interact with displays and controls in your car and being able to customize that to your liking was far more than I had ever thought would happen. That future is clearly years away because it requires a lot of cooperation with the automakers but as they adopt it, it will certainly sway my future car purchases.

I wear an Apple Watch and very much care about the quality of my sleep. That they have added the ability to see your REM, core and deep sleep cycles is very cool. I will definitely be wearing my watch to bed more often as a result. They are adding a medication reminder system which I can see as being a benefit. I only take one pill a day so it’s not something I would use but my wife takes several and on her busy days sometimes forgets to take them so it’s a feature she will definitely use.

The M2 was something I was fully expecting and it’s nice to see it incrementally getting better. Apple made it clear that performance per watt is the key metric for them and that makes a lot of sense. We need that kind of metric in many other places in society so that we better understand the impact we are having on each other and our planet.

The surprise feature in macOS Ventura was Stage Manager. it makes it easy to avoid the clutter of having a lot of windows open. I wasn’t expecting it and yet I’m sure I will use it. Like Messages, Mail is getting an unsend feature and lots of other nice improvements especially to search (which has always felt weak to me) but I’ll have to test it to know just how much it has improved. Passkeys is Apple’s name for their implementation of the Fido standard they are collaborating on with Google and Microsoft. It’s designed to get rid of passwords entirely, something of which I will definitely be an early adopter. They really have thought that one through. It will make all of our devices and data far more secure. Being able to use FaceTime with Handoff will be really nice. I’ve been on a FaceTime call and then hung up to call someone back from my Mac so it will be nice to be able to just transfer it from one device to another.

The new MacBook Air is a nice incremental upgrade. If you have an Intel-based MacBook Air, this is a good time to upgrade.

iPadOS 16 is bringing some more desktop-like features to iPad. Things like standard ways for accessing documents, renaming them, collaboration, etc., all make iPad feel a little more like a desktop without it being a desktop. It feels like Apple is striking the right balance. They also previewed a new app called Freeform which is essentially a digital whiteboard that you can use to collaborate with others. Though now that I say that, it seems to not really do it justice given that you can share so many different things in a common space, from text, drawings, photos, video and more. It would be great for brainstorming with a remote team.

Overall, this keynote demonstrated a lot of incremental improvements across the software side of the product line and that’s a good thing. We all want something big, new and flashy but those often come at the cost of a lot fewer incremental improvements. I’m actually quite happy that we weren’t blindsided by something that could potentially change our short term plans here at Xojo. I look forward to using many of the new features they are adding this year.

PDFDocument: Signing PDFs

Javier Menendez — Tue, 05 Apr 2022 13:30:00 +0000

Beginning with Xojo 2022r1 you can use Xojo’s newPDFSignatureForm Control in your PDFDocuments. Using this allows your users to be able to sign documents using a Digital Certificate. Read on to learn how…

Once the document has been signed and saved to disk, anyone opening the document will be able to check if the signature on the document is still valid or if, on the contrary, there have been changes to the documents after it was signed.

Adding signing controls to a PDF Document with this code:

Var d As New PDFDocument

// Creating a new PDFSignature instance
Var signatureField As PDFSignature = New PDFSignature(1, X, Y, Width, Height, "SignatureField")

// …and adding it to the Form controls in the PDFDocument instance
d.AddControl(signatureField)

As you can see, you need to create a new instance from the PDFSignature class providing to the Constructor method the page number, X and Y coordinates, and the width and height values for the interactive signing box.

These screenshots show a PDF document with a PDFSignature control added before it has been signed (on the left), and after it has been signed using a Digital Certificate (on the right). The project that produced the example below is included in the Example Projects folder in the Xojo download.

Lastly, and as it happens with many other features of the PDF format specification, the ability to digitally sign the PDF documents created with the PDFDocument class is up to the PDF viewer you use. For example, the free app Adobe Acrobat Reader does support this feature, while that is not the case with the Preview app provided by macOS.

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

Crypto Improvements

Paul Lefebvre — Thu, 18 Nov 2021 12:40:00 +0000

Xojo 2021 Release 3 has a few improvements to the Crypto module that you might find useful.

SHA3

A new SHA3 algorithm is available for use with the Hash function. You can now use SHA3-256 (SHA3 with 256-bit digest) and SHA3-512 (SHA3 with a 512 bit digest) from the Crypto.HashAlgorithms enumeration for stronger encryption or compatibility with something else that uses them.

Var hash As String
hash = Crypto.Hash("YourPasswordSentence", Crypto.HashAlgorithms.SHA3_512)

BlowFish / TwoFish

The BlowFish and TwoFish encryption algorithms can now be used in Xojo. These two algorithms are similar, with BlowFish being the original algorithm and TwoFish being a newer, more secure version that was derived from BlowFish.

You can use them in Xojo with the Crypto.BlowFishEncrypt, Crypto.BlowFishDecrypt, Crypto.TwoFishEncrypt and Crypto.TwoFishDecrypt methods.

You can use either to encrypt data, but in general you’ll want to avoid BlowFish for your own code, although it might prove useful for compatibility with other libraries or tools.

AES

AES (Advanced Encryption Standard) is also used to encrypt data. You can do this using the Crypto.AESEncrypt and Crypto.AESDecrypt methods. Here is a quick sample:

Var encrypted As MemoryBlock

Var dataToEncrypt As MemoryBlock = "Secret!"
Var key As MemoryBlock = Crypto.GenerateRandomBytes(16)
Var initVector As MemoryBlock = Crypto.GenerateRandomBytes(16)
encrypted = Crypto.AESEncrypt(key, dataToEncrypt, Crypto.BlockModes.CBC, initVector)

Var decrypted As MemoryBlock
decrypted = Crypto.AESDecrypt(key, encrypted, Crypto.BlockModes.CBC, initVector)
// decrypted = "Secret!"

CRC-32

CRC32 is just a simple way to test data integrity and is not cryptographically secure. It still has its uses for fast data comparison and simple hash tables. It can be called like this:

Var crc32 As String
crc32 = Crypto.Hash("StringOrDataToTest", Crypto.HashAlgorithms.CRC32)

RSASign

RSASign now takes an optional parameter and RSASignModes let you specify the hash to use.

Learn more about the Crypto module in the Xojo Documentation.

Updated (Nov 22, 2021): Added AES section

The Modern Control Panel + 4 More Powerful Features New in Xojo Cloud

Geoff Perlman — Thu, 27 Aug 2020 11:17:00 +0000

Our vision for Xojo Cloud has always been a simple, safe, one-click deployment option for your web apps. Xojo Cloud allows you to focus on developing your apps instead of dealing with the nitty gritty details of web hosting and security. Xojo Cloud has tons of new stuff to compliment apps built with Xojo 2020r1!

Here’s what’s new:

Apps deployed to Xojo Cloud are now 64-bit stand-alone apps for better security and faster performance*
Apps deployed to Xojo Cloud are now automatically load-balanced to support more concurrent users
Domains can now be pointed at individual web apps
Unique subdomains are available on the xojocloud.net domain for users who don’t have dedicated app domains
Manage team members and grant access to your server directly from the all-new, made-with-Xojo, Xojo Cloud Control Panel

Xojo Cloud eliminates the complicated process of deploying a web application; it requires no configuration, includes security, automatic backups and predictable pricing. Xojo Cloud servers are available in locations around the globe and start at just $49/month. More details about using Xojo Cloud can be found in the User’s Guide.

*CGI-based web apps built with previous versions of Xojo are still supported.

Code Tip: How to Implement the ARC4 Encryption Algorithm

Javier Menendez — Thu, 25 Jun 2020 10:00:00 +0000

ARC4 is a symmetric encryption algorithm fast and easy to implement. Being symmetric does means that it uses the same function with the same key (varying from 40 to 2048 bits) both for cyphering and de-cyphering a block of data.

Is it the most secure or robust encryption algorithm around? Not really. But it provides a good amount of performance and you can take further steps in order to correct some of its flaws. So, continue reading if you are interested in having this one in your developer toolset implemented as a Class with separate methods to encrypt and decrypt a block of information (even if it uses the same function in both cases).

Add a new Class to your project and name it ARC4. Next, add the three properties needed to implement it:

Name: mBox
Type: MemoryBlock
Scope: Private

Name: mKeyBlock
Type: MemoryBlock
Scope: Private

Name: mKeyLength
Type: Integer
Scope: Private

ARC4 uses a main state box with a length of 256 bytes and the first one will be the one pointed by the mBox property. The second one, mKeyBlock, is declared as a MemoryBlock just to be more efficient in accessing the individual bytes of the provided Key. Lastly, the mKeyLength property is just a convenience property so we can access the original Key length from our Methods.

Now, let’s add the required Class methods, starting with the Constructor. This one will let the user provide the Key string as part of the instance initialization; so we don’t need to provide it again every time we want to encrypt or decrypt a new block of data.

With our ARC4 class selected in the Navigator, add a new method and type the following values in the Inspector Panel:

Name: Constructor
Parameters: Key As String
Scope: Public

Next, type the following snippet of code in the associated Code Editor for the method:

// If Key is not an empty String
// We call the Key method in order
// to initialize the State box

If Not (key.IsEmpty) Then
  Me.Key = key
Else
  // Empty String, so we raise an exception
  Raise New RuntimeException(kkeynotinitialized,Integer(ARCError.KeyNotInitialized))
End If

As you can see, the main thing that the Constructor does is call the Key Method; it’s in charge of initializing the required state box with the provided key. If the key is an empty String, it will raise a Runtime Exception giving a descriptive error message an error number.

Now, let’s add the Key method to our RC4 class:

Name: Key
Parameters: Assigns Value As String
Scope: Public

Being a Public method means that you can change the Key String without needing to create a new instance, if that is what you want to do. For example, you may want to initialize the Class instance using a key, encrypt some blocks of data using that one and then change to a different key in order to encrypt other blocks of data. Just remember that you’ll need to use the same keys in order to reverse to plain data those blocks encrypted with a given key.

In addition, the use of the Assigns keyword is simply syntactic sugar to make it possible to call the method using the equal operator to pass along the required parameter instead of using the regular syntax when calling a method in Xojo code. So, for example, you can use call it using:

MyRC4Instance.Key = "MySecretKey"

Instead of:

MyRC4Instance.Key("MySecretKey")

This is the code snippet that’s going to execute this method:

// Disabling some features for better speed
#Pragma DisableBackgroundTasks
#Pragma DisableBoundsChecking
#Pragma NilObjectChecking False
#Pragma StackOverflowChecking False

// Initialize the index values
Var mFirstIndex As UInt8
Var mSecondIndex As UInt8

// Let's check that this is not an Empty Key String
If Not (value.IsEmpty) Then

  // Trim key length if greater than 256 = max 2048 bits supported by ARC4
  If value.Length > 256 Then value = value.Left(256)

  // Pad the key if it is less than the required min 40 bits (5 bytes)
  // We are going to pad the key repeating the remaining 'n' characters
  // from the begining of the key.
  If value.Length < 5 Then

    Var pad As Integer = 5-value.Length

    value = value + value.Left(pad)

  End If

  // Initialize the State Box if this is the first call to the method.
  // The State box has a maximum of 256 bytes.
  If mBox = Nil Then mBox = New MemoryBlock(256)

  // Just in case there is an older Key in use
  // Let's get rid of the old MemoryBlock storing it
  // And create a new one with the Key lenght (in bytes)
  mKeyBlock = Nil
  mkeyBlock = value
  mKeyLength = value.Length

  // Required initialization of the State Box
  For n As Integer = mFirstIndex To 255
    mBox.UInt8Value(n) = n
  Next

  mFirstIndex = 0

  // Last step on State Box initialization
  // Permutation of values in the State Box
  // using for that the provided Key.

  For n As Integer = mFirstIndex To 255

    mSecondIndex = (mSecondIndex + mBox.UInt8Value(n) + mkeyblock.UInt8Value(n Mod mKeyLength)) Mod 256

    SwapValues(n,mSecondIndex)

  Next

Else

  // If the provided key is an empty String, we raise a new Runtime Exception
  // with a descriptive error message and error number.
  Raise New RuntimeException(kKeyNotInitialized, Integer(ARCError.KeyNotInitialized))
End If

As you can see, both the Constructor and the Key methods raise a Runtime Exception if the provided Key is an empty string. Both the message and error number are defined as a Constant (the message error) and an Enumerator (Error value) as part of the class itself. So go ahead and add a Constant to the ARC4 class using these values:

Constant Name: kKeyNotInitialized
Default Value: Key Not Initialized
Type: String
Scope: Protected

And for the Enumerator:

Name: ARCError
Type: Integer
Scope: Public
Value: KeyNotInitialized = -1

In addition, the Key method calls the SwapValues method in order to make the values permutation in the State Box. So add a new method using these values in the Inspector Panel:

Method Name: SwapValues
Parameters: FirstValue As UInt8, SecondValue As UInt8
Scope: Private

While the code to type in the associated Code Editor will be:

Var tmp As UInt8

tmp = mBox.UInt8Value(SecondValue)
mBox.UInt8Value(SecondValue) = mBox.UInt8Value(FirstValue)
mBox.UInt8Value(FirstValue) = tmp

Now just two additional methods left to be added to the class- the ones in charge of encrypting and decrypting a given block of data.

In order to encrypt the data, add a new Method with the following values in the Inspector Panel:

Method Name: Encrypt
Parameters: Value As String
Return Type: MemoryBlock
Scope: Public

And with the following block of code in the associated Code Editor:

// Disabling some features for better speed
#Pragma DisableBackgroundTasks
#Pragma DisableBoundsChecking
#Pragma NilObjectChecking False
#Pragma StackOverflowChecking False

// Index initialization
Var mFirstIndex As Integer
Var mSecondIndex As Integer

Var k As UInt8

// If we have a non initialized mKeyBlock
// that means that the key has not being initialized
// so we raise an exception
If mKeyBlock <> Nil Then

  // Initialize Key again

  me.Key = mKeyBlock.StringValue(0,mKeyBlock.Size)

  // Let's put the text to encrypt into a memoryblock
  // so it is faster to iterate through their bytes
  Var target As MemoryBlock = value
  Var temp As UInt8
  Var maxSize As Integer = target.Size-1

  // And we calculate the new bytes values (encrypted values)
  // using the ARC4 algorithm
  // Basically, every byte in the source block will be XORed
  // with the calculated byte from the State box.
  For n As Integer = 0 To maxSize

    mFirstIndex = (mFirstIndex + 1) Mod 256
    mSecondIndex = (mSecondIndex + mBox.UInt8Value(mFirstIndex)) Mod 256

    SwapValues(mFirstIndex,mSecondIndex)

    k = mBox.UInt8Value((mBox.UInt8Value(mFirstIndex) + mBox.UInt8Value(mSecondIndex)) Mod 256)

    target.UInt8Value(n) = target.UInt8Value(n) Xor k
  Next

  //…and return the block of data already encrypted
  Return target

Else
  Raise New RuntimeException(kKeyNotInitialized, Integer(ARCError.KeyNotInitialized))
End If

And the last Method, the one in charge of decrypting a block of ARC4 encrypted data:

Method Name: Decrypt
Parameters: Source As MemoryBlock
Return Type: MemoryBlock
Scope: Public

Typing the following code fragment in the associated Code Editor:

If Not (Source Is Nil) Then

  // Simply call the same method we use to
  // encrypt data, avoiding code duplication
  // and returning the now deciphered data to the caller
  Return Me.Encrypt(Source)

End If

And, that’s all! If you are interested in more information about the ARC4 algorithm you can read this article on the Wikipedia. Or better yet, read the excellent books “Applied Cryptography” and “Cryptography Engineering” to dig in even more on this and other cyphering algorithms. Of course, remember that the Crypto module included in the Xojo framework has a good bunch of these ready to use!

Of course, you also can download the Xojo example project that includes this Class ready to use from this link.

#JustCode Challenge Week 2 – Password Generator

Paul Lefebvre — Fri, 29 Jun 2018 01:00:53 +0000

In week 2 of the Just Code challenge I took inspiration from a feature in 1Password that can generate a password suggestion. This desktop app allows you to specify a desired password length and the number of digits and symbols to include in it.

Here is the Window layout in the Xojo IDE:

I’m using a read-only TextField to display the generated password. There are a couple PushButtons for copying the password text to the clipboard and for generating a new password. I use Slider controls to set the length of the password and the number of digits and symbols to include, along with corresponding labels.

When the window opens, it populates some arrays with the acceptable characters that can be used for letters, digits and symbols. In particular, some characters are excluded such as “O”, “o”, “0” and quotes because those are difficult to distinguish. The code to do this is in the Open event:

The last line calls the GeneratePassword method which uses the settings from the user interface to generate a password. This way you’ll have a password displayed immediately when the window appears.

The GeneratePassword method first determines how many digits are needed, making sure it does not exceed the requested password length. Then it adds any symbols, also ensuring it does not exceed the set length. Lastly, if more characters are needed it adds letters to reach the desired length.

The characters are added to a String array that is then shuffled to mix all the parts together. Try commenting the Shuffle line out and when you run the project you’ll see that numbers always appear first, followed by symbols and then the letters. Here is the GeneratePassword code:

A similar technique is used by the RandomDigit, RandomLetter and RandomSymbol. It uses the Shuffle method to randomize the appropriate array and then returns the first item.

Download the Password Generator project file.

Download and check out earlier projects:

Week 1: Color Picker Desktop App

Discuss your Week 2 project in the Xojo forum:

Just Code Challenge Week 2 Projects

Software Distribution Simplified with GuancheMOS

Javier Menendez — Tue, 26 Jun 2018 10:00:09 +0000

In an ideal world there is a person responsible for every step in software development, from coding, UI design, distribution, documentation, marketing and support. All of this can seem really overwhelming for independent developers and small businesses. But if you break it down and take it one piece at a time, it’s manageable by even the smallest team of one. Right now, let’s look at software distribution.

For software, distribution usually means generating and validating unique serial numbers for each of your products and users. Serial numbers (or license keys) help you manage your users, unlock a free trial or demo version for full use and, of course, minimize illegal use of your apps.

Let’s admit it, there is no silver bullet. Even the greatest companies (you know who you are) throw lots of money at implementing and improving serious protection schemes that are often quickly bypassed. It comes down to: How much time, money and resources are you willing to spend implementing a protection or licensing scheme?

The bad guys will always find a way to break your software protection if they are interested in doing that. Does that mean giving up on protecting your software? Not at all! When I was faced with the problem myself, in order to protect my own products, I went to the drawing board to build a way to generate unique serial numbers —or licensing information— for all the Xojo supported platforms.

The result of this process was the GuancheMOS plug-in. GuancheMOS is a fully multiplatform plug-in for desktop, web and console apps (not for iOS due to the fact that iOS only can link against static libraries), on 32-bit and 64-bit architectures.

The simplicity of GuancheMOS means that you can use it as is, or as the starting point to build your own private and unique serial number automations. Integrate it as part of the purchase process in your website, wrap it as the core piece of other unique information collection. It’s already used by dozens of developers around the world in ways I hadn’t ever thought of while designing it! The best part, is that implementing GuancheMOS in your product takes about 5 minutes.

You can download and try GuancheMOS for free today.

Javier Rodriguez has been the Xojo Spanish Evangelist since 2008, he’s also a Developer, Consultant and Trainer who has be using Xojo since 1998. He manages AprendeXojo.com and is the developer behind the GuancheMOS plug-in for Xojo Developers, Markdown Parser for Xojo, HTMLColorizer for Xojo and the Snippery app, among others

A compromise to security is always just that.

Geoff Perlman — Mon, 28 Aug 2017 18:22:02 +0000

Last month the Australian government suggested they might require tech companies to provide back doors into their systems to help law enforcement use those back doors to catch bad guys. Apple immediately dispatched people to go talk with them about it. Apple’s stance has been that such back doors don’t help catch bad guys and just make the rest of us less secure. Is that really true?

Systems like Apple’s iMessage (their text messaging service) use encryption ensuring that all messages sent between Apple devices via iMessage are encrypted with keys that Apple does not have. They keys are on your device. Law enforcement agencies want Apple and others to provide a means of decrypting those messages without having to obtain the device itself. The problem is that if the government and Apple can get in, others will inevitably find a way to exploit that same back door too, making us and our data less safe and secure.

What some governments have failed to understand is that the bad guys can bypass any back door by using their own encryption. The smart bad guys probably assume that these back doors exist now (or at least aren’t taking any chances) and are already using their own encryption for their communications. How hard is it to write software to encrypt and decrypt messages? Do bad guys have access to programmers smart enough to do this? Yes, they almost certainly do.

Let’s take a look at what is involved in using Xojo to write an app that encrypts and decrypts messages. First, two keys need to be generated, a public key and a private one. The public key allows anyone to encrypt a message that only the holder of the matching private key can decrypt. Public keys can only encrypt. They are no good for decrypting messages. This means you can give anyone your public key which they can then use to send encrypted messages to you that no one else but you can decrypt.

Dim privateKey As String
Dim publicKey As String
If Crypto.RSAGenerateKeyPair(KeySize, privateKey, publicKey) Then
 PrivKey.Text = privateKey
 PubKey.Text = publickey
 SaveNewKeys(privateKey, publicKey)
Else
 Beep
 MsgBox "An error has occured. Keys could not be generated."
End If

This is just 10 lines of code and it could be further reduced. I wrote this to make it easier to read. The important function is RSAGenerateKeyPair on the third line. Next, you need to be able to encrypt a message using someone else’s public key. Let’s take a look at the code to do that:

Dim publicKey As String = RecipientsPublicKey.Text
Dim msg As MemoryBlock = OriginalMessage.Text
try
 Dim encryptedData As MemoryBlock = Crypto.RSAEncrypt(msg, publicKey)
 beep
 If encryptedData = Nil Then
  MsgBox("Encryption failed.")
 else
  Dim c As New Clipboard
  c.Text = Encodebase64(encryptedData)
  c.close
  MsgBox("Your encrypted message has been copied to the clipboard.")
 End If
Catch rte As RuntimeException
 If rte IsA CryptoException Then
  Beep
  MsgBox "Encryption failed because the Public key provided is not valid."
 Else
  Raise rte
 End If
End Try

This is 21 lines of code, most of which is handling errors. The one line that is really doing the work is the fourth one that contains RSAEncrypt. Next we need to be be able to decrypt. Here’s what that code looks like:

Dim privateKey As String = privKey.Text
try
 Dim decryptedData As MemoryBlock = Crypto.RSADecrypt(DecodeBase64(EncryptedMessage.Text), privateKey)
 Decryptedmessage.Text = DefineEncoding(decryptedData.StringValue(0, decryptedData.size), Encodings.UTF8)
Catch rte As RuntimeException
 If rte IsA CryptoException Then
 Beep
 MsgBox "The message could not be decrypted because the incorrect key was provided."
 Else
 Raise rte
 End If
End Try

This is 12 lines of code and like the other code examples, is mostly error checking. The important line is the third one that calls RSADecrypt. There is some additional code to save the keys to a text file and load them back in automatically when the app is launched. However, even adding in all that code gets you to only about 80 lines total. In other words, this is not a big app and not beyond the ability of someone with intermediate programming skills or even perhaps a very dedicated novice. (To learn about this in more depth, read Using Public/Private Key Encryption in Xojo).

If you’d like to try out encrypting messages with the app from which the code above originated, you can download CryptoMessage for macOS, CryptoMessage for Windows or CryptoMessage for Linux. Have a friend do it as well and you can send encrypted messages back and forth. If you’re more adventurous and would like to try playing around with the source code itself, make sure you have Xojo installed (which can be downloaded and used for free) then download the CryptoMessage Xojo Project.

Xojo has a crypto library (the part that provides key generation, encryption and decryption) built-in to it. However, if a programmer wasn’t using Xojo, they could easily find a crypto library on the Internet to use. In other words, building your own app to encrypt and decrypt messages is not very challenging. As I mentioned earlier, the bad guys (at least the smart ones) are likely already doing this as they are probably sufficiently paranoid that despite public announcements to the contrary, the back doors already exist.

The assumption that compromising our security enables catching more bad guys is a flawed one that I have written about before. It won’t work and we will all suffer needlessly. Imagine not being able to carry on a private conversation via your smartphone. That would make your device feel a lot less useful. Some governments have “experts” that have suggested it would be possible to have a back door Law Enforcement could use but could not be compromised by anyone else. That is a logical impossibility. Governments do not possess magic powers. They are made of up people like you and me. That is wishful thinking at best and negligent at worse.

When your government starts making noises about doing this, I advise you to make it clear to them that for the reasons I have stated in this post, such a compromising security is all downside with no upside at all.

RSA: Private/Public keys between Xojo and PHP

Javier Menendez — Tue, 06 Jun 2017 04:37:26 +0000

Among other topics, Cryptography and data ciphering always fascinated me. Beyond their mathematical perspective, most of the time it is a matter of putting them in practice with developed solutions: dealing with data only visible between the transmitter and the receiver. As it happens, the Xojo framework makes it really easy to deal with ciphered data.

All the methods related to cryptography and data ciphering are available under the Crypto module of Xojo, using behind the scene the Crypto++ 5.6.3 library. From the practical side, this allows us to use the RSA public key ciphering and other algorithms to compute unique footprints for given data, as for example Hash, MD5 or SHA. Paul blogged about using Public/Private Key Encryption in Xojo back when we added RSA encryption functions in 2014.

Among the methods related to RSA, we can find the ones to create the Private/Public keys, test the integrity of the public key, signing the given data and, of course, check the integrity of the signature, and ciphering / deciphering the given group of data.

As you probably already know, when we work with RSA we have to keep the Private key in a safe place, using the Public one to give to other people/service/app to whom we want to share information with in a safe manner. This way the users and/or apps and services will be able to use our public key to cipher the data that they want to share with us, and we will be able to use our private key to decipher that group of data so it is legible again.

RSA: Creating and interchanging the keys

Generating the pair of keys could not be more easy in Xojo, with this snippet of code:

Dim publicKey As String
Dim privateKey As String
If Crypto.RSAGenerateKeyPair( 1024, privateKey, publicKey ) Then msgBox “Successfully generated Keys!"

As you can see, the RSAGenerateKeyPair method receives the Integer number that indicates the strength (robustness) of the generated keys, followed by the String variables containing the generated Private and Public keys, passed by reference.

But in some cases it is possible that you want to use these keys beyond the scope of Xojo, for example when integrating your app with a service or solution developed in PHP. In these cases you have to consider that the keys generated with Xojo are in hexadecimal format.

What does this mean? Well, a public key generated with Xojo will look like this chunk of data:

30819D300D06092A864886F70D010101050003818B0030818702818100B4B531D3402C250D8640E739601F01FBE8ABB39635BE1778A7F4E55C49419C0595EF5A5824EA8E7A1871FB63B8960EDBB97B08C2E7EA43229903AEBCB45B9FD9E24780B15BCADB5E026849592CC1FA9B399EBD8457CC4E7A686CF53E9146E1D867ACEB675728E8821DEDA4C2F807FD668A81601F551484C5D1334B62D5E90E33020111

While other external libraries (as is the case in most of the web development frameworks), expect other data format codified as Base64. This is, something like this:

So the first step to encode our Xojo keys (Public or Private ones) as Base64 is converting them previously from his hexadecimal form to the DER encoding (Distinguished Encoding Rules). Here is where we have to employ the DEREncodePrivateKey and DEREncodePublicKey methods if we want to encode the Private or the Public key, respectively. Once we have done this, we will be able to encode the resulting chunk of data as Base64 without forgetting to add the header “—–BEGIN PUBLIC KEY—–“ and the footer “—–END PUBLIC KEY—–“ with the accompanying ends of lines, or maybe the header “—–BEGIN CERTIFICATE—–” and the footer “—–END CERTIFICATE—–“ if we are dealing with a Public Key (for the Private keys we have to use the header “—–BEGIN RSA PRIVATE KEY—–” and the footer “—–END RSA PRIVATE KEY—–“).

You can interchange and use the Private and Public keys generated with Xojo using the PHPSecLib library.

In addition, as pointed by Thom McGrath, you can use also these keys with OpenSSL this way:

if (@openssl_public_encrypt($data, $result, $public_key, OPENSSL_PKCS1_OAEP_PADDING)) {
         return $result;
 } else {
         throw new \Exception('Unable to encrypt');
 }

Xojo’s Crypto library will be able to use a private key to decrypt $result in this case.

Finally, if you are interested in the cryptography topic, let me recommend you some good books: Applied Cryptography and Cryptography Engineering.

JSON Feed iOS App

Paul Lefebvre — Wed, 31 May 2017 16:56:23 +0000

In a previous post I showed how easy it was to create a web app that displays the JSON Feed for Daring Fireball. In this post, I’ll show you how to make an iOS app to do it.

Designing the User Interface

To start, download Xojo for free, install and launch it. At the Project Chooser, select “iOS”, enter “JSONFeed” as the Application Name and click OK.

You are now looking at the Layout Editor. You can drag controls from the Library on the right to create your user interface. For this example you’ll create an iPhone app, so we’ll focus on that layout. The iPhone app will consist of two “views”. The first view will let you enter the JSON Feed URL and then display the article titles. When you click on an article, the second view will appear displaying the article content.

By default Xojo created your project with the first view, called View1. You’ll want to drag three controls to this view: a TextField, a Button and a Table. Arrange them to look like this:

Next you’ll want to set some of the properties for these controls. But first, change the name of View1. Click the Inspector button on the toolbar to show properties and then click anywhere on the View that is not a control. This displays the properties for the view itself.

In the view change these properties:

Name: FeedView
NavigationBarVisible: ON
Title: JSON Feed

You’ll next change some properties for each of the controls. Click on the TextField and set these properties:

Name: URLField
PlaceHolder: Enter JSON Feed URL
Text: https://daringfireball.net/feeds/json

Now click on the Button and change these fields:

Name: LoadButton
Caption: Load

Lastly, click on the Table and change these fields:

Name: FeedTable

Lastly, you want to add a non-UI control to the view. This control is what will connect and download the JSON Feed. Click on Library in the toolbar and scroll down to find the control called “Generic Object”. Drag that on to the view layout where it will appear at the Shelf on the bottom. Switch to the Inspector and change these properties:

Name: FeedSocket
Super: Xojo.Net.HTTPSocket

With this view finished you now need to create the second view. From the Insert button or menu, select “View” to add a new view to the project. Click on the view and change these properties (select the Inspector if it is not visible):

Name: ArticleView
NavigationBarVisible: ON

This view has only a single control on it: HTMLViewer. Drag it onto the view so that it takes up the entire area of the layout like this:

Click on the Inspector to show the properties for the HTMLViewer and change these properties:

Name: ArticleViewer

With the two views done, you can now move on to adding code.

Adding Code

Now it’s time to add the code. Start by double-clicking on the button FeedView. This displays the Event Handler window. Click on Action and select OK. You are now looking at a blank Code Editor. The code you put here runs when the button is tapped. Your code needs to tell the FeedSocket to get the JSON feed for the URL entered in the TextField. This is the code to do that:

FeedSocket.Send("GET", URLField.Text)

Next you need to put code in FeedSocket to parse the JSON Feed that gets returned. Double-click FeedSocket to display the Event Handler window, select PageReceived and click OK. The code below converts the JSON from binary data to Text, then parses the JSON in the Text to get a Dictionary. From the Dictionary you can get the array of articles in the JSON (called items), loop through them and add them to the table.

If HTTPStatus = 200 Then
  Dim jsonText As Text = Xojo.Core.TextEncoding.UTF8.ConvertDataToText(Content)
  Dim jsonDict As Xojo.Core.Dictionary = Xojo.Data.ParseJSON(jsonText)
 
  FeedTable.RemoveAll
 
  // Display the feed title
  Self.Title = jsonDict.Value("title")
 
  // Display the feed articles
  FeedTable.AddSection("")
  Dim items() As Auto = jsonDict.Value("items")
  For Each article As Xojo.Core.Dictionary In items
    Dim title As Text = article.Value("title")
    Dim pubDate As Text = article.Value("date_published")
 
    // Create cell with values and content in the Tag
    Dim cell As iOSTableCellData = FeedTable.CreateCell
    cell.Text = title
    cell.DetailText = pubDate
    cell.Tag = article.Value("content_html")
    FeedTable.AddRow(0, cell)
  Next
End If

The next bit of code displays the content for the selected article. Double-click the FeedTable control and in the Event Handler window choose Action and press OK. This is the event that is called when you tap on a row in the list. In the Code Editor add this code to get the article content (that was previously saved in the RowTag) and send it to the ArticleView to display there:

Dim content As Text = Me.RowData(section, row).Tag

Dim v As New ArticleView
v.SetContent(content)
PushTo(v)

The final code is the SetContent method on ArticleView (called by the code above) that takes the content and prepares it to display in the ArticleViewer. Select ArticleView and create a new method by clicking the “+” button on the command bar and choosing Method. Set these properties in the Inspector for the method:

Method Name: SetContent
Parameters: content As Text

This is the code to put in the method:

// Save content to a file
Dim articleFile As FolderItem = SpecialFolder.Documents.Child("article.html")
Dim output As TextOutputStream
output = TextOutputStream.Create(articleFile, TextEncoding.UTF16)
output.Write(content)
output.Close

// Display the file
ArticleViewer.LoadURL(articleFile.URLPath)

Since the HTMLViewer can only display content from a URL, the code first saves the content to a file in the app’s private Documents folder and then tells the ArticleView to load the file using its URLPath.

Testing

You can run the project to test it out. If you don’t already have it, you’ll need to first install Xcode so that you have the iOS Simulator. With Xcode installed you can click the Run button on the Xojo toolbar which builds your iOS app and launches it in the iOS Simulator.

Click the Load button to load the feed…wait. It didn’t show anything did it?

It turns out that the Daring Fireball site does not yet have TLSv1.2 enabled, which iOS requires by default to access web sites. I checked with John Gruber and he said he’s been planning a server upgrade, but until he does so we have to tell iOS to accept a lower level of security for this web site.

Anyway, quit the iOS Simulator for now.

To change security settings, create a text file (using your favorite text editor) and name it Info.plist. This is the contents of the plist file:





  NSAppTransportSecurity
  
    NSExceptionDomains
    
      daringfireball.net
      
        NSIncludesSubdomains
        
        NSTemporaryExceptionAllowsInsecureHTTPLoads
        
        NSTemporaryExceptionMinimumTLSVersion
        TLSv1.0
        NSTemporaryExceptionRequiresForwardSecrecy

Now drag the text file to your Xojo JSONFeed project so that it can be incorporated into the app when it gets built.

You can now Run the JSONFeed project again. This time when you click the Load button you’ll see a list of the current Daring Fireball articles. Tap on one of the posts and a new view with the content appears. Tap the Back button to go back to the list of articles.

Related posts: JSON Feed Web App and JSON Feed Desktop App

The Ultimate Password Solution

Geoff Perlman — Thu, 04 May 2017 12:00:00 +0000

World Password Day brings attention to some simple steps everyone can take to secure their digital life: 1. Create Strong Passwords, 2. Use a different password for each account, and 3. Get a password manager, no, not a post-it note in your desk drawer!

The best password is one that is diffcult to guess. But difficult to guess takes on a new meaning when hackers use computers to do the guessing. Hence, the best password becomes one that would take a computer so long to guess that it’s not practical to do so. That means a long series of random characters and the longer and more random, the better, and a different password for every site you use.

Make Your Passwords Strong and Long

If every password you created was different set of 100 randomly-selected characters, breaking into an account would be close to impossible for a hacker. The lower-half of the ASCII character set (the most commonly used characters) is 128 characters. The number of possible passwords for a 100 character password made from randomly-selected, lower-ASCII characters would be 100 to the 128th power. That number is so large that it would take the typical PC years to find a match. But again, the problem is that users can’t even remember a handful of meaningful passwords just 10 characters long. If the average person has 50 things in their life that each need a password, how do we get them to remember 50 unique, random 100 character passwords? We don’t.

Password manager software such as the Keychain on OS X, 1Password, or Roboform that can generate these types of passwords and store them securely on the user’s device. The long, unique and random passwords can then be entered automatically so the user doesn’t have to remember them or deal with them. How do we get people to use a password database? Easy –

We don’t allow people to choose their passwords.

Stick with me here. Imagine if websites and applications that required passwords generated the them for you rather than allowing you to choose one? Hello Mr. Perlman, your password is:

KÂs-&DÂbu^ÂF|ÂUÂÂ]qÂÂÂÂ95ÂÂÂIkKXjoÂ;O6ÂuÂÂRUÂdÂ!AUÂx(IÂwÂÂ~ÂYlÂF Â#ÂÂÂÂ:8?LD$Â5tfK%P.VbT9HQi%Y[Â7a

You would have no choice but to use a password database to keep track of them. Now this might seem a bit extreme. However, requiring a password at all seemed extreme when we first started on the web. If websites and software applications generated the passwords at random, people would have no choice but to use a password database. It’s the login equivilent of a seatbelt law.

In this scenario, programs written by hackers to guess passwords become obsolete. Now you might say that the hackers will just turn their attention to hacking your password database. That’s true but that’s a much bigger problem for the hacker. They don’t want your credit card number. They want thousands of credit card numbers. Getting them one at a time, person by person, is totally impractical.

We’ve blogged about web security and passwords before. Well-designed websites don’t store your password, they store a hash of your password. When you attempt to login, they hash the password you type and compare it to the hash of the password in their database. If the two match, the site knows only that that they matched. The website still does not know your password, even if that website generated your password, because it shouldn’t be storing it. That’s what we do with user accounts at Xojo.

What would be required to implement such a thing?

First, websites and applications need to allow longer passwords. Passwords are usually stored in a database field so changing the field to allow a 100 character password is two seconds work. Next, you need to write the code to generate the random passwords. In Xojo, that code is a trival 5 lines. Ideally, the code creating the password could pass the password back to the user’s device securely so that it could be automatically stored in their password database without the user having to be involved.

Removing the user’s ability to choose their own password may seem draconian, but it would be the ultimate password solution. Existing password databases can be made to interact seemlessly with websites to store new passwords and pass them back when needed. Of course, websites need to be properly written to be secure and hosted in secure facilities. But the great thing about this solutions is that instead of hackers having to target 100,000 servers with valuable data on them, they have to attack potentially hundreds of millions of devices which is totally impractical.

And exactly how long would it take for a PC to crack that 100 character password I suggested above?

According to HowSecureIsMyPassword.net, it would take 69,003 NONAGINTILLION years to crack your password. I’m quite certain it’s long enough.

There’s No Excuse For Storing Passwords

Geoff Perlman — Thu, 04 May 2017 06:00:00 +0000

A few years ago it was reported that Russian hackers had stolen 1.2 billion usernames and passwords from a variety of websites. This was only possible because those websites were storing the actual password. Because it’s World Password Day and because this is web security 101, let’s discuss why there’s really no excuse for a website to store your password – ever.

A website that has a login only needs to store a hash of your password after you create your account (or change your password). There is never a need to store the password itself. Hashing is one-way encryption. If a website uses a good hashing algorithm, it’s completely impractical to decrypt the hash back to the original password. When you go to login to a website, the site will take the password you just entered, hash it and compare that hash to the hash created when you created your login (or last changed your password). If they match, it knows the passwords that were used to create both hashes are the same but it still doesn’t ever need to know the password itself.

We’ve blogged before about how to securely handle passwords in app development. There are simple techniques that make it easy to disassociate the password hash from the user. That way if a hacker got your database, got all the hashes and was willing to put the enormous computing resources into decrypting a specific hash for a specific user, it still would not matter because they wouldn’t know which hash belonged to which user.

Anyone responsible for the security of a website should know all this. This is web security 101. While the identities of these websites were not made public, you can bet they were sites with a lot of users. It’s hard to believe that sites with large numbers of users wouldn’t be doing these security basics.

App Transport Security for iOS

Paul Lefebvre — Wed, 27 Jul 2016 07:10:36 +0000

Last year with iOS 9, Apple announced a new security requirement for your iOS and OS X apps: App Transport Security.

From Apple’s docs:

Starting in iOS 9.0 and OS X v10.11, a new security feature called App Transport Security (ATS) is available to apps and is enabled by default. It improves the privacy and data integrity of connections between an app and web services by enforcing additional security requirements for HTTP-based networking requests. Specifically, with ATS enabled, HTTP connections must use HTTPS (RFC 2818). Attempts to connect using insecure HTTP fail. Furthermore, HTTPS requests must use best practices for secure communications.

Starting with Xojo 2016 Release 2, this change matters to you because Xojo is now using the updated Apple libraries that have this requirement. Simply stated, it means that if your iOS apps use HTTPSocket or iOSHTMLViewer, then your URLs have to be secure (https). If they are not, you will get an error returned with HTTPSocket and no page displayed in the HTMLViewer.

If you are relying on other services or URLs that do not yet support https, then what do you do? Apple has provided a workaround: you have to specify an exemption in your plist file. In the plist you identify specific URLs for which you want to allow unsecured connections. To do this, create a text file called Info.plist, add this content to it and drag the file to the Navigator to add it to your project:





  NSAppTransportSecurity
  
    NSExceptionDomains
    
      firstsite.com
      
        NSIncludesSubdomains
        
        NSTemporaryExceptionAllowsInsecureHTTPLoads
        
      
      secondsite.com
      
        NSIncludesSubdomains
        
        NSTemporaryExceptionAllowsInsecureHTTPLoads

Replace the domain names (or add more) based on your needs. You can also allow all unsecured connections, but Apple may reject App Store submissions that use this without valid reasons:

NSAppTransportSecurity

  
  NSAllowsArbitraryLoads

For additional information, refer to the Using a plist, Xojo.Net.HTTPSocket and iOSHTMLViewer pages in the docs.

Update (August 10, 2016): Apparently there is a bug in iOS that prevents the use of IP addresses in this plist. So to enable http on your local computer for testing use “localhost” rather than “127.0.0.1” and be sure to use “http://localhost” in your URLs instead of “http://127.0.0.1”.

If Smartphone Encryption Is A Red Herring, How Do We Track The Bad Guys?

Geoff Perlman — Thu, 04 Feb 2016 00:00:00 +0000

In the blog post Smartphone Encryption is a Red Herring, I pointed out the folly of requiring an encryption back door for the Good Guys to use. So the question arises- “What can be done? If we don’t want a global encryption back door that can be used by anyone, can we still track the Bad Guys?”

The answer is yes. There are plenty of options that don’t require a global back door. I’m not passing judgment on whether these are inherently good or bad options, just that they are available when there is a reason to track a Bad Guy.

Keyloggers
A keylogger is used to track everything someone types. They come in both software and hardware varieties. Once installed, they can provide regular data about passwords and other communications the Bad Guy is making. Some store the data for later retrieval, while others broadcast it on a regular basis. They exist in varieties for both computers and cell phones.

Online Man in the Middle
With proper authorization, the Good Guys can stand between the Bad Guys and common online services they might be using. Working with their internet provider, they can gather data similar to keyloggers by intercepting and relaying data back and forth.

Digital Evidence Collection
When a warrant is served and computers or mobile devices are retrieved for analysis, gathering evidence quickly is paramount. The Bad Guys may have countermeasures installed on their devices, so being able to copy data from hard drives and other storage mediums across platforms while they are still online is important. Once images of the data are created, the evidence can be safely analyzed without being concerned about time bombs or other countermeasures. Xojo has been used to create tools that are used for both digital evidence collection and analysis. Being a cross platform tool is a particular advantage in this scenario.

None of the above options require a global back door, and they can all be limited to just the Bad Guys in question when surveillance is warranted. A recently released Harvard study has similar findings. Some options are better than others depending on the region in the world and the technical prowess of the Bad Guys. Smartphone Encryption is a Red Herring, but the Good Guys have other options. We don’t need universal back doors.

Smartphone Encryption is a Red Herring

Geoff Perlman — Wed, 27 Jan 2016 00:00:00 +0000

As the Founder and CEO of a software company that makes a development tool for mobile platforms, as well as for desktop and web, I have a lot of experience with encryption. The current controversy over encryption is really important to me. During World War II, the Germans created a way of sending encrypted messages to commanders in the field. The device came to be known as an Engima machine. It looked like a typewriter but had an encryption key that changed a message into unreadable noise. That message could only be decoded if you knew the key used to encrypt it. The Allies worked very hard to get their hands on one of these devices so they could learn how it works and be able to decrypt the messages and know what the German military plans. Ultimately the Allies figured it out and it helped them win the war. If this has peaked your curiosity, check out the movie U-571 (a fictional account of the effort to obtain an Enigma machine) and The Imitation Game about the team that figured out the encryption key.

Today, terrorists are using encryption to hide their communications just like the Nazis did in WWII. What makes encryption different today is that it is also being used by millions of ordinary people, many of whom have no idea they are even using it. Almost every smartphone in use today, encrypts text messages and other data automatically. This is all done behind the scenes without the user ever being aware of it.

The type of encryption used on the iPhone and Android is called AES and it’s formidable. Intercepting your text messages isn’t actually difficult but decrypting those messages is, at best, impractical. To decrypt a message, just like with the Enigma machine, you need to know the key that was used to encrypt it. If you don’t have that key, you’d have to guess at what the key might be then look at the results of decrypting the message with that key to see if you have anything but unintelligible gibberish. Even with access to the fastest computers in the world, it could literally take years to guess the right key. It will come as no surprise that governments at almost every level don’t like this one bit. At their most transparent, they are used to getting a search warrant and being able to look at whatever you’ve got to see if it supports their suspicion that you are in fact up to no good. At their least, they wish to get on your phone (ideally from a secure, remote location) and take your data without a warrant or you having any idea they were ever there. The problem for governments is that they can’t. In Apple’s case, even if Apple was willing to compile with a request that they decrypt the data on your phone, they can’t. The key is stored on your phone in a way that even Apple can’t get to it. In this sense, Apple is in complete alignment with you in terms of your privacy.

There are lawmakers here in the United States that want to force companies like Apple and Google to provide a back door. This would be a way for Apple to get into your data should a search warrant (presumably) be issued. Apple’s CEO Tim Cook as pointed out what a bad idea this is. Back doors don’t get used by just the good guys. They will get used by the bad guys as well. In an effort to make it possible for law enforcement to get at the data of the tiny percentage of the population that is doing wrong, we would be opening everyone up to being hacked remotely. It’s not possible to make a back door that only the good guys can use. Think about your contacts, text messages, email, photos, all being exposed. Just the increased level of extortion alone would be so bad that your smartphone would go back to being useful as nothing more than a phone. Do any of you really want to go back to the 1980s?

What is worse than that, however, is what is not being talked about in the news. Smartphone encryption is a red herring. A back door wouldn’t solve the problem. Bad guys would simply write their own apps to encrypt the data themselves before they send it. This is incredibly easy to do. Xojo, the development tool my company created, has this same type of AES encryption built-in. Many other development tools have it as well. I could write an app to encrypt a message in a few minutes. Even if you have never written a line of code in your life, after a few hours learning Xojo, you could write the same app yourself. If you or I can do it, the bad guys can too. The smartest of them are almost certainly already doing this today. The end result would be that every law-abiding citizen’s personal and private data would become hackable- causing a digital tsunami of cybercrime that would be impossible for law enforcement to stop while achieving next to nothing towards actual security.

I understand why our lawmakers and law enforcement are concerned about encryption. It is a barrier to evidence for them. Tim Cook has argued that we have to balance law enforcement with our personal privacy. That’s certainly true. However, in this case, you don’t even have to go that far. What our elected officials are proposing will not work and will only create an exponentially greater problem. You may be asking yourself, “Surely they have thought of this, right?” Clearly they haven’t. Too often people make decisions without complete information or having taken sufficient time to to think the matter through. We have all seen this many times in our lives. Smartphone encryption is just the latest example. It’s not the first and won’t be the last. I’m all for looking for better ways to catch the bad guys but smartphone back doors will not work. Your elected officials are wasting your precious taxpayer dollars. If you want to stop this, contact them and ask them to better educate themselves on this topic. You can point them to this blog post to start. I can’t speak for countries outside the United States, but here elected officials give considerable weight to their constituents that reach out to them. You can contact your Representatives in the House here and your Senators here.

Lastly, while I am proud of Tim Cook for fighting back on this issue, it saddens me that he appears alone on the world stage while doing this. Powerful people in technology such as Mark Zukerberg of Facebook, Larry Page and Sergey Brin of Google, Satya Nadella of Microsoft and others should be taking an equal stand. They are in an even better position than we are as individuals to make it clear that the proposed solution won’t work. Until then, contact your elected officials and tell them that dog won’t hunt.

Security – Xojo Programming Blog

Web Apps Denial of Service

Am I affected? What do I do?

Timeline

What Happened

The Fix

What Xojo has already done for you

What you should do

If you’re on Web 2

If you’re on Web 1

Hosting-level mitigations

If your Xojo app is exposed directly to the internet

If you use DecodeURLComponent in a non-Web project

Acknowledgments

References

Code Signing on macOS: What Developers Need to Know, Part 4

What kind of macOS code signing do you want to do today?

How the Xojo IDE helps with all of this?

Developer ID – Build For

Sandboxing

Hardened Runtime

Notarization

Entitlements

Provisioning Profiles

Property List Editor

Publishing to the Mac App Store

Dealing with Certificates Issues

Backup Your Certificates

Review Pending Apple Developer Agreements

Missing and Expired Certificates

Certificates are all good… but the signing throws errors

In summary

Team-based Signing Arrives to macOS

The new approach: How it works

macOS Certificates Inspector Window

Improvements to macOS Builds and Debugged apps

Looking forward

Code Signing on macOS: What Developers Need to Know, Part 3

Entitlements and Provisioning Profiles

Entitlements

Provisioning Profiles

When Certificates and/or Provisioning Profiles expire…

Nearly Concluded

Code Signing on macOS: What Developers Need to Know, Part 2

Installing Apple Developer Intermediate Certificates

Developer Certificates: The final goal!

Creating and Installing the Developer Certificates

It’s All About Identities

Code signing With Developer Certificates

Wrapping up

Code Signing on macOS: What Developers Need to Know, Part 1

Under the hood: How “Ad-Hoc” signing works

Apple Developer Certificates: Establishing Trust on macOS

Intermediate Certificates and the Chain of Trust

Wrapping up

New WebUserAuthentication Control: Look, Mom, No Passwords!

Passkeys Demo

Other User Journeys

Multi-Factor Authentication

Usernameless + Passwordless Authentication … Wait, What?!?

How To Use The New Control

Adoption and Compatibility

Wrapping Up

macOS Apps: From Sandboxing to Notarization, The Basics

A Bit of Common Ground

Sandboxing

Hardened Runtime

Notarization

Preparation

Creating the Entitlements File

Sandbox Your App

Hardened Runtime

Notarizing the App

Creating an App-Specific Password

Adding the notarytool specific password to the Keychain

Creating a Zip file for your app

Uploading the app for Notarization

Staple the Ticket!

App Distribution

In Summary

If you use `DecodeURLComponent` in a non-Web project