Plan for changes: Azure Sphere February release - Part 2
Published Jan 09 2020 03:05 PM 1,926 Views
Steel Contributor

This is the second in a series of posts about changes coming in the February release of Azure Sphere.

 

As we mentioned previously, we are making a number of enhancements to our OS and SDK to further strengthen the security of devices at customer sites and ensure supportability from GA onward. Although our goal is to avoid the introduction of breaking changes and incompatibility between releases, our transition from Public Preview to the General Availability (GA) release requires several important updates. In a few situations, you will need to make changes to ensure your devices and applications continue to work as intended. Thank you very much for your support in Public Preview and for helping us deliver a great GA product.

 

Tighter security for deployed devices

 

Starting with the February release, connected device manufacturers and OEMs can disable computer-to-device communications over USB to prevent malicious use by those who have physical access to the device.

 

Disabling such access is part of device finalization. Finalization is typically performed on the factory floor before the manufacturer ships the device to an end user site, but some dev kit manufacturers may finalize devices as well. After finalization, a user will be able to get the device ID over a USB connection. All other operations require a device capability.

 

Field support technicians who need USB communications for set-up and servicing can use the new fieldServicing capability. This capability provides temporary access over USB. See Upcoming Changes for details. For application developers, the azsphere device enable-development command (which applies the appDevelopment capability) will continue to work as in preview releases.

 

Removal of default CA certificates

 

Preview releases of Azure Sphere included several CA certificates for use in authenticating HTTPS servers, and the cURL library was configured to look for these certificates on the device. To provide a more sustainable security environment, the Azure Sphere OS will no longer contain these certificates starting with the February release.

 

Applications that rely on the presence of one or more of these default certificates will require changes. To authenticate a server, you’ll need to add the required certificate to the application image package. For details, see Server Authentication.

 

Deprecation of support for Visual Studio 2017

 

Development of Azure Sphere applications with Visual Studio 2017 will no longer be supported starting with the February release. We released support for Visual Studio Code and Linux in the fall of 2019, and we continue to support Visual Studio 2019, which provides enhanced support for CMake.

On Windows, you can compile, build, and debug Azure Sphere apps with Visual Studio 2019, Visual Studio Code, or on the command line.

 

On Linux, you can compile, build, and debug Azure Sphere apps with Visual Studio Code, or on the command line.

 

Verify your apps with the Retail Evaluation OS feed

 

When the GA release of the OS is ready, we will make it available on the Retail Evaluation OS feed at least 14 calendar days before it is released to the Retail OS feed. Please plan to verify your scenarios against the OS; this is the best way to ensure compatibility with the forthcoming OS before its Retail release. Be aware that you might need to modify your procedures or applications.

 

We will provide additional information about upcoming changes through the IoT Blog on Tech Community and in the Azure Sphere online documentation as GA nears and we develop detailed guidance.

Version history
Last update:
‎Jan 09 2020 03:03 PM
Updated by: