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

Finding Clarity in the Chaos of a Job Search

Job searches are humbling. They test your confidence, your patience, and your ability to stay motivated when things don’t move as quickly as you’d like. But they also teach you things about yourself that you might not have learned any other way. For me, the past few months have been a crash course in rediscovering what really matters: not just in a résumé, but in relationships, self-perception, and how we use technology to help tell our stories. Here are three lessons that stood out. Reach Out to Your Network (Long Before You Need It) Your network is a living thing. It requires upkeep, time, and attention, just like a flower garden. You can’t ignore it for years and expect it to bloom the moment you need it. Start planting early. Stay in touch with people whose paths you’ve crossed - colleagues, mentors, partners, even those you only worked with briefly. Drop a note once in a while. Comment on their posts. Share something that made you think of them. These small gestures are the sunl...
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