Espressif has released updates for ESP-IDF, ESP8266 RTOS SDK, & ESP8266 NONOS SDK on their Github page.
When will you be upgraded?
Already updated in https://github.com/esp8266/Arduino/commit/e04903225e8e257a21c4a9872308d9edff08755c, pre-release 2.4.0-rc2 contains the patch.
Thank you @igrr and espressif team in getting the patch out there so fast. We appreciate the hard work you guys do!
Is there an estimated release date for a final/stable version that contains the KRACK fix?
@igrr - I saw in your referenced commit above a comment that the version brought in was v2.1.0-10-g509eae8, however, don't we need v2.1.0-13-gb762ea2? My apologies if I've missed something here.
Sorry, i must have forgotten to update version number when squashing the commits (previous version of the SDK branch indeed had 509eae8).
I have double checked the libraries and they are indeed from b762ea2.
That being said, it would be good if someone could run the attack against 2.4.0-rc2 to confirm that the issue is indeed fixed. Any takers?
Will update VERSION file in the SDK directory next week, as there is another follow-up fix coming to NONOS_SDK. The fix for KRACK introduced a regression seen with some models of APs.
@igrr if rc2 contains the patch, is this considered staged, or should it just be closed?
@igrr Given the KRACK vulnerability, do you think it is worth releasing a final 2.4.0 version (after checking the fix works), despite the long list of nice-to-haves in 2.4.0? Or perhaps release the 2.4.0-rc2 as 2.3.1 so it doesnt break any other processes? Just think it would be good for people who arent on RC releases.
EDIT: I also wanted to say thanks for everything you do to keep this library working so well, if there is anything I can do to help with the release then please let me know! (I can have a look at testing next week though would have to learn it first so probably somebody else might be better placed for it!)
What is the status of this issue? I noticed 2.3.0 is still considered the 'stable' release, even though KRACK is in there.
Did anyone try the KRACK attack on pre 2.4 and verify its not possible anymore on 2.4?
Don't worry @objarni no one will attack your ESP device! ;)
@beicnet maybe not _my_ device but my customers in which I use ESP ;). It's more of a "get the worry out of the world while selling" than anything else ...
@objarni If someone wants to crack some device, then he will do it anyway, no matter what security you or your customers have.
@beicnet I don't understand what are you trying to say. Should we ignore security? Hacking ESP is more similar to hacking brick than hacking for example Windows computer. Main difference between brick and ESP is vulnerable Wi-Fi. And that's exactly what should be fixed.
If you don't understand why unpatched KRACK vulnerability is huge problem and why fixing it is really important even if there are maybe other vulnerabilities, please don't write ANY code commercially.
For others, please patch your devices as soon as possible.
Is there any way this can be backported to 2.3..? If there are a lot of instabilities-issues in 2.4RC then that can potentially take quite some time... (If anyone are willing to explain what needs to be backported, I'd be happy to contribute code- or testwise.)
Unlikely for the backport. The fix is in Espressif's code, and it was added after their SDK 2.1.0.
@devyte thank you, I wasn't aware the espressif SDK was included "in repo". So 2.4 includes a newer version of the ef lib compared to 2.3?
Correct. 2.3 was considered stable at the time of release, but a long list of issues have been found since then. 2.4-rc2 has a newer sdk, and when built with lwip2 is considered much more stable at this point.
Be aware, though, that building with lwip2 will be considered "experimental" for a (long) while to come.
Ok thank you. Would you recommend learning how to build my software using 2.4rc2 instead of 2.3 at this point? It's in use in an enterprise level product hitting market in January/February.
I'm considering switching to EF 'native' in future, or even rtos, however except for this issue see no reason to do so atm.
Yes. I do not recommend moving to rtos, the available heap is much lower. As for native, you will likely run into several gotchas that are already resolved here, but you might get a bit more free heap. The development effort for you would likely be very high, though.
Use 2.4-rc2, wait until 2.4 stable is out. Alternatively, learn to build from git, and keep aware of what is changing. Test extensively, then freeze for your own next release.
Thanks for advice. Currently I'm using the library manager of Arduino IDE 1.8.1; how would I go about switching to 2.4rc2? I tried adding the URL specified in main page of this repo (the README I guess):
http://arduino.esp8266.com/stable/package_esp8266com_index.json
.. which only brings up 2.3, 2.2, 2.0 and 1.6.5.
Is there another URL for RCs?
Github repo -> releases tab.
There are 25 commits after rc2. I suggest again building from git. Once set up, you can update with just git pull, then rebuild your app.
Instructions for git are on readthedocs.
Great, thanks.
Is there anything more than follow the following instructions to build esp8266-Arduino-lib from git (source)?
https://github.com/esp8266/Arduino#using-git-version
I mean, will ArduinoIDE automagically build the lib under the hood by just copying the files to the subdirectory, as is described in the documentation?
Thanks a bunch for your support and a great (wrapper) library!
Most helpful comment
Already updated in https://github.com/esp8266/Arduino/commit/e04903225e8e257a21c4a9872308d9edff08755c, pre-release 2.4.0-rc2 contains the patch.