[{"author":"damonbarry","date":"2026-04-16T23:58:40+00:00","message":"Remove longhaul tests (#7502)\n\nThis change removes the long haul and nested long haul test pipelines, and supporting scripts and code, which have not been used for a while and have fallen into disrepair.\n\nTo test, I ensured the surrounding pipelines still pass and are not adversely impacted:\n- Build CI\n- End-to-end tests\n- Nested end-to-end tests\n- ISA95 smoke tests\n\nNote that the Connectivity test pipeline is also affected by these changes, but is currently undergoing major changes of its own (converting to federated identities to communicate with IoT Hub and Event Hub) so it couldn't be tested here. There is a separate effort to ensure that it runs and passes.\n\n## Azure IoT Edge PR checklist:","sha":"8f43dc6f6d2c6b09a8ec68d91846eede4e7838cb","url":"https://github.com/Azure/iotedge/commit/8f43dc6f6d2c6b09a8ec68d91846eede4e7838cb"},{"author":"damonbarry","date":"2025-08-26T18:29:44+00:00","message":"Document UseOfflineCheck in EnvironmentVariables.md (#7469)\n\n@vipeller recently merged a change that adds a new environment variable to Edge Agent. This change adds the missed documentation.\n\nThis change also does minor formatting of the tables in the markdown file, and replaces \"EdgeAgent\" and \"EdgeHub\" with \"Edge Agent\" and \"Edge Hub\" for consistency.\n\n## Azure IoT Edge PR checklist:","sha":"8d74df08f6d07aa5babdecc364f34b3e2e746022","url":"https://github.com/Azure/iotedge/commit/8d74df08f6d07aa5babdecc364f34b3e2e746022"},{"author":"kevin-vitro","date":"2025-08-07T19:44:53+00:00","message":"Update IPv6Configuration Doc for config.toml (#7445)\n\nUpdated documentation pertaining to IPv6 usage with the newer config.toml setup. Addresses https://github.com/Azure/iotedge/issues/7419\n\n## Azure IoT Edge PR checklist:","sha":"d8e7dd9e00f026a777d2162df3c9fe0582216301","url":"https://github.com/Azure/iotedge/commit/d8e7dd9e00f026a777d2162df3c9fe0582216301"},{"author":"nyanzebra","date":"2025-06-11T23:10:44+00:00","message":"Infinite timeout for throttled requests (#7440)\n\n* retryable timeout for throttled requests\n\n* infinite timeout on semaphore\n\n* remove bool and exception\n\n* use new ModuleRequestThrottleTimeout env var\n\n* pass new param to test module\n\n* lower to 240s\n\n* convert to millis later\n\n* fix var spelling\n\n* don't multiply if < 0\n\n* add blank line after if block\n\n* standardize timeout naming\n\n* fmt\n\n* Update edgeagent env var table\n\n* explain range of acceptable values\n\n* add warning\n\n---------\n\nCo-authored-by: Robert jang <rojang@microsoft.com>","sha":"f219589cb505fee044781158e570e0871b03f137","url":"https://github.com/Azure/iotedge/commit/f219589cb505fee044781158e570e0871b03f137"},{"author":"sush-101","date":"2025-03-28T17:32:36+00:00","message":"Fix usage of unapproved padding schemes for RSA signing (#7427)\n\nThe CodeQL query detected a call to an RSA signing method using an unapproved padding scheme on line 28 of the ClientAssertionCertificate.cs file. As per the guidelines, the only permitted padding for RSA signing is System.Security.Cryptography.RSASignaturePadding.Pss. More details can be found in the guide:\n[CodeQL.SM03799 - Scanning Tool Warnings](https://liquid.microsoft.com/Web/Object/Read/ScanningToolWarnings/Requirements/CodeQL.SM03799#Zguide).\n\n## Azure IoT Edge PR checklist:","sha":"8f9abc7a920a7a7ac292c4db13ee7c2649fa6d27","url":"https://github.com/Azure/iotedge/commit/8f9abc7a920a7a7ac292c4db13ee7c2649fa6d27"},{"author":"vadim-kovalyov","date":"2024-09-23T23:37:47+00:00","message":"Updated docs for MessageCleanupIntervalSecs env var to clarify TTL vs MessageCleanupIntervalSecs behaviour. (#7314)\n\nUpdated docs for MessageCleanupIntervalSecs env var to clarify TTL vs MessageCleanupIntervalSecs behaviour.\n\n## Azure IoT Edge PR checklist:","sha":"b008102e9ff8ce4cefcb8b4a92a7255524b61cee","url":"https://github.com/Azure/iotedge/commit/b008102e9ff8ce4cefcb8b4a92a7255524b61cee"},{"author":"vadim-kovalyov","date":"2024-09-05T21:50:47+00:00","message":"Add an event listener to log SDK events.  (#7320)\n\n- This PR adds an event listener to log SDK events. The event listener is guarded by the env var and otherwise should have no effect.\n- Also this PR fixes the devguide to specify .net 8.\n\nLocal testing is in progress...\n\n## Azure IoT Edge PR checklist:","sha":"3557a2201bee4368b4e71713a45eb11367237795","url":"https://github.com/Azure/iotedge/commit/3557a2201bee4368b4e71713a45eb11367237795"},{"author":"damonbarry","date":"2024-04-12T00:03:54+00:00","message":"Upgrade to .NET 8 + latest LTS of IoT SDKs (#7262)\n\nIn preparation for v1.5, this change updates our C# code to .NET 8.0. It also updates our dependency on the IoT SDKs to the latest LTS versions (Microsoft.Azure.Devices.Client 1.36.10, Microsoft.Azure.Devices 1.31.6).\n\nI had to upgrade our dependency on Azure.Storage.Blobs because the device SDK upgraded theirs. This required that I upgrade the code in Edge Agent and some test modules to use newer storage blob libraries that aren't deprecated. I did local testing of the Edge Agent code to ensure that the new calls work as expected.\n\nI updated the buildBranch.sh and runTests.sh scripts. buildBranch.sh was building two different ways: (1) it was doing a standard build of all .NET components from the repo root (`dotnet build -c Release`), and (2) it was publishing each \"app\" in a manner suitable for including in Docker images. I simplified it to just focus on the second scenario. For the first, I updated dotnet.yaml to call `dotnet test` directly. I simplified runTests.sh to use `dotnet test` instead of `dotnet vstest` (which is being deprecated) because `dotnet test` now supports running pre-built binaries instead of always building the binaries itself. Note that `dotnet test` apparently doesn't support some of the parallelization features that vstest did, but the time difference is minimal and the script logic is vastly simplified.\n\nI updated EdgeHubTriggerCsharp.csproj to specify its own TargetFramework property, rather than including netcoreappVersion.props, because it has dependedencies that don't yet support .NET 8.\n\nI successfully ran the CI Build pipeline with these changes. To test, I ran the end-to-end tests, nested end-to-end tests, connectivity tests, and ISA-95 smoke tests against the new bits.\n\n## Azure IoT Edge PR checklist:","sha":"7508ffc6ab9f4d52a3243d0cdce1e52cdfd29912","url":"https://github.com/Azure/iotedge/commit/7508ffc6ab9f4d52a3243d0cdce1e52cdfd29912"},{"author":"damonbarry","date":"2024-03-19T21:34:57+00:00","message":"Fix identity cleanup (#7244)\n\nCherry-pick 3bac80274305c7f2d4af92c161bead2c486d6820","sha":"bfb6d2f872571021314a13c0a6926969dd56ce00","url":"https://github.com/Azure/iotedge/commit/bfb6d2f872571021314a13c0a6926969dd56ce00"},{"author":"gordonwang0","date":"2023-12-11T19:59:21+00:00","message":"Add TLS 1.3 support and remove TLS 1.0 and 1.1 support in edgeHub (#7173)\n\n- Updates .NET Standard modules to .NET 6 (required for TLS 1.3 support)\n- Removes support for TLS 1.0 and 1.1 and adds support for TLS 1.3. The default setting for edgeHub is to enable both TLS 1.2 and 1.3.\n- Removes the unused `min_tls_version` setting from aziot-edged.\n\nAlthough removing TLS 1.0 and 1.1 is a breaking change for users, these versions are deprecated everywhere and should be removed. Furthermore, current versions of edgeHub already do not support TLS 1.0/1.1 due to being built against a version of openssl that disables TLS 1.0/1.1 support, so in reality edgeHub has already dropped support for TLS 1.0/1.1.","sha":"891d701a825a633461d1bebf85dc7404150dd2e9","url":"https://github.com/Azure/iotedge/commit/891d701a825a633461d1bebf85dc7404150dd2e9"},{"author":"damonbarry","date":"2023-11-22T20:10:30+00:00","message":"Remove Ubuntu 18.04 support (#7143)\n\nUbuntu 18.04 went out of support in May 2023. This change updates our build/release pipelines so that they won't produce Ubuntu 18.04 packages. It also removes Ubuntu 18.04 references generally.\n\n_Note:_ We can merge this change to main at any point, but we shouldn't make this change in the release/1.4 branch until after November 30, 2023, which is when we documented that we'll stop producing Ubuntu 18.04 packages.\n\nTo test, I ran the CI Build pipeline to confirm that 18.04 packages are not built. Then I ran the end-to-end, nested end-to-end, and ISA-95 smoke test pipelines, and confirmed they run and pass.\n\n## Azure IoT Edge PR checklist:","sha":"7b3f617da35779b2fe44c0286628875ac661e6f9","url":"https://github.com/Azure/iotedge/commit/7b3f617da35779b2fe44c0286628875ac661e6f9"},{"author":"PatAltimore","date":"2023-11-08T22:49:09+00:00","message":"Add how to set Edge Agent and Edge Server environment variables steps (#7083)\n\nWe are missing instructions on how to set environment variables for Edge Agent and Edge Hub. PR adds portal instructions and link to docs for more information about deployment manifests. The instructions improve the reference link in IoT Edge documentation table of contents and this PR  https://github.com/MicrosoftDocs/azure-docs-pr/pull/248363\n\n## Azure IoT Edge PR checklist:","sha":"cc8eeea758f4a99c0f9941f5a48175372fe44b81","url":"https://github.com/Azure/iotedge/commit/cc8eeea758f4a99c0f9941f5a48175372fe44b81"},{"author":"varunpuranik","date":"2023-04-10T18:35:13+00:00","message":"Add support for MaxCheckCertExpiryInMs (#6938)\n\nAdd a flag in EdgeHub for the interval after which EdgeHub will check for server cert expiry.\n\nManual tests done: \n- Configured device to not use NTP, but set the correct time\n- Configured IoT Edge to have a delayed start. \n- Deployed EdgeHub with MaxCheckCertExpiryInMs=120s. \n- Also deployed SimulatedTemperatureSensor\n- Started IoT Edge. EdgeAgent, EdgeHub, SimulatedTemperatureSensor came up and was working fine. \n- Restarted device\n- When device restarted, set the time to 2018, before IoT Edge started. \n- IoT Edge started, and EdgeHub came up. The server cert it obtained had an expiry date in 2018. \n- Set the correct time to 2023. EdgeHub detected the expired cert in 120s, and restarted, got the correct cert. \n- Simulated temperature sensor was able to continue.","sha":"c3e5f4c3727647f1cae78e2761d1fcfba571fc97","url":"https://github.com/Azure/iotedge/commit/c3e5f4c3727647f1cae78e2761d1fcfba571fc97"},{"author":"damonbarry","date":"2023-04-04T17:40:47+00:00","message":"Align to pre-1.4.9 Docker image structure (#6939)\n\nWe ship six IoT Edge modules as Docker images: Edge Agent, Edge Hub, API Proxy (for nested edge scenarios), Metrics Collector, simulated temperature sensor (a sample), and Diagnostics (not really a module, used internally by the `iotedge check` command). We also maintain a number of images internally as test modules. Until recently, the structure of our Docker images looked like this:\n\n```\n               1.x.x-linux-<arch>\n                 +-----------+\n                 |  linux/   |\n               +-|   amd64   |\n               | |[BuildInfo]|\n               | +-----------+\n     1.x.x     | \n   +--------+  | +-----------+\n   | Multi- |  | |  linux/   |\n   |platform|--+-|   arm64   |\n   |        |  | |[BuildInfo]|\n   +--------+  | +-----------+\n               |\n               | +-----------+\n               | |  linux/   |\n               +-|  arm/v7   |\n                 |[BuildInfo]|\n                 +-----------+\n```\n\nThe \"BuildInfo\" metadata embedded in the platform-specific images was added more recently. It contained information about the base image to help us detect when a newer version becomes available.\n\nDocker recently replaced the BuildInfo metadata with [provenance attestations](https://docs.docker.com/build/attestations/slsa-provenance/). We updated our builds to begin generating and consuming provenance attestations (#6878, #6922) and, using the recommended docker tooling (specifically, `buildx imagetools create`), it modified the structure of our images:\n\n```\n                                    +-------------+\n            1.x.x-linux-<arch>   +--| linux/amd64 |\n                 +--------+      |  +-------------+\n                 | Multi- |------+\n               +-|platform|      |  +-------------+\n               | |        |      +--| Provenance  |\n               | +--------+         +-------------+\n               |                \n     1.x.x     |                    +-------------+\n   +--------+  | +--------+      +--| linux/arm64 |\n   | Multi- |  | | Multi- |      |  +-------------+\n   |platform|--+-|platform|------+\n   |        |  | |        |      |  +-------------+\n   +--------+  | +--------+      +--| Provenance  |\n               |                    +-------------+\n               |                \n               | +--------+         +-------------+\n               | | Multi- |      +--| linux/arm64 |\n               +-|platform|      |  +-------------+\n                 |        |------+\n                 +--------+      |  +-------------+\n                                 +--| Provenance  |\n                                    +-------------+\n```\n\nWhile the change should be transparent to users, it could potentially present a problem if people are relying on specific details of our image structure in their pipelines. We haven't seen any evidence of this, but we did run into some minor problems with our internal tooling for publishing images to mcr.microsoft.com.\n\nCrafting our images more carefully to give us a structure that (1) supports the new provenance attestations and (2) more closely resembles the original structure will provide the most seamless experience. This change updates our build pipelines to produce images with the following structure:\n\n```\n            1.x.x-linux-<arch>\n                 +--------+\n                 | linux/ |\n               +-|  amd64 |\n               | |        |\n               | +--------+  +------------+\n               +-------------| Provenance |\n     1.x.x     |             +------------+\n   +--------+  | +--------+\n   | Multi- |  | | linux/ |\n   |platform|--+-|  arm64 |\n   |        |  | |        |\n   +--------+  | +--------+  +------------+\n               +-------------| Provenance |\n               |             +------------+\n               | +--------+\n               | | linux/ |\n               +-| arm/v7 |\n               | |        |\n               | +--------+  +------------+\n               +-------------| Provenance |\n                             +------------+\n```\n\nTo test, I ran my changes through the CI Build pipeline and confirmed that the resulting images passed the end-to-end tests.\n\nI also set up the release pipelines in a test environment, and confirmed that the pipelines run and produce the expected images:\n- Metrics Collector stage/publish\n- API Proxy stage/publish\n- Core images stage/publish\n- Metrics Collector auto-refresh\n- Core images auto-refresh","sha":"9bfe28ec823c4248f37d3a55541dab6abcbdee94","url":"https://github.com/Azure/iotedge/commit/9bfe28ec823c4248f37d3a55541dab6abcbdee94"},{"author":"damonbarry","date":"2023-02-03T18:36:13+00:00","message":"Update Docker image builds to use newer tooling (#6878)\n\nDocker recently introduced [provenance attestation](https://docs.docker.com/build/attestations/slsa-provenance/) in buildx 0.10.0, which broke our multi-arch image builds. To build our multi-arch manifests, we use a really old tool that isn't compatible with the buildx changes. To work around the problem, we disabled provenance attestation in our builds (see f82a7d94f37a795ce908c67dca8192e626b38788).\n\nWith this change, we re-enable provenance attestation and upgrade our multi-arch build tooling to support it.\n\nI also took this opportunity to refactor our Dockerfiles into a single Dockerfile per module except API Proxy (which structures its x64 and arm images very differently). I initially did this refactoring because I planned to upgrade our pipelines/scripts to the canonical method for building Docker images: passing a comma-separated list of platforms to `docker buildx build` and letting it build the images _and_ the multi-arch manifest at once. This method would have required a single Dockerfile for all architectures. However, since we provide per-architecture tags for our images, it ended up being easier to keep our current pattern (build each single-arch image, then create the multi-arch manifest separately) and just upgrade the tools.\n\nOther changes:\n- In cases where I was already updating a pipeline script task (e.g., to add/change a parameter passed to a script), I converted the task syntax to use the newer 'script' alias for consistency with other pipelines.\n- In our API Proxy pipelines, there were three different places where we installed qemu and binfmt to prepare for cross-compiling the code, but the agent already has those installed so I removed it.\n- Also in our API Proxy pipelines, there was a place where we did some docker buildx setup even though the job doesn't use docker buildx. Maybe it used to? Anyway, I removed the setup task.\n- Removed the explicit bin_dir argument from all image-linux.yaml calls, since it is redundant with that parameter's default value.\n- Deleted all manifest.yaml.template files, since they were required for the old manifest tool and are no longer used.\n- In some of our release pipelines we have a default value for the 'tags' parameter that is given in not-quite-JSON format (an array with a single string value in _single_ quotes). I changed it to valid JSON so I can use jq to merge it with other tags when building the multi-arch image.\n- Removed the unused '--postfix' parameter from buildRocksDb.sh.\n- Removed the redundant and misnamed '--image-name' parameter from buildApiProxy.sh.\n- Cleaned up script variables and args parsing for consistency, and in a few cases to fix minor bugs.\n\nTo test, I ran the CI build, which exercises the key YAML templates and all the scripts. I also ran the end-to-end tests and nested end-to-end tests to verify that the images still work as expected.\n\n## Azure IoT Edge PR checklist:","sha":"e6fc2eef095ea03253c388789b93442ca79d1718","url":"https://github.com/Azure/iotedge/commit/e6fc2eef095ea03253c388789b93442ca79d1718"},{"author":"ancaantochi","date":"2022-11-30T17:21:19+00:00","message":"configurable management api timeout (#6797)\n\n* set httpclient timeout 1.4 (#6773)\n* Update env var","sha":"1c026cc241f2dbc818050434808afcd54c80359d","url":"https://github.com/Azure/iotedge/commit/1c026cc241f2dbc818050434808afcd54c80359d"},{"author":"micahl","date":"2022-08-16T21:17:44+00:00","message":"Document the DisableDeviceAnalyticsMetadata option (#6597)\n\n## Azure IoT Edge PR checklist:","sha":"9e7e40e2688f08162a431c82e2fad9dfcecfb94f","url":"https://github.com/Azure/iotedge/commit/9e7e40e2688f08162a431c82e2fad9dfcecfb94f"},{"author":"and-rewsmith","date":"2022-07-21T01:41:21+00:00","message":"Edge Agent: Support feature flag `ModuleUpdateMode` (#6508)","sha":"303b3fdcc065c5f6e2e8087e4f92baaafb03b85a","url":"https://github.com/Azure/iotedge/commit/303b3fdcc065c5f6e2e8087e4f92baaafb03b85a"},{"author":"damonbarry","date":"2022-06-16T04:58:38+00:00","message":"Remove experimental mqtt broker code (#6410)\n\nThis change removes `edge-hub/watchdog`  and most of `mqtt/` from the codebase and removes the experimental feature flag in Edge Hub. It also removes the test module `generic-mqtt-tester`, which is no longer needed. Finally, it removes several unused build/test pipelines, most of which were related to the broker.\n\nTo test, I ran the following pipelines:\n- Build Images\n- Edgelet Packages (pretty sure this one was unnecessary)\n- Single-node End-to-end\n- Single-node Connectivity\n- Nested End-to-end\n\n## Azure IoT Edge PR checklist:","sha":"85084e4f04aafbd7b68931e80d3c84f28eb47585","url":"https://github.com/Azure/iotedge/commit/85084e4f04aafbd7b68931e80d3c84f28eb47585"},{"author":"vipeller","date":"2022-06-14T02:20:53+00:00","message":"Turning of batching for incoming amqp messages to gain faster feedback to the sender (#6441)\n\ncherry pick of:\n\nTurning of batching for incoming amqp messages to gain faster feedback to the sender #4765","sha":"5667c58ce0a70f47026efa87fabf29b3ef92c9c1","url":"https://github.com/Azure/iotedge/commit/5667c58ce0a70f47026efa87fabf29b3ef92c9c1"}]