My bad… just realized that SDK uses linux stuff from the yun, inclusive it calls a python mqtt client…
I’ll see what I can extract from that code in terms of logic, and I’ll look for the paho client + possibly some TLS library (apparently the move is more toward TLS than SSL)
I dug into the arduino yun SDK for AWS, looked at the paho client, and the thing is, it relies on the TCP layer, tries to connect using TLS and fails over to unencrypted. I believe the main difference with Particle’s MQTT lib is, the latter doesn’t at all consider using TLS, although it may not be difficult to just add that in. It might be a more judicious decision to go with paho, since it is officially supported by IBM, whereas the current MQTT lib is a port from Nicholas O’Leary - who happens to also work at IBM - and he’s the only really active contributor to the project. Paho is developped under an Eclipse BSD license vs. Nicholas O’Leary’s MIT license use.
I’m inclined to go with paho, which seems to be ready for TLS use, and look into the TLS library @zach mentioned here and @mdma confirmed here. It would seriously bother me to have to wait for the end of the year to be able to connect using MQTT/TLS so I guess I’ll have to take care of that on my own… I saw a reference to TropicSSL
in the firmware repo on github, which is a fork from PolarSSL that’s not been updated for many years, so I may start with mbed TLS 2.1.12 which is the successor of PolarSSL that ARM took over and rebranded.
Anyways… MUCH more work than I initially planned But do I have a choice? even if I used AWS’s HTTPS access, I would have to use the HTTPS lib, which is GPL, which worries me a bit…