# CMake-internal CURL\_DISABLE\_HSTS ON

**URL:** https://discourse.cmake.org/t/cmake-internal-curl-disable-hsts-on/8917
**Category:** Development
**Created:** [September 12, 2023, 7:07pm UTC](https://discourse.cmake.org/t/cmake-internal-curl-disable-hsts-on/8917 "2023-09-12T19:07:04Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![scivision](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/s/a87d85/32.png) [@scivision](https://discourse.cmake.org/u/scivision)
#### Post date: [September 12, 2023, 7:07pm UTC](https://discourse.cmake.org/t/cmake-internal-curl-disable-hsts-on/8917/1 "2023-09-12T19:07:05Z")

</div>

I was looking at CMake’s [Utilities/cmcurl/CMakeLists.txt](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Utilities/cmcurl/CMakeLists.txt?ref_type=heads)  
and noticed `set(CURL_DISABLE_HSTS ON)` while Curl’s general default is OFF.

Basically, I’m wanting to be sure that CMake default is to use Curl with HSTS for security benefits.

I made this test that appears to show that CMake internal Curl is NOT HSTS promoting to HTTPS.

> <https://gist.github.com/scivision/99a4cb17279c6278d7be022ffbdfce16>

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [September 13, 2023, 2:47am UTC](https://discourse.cmake.org/t/cmake-internal-curl-disable-hsts-on/8917/2 "2023-09-13T02:47:29Z")

</div>

It was added in [this MR](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6168) without comment. @brad.king, was this just a goof on the default or was there a reason beyond “seemed like a more secure default”?

---

<div class="post-metadata">

### Author: ![scivision](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/s/a87d85/32.png) [@scivision](https://discourse.cmake.org/u/scivision)
#### Post date: [September 13, 2023, 12:34pm UTC](https://discourse.cmake.org/t/cmake-internal-curl-disable-hsts-on/8917/3 "2023-09-13T12:34:54Z")

</div>

Yeah, what I’m saying is that the way CMake sets/overrides it looks like CMake internally is trying to disable HSTS, even though it ends up being built with HSTS.

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [September 13, 2023, 2:32pm UTC](https://discourse.cmake.org/t/cmake-internal-curl-disable-hsts-on/8917/4 "2023-09-13T14:32:38Z")

</div>

It was not intentionally left off. [CMake MR 8801](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8801) enables it now.

---

<div class="post-metadata">

### Author: ![scivision](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/s/a87d85/32.png) [@scivision](https://discourse.cmake.org/u/scivision)
#### Post date: [September 13, 2023, 4:34pm UTC](https://discourse.cmake.org/t/cmake-internal-curl-disable-hsts-on/8917/5 "2023-09-13T16:34:22Z")

</div>

OK thanks! I rebuilt CMake with that change.

My Gist is not a good test because how the browser acts depends on if the browser previously visited the website to get the HSTS header for upgrading the connection.

Well anyway, at least 8801 makes a better default.

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [September 13, 2023, 4:43pm UTC](https://discourse.cmake.org/t/cmake-internal-curl-disable-hsts-on/8917/6 "2023-09-13T16:43:52Z")

</div>

`CURL_DISABLE_HSTS` only controls whether the feature is built in to curl. An application may still need to set associated options when making a connection, which we don’t.

If I understand HSTS correctly, it makes sense only when making multiple connections over time. In order to take advantage of it across multiple cmake runs, we’d need to set curl options to cache information in a file somewhere.
