Skip to main content

Apple Did What?

Figure 1.  The iOS code exhibiting the SSL handshaking problem.
(Originally published on www.servicevirtualization.com)

As a veteran of the application development industry, I can share plenty of horror stories about things that just "went wrong," from a tape backup software vendor not having a backup of my hard drive and then having the hard drive fail after I left, to projects that were canned after being in development for four years without a single beta release.

During those 18 years, however, I can recall having to go through a very rigorous process while working on Wall Street whenever any code was considered a Release Candidate for production.  Essentially, any code to be rolled out to production had to pass a code review by your peers, and we all took delight in shooting down other members' code, all in the name of quality.  In one instance, a library of common routines that I created after refactoring a few of my own applications was stuck in repeated reviews for six months before it was finally approved (after many adjustments on my part).

So, it's with this hindsight that I look at the gaffe by Apple where SSL handshaking wasn't being properly validated (that ultimately resulted in iOS 7.0.6 being released during the end of February), and I marvel that this even happened in the first place. Essentially, a superfluous "goto" statement was left in the code, causing it to exit out of the validation routine prematurely.  The code in question is shown in Figure 1 (taken from the Wired UK article with indentation reformatted to better fit here).

Although static code analysis tools such as HP Fortify and CAST should have caught this immediately, this lends itself to a discussion on why establishing a discipline such as Service Virtualization is so important.  It has been discussed repeatedly how virtualization decreases as the software progresses to the right of the SDLC (i.e. closer to a production release), but things are slightly different in reality as illustrated in Figure 2.

In this diagram, you can see that there are actually two types of virtualization that are utilized in the process of writing a software application:

Intra-application virtualization is the exercise of developing virtual services for components that exist within your own application. This occurs because components upon which a developer is dependent do not exist due to code development prioritization that is based upon the priority of the underlying business requirements. However, these availability constraints eventually work themselves out and, as a result, the need to virtualize those other components is reduced to zero at some point.

Figure 2.  The two types of virtualization
Inter-application virtualization is much different due to the underlying need that it satisfies. Here, other applications with which your application interacts have independent release cycles, independent infrastructure requirements (i.e. not typically covered by your application's CapEx budget), etc. Most importantly, these factors typically require virtualization of those systems to occur up to the go live date.

(I realize these statements about the length of usage of virtualized services is not entirely accurate because there are legitimate situations where the end of virtualization may be extended or contracted.)

Regardless of the type of virtualization being used at any given time, virtual services are developed based on the flow of data between components as part of one or more transactions. This flow of data is independent of the code in that it is frequently "designed" in advance of any code being written.  As a result, the data reflects the desired end state of the application or, to put it another way, what would be observed "on the wire" if the code were 100 percent correct.

Furthermore, because virtual services are essentially data and little more than data, the set of responses that can be returned by a virtual service in response to any given transaction is fully within the control of the owner of those virtual services. This allows the consumer to more easily test negative cases such as boundary conditions, off by one errors, etc.

This brings us back to the Apple problem. As you know, SSL is a technology that is used to facilitate secure communications between multiple software entities. And while both endpoints could be within the same application, more frequently it is used in inter-application communication.

The point is that virtual services could have easily participated in the SSL handshaking instead of live code. (More importantly, that inter-application virtualization would have existed a lot longer during the SDLC as noted in Figure 2.) And, since virtual services are just data that can be modified to setup specific testing scenarios, it would have been trivial to reproduce the condition that resulted in the premature exit of the handshaking code in iOS 7.

Popular posts from this blog

Time to Level Up!

With the recent news out of Salesforce and Oracle, it’s easy to understand why folks affected by layoffs might feel discouraged. Not only are they leaving companies they may have called home for years, but they’re also facing the daunting prospect of job hunting while headlines scream about “AI taking over human jobs.” Not long ago, another company I follow - let’s call it Acme  - went through a similar round of layoffs. Two employees in particular (we’ll call them Jim and John) showed how mindset can make all the difference. Jim had been at Acme for over 20 years. He was reliable, steady, and well-liked, but not exactly the standout type. When he was laid off, he decided to take some time off before even thinking about his next move. After all, he had a severance package. Didn’t he deserve a break after two decades of hard work? John’s story was different. Though he hadn’t been at Acme as long, he’d built a strong reputation and had both technical and leadership skills. Instead of...
Read more

So What is this IPaaS Stuff, Anyway?

 In my last post , I discussed how no-code/low-code platforms fulfill rapid development of business applications - addressing the needs of the Citizen Developer (a Gartner term  first used around 2009).  I also commented on how this specific objective limits their ability to provide true integration capabilities, which require the flexibility to adapt to the myriad variations of infrastructure.  This is a concern because companies often have acquired legacy systems via M&A activity while simultaneously investing in new technology solutions, resulting in a mishmash of systems with multiple ways of accessing them. In this post, I'd like to examine how the needs of the latter group are met by describing some key capabilities that are "must-haves" for any company looking to execute on a digital transformation strategy.  In order to do this, let's define who the target user base is for such a technology platform. Disclaimer:   I work for MuleSoft (a division...
Read more

COSMIC Insights

Consider the following scenario:  you're a mid-level manager and find out that a layoff is coming.  You're about too lose one of your best direct reports, but you have no ability to influence the decision to lay them off. Oy! My head hurts! What do you do? Oftentimes, I find that people - when presented with situations where they feel compelled to act but have no ability to change the outcome - enter a state of mental lethargy.  They don't know exactly what it is they should do but, "gosh darnit!", something has  to be done.  When they realize how helpless they actually are, they start lamenting about the situation, how they are backed into a corner, etc. In a very real sense, they go through the five stages of grief . I'd like to offer the following alternative way of approaching these and other situations:  I call it the COSMIC method, not only because it sounds cool but also because I like science fiction (" Lisan al Gaib! "). COSMIC is an acronym...
Read more