The word Serverless has been gaining more and more traction over the years since the introduction of Amazon Lambda, and many similar products like Google’s Firebase Cloud Functions are also getting a lot more attention.
I think that is why my library, lambda-local, is getting more attention lately too.

https://github.com/ashiina/lambda-local

In Numbers

• 6,630 downloads (only within September 2017)
• 316 stars
• 16 contributors
• 47 merged Pull requests

I’ve been very busy the past year or so with my startup growing in size, and haven’t been able to put enough effort into nurturing this library. I’ve been receiving pull requests, issues, and emails, trying to do my best to respond to them. Thank you everybody for making lambda-local better.

Features

A lot of features have been added by many people, since I first started coding for this library. We tried to pursue the evolution of Amazon Lambda itself.

• Usage as an importable node.js module
• AWS region configuration
• Support for environment variables

Going from Here

So where do I want to take lambda-local ? My Simple answer - I want to keep it as simple as possible . Over the years, there are feature-rich serverless frameworks such as Serverless, Apex, etc. There also is a lighter library node-lambda too. All of these take care of local execution, packaging, and deployment of the code.

These are all great libraries with great features, and there is no reason for lambda-local to mimic their paths.
I want lambda-local to stay as a super simple tool where you can simulate the node execution of a lambda function in an instant.
I want these two lines to be all anyone needs to do when they first think “I wish there is a tool to execute Lambda functions locally” :

$ npm install -g lambda-local
$ lambda-local -l index.js -e event.js

Being able to programatically execute lambda locally is also a big plus. Lambda functions become testable modules now.

lambdaLocal.execute({
    event: jsonPayload,
    lambdaPath: 'index.js'
})

This simplicity and modularity should continue to be at the core of lambda-local, and that will be the value it provides in a world of awesome serverless frameworks.

The CodeIgniter database module automatically saves all queries you ran in the request, apparently for profiling. You can see the code here:

https://github.com/bcit-ci/CodeIgniter/blob/3.0-stable/system/database/DB_driver.php#L633

This can really eat into your memory, especially if you are running a large script via CodeIgniter CLI, processing a large amount of data.

Thankfully this is faily easy to stop. Just set the flag below to FALSE. It’s in the DB_driver.php file, same as above.

	/**
	 * Save queries flag
	 *
	 * Whether to keep an in-memory history of queries for debugging purposes.
	 *
	 * @var	bool
	 */
	public $save_queries		= TRUE;
	

I haven’t found a way to dynamically turn this on/off (at least through officially supported means), but ideally I think this should be able to be set on/off depending on your environment. In a production environment where you rarely would be using the CodeIgniter profiler, this will just be a waste of memory, and can be very harmful to your application.
Until that dynamic configuration is possible, I suggest just turning it off everywhere, and turning it on only when you need it.

I wish this becomes configurable…

As many people are already aware from various news outlets, Android has a nasty vulnerability that allows remote code execution by simply receiving a MMS.
The other day, this video has been finally released - it’s the Black Hat presentation of the actual guy who discovered the vulnerability. He goes into great detail of how he found the vulnerability and how he discovered various attack vectors by tracking where StageFright is being called.
It’s a very interesting video so please watch (Black Hat videos are always really insightful).

Now, this issue really troubles me. Not the vulnerability itself - of course it’s bad, but hey let’s face the truth, all OS (all software even) has some sort of vulnerability, and that’s why there are updates and patches. Nobody is to blame for the bug itself.

What’s the Problem?

The problem is that the patch for this vulnerability has not reached enough people, and will never reach enough people who are affected. The reason is simple - It’s because there are too many layers in between Google, and the end user.

This is an article telling us about Verizon pushing the updates out for several Samsung devices.
http://www.ubergizmo.com/2015/08/galaxy-s4-gets-stagefright-fix-on-verizon/
http://www.tmonews.com/2015/08/samsung-galaxy-s4-getting-an-update-with-stagefright-patch/

So there is

1. Google (OS developer)
2. Samsung (manufacturer)
3. Verizon (phone carrier)
4. End-user

So first, even if Google fixes its bug and releases a patch, the manufacturer has to incorporate it into their version of the OS. Since Android is an open-sourced OS, the manufacturer can fiddle with its code all they want, and therefore these types of fixes have to be done by the manufacturer, not Google.
And the manufacturers have different flavors of the OS depending on the phone carrier too. Samsung has to release an updated OS for Verizon’s Samsung S4, as well as T-Mobile’s Samsung S4. And if you know anything about releasing OS, you would know that it’s no easy task testing and releasing an update for an OS.

So this model of distribution is TOO long for a critical security update. As you can see in the articles above, the Verizon Samsung patch took roughly 2 weeks since the discovery of the bug, and the T-mobile Samsung took almost a month. And obviously these are not the only devices existing in the world, so there are A LOT more devices affected, where either the manufacturer or the phone carrier has not done its job and release the patch yet.
As of today, in Japan, I am not able to find even one phone carrier that has released a patch for this. It is terribly unfortunate, and it’s a pretty good deal for any malicious hackers who want to take root of your phone.

What Can They Do?

Frankly, I don’t know. I understand Google’s philosophy of open-sourcing Android, and I’m sure there has been a lot of benefits to that decision (especially in competing with iOS). But there has to be a realization that this model is fundamentally broken, and it will be detrimental to all stakeholders in that chain. There will be more vulnerabilities like this in the future, and that’s a fact as long as Android keeps on evolving. And when this kind of negligence against security is left, it will cost Android(Google) their brand image and customer loyalty.

I like the Windows model where they don’t let manufacturers touch the OS itself, and only allow applications to sit on top of it just like any other third party. I was entertaining myself with the idea of Android not open-sourcing their AOSP, and distributing their OS as a freeware instead of an open-source, but I’m sure that’s not the best idea.

I just believe that the first step is acknowledging that this is a broken model, and SOMETHING has to be done.