@britzl
Would a PR to the extender build server repo be welcome adding cmake support?
1 Like
While we normally would accept PR’s this particular feature is not something we will support.
We cannot allow generic user scripts to run on the server.
As Britzl mentioned, the easiest way is to simple add the source to the ./src folder of your extension, and we’ll build it automatically for you. You can still set flags + defines if you need them.
If it doesn’t work, we can try to help with more information.
2 Likes
so, the main reason I ask this is because I investigated adding WebTransport/QUIC support to Defold.
however by far the biggest blocker is that all existing QUIC libraries require OpenSSL, BoringSSL, mbedTLS, or WolfSSL (etc) as a dependency.
is there a way to add a crypto library to defold without precompiling a binary?
britzl
August 4, 2026, 5:35am
44
ValorZard:
mbedTLS
mbedTLS is already included in Defold.
dev ← update-mbedtls-v3
opened 04:03PM - 23 Apr 26 UTC
We updated to MbedTls 4.1.0 to get improvements + security fixes.
One improveme… nt is support for TLS1.3, which also grows the executable a bit.
On macOS/iOS we now use native frameworks for this, allowing us to save some build size.
Here are the differences in build size:
| Platform | v2.17 | v4.1.0 | Diff |
|---|---:|---:|---:|
| iOS | 3,518,472 | 3,340,032 | -174 kb |
| Android | 4,704,056 | 4,859,792 | +152 kb |
| Wasm | 2,914,175 | 2,924,310 | +9.9 kb |
Fixes https://github.com/defold/defold/issues/9527
Fixes https://github.com/defold/defold/issues/11259
### Technical changes
We won't provide mbedtls in two different versions for a few reasons:
* They're not ABI compatible
* We'd have to supply headers for two different versions(!) in dmSDK.
* The mbedtls library is an internal detail, it may be replaced with something else.
* We now aren't using mbedtls on all platforms (macos, ios)
Instead, we use `rename defines` to make our symbols not clash with a users custom version.
In the future, we may well not need mbedtls for our own socket implementation, if we redesign things to use Android native apis.
On darwin, build with `--enable-feature=mbedtls` to force build with MbedTls for easier testing.
As the size increase is relatively large for Android, some easy-to-do improvements were made.
However, some suggested improvements were left for future.
In particular, being able to use a fully native implementation might be a thing, but that also requires a big rewrite.
Eventually, we should be able to remove TLS 1.2 support as well (only saves ~24kb. I.e result is +120kb)
| Improvement | Likely win | Risk |
|---|---:|---|
| Disable unused PSA storage/ITS | Small/medium | Low if no persistent PSA keys |
| Remove write/parse source files from mbedtls_dirs once config disables them | Small | Low, but must avoid fighting
upstream layout |
| Remove MBEDTLS_DEBUG_C in release/profile builds | Small | Low |
| Disable CBC/TLS 1.2 legacy cipher support | Medium | Medium; can break older HTTPS endpoints |
| Remove ARIA/Camellia/CCM source paths too | Small/medium | Medium; config may already make most empty |
| Curated ciphersuite list | Medium | Medium; compatibility-sensitive |
| Drop TLS 1.2 entirely | Large | High; not recommended |
| Android native TLS backend | Large | High engineering cost |
Summary of changes:
The current Mbed TLS 4.1.0 profile is at least on par with the Mbed TLS 2.17 usage Defold exposes through `sslsocket_mbedtls.cpp` for common HTTPS client cases, and it adds TLS 1.3 support.
It is not strict config parity with the broad 2.17 default profile. The current profile intentionally removes unused or legacy functionality such as DTLS, server TLS, PSK-only handshakes, uncommon curves, persistent PSA storage, and X.509 write/CSR/CRL functionality.
## Common Client Feature Comparison
| Capability | Mbed TLS 2.17 | Current Mbed TLS 4.1.0 |
|---|---:|---:|
| TLS client | yes | yes |
| TLS 1.2 | yes | yes |
| TLS 1.3 | no | yes |
| ECDHE-RSA | yes | yes |
| ECDHE-ECDSA | yes | yes |
| TLS 1.3 ECDHE | no | yes |
| TLS session tickets | yes | yes |
| TLS 1.3 PSK+ECDHE resumption | no | yes |
| X.509 certificate parsing | yes | yes |
| X.509 certificate verification | yes | yes |
| RSA certificate support | yes | yes |
| ECDSA certificate support | yes | yes |
| AES-GCM | yes | yes |
| ChaCha20-Poly1305 | yes | yes |
| AES-CCM | yes | yes |
| SHA-1/SHA-256/SHA-384/SHA-512 | yes | yes |
| MD5 for `dmCrypt` compatibility | yes | yes |
| Base64 for `dmCrypt` compatibility | yes | yes |
## Current TLS 1.3 Support
The current TLS 1.3 support is a good modern HTTPS client profile:
| TLS 1.3 Feature | Current State |
|---|---:|
| `MBEDTLS_SSL_PROTO_TLS1_3` | enabled |
| `MBEDTLS_SSL_TLS1_3_COMPATIBILITY_MODE` | enabled |
| `MBEDTLS_SSL_TLS1_3_KEY_EXCHANGE_MODE_EPHEMERAL_ENABLED` | enabled |
| `MBEDTLS_SSL_SESSION_TICKETS` | enabled |
| `MBEDTLS_SSL_TLS1_3_KEY_EXCHANGE_MODE_PSK_EPHEMERAL_ENABLED` | enabled |
| `MBEDTLS_SSL_TLS1_3_KEY_EXCHANGE_MODE_PSK_ENABLED` | disabled |
| `MBEDTLS_SSL_TICKET_C` | disabled |
This means TLS 1.3 supports certificate-authenticated ephemeral handshakes and ticket-based resumption with PSK+ECDHE. Pure PSK remains disabled, and the server-side ticket callback implementation remains disabled.
## PR checklist
* [ ] Code
* [ ] Add engine and/or editor unit tests.
* [ ] New and changed code follows the overall code style of existing code
* [ ] Add comments where needed
* [ ] Documentation
* [ ] Make sure that API documentation is updated in code comments
* [ ] Make sure that manuals are updated (in github.com/defold/doc)
* [ ] Prepare pull request and affected issue for automatic release notes generator
* [ ] Pull request - Write a message that explains what this pull request does. What was the problem? How was it solved? What are the changes to APIs or the new APIs introduced? This message will be used in the generated release notes. Make sure it is well written and understandable for a user of Defold.
* [ ] Pull request - Write a pull request title that in a sentence summarises what the pull request does. Do not include "Issue-1234 ..." in the title. This text will be used in the generated release notes.
* [ ] Pull request - Link the pull request to the issue(s) it is closing. Use on of the [approved closing keywords](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue).
* [ ] Affected issue - Assign the issue to a project. Do not assign the pull request to a project if there is an issue which the pull request closes.
* [ ] Affected issue - Assign the "breaking change" label to the issue if introducing a breaking change.
* [ ] Affected issue - Assign the "skip release notes" is the issue should not be included in the generated release notes.
----------
Example of a well written PR description:
1. Start with the user facing changes. This will end up in the release notes.
1. Add one of the GitHub approved closing keywords
1. Optionally also add the technical changes made. This is information that might help the reviewer. It will not show up in the release notes. Technical changes are identified by a line starting with one of these:
1. `### Technical changes`
1. `Technical changes:`
2. `Technical notes:`
```
There was a anomaly in the carbon chroniton propeller, introduced in version 8.10.2. This fix will make sure to reset the phaser collector on application startup.
Fixes #1234
### Technical changes
* Pay special attention to line 23 of phaser_collector.clj as it contains some interesting optimizations
* The propeller code was not taking into account a negative phase.
```
Note that it is an internal detail.
While I don’t believe we’ll replace it anytime soon, we need to reserve the rights to doing so, and it will break. Also, more importantly, our mbedtls have a “renamed” api, so that it doesn’t clash with other user’s implementations of mbedTLS.
I’d recommend creating a separate extension for mbedTLS or OpenSSL, with precompiled libraries.
I have experienced instances where some ParticleFX components arent being set off when they should
I have reported the issue on github
opened 09:24AM - 11 Aug 26 UTC
triage
### Expected behaviour
Particles are set off when expected
### Actual behaviour…
In some instances, particles arent set off when they should.
### Steps to reproduce
1. Create a particlefx component and adjust playback settings (Duration, lifetime etc)
2. Attach the particlefx component and a script to a game object
3. Set off the particlefx component by either within the init(self) function or a message sent from another url
4. Sometimes the particles arent set off and sometimes they are
<hr/>
<table>
<tr><td>Build time</td><td>2026-08-10T21:23:54.048347</td></tr>
<tr><td>Defold channel</td><td>beta</td></tr>
<tr><td>Defold editor sha</td><td>5e46d032319c549fc024b1fedf9a21fd008348c6</td></tr>
<tr><td>Defold engine sha</td><td>5e46d032319c549fc024b1fedf9a21fd008348c6</td></tr>
<tr><td>Defold version</td><td>1.13.1</td></tr>
<tr><td>GPU</td><td>Mesa Intel(R) HD Graphics 4000 (IVB GT2)</td></tr>
<tr><td>GPU Driver</td><td>4.2 (Compatibility Profile) Mesa 26.1.6</td></tr>
<tr><td>Java version</td><td>25+36-LTS</td></tr>
<tr><td>OS arch</td><td>amd64</td></tr>
<tr><td>OS name</td><td>Linux</td></tr>
<tr><td>OS version</td><td>7.1.8-200.fc44.x86_64</td></tr>
<table>
More Information:
I have been using Defold 1.13.1 BETA for a while now and I noticed this within 2 projects.
In both of them, there are instances where particles should be set off, but aren't.
In one of the projects, there are 2 collections where the same particlefx component and script (used across all collections) do not set off and the fix is as simple as navigating to other collections and then heading back to the collections where they werent being set off before and now they are working.
The script is as simple as function init(self) particlefx.play("#star1") end
In the other project, there is a collection with 2 collisions objects (Spikes; Same Collision Group) and when a ball game object interacts with them, they should set off some particles but it only does with one of the collision objects.
It was working (The 2nd Project) initially with an older Defold 1.13.1 Beta version, but at the same time, I can reproduce the same issue in Defold 1.13.0 in the former project
I only have video clips to showcase the issue. I can provide zip projects to help investigate the issue further, but only through emails; not here.
This is proof showing that in project 2, the particlefx component was being set off properly in the middle spike button
https://bsky.app/profile/oneredeyedev.bsky.social/post/3mrfy7rquus2m
These are the video clips:
https://github.com/user-attachments/assets/89048203-1b93-46af-8f25-6c75a05e69ac
https://github.com/user-attachments/assets/0a595cd5-79b8-4632-965e-d248652c3432
Just to confirm, you could reproduce it in 1.13.0?
(so it’s not an actual beta issue?)
1 Like
Apologies, I discovered a workaround and an error in both projects.
Closed the issue with this comment:
opened 09:24AM - 11 Aug 26 UTC
closed 08:40AM - 12 Aug 26 UTC
triage
### Expected behaviour
Particles are set off when expected
### Actual behaviour…
In some instances, particles arent set off when they should.
### Steps to reproduce
1. Create a particlefx component and adjust playback settings (Duration, lifetime etc)
2. Attach the particlefx component and a script to a game object
3. Set off the particlefx component by either within the init(self) function or a message sent from another url
4. Sometimes the particles arent set off and sometimes they are
<hr/>
<table>
<tr><td>Build time</td><td>2026-08-10T21:23:54.048347</td></tr>
<tr><td>Defold channel</td><td>beta</td></tr>
<tr><td>Defold editor sha</td><td>5e46d032319c549fc024b1fedf9a21fd008348c6</td></tr>
<tr><td>Defold engine sha</td><td>5e46d032319c549fc024b1fedf9a21fd008348c6</td></tr>
<tr><td>Defold version</td><td>1.13.1</td></tr>
<tr><td>GPU</td><td>Mesa Intel(R) HD Graphics 4000 (IVB GT2)</td></tr>
<tr><td>GPU Driver</td><td>4.2 (Compatibility Profile) Mesa 26.1.6</td></tr>
<tr><td>Java version</td><td>25+36-LTS</td></tr>
<tr><td>OS arch</td><td>amd64</td></tr>
<tr><td>OS name</td><td>Linux</td></tr>
<tr><td>OS version</td><td>7.1.8-200.fc44.x86_64</td></tr>
<table>
More Information:
I have been using Defold 1.13.1 BETA for a while now and I noticed this within 2 projects.
In both of them, there are instances where particles should be set off, but aren't.
In one of the projects, there are 2 collections where the same particlefx component and script (used across all collections) do not set off and the fix is as simple as navigating to other collections and then heading back to the collections where they werent being set off before and now they are working.
The script is as simple as function init(self) particlefx.play("#star1") end
In the other project, there is a collection with 2 collisions objects (Spikes; Same Collision Group) and when a ball game object interacts with them, they should set off some particles but it only does with one of the collision objects.
It was working (The 2nd Project) initially with an older Defold 1.13.1 Beta version, but at the same time, I can reproduce the same issue in Defold 1.13.0 in the former project
I only have video clips to showcase the issue. I can provide zip projects to help investigate the issue further, but only through emails; not here.
This is proof showing that in project 2, the particlefx component was being set off properly in the middle spike button
https://bsky.app/profile/oneredeyedev.bsky.social/post/3mrfy7rquus2m
These are the video clips:
https://github.com/user-attachments/assets/89048203-1b93-46af-8f25-6c75a05e69ac
https://github.com/user-attachments/assets/0a595cd5-79b8-4632-965e-d248652c3432