Go Plugins and Avoiding Cyclic Dependencies
The other day, I started a project to eventually replace the backend of Kirsle.net with a Go program instead of the current Python one (Rophako). It will support a similar feature set (being modular with even the core functionality, like user accounts and web blogs, being served by built-in "plugins" and allowing users to extend it with their own plugins).
The plugin system will support both compile-time plugins (your
main.go imports and registers all the plugins you need when compiling the binary), and run-time plugins using Go's plugins from *.so files support.
This post will focus on the former, compile-time plugins, and how I ran into a cyclic dependency issue and worked around it.
This is going to be yet another blog post in the "tabs vs. spaces" holy war that software developers like to fight about. I generally prefer tabs over spaces, but for certain types of programming languages I do use spaces instead of tabs.
Recently, I was developing a Python/Flask app to implement Web Hooks for a third-party API that I was working with. The API recommended the use of ngrok during local development so that the server running on your local computer could be accessed publicly over the Internet (so that their API could reach yours).
ngrok is cool and all, but for their free plan they randomize the subdomain they give you every time you start the program. This meant I always had to log into my API account and change my Web Hook URL each day.
What ngrok is doing is nothing new: I've written about using SSH to forward ports between machines, and figured it should be easy enough for me to configure a subdomain on my own server that forwards traffic to another port that I could open when I need to.
I wrote this article for the RiveScript Community Wiki, but am reposting it here for visibility.
I've been noticing more and more lately that people are using RiveScript to power Facebook Messenger chatbots, which adds a whole lot of complexity that RiveScript wasn't ready for. This article explains why RiveScript was designed the way that it is, what it's doing to support modern chatbots, and recommendations for how to design a modern chatbot.
It seems there's a new iOS vulnerability where receiving a certain text message can crash your phone (forcing a reboot), and then lock you out of the Messages app--presumably because attempting to display the offending message will crash the phone again. Also, apparently, you don't even have to read the text message; the notification for the message alone will crash the phone too.
I heard of it from this article on Cult of Mac, and I have various thoughts on the matter (and about iOS vulnerabilities in general and how people handle them once discovered--the long story short is they're handled very poorly).
The article mentions that if you found yourself a victim to this exploit, you can "fix" it by visiting a web page in Mobile Safari which then offers to "Open this page in Messages" and then finds some way to allow safely deleting the text without crashing the phone.
I tried inspecting the source code of the "fix" page with the
curl command line HTTP client (because you should never check out a possibly shady web page in your normal browser, as they might try and exploit some zero-day vulnerability in your browser and compromise your computer). But, it seems that the domain the fix was hosted on no longer exists: it gave me some DoubleClick "inquire about this domain" nonsense and tons of advertisements.
Either this is an extraordinary coincidence that the site is down now (given that the article was written today, and presumably the site worked when the author wrote the article), or the site was up to something shady and got reported and terminated by its host/registrar. My guess is that it was basically a jailbreak exploit, as iOS tends to be very locked down compared to Android (for example, no "Intents" system for apps to communicate with each other, and iOS doesn't allow replacing the default Messages app for managing your text messages).
Which brings me to how iOS vulnerabilities are handled in general by the users: very badly. Somebody discovered that they can crash iOS by sending a certain text message to an iPhone user, and instead of doing the responsible thing of privately informing Apple about it and not disclosing it publicly, they make YouTube videos being like "Text your friend these 3 characters and crash their phone! It's hilarious! Fun prank!"
It's not a fun prank. Short of using a shady as fuck web page that probably gains root privileges on the phone in order to fix your Messages app, the other way to fix it would probably be to factory reset the entire phone.
To compare with Android, vulnerabilities get disclosed in vague terms, like "somebody can craft a special audio file and text you it", but with no specific details, and the users are more concerned with updating their OS to patch the problem as soon as possible; rather than being, "I can crash all my friends' phones! I know exactly how to do it because blogs and YouTube videos are telling me how; and I'll use it to 'prank' as many of my friends as I can before Apple can fix it!"
One reason I'm glad not to be an iPhone user. I'd have to unfriend people IRL if they intentionally abused such a dangerous exploit against me.