Auditing the Hammer

01 Sep 2011

There have been some people who are extraordinarily vocal in our community about their code not being backwards compatible. However, none of these historically vocal individuals have sent us code examples. I continue to assert: in order to help you, you need to get involved and send us code. Put your code where your mouth is. Help us help you. We can't address what we can't see. Saying nasty things about backwards compatibility and not letting us identify the issues doesn't help us work together and fails to solve anything for either of us.

Help us understand how you use the hammer.

However, we did have a number of wonderful individuals send in code (thank you!), which has been a wonderfully revealing experience. Our benevolent dictator himself (Kyle) has been assigned the core role of checking the code manually. This is a great way of getting these issues dealt with right where the rubber hits the road in our development team.

And here's the fact, you may need to sit down for: we have found places where Lasso 9 does not run Lasso 8 code. *gasp*

However, as I personally have been through some of the code auditing myself, I have watched an interesting process unfold. For example, in one system we audited, in thousands of lines of codes spanning several dozen pages and folders, we found a total of 10  "places Lasso 8 wouldn't work in 9". Of these 10 errors, there were 4 issues.

The Issues

*Note that these issues are from this one snapshot of code we were testing.

Issue #1: In a [loop] statement, the number of loops needed to be defined as an integer. Obviously, you can't loop "a banana" number of times, you can only loop an integer "10" times. In Lasso 9, this needed to be explicit. By forcing this to be explicit, you can catch a buggy loop statement earlier. However, we relaxed the need to loop by an integer so this problem doesn't happen again.

Issue #2: In a set of [currency] variables, the number needed to be explicitly set to a decimal. I guess the assumption was, when dealing with currency, it is a decimal. Requiring it to be so minimizes bugs. However, as we should support Rai Stones as a currency, which don't have smaller denominations (unless gravel counts?), we relaxed Lasso 9 to accept other options for currency to help with backwards compatibility.

Issue #3: In some code lifted from TagSwap*, there were a set of brackets missing around a (date), where Lasso 9 was grabbing a larger part of the code to process than grabbed by Lasso 8. This is a syntax difference. We addressed how Lasso 9 looks at this code in order to ensure Lasso 9 is a little less greedy in its need for brackets.

Issue #4: In a database search, the flag "-cn" was used. Lasso 9 did not have an explicit flag for this in the same way as Lasso 8. Ergo, putting quotes around the parameter solved the problem. This issue as well has been addressed, by adding these explicit flags to 9.1.3.

All of these issues are "usage" issues. We have never bumped across these issues in our own code, and couldn't have imagined them happening. By golly, Eureka!

*Note we will also be going through and providing all tags on TagSwap in both Vintage Syntax (where possible) and Lasso 9 syntax - so the tags will work in Lasso 9 in either syntax.

The Solution

We were able to very quicky identify all of these problems from the thousands of lines of code and rectify them through simple syntax changes. In addition, we were able to identify how to add features for all of these slight syntax differences so that in the future Lasso 9 could handle them all without problems.

(Note we had to go back and forth a few times with the developer using actual data, as the test data we worked with didn't show a few of the instances of this code, so it took additional time).

Overall, the transfer was quick and painless, as predicted.

This enabled us to give back Vintage Syntax code to the original developer of a full working system which would work perfectly in both Lasso 8 and Lasso 9.

It also means that these problems will never be seen again in future versions of Lasso 9. Here's a live version of changes we made and are still making;

http://www.lassosoft.com/Lasso-9-Change-Notes

And in Addition

Ironically, there were two other things discovered in the code which came to our attention while looking through it in detail. This is the benefit of having a senior developer look through code afterwards - a second set of eyes, as such, who looks at the code overall and checks logic.

Performance Enhancements: We were able to make some meaningful recommendations on how various things were being used (includes, for example) in order to speed up how the pages were loaded and how memory on the machine might be affected.

Security Issues: We were able to identify a critical security hole where someone with explicit knowledge of the system architecture could interact with the database directly without security privileges through direct access to a nested include file. Obviously, this was a big win for the audit. Admittedly, it was a one in a billion potential threat. But a threat, nonetheless.

Stylistic Suggestions: We were able to address the elements of coding style and make recommendations for readability and additional commenting. (Though the actual comment was "great code!", which was true.)

And so, with this in mind and in keeping with our values of security, speed and simplicity, we realized the need within our community to offer a service which would address the issues above. To have the big cheese Kyle himself (amongst others) look at the code and see how people use it and make suggestions on critical improvements to keep our community's code optimally secure.

Introducing: Code Auditing

We have realized the need for a second set of eyes for code which is created. Obviously, although it would be wonderful to offer code auditing for fun (especially given the additional insights we have gained about backwards compatibility), we need to be compensated for our time in return for the value we provide.

We also realize that almost all developers are short time to go through old code and check for critical security issues. However, in this day and age, a good code mine-sweep could save more than just embarrassment. It could save litigation or even lives.

Ergo, we will now be offering the services of our team to audit code bases - Lasso 8, Lasso 7... back even to Lasso 3.6. We will take your code, sweep for security issues, check for performance issues, and as a side benefit, attempt to clean the code (if in Vintage Syntax) to work flawlessly in Lasso 9.

This is also a service which genuinely improves the value proposition of the Lasso product to the end client. To have a third party check code for obvious security concerns can help the end client or boss sleep at night.

Note that we will accept no responsibility for the end code or issues therein, and obviously cannot guarantee we catch everything. We are just performing a logical, best-effort sanity check to root out the obvious.

Anyone that has a system and would like a formal audit, please contact us immediately.

Also, I will casually note that will be continuing to backwards-compatibility-check code provided to us to date. We will be concentrating on ensuring some of the existing frameworks and open-source vintage-syntax CMSs work in both 8 and 9.

We have also, during this process, continued to move Lasso 9 forward. (For example, cache tags are now available in  9.1.3b).

As we continue to push forward, we thank you for sticking with Lasso and being so supportive to us.

Sean Stephens
CEO