Thursday, September 22, 2016

Chef at DevOpsDays Dallas [feedly]

Chef at DevOpsDays Dallas

-- via my feedly newsfeed

In the great state of Texas we are lucky enough to have a couple DevOpsDays. This year, Chef was a Platinum Sponsor at the first ever DevOpsDays Dallas on September 15th and 16th. We had Michael Hedgpeth emceeing our maiden voyage. The organizers were able to wrangle up an all star Keynote group of speakers including our very own Nathen Harvey, and Microsoft's Jeffrey Snover.

Photo credit: @DevOpsDaysDFW

Nathen helped open the two day conference with his talk "Delightful DevOps Days". He explained the culture of DevOps and how you can help bootstrap it. Nathen is an animated and interactive presenter. He had the whole audience listening to every word.

Photo credit: Annie Hedgpeth @anniehedgie

I presented an Ignite talk about being an introvert at conferences. It was a quick 5 minute talk with some ideas on how to make it as delightful as possible. "Remember, you can always be a Patient Bear. Leverage those lunch tables to your advantage."

Photo credit: Trevor Hess @trevorghess

The Open Space portion of this conference was unique compared to most other DevOpsDays I've attended. With an audience still learning to to leverage the DevOps mentality in their organizations, the Open Spaces revolved around cultural and mental changes. Also, the technical talks weren't based around Linux and cloud technologies, they were around Azure and Windows! It's great to see the Windows ecosystem at DevOpsDays.

Get Involved

The post Chef at DevOpsDays Dallas appeared first on Chef Blog.

The Ruby Behind Chef [feedly]

The Ruby Behind Chef

-- via my feedly newsfeed

On September 14th I presented a live webinar on The Ruby Behind Chef. There is quite a bit of Ruby behind Chef and it is rather complex. Watch the recording below to hear me explain core Ruby topics by creating our own version of Chef: T-Rex Chef.

In the presentation, I focus on demystifying the recipe domain specific language (DSL) by showing that what you're reading are Ruby methods being invoked. Ruby can be tricky because a lot of the other characters used to denote method arguments and commands are missing.

I also explain Ruby's blocks. In Ruby, every method can be given a block, leaving it up to the method author if they want to evaluate them. I show both how Ruby blocks can be explicitly named and invoked or implicitly described and invoked.

At the end, I answered a few questions that I have included here in this post.


Why was Ruby chosen as a language for Chef, not Python for example?

Ruby was probably initially chosen for Chef because of the tools that it originated from using that language. I believe Ruby remained and will remain for some time because of the power and flexibility that it provides.

When you are writing your resources within an recipe file you are actually writing Ruby code. That means there is incredible power immediately available to you if you needed to iterate over a data collection, calculate a value, or make an API call to an endpoint. But you also do not have to use it and you are still able to compose your desired state in a language that almost has a natural language approach that is more accessible to new or novice users stepping into the role of managing the infrastructure.

Is there a list the topics of ruby that one needs to be familiar with, to write cookbooks?

Within our documentation we provide a resource for some Ruby topics ( I believe this covers quite a few of the most common concepts one would need to understand to be successful composing recipes.

As your challenges grow and your skills grow the need for more Ruby skills will grow and from that point I would strongly suggest building your Ruby skills through Ruby tutorials or exercises like the ones found at (

What does the # mean in File#read?

Within Ruby documentation the hash symbol is placed between a class and an instance method. This means that if you created an instance of the 'File' class you would have access to a method with the name 'read'.

Alternatively you will see class methods shown with a period between the class or module and the method. This means that the method is available to the class or module. This means you do not need to create an instance of the class to invoke the method. You can simply execute that method with the class itself. This is similar to static methods in Java/C#.

What is the :: notation you see in front of classes and other things sometimes. In particular with nothing in front of the initial ::

An example from the Chef-Client cookbook.

class ::Chef::Recipe
include ::Opscode::ChefClient::Helpers

The '::' is called the unary operator that allows you to traverse the class or module namespaces that may be specified within a different namespace. At first it was easier for me to think of this operator as something similar to the character used for paths (forward slash or backslash). When you define that operator you are traversing through namespaces which are similar to directories.

By placing that '::' at the start of the class or module name you are resetting your path back to the beginning; similar to how you might specify a directory with a proceeding forward slash or 'C:\'. Resetting this path ensures that you walking the correct path to the correct class or module that you are hoping to find.

Sometimes this is not absolutely necessary because Ruby is able to determine the class or module without it. It first attempts to find it locally, relative to the namespace you currently reside, and then it looks from the top-level. Specifying, when it is not necessary, does not hurt and often times makes it more clear.

Where this is necessary is when there is a possible collision. Take for example Ruby's File class and Chef::Resource::File. If you were in the namespace Chef::Resource and used File, Ruby would assume you meant Chef::Resource::File and not ::File. Which means you would likely receive an error if you were to attempt to use a method like 'File.exist?(filename)'. To ensure you would use Ruby's File class you would place the '::' in front of File to reset the namespace to ensure Ruby used the correct class for you.

Why doesn't 'chef generate cookbook' create the following directories: 'templates'; 'resources'; and 'files'?

The new 'chef' command-line application packaged with the Chef Development Kit (Chef DK) generates a number of files and directories for you. However, there was a conscious choice to stop automatically generating a few directories because they were not standard to every cookbook.

The good news is that if you want a template you can use the 'chef' to generate a template and it will automatically generate the 'templates' directory for you. This is the same for 'resources' as well when you use 'chef' to generate an 'lwrp'.

So take a look at the additional generators within the 'chef' command-line tool and see which one is right for you.

The post The Ruby Behind Chef appeared first on Chef Blog.

Wednesday, September 21, 2016

Five Steps for IT Management Success When Deploying Bromium with End Users [feedly]

Five Steps for IT Management Success When Deploying Bromium with End Users
// A Collection of Bromides on Infrastructure

  • Deploying Bromium frees-up end-users from having to worry about ransomware, viruses, Trojan horses, worms and other forms of malware.
  • Bromium is a trouble free-experience for end users with hundreds of thousands of endpoints deployed globally and billions of micro-VMs launched globally.
  • The key is helping end users understand how compliance protects your organization.

sunglasses-hand-smartphone-deskWhat's it like to be a Bromium end user? In an ideal world, they wouldn't even notice Bromium was there. And they wouldn't notice a lot of other things, too.

Learn: Here's how Bromium works

Things like viruses, Trojan horses, worms or sypware, for example. The whole point of Bromium is that it lets you go about your online business without risk of a breach. So your end users could spend a whole day browsing through the content from a hacker's convention on the dark web – or just do their jobs – and still emerge without a trace of malware.

How to make security easy for the end user.

In practice, Bromium's ability to isolate the desktop from these threats is as close to ideal as you can get. But in reality, there are times when an end user believes the security on their computer is slowing things down or preventing them from accessing a site or application. What should you do in these situations? We talked with our IT Director, Lee Hutchinson, to get his advice.

Here are his five steps to success.

  1. Minimum requirements. Make sure the machine running Bromium meets our minimum requirements. It seems so simple, but it's the number one flag we get from our customers.
  2. Determine a standard configuration. This might be company-wide or by department. For example, marketing often hits a lot of social media sites and cloud-based tools. You'll want to add trusted sites as appropriate for different groups.
  3. Train your IT team. Put Bromium on their computers first and let them bang around. They should understand how it works and where the software might limit certain behaviors (like how apps look differently when opening an attachment). That will help them understand what issues are attributable to the Bromium configuration and what's new behavior.
  4. Explain how it works. Since most users won't even notice Bromium is running, Lee suggests educating folks as needed; although there might be cases when a department could use a briefing. For example, if Legal is used to downloading PDFs and is struggling with the extra step Bromium enforces, it's an opportunity for you to talk to the team and explain what's happening so they understand the value of taking the extra step.
  5. Create a culture of success. This is probably the most important step. It starts with the IT team believing security is a high-value practice. With that attitude, as they reach out to end users they can share their commitment to keeping the company safe and show resilience in problem solving that helps the end user feel good too.

Lee reminds us that, "It is practically impossible to test all possible technology combinations and configurations, so there is always a possibility that someone, somewhere, will run into an issue with their computer security system with any security technology that's actually stopping threats." When that happens, you need to let us know. We are here to help.

The bottom line: he recommends  never switching the protection off completely. After all, the inconvenience you may get from a security system is nothing compared to that you will experience if a cyber threat gets through.


Shared via my feedly newsfeed

Sent from my iPhone

The Next DevOps Enterprise Live Chat is Set and It’s Going to Be Awesome! [feedly]

The Next DevOps Enterprise Live Chat is Set and It's Going to Be Awesome!
// IT Revolution

DevOps Enterprise Summit San Francisco 2016

Can you believe that the DevOps Enterprise Summit San Francisco (#DOES16) is only two months away! This year, we're thrilled to have many speakers (representing Docker, Capital One, Nationwide, GitHub, Heroku and more) coming back for a second, or even third, time to share new insights related to what we consider to be one of the most challenging, yet rewarding experiences for people to undergo –   DevOps transformation journeys.

To give our community a preview of what's to come this November, we're hosting a live, one-hour video chat discussion with our founding partner, Electric Cloud, and several gentlemen who've lived and breathed DevOps and IT transformation experiences for years. Their breadth of experience and knowledge always seems to astound us. Please join us as we welcome Carmen DeArdo, Technology Director at Nationwide Insurance; Mark Imbriaco, Co-Founder and CEO at Operable (previously of GitHub, Heroku, 37Signals); Topo Pal, Director and Platform Engineering Fellow at Capital One; and John Willis, Director of Ecosystem Development at Docker, Inc.

DevOps Enterprise Summit

Gene will be leading the discussion on "How Do Large Enterprises Do DevOps?" on Wednesday, September 28, at 11:30am PST/2:30pm ET.

Be sure to add the event to your calendar »

Reminder: I you haven't registered for the event yet, don't delay. Despite having more space this year at a larger venue, DOES16 has sold out each of the last two years!

Don't forget to add the event to your calendar »

What's Top of Mind?

Ahead of the live video chat, we were able to catch up with Mark, Topo and Carmen to ask them a few pressing questions, read on for their interesting responses!

1)     What's the biggest misconception about DevOps?

Mark: The biggest misconception is that embracing DevOps has a negative impact on security. Automation and DevOps go hand in hand, reducing the likelihood of manual errors when building environments. Beyond automation, a key tenet of DevOps is a focus on improved visibility. Mature security organizations have recognized for a long time that prevention and access control alone are not enough, and this focus on visibility results in processes that are often fundamentally more auditable.

Topo: The biggest misconception is that DevOps is a "thing" that you can implement by buying some new shiny tools and hiring some consultants and new associates with the word "DevOps" in their job titles.

Carmen: I think the biggest misconceptions are that DevOps is primarily about the application of technology when we know that a lot of DevOps success is based on culture and application of Lean principles. Another is that DevOps is focused on reducing the lead time starting with code commit when really being responsive to business needs has to be focused on reducing the total time from the customer concept or hypothesis of what they believe could add value to the delivery of that capability.   Many organizations spend a majority of their lead time (and costs) prior to cards ever getting into the backlog of an agile team.

2)     How should business leaders decide which performance metrics are important for their situation and why?

Mark: It's important to recognize that the key metrics are likely to change over time. For example, a common first early metric is the time that is required to provision a new environment or to deploy an application, in order to drive improved engagement from developers. As more applications are deployed, perhaps access to telemetry becomes more of a pain point and it becomes useful to track the number of metrics that are being collected for each application. DevOps is all about iteration and learning, so the key is to constantly evaluate your processes and interactions for opportunities to improve or signs of friction.

Topo: Usually there is no single metrics that alone can clearly indicate business performance. From DevOps perspective, I think few metrics become essential: Cycle Time, Mean Time to Recovery and some measure of a flow rate (Feature Flow Rate, Number of deployments per day per developer, Number of commits deployed to production etc.)

Carmen: Business leaders need to determine what the important drivers are for them to add value for their customers. In some cases, it needs for a system to be more reliable while in others, it needs to be able to experiment with different user experiences or products that can improve business outcomes.   We have over 20 business areas and for each of their products, this could vary at any given time. That's why it's important to provide a delivery capability that can allow the business to balance risk and speed to determine what course is best for them.

3)     If DevOps was a Halloween costume, what would it be and why?

Mark: I'll go with the classic horse costume because it requires the head and tail to be working in sync. No comment about whether Dev or Ops is the tail.

Topo: Horse. Why? Because we do not necessarily need to find a Unicorn.

Carmen: The first thing that comes to mind is the Flash costume that Sheldon wore in Big Bang Theory. It's Lean and mean, and of course, FAST! What could be better than that? J

Trust us, you don't want to miss what additional insights Mark, Topo, Carmen, John and Gene will be sharing on September 28.

Add the event to your calendar »

For more background on the panelists, see below!

Gene Kim

Gene Kim is a multi-award winning CTO, researcher and author. He is the founder of Tripwire and served as CTO for 13 years. He has written three books: "The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win," "The Visible Ops Handbook" and "The DevOps Handbook."

Gene is a huge fan of IT operations, and how it can enable developers to maximize throughput of features from "code complete" to "in production" without causing chaos and disruption to the IT environment. He has worked with some of the top Internet companies on improving deployment flow and increasing the rigor around IT operational processes. In 2007, "ComputerWorld" added Gene to the "40 Innovative IT People to Watch, Under the Age of 40" list, and he was named a Computer Science Outstanding Alumnus by Purdue University for achievement and leadership in the profession.

@RealGeneKim |

John Willis

John Willis has worked in the IT management industry for more than 35 years. Currently, he is Director of Ecosystem Development at Docker, Inc. Prior to Docker Willis was the VP of Solutions for Socketplane (sold to Docker) and Enstratius (sold to Dell). Prior to Socketplane and Enstratius Willis was the VP of Training & Services at Opscode where he formalized the training, evangelism, and professional services functions at the firm. Willis also founded Gulf Breeze Software, an award winning IBM business partner, which specializes in deploying Tivoli technology for the enterprise. Willis has authored six IBM Redbooks for IBM on enterprise systems management and was the founder and chief architect at Chain Bridge Systems.

@botchagalupe |

Topo Pal

Tapabrata Pal has 20 years of IT experience in various technology roles (developer, operations engineer, and architect) in the retail, healthcare, and finance industries. Over the last three years, Tapabrata has served as director of Capital One's Enterprise Architecture group and led the company's DevOpsSec initiatives. He is currently director and platform engineering fellow and is focused on next-generation infrastructure. Previously, Tapabrata spent some time in academics doing doctoral and postdoctoral research in the field of solid state physics.

@TopoPal |

Mark Imbriaco

Mark Imbriaco has spent the past 20 years working at some of the most interesting and innovative companies in the industry, including 37Signals, GitHub, and DigitalOcean before moving on to become Co-Founder and CEO at Operable. You can also find him talking about various DevOps topics at conferences and elsewhere online

@markimbriaco |

Carmen DeArdo

Carmen DeArdo, technology director at Nationwide Insurance, is responsible for driving continuous delivery utilizing DevOps, lean and agile techniques across mobile, distributed and mainframe and other technologies. This includes recommendations and implementation of technologies integrated across the development life cycle to drive variable speed IT.

@carmendeardo  |


The post The Next DevOps Enterprise Live Chat is Set and It's Going to Be Awesome! appeared first on IT Revolution.


Shared via my feedly newsfeed

Sent from my iPhone

DevOps Handbook Author Highlight Reel [feedly]

DevOps Handbook Author Highlight Reel
// IT Revolution

Many of you may already know who Jez Humble, Patrick Debois, and John Willis are… but even for those who are familiar with their work, you can read more about the history of my relationship with my fellow co-authors on this post.

Here are some of my "best of" videos and blog posts for each of them.

DevOps Handbook

John Willis, Patrick Debois, and Gene Kim (not pictured: Jez Humble)

John Willis

One of the many things that John Willis is known for is the State of the Union talks he's given at many DevOpsDays, having attended over nearly of them since 2009. Here is a ten minute talk that he gave at DevOpsDays Silicon Valley 2015, where he gives a ten minute presentation on where we've come in the last seven years in the DevOps community, as well as some of the important issues and achievements ahead of us.  John also wrote a fantastic summary of where DevOps came from here in a post called "the convergence of DevOps."

Also, here is an extremely moving talk that John gave on burnout in the technology community at DevOpsDays Atlanta 2016, and more importantly, what we can do about it.  In this talk, you can see how much he cares about our community and the people within it — the "karōjisatsu" post he refers to is here.

Patrick Debois

One of the amazing moments for me at DevOps Enterprise Summit 2016 in London was hanging out with both Patrick Debois and John Willis, which was the first time in years that we had actually all gotten together in person. (I'm looking for the video of the talk he gave at the conference, and will post it when I find it.)

That week, it reminded me of how much further Patrick can see into the future than the rest of us, just like he was ahead of almost everyone exploring how we solve the problems of the Dev vs. Ops divide.  Here is a fantastic talk he gave at the Velocity Conference Amsterdam 2015 on "mobile delivery and the devops mindset," and here's wonderful 2016 interview of Patrick by John Willis and Damon Edwards on DevOps Cafe, where he describes the journey he's been on for the last several years, applying his ingenuity to mobile development and testing, "serverless" infrastructure such as Amazon Lambda, and much more.


You can see his writings on the four key areas of DevOps that referred to in the video here.

(Lastly, here is the video that Patrick Debois opened up DevOpsDays Mountain View 2010 based on old Charlie Chaplin scenes that made me think in the first few minutes of the day, "Holy cow, I'm in the right place!")

Jez Humble

DevOps Enterprise SummitI had mentioned the four years of working on the State of DevOps Report with Jez Humble earlier: here is a video of the talk that Jez, Dr. Nicole Forsgren and I did at Velocity Santa Clara 2016. And here is fantastic talk the Jez did on architectures that support DevOps principles and practices that he did at DevOps Enterprise Summit 2015 in San Francisco, which I think every architect, developer, tester, operations and security person must see.

I still frequently refer to Jez's writings on the principles of continuous delivery: configuration management, continuous integration and continuous testing. And anyone reading the DevOps Handbook who also attended Jez's FlowCon 2013 or 2014 conferences will recognize many of the speakers, which included Gary Gruver, Randy Shoup, Adrian Cockcroft, Don Reinertsen, and more.

The post DevOps Handbook Author Highlight Reel appeared first on IT Revolution.


Shared via my feedly newsfeed

Sent from my iPhone

The Authors of The DevOps Handbook [feedly]

The Authors of The DevOps Handbook
// IT Revolution

An amazing group of co-authors to tackle this topic

I have never learned as much during any project than researching and writing The DevOps Handbook. And so much of that learning was from my fellow coauthors.

I love the saying, "You're only as smart as the top five people you hang out with." Writing a book is like so many things in life, where the outcomes are a function of who our collaborators are. And it seems impossible for me to overstate how much I've learned from them.

And holy cow, what a bunch of amazing collaborators I've had on The DevOps Handbook journey!  Many of you may already know who Jez Humble, Patrick Debois, and John Willis are… but even for those who are familiar with their work, I'm hoping that I'll share something about them that may surprise you!

ALL RIGHTS RESERVED foto: Ton Hendriks

I first met Patrick Debois at the 2010 DevOpsDays in the U.S., which was held on the LinkedIn campus in Mountain View, California. Among his many claims to fame, Patrick hosted a "birds of a feather" session at a 2007 Agile conference, trying to find other people who were applying Agile principles to operations work. Although Andrew Shafer was the only person who showed up, that conversation led to Patrick creating an entire two-day conference in 2009 in Ghent, Belgium that they called "DevOpsDays." By doing so, he coined the term devops that has since entered our vocabulary.

When I first met Patrick, it was so clear to me that he was not only brilliant, but also a boundary-spanner — although he came from a development background, he was equally comfortable talking about the goals and aspirations (as well as the trials and suffering) of operations, support, and even marketing. I've always believed that communities often reflect the cues of their leaders, and I think that's why there is so much humility, curiosity, and candor in the DevOps community. So much of that comes straight from Patrick, all the way from the beginning.

John WillisJohn Willis was also present at that first famous 2009 DevOpsDays in Ghent, getting himself invited after he heard Andrew Shafer talk about it on a Redmonk podcast with Israel Gat and Michael Cote. Previously, John had spent decades in operations and configuration management, having served as the VP of Services for Chef.

I got my first chance to collaborate with John Willis as I was finishing up The Phoenix Project — he reviewed many of draft manuscripts, and after reading each one, he would send me back pages and pages of scholarly critiques and comments, many with extensive citations. Like me, John self-identifies most as an Ops person, but he is equally at home discussing development practices and philosophy such as Agile, continuous integration and delivery. His startup was recently acquired by Docker, and he's been on the programming committee of the DevOps Enterprise Summit from the very beginning.

jezJez Humble co-authored the famous book Continuous Delivery, which described how to extend the development concepts of continuous build, test, and integration into the the world of operations, in the form of continuous delivery and deployment. He later co-authored the book Lean Enterprise that widened the field of view to the "fuzzy front end" of product and portfolio management, as well as how to improve operational and customer outcomes.

Like John and Patrick, Jez also provided fantastic feedback for The Phoenix Project. But I got to collaborate with him on the 2013 State of DevOps Report that we did with Puppet Labs, where we surveyed over 4,000 practitioners, giving us our first glimpse at how high-performing organizations using DevOp principles and practices were massively outperforming their peers. We just finished our fourth year of that continuing collaboration (having added Dr. Nicole Forsgren to the team two years ago), and that data set now encompasses over 26,000 respondents, making it the largest ongoing study of its kind.

Wow, it's really tough trying to condense these three amazing people into two paragraphs (which was supposed to be only one paragraph!).  

To give you an even better glimpse into these three amazing people, I've written a blog post with a "highlights reel," showing off my favorite videos of them, as well as some of their writings that hold special meaning to me.

This post just barely scratches the surface of what makes these three people the perfect cohort for writing The DevOps Handbook.

The post The Authors of The DevOps Handbook appeared first on IT Revolution.


Shared via my feedly newsfeed

Sent from my iPhone

The Cloudcast #268 - Multi-Cloud Serverless Platform [feedly]

The Cloudcast #268 - Multi-Cloud Serverless Platform
// The Cloudcast (.NET)

Aaron and Brian talk with Chad Arimura (@chadarimura, Founder/CEO of about the history of Serverless/Event-Driven/FaaS/Jeff computing, the differences in frameworks in the market, common customer use-cases and the need for multi-cloud platforms.

Show Links:
Show Notes:
  • Topic 1 - Welcome to the show. Give us some of the background on and how we've gotten from the start to where this serverless movement is going these days.
  • Topic 2 - As the serverless movement has started to gain momentum, we've been seeing mentioned in more and more partnership announcements with platform companies (Docker, Red Hat OpenShift, Cloud Foundry, etc.). Gives us the basics of the technologies - How does it augment these platforms?
  • Topic 3 - There seem to be lots of events-driven platforms / frameworks emerging. What are the core elements that developers and operators should be considering?
  • Topic 4 - has been doing this for quite a while. What are some of the application and design patterns that customers use the platform to accomplish?
  • Topic 5 - What are some of the business challenges that are solved with these events-driven architectures? How do you have a business-level conversation around "serverless"?
  • Topic 6 - Where are the open source elements of and which parts are commercial?


Shared via my feedly newsfeed

Sent from my iPhone

Xen Project 4.5.5 Maintenance Release is Available [feedly]

Xen Project 4.5.5 Maintenance Release is Available
// Xen Project Blog

I am pleased to announce the release of Xen 4.5.5. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.5 stable series update to this point release.

Xen 4.5.5 is available immediately from its git repository:;a=shortlog;h=refs/heads/stable-4.5
    (tag RELEASE-4.5.5)

or from the Xen Project download page at

This release contains many bug fixes and improvements. For a complete list of changes in this release, please check the lists of changes on the download page.

We recommend all users of the 4.5 stable series to update to this latest point release.


Shared via my feedly newsfeed

Sent from my iPhone

Introducing Developer Certificate of Origin [feedly]

Introducing Developer Certificate of Origin
// Chef Blog

Hello Chefs!  Currently, Chef asks each contributor to a Chef-managed open source project to sign a contributor license agreement ("CLA") or to be part of a corporate contributor license agreement ("CCLA") signed by their employer.

We've justified this in the past because (i) it ensures that we will always be able to release our projects, free from any individual contributor revoking our rights to distribute their contribution; (ii) if you fork a Chef project, or utilize it in a commercial product, you know that you are clear of patent and copyright issues; and (iii) it makes clear what is required of our contributors.  We also said that the most important thing about the CLA is that it doesn't give Chef any special rights – it just makes things more explicit.

We still believe all of that. HOWEVER, we also believe there are other, easier ways to achieve the same thing.

Effective October 3, 2016, Chef will no longer require CLAs or CCLAs for contributions to its open source projects.  Rather, Chef is adopting the developer certificate of origin ("DCO") used by several other projects and overall smart people.

The DCO is an attestation attached to every contribution made by every developer. In the commit message of the contribution, the developer simply adds a Signed-off-by statement and thereby agrees to the DCO, which you can find below or at

Developer's Certificate of Origin 1.1    By making a contribution to this project, I certify that:    (a) The contribution was created in whole or in part by me and I      have the right to submit it under the open source license      indicated in the file; or    (b) The contribution is based upon previous work that, to the       best of my knowledge, is covered under an appropriate open       source license and I have the right under that license to         submit that work with modifications, whether created in whole      or in part by me, under the same open source license (unless      I am permitted to submit under a different license), as       Indicated in the file; or    (c) The contribution was provided directly to me by some other      person who certified (a), (b) or (c) and I have not modified      it.    (d) I understand and agree that this project and the contribution      are public and that a record of the contribution (including       all personal information I submit with it, including my      sign-off) is maintained indefinitely and may be redistributed      consistent with this project or the open source license(s)      involved.

Subsequent developers who co-author or otherwise help shepherd the contribution in some way also add their own attestation so it's not unusual to end up with a contribution which looks like:

 Author: Nathen Harvey <>     Committer: Adam Jacob <>       Sprinkle extra delight on our DSL       Due to an oversight, we were only 96% delightful. Ensure the      delight now goes to 11.       Signed-off-by: Nathen Harvey <>     Signed-off-by: Julia Cook <>     Signed-off-by: Adam Jacob <>

We've considered this change in the past and have hesitated because the CLAs have more words and therefore must be clearer, right?  Maybe not…  We agree that the DCO accomplishes the same purpose as the CLAs by indicating that developers are responsible for the code that they contribute and that they understand that the contribution is under the terms of the Apache License. This simple process is familiar to developers and more and more legal departments are willing to consider this approach as well.

That's it.  It's that simple.  We have more information in the FAQ's if you want to know more, but if you just want to know how to contribute, you're done and happy contributing!


The DCO started with the Linux project.  Does that mean you're moving to GPL or another license?

No Way!  Chef will continue to use the Apache License Version 2 because it provides the same level of freedom for our users that we desire for ourselves. The DCO is increasingly seeing adoption outside the Linux kernel – for example Docker, Samba, Git, Open vSwitch, OpenDaylight, Ceph and qemu all now use it.  Red Hat initiates more open source projects than any other company, and the vast majority of these have never used any sort of CLA or copyright assignment.

Does this Change the Obvious Fix Rule?

No Way!  The theme here is "everything is the same, just easier and more delightful."

No CLA means the patent language goes away, right?

WRONG.  This move is a confirmation that the Apache License 2.0 speaks for itself.  The CLA was just a process wrapped around the rights.  Your rights and our rights don't change. To argue otherwise would imply that the Apache License 2.0 contains fundamental legal flaws and would call into question open source licenses as whole.

The Apache License 2.0 actually contains an explicit license condition that says, in effect, that patches submitted to the upstream project are by default to be licensed under the same terms that the contributor received the project code under — namely the Apache License 2.0. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. […]

What if I've already signed a CLA?

None of your rights are changing, and you don't need to do anything with your previous contributions (see above for more information). In the future, just add the DCO statement to your commits as usual.

What about Contributors from Europe?  Are their contributions valid without a CLA?

Yes.  The DCO is an express statement from a contributor that they have the right to make their contributions and that they are intentionally making their contribution under terms enabling distribution under the project's license – in this case the Apache License 2.0.  There are two basic conceptual elements of a CLA that are beneficial – that contributors explicitly state they have the right to make their contributions and that they are intentionally making their contribution under terms enabling distribution under the project's license. Apache-style CLAs are not the sole means of achieving these objectives.  Just like a CLA, the DCO is an attestation attached to every contribution made by every developer.

So are the rights granted and given under the Chef CLA different from the Apache License?

It is important to note that the DCO is not a license. The license of the project – in our case the Apache License – is the license under which the contribution is made. However, the DCO in conjunction with the Apache License may be considered an alternate CLA.

The existence of section 5 of the Apache License is proof that the Apache License is intended to be usable without CLAs. Users need for the code to be open source, with all the legal rights that implies, but it is the open source license that provides this.  The Apache License provides very generous copyright permissions from contributors, and contributors explicitly grant patent licenses as well. These rights are granted to everyone. A number of Apache License 2.0 projects use CLAs as well, but invariably these CLAs are, from the contributor's perspective, more restrictive legal obligations that run to the benefit of one organization rather than to the community. And unlike the Apache License, which is, like all open source licenses, operational without requiring additional legal formalities or paperwork, CLAs are typically structured like conventional contracts, entailing some system of formal assent and bureaucratic procedure.

If I'm contributing while an employee, do I still need my employer to sign something?

No!  Isn't that great!?  The DCO confirms that you are entitled to submit the code, which assumes that you are authorized to do so.  It treats you like an adult and relies on your accurate statement about your rights to submit a contribution.  

What took you so long?  Why are you doing this now?

With the updates to Supermarket, we thought we had a nifty, streamlined process.  However, the advantages of a DCO are compelling so we consider this the next step in our continuing path to greater awesomeness.

  • The simple DCO document and workflow lower the barrier to contribution for first time contributors.
  • Contributors reaffirm their rights to contribute with each and every contribution made.  This is more clear than asking each contributor to sign a CLA when first contributing and then expecting the contributor to remember the terms of that CLA with each commit.
  • Commits with multiple authors may easily be affirmed by each author.
  • A DCO statement can be included in contributions made via email or a bug tracking system, since it is merely some textual metadata attached to the description of the contribution.
  • The DCO statement makes it clear that all of the contributions are made under the same terms:  the project's license.

This all sounds great – how is it going to work?

Each commit must include a DCO which looks like this

Signed-off-by: Joe Smith <>

The project requires that the name used is your real name. Neither anonymous contributors nor those utilizing pseudonyms will be accepted.

You may type this line on your own when writing your commit messages.  However, Git makes it easy to add this line to your commit messages. Make sure the and are set in your git configs. Use -s or –signoff to add the Signed-off-by line to the end of the commit message.

What if I forget to add the attestation to my commit message?

Every commit, that does not meet the criteria for an obvious fix, must have a Signed-off-by line.  If you have already submitted a PR you must amend your commits to include the Signed-off-by line.  In the case where your PR is a single commit, amending your message can be as simple as running git commit –amend -s.  When there are multiple commits in your PR this will require a little more work to rewrite the commit message for each commit.

Rewrite my commit history?!  I am not a git guru, can you just accept my pull request?

Every commit, that does not meet the criteria for an obvious fix, must have a Signed-off-by line.  Chef maintainers, listed in the project's file, may ask you to attest to the DCO by way of a comment on your PR.  After you have done so, a maintainer will rebase your branch adding an appropriate attestation to each commit.  The resulting commit message would include something along the lines of:

Signed-off-by: Jane Doe <> on behalf of Joe Smith <>

Was the community involved in this decision?

Absolutely!  This change was proposed as a pull request to the Chef RFC repository there was a lengthy and healthy discussion on the matter before it was adopted by the community as RFC-80 – Developer Certificate of Origin (DCO) for Contributions.

Thank you for your contributions!  You are awesome.

The post Introducing Developer Certificate of Origin appeared first on Chef Blog.


Shared via my feedly newsfeed

Sent from my iPhone

ALDO – Agile Lean DevOps Outcomes [feedly]

ALDO – Agile Lean DevOps Outcomes
// Chef Blog

It's no secret that DevOps is taking the enterprise by storm. In a recent RightScale survey, more than 80 percent of the enterprise and 70 percent of SMBs are adopting DevOps.


At its core, DevOps is about building and delivering quality software at scale. But exactly how you go about doing that is going to vary from company to person to project. DevOps does not look the same anywhere.

As our VP of Worldwide Transformation Justin Arbuckle describes in Data Economy, an effective approach to changing your development processes and teams should start with ALDO – Agile Lean DevOps Outcomes. As he notes, begin with "a practical discussion about what you're trying to achieve. Then you consider what combination of approaches will help deliver the results you need." Let's take a closer look at ALDO:

  • Agile makes and delivers projects in smaller chunks. And the ability to change what you're building, based on customer feedback, while you're building it.
  • Lean removes barriers that add friction to your development process. Or those that add friction to your attempts to create value for the customer.
  • DevOps ensures everybody across your organization who is a stakeholder in the outcome of a particular application, is also stakeholder in its creation.
  • Outcome: Now what task in the world isn't better tackled by breaking it down into smaller pieces? Or adapting if the task changes? Or using more efficient processes? Or collaborating more?

And while these concepts may seem daunting, you don't need to boil the ocean to get started. As our CEO Barry Crist told Caroline Donnelly of Computerweekly:

The best way to drive change is, instead of having a very conceptual conversation about things, to get people from across the whole IT stack and get them working on one thing. The result will become readily apparent.

So if you're looking to start driving change inside your organization, it just takes one project and the courage to test out a new approach.

For more on how you can get started, check out how we support DevOps here.

The post ALDO – Agile Lean DevOps Outcomes appeared first on Chef Blog.


Shared via my feedly newsfeed

Sent from my iPhone

Chef Board of Governance Meeting [feedly]

Chef Board of Governance Meeting
// Chef Blog

The Chef Board of Governance (CBGB) held its second meeting of 2016 on Wednesday, September 7. Eight members of the board attended the meeting. Nathen Harvey and Thom May from Chef Software were also there to observe and advise.

Members in Attendance

Project LeadUsers / ContributorsCorporate ContributorsLieutenants
Adam JacobRanjib DeyFacebook – Phil DibowitzJoshua Timberman
Doug IretonPagerDuty – Evan Gilman
Noah KantrowitzNordstrom – Mark Ayers

Katherine Daniels, a corporate contributor, Charity Majors, a user / contributor, and Seth Vargo and Jon Cowie, both lieutenants, were unable to attend.

The board reviewed the governance policy and outcomes from the last meeting. It was decided that the CBGB should meet twice per calendar year instead of quarterly.

Mission Statement and Core Values

The mission, vision, and values, as outlined in the previous meeting, were reviewed and the board's commitment to them is strong.


The Chef community exists to create a welcoming, transformative, and transparent environment that enriches the daily life of Chef users.


Chef community members feel safe, supported, and effective participating in and contributing to the Chef ecosystem.


  • Welcoming
  • Inclusive
  • Safe
  • Diverse
  • Transformative
  • Transparent
  • Helpful
  • Delightful
  • Pragmatic

State of the Chef Community

The state of the Chef Community was discussed. Specifically, the board was interested in assessing the current state of health of the community. Noah shared that about 90% of recent contributions to the project have come from Chef employees with Facebook employees making up a significant portion of the remaining contributions. The board decided to gather some metrics about the usage of the new Chef Community Slack team. The board has also recommended a survey be sent to all Chef Community members to help gather data and insights as to its health and improvement the community could consider.


The board raised some concerns about the official Chef documentation. Concerns included that the docs are incomplete, inaccurate (in some cases), and the that documentation team does not have enough capacity to keep up with the pace of development. Additionally, new releases sometimes result in deprecated or older features being removed from the documentation even though there may still be many people using those features.

The CBGB will ask maintainers to encourage updates to along with pull requests and other code updates.

The CBGB recommends that we work to stabilize the documentation by not removing deprecated features too quickly.

An exploration of ways to make it easier to contribute to documentation was recommended. The current process for getting documentation running locally for development purposes is difficult. Contributing to documentation should be very easy. Discussions about documentation and changes to our processes and tooling there would make for great topics at the upcoming Chef Summits.

RFC Process

The RFC Process continues to work well. There was some concern that some proposed RFCs do not receive enough attention from the community. As such, the CBGB will be recommending some changes to the process.

  • GitHub PRs to the chef-rfc repository should automatically post in the general channel of the Chef Community Slack.
  • The author must announce the RFC in the Chef Mailing List / Online Forum.
  • A PR for an RFC must be open for at least 14 days before it may be accepted.
  • An agenda item has been added to the weekly slack meeting to ensure we review the status of accepted RFCs.

Chef 13

The CBGB recommends we start planning for version 13 of Chef. That planning should include automatic testing plans and paths for the upgrade. The plan should also include listing and freezing all breaking change that are in-scope for Chef 13 at least three months in advance of release date.

The Future

The next CBGB meeting will be planned for the end of 2016 or beginning of 2017. Elections for the 2017 board will be held during this timeframe as well. Questions or thoughts for the board may be sent to

The post Chef Board of Governance Meeting appeared first on Chef Blog.


Shared via my feedly newsfeed

Sent from my iPhone

Firefox Browser vulnerable to Man-in-the-Middle Attack [feedly]

Firefox Browser vulnerable to Man-in-the-Middle Attack

-- via my feedly newsfeed

A critical vulnerability resides in the fully-patched version of the Mozilla's Firefox browser that could allow well-resourced attackers to launch man-in-the-middle (MITM) impersonation attacks and also affects the Tor anonymity network. The Tor Project patched the issue in the browser's HTTPS certificate pinning system on Friday with the release of its Tor Browser version 6.0.5, while

Friday, September 16, 2016

No, I won’t tell you what DevOps is. Tell me what you want to achieve instead. [feedly]

No, I won't tell you what DevOps is. Tell me what you want to achieve instead.

-- via my feedly newsfeed

Our friends at Data Economy just launched their new site, dedicated to covering the world's most critical IT infrastructure issues, from cloud to data centers, and how they impact our global economy. To accomplish this mission, Data Economy will be publishing daily news, analysis, opinion and leadership insight from all angles of the IT business. In that vein, Data Economy published an editorial by our own Justin Arbuckle, entitled, "No, I won't tell you what DevOps is. Tell me what you want to achieve instead."

Justin urges us all to move past buzzwords, definitions and the arguments they can create. Instead, he recommends, focus on the outcomes you want to achieve, then align your practices and tools to those goals.

Enough of the navel-gazing and phony definition war. Whether DevOps is a buzzword or not, or what it covers and doesn't cover, is not a valuable conversation. Instead, we should focus first and foremost on the outcomes — the specific results our clients are trying to achieve in their business. Otherwise, you begin by, or even worse end up, having a dogmatic argument about methodologies. In spite of the fact that technology and ways of working are just tools — a means to an end.

You can read the entire piece over at Data Economy. As Justin suggests, let's move past debates over terminology and start having tangible, results-based discussions.


The post No, I won't tell you what DevOps is. Tell me what you want to achieve instead. appeared first on Chef Blog.

Chef at DevOpsDays Oslo [feedly]

Chef at DevOpsDays Oslo

-- via my feedly newsfeed

On September 5th, Chef sponsored the first ever DevOpsDays Oslo. It was also my first DevOpsDays event. If you've not been to one, let me share my experience and what to expect.

Having come from the busy-ness of London, it was a breath of fresh air to leave my hotel in the cool calm Oslo morning. The streets were quiet and a 10 minute walk from my hotel opposite the train station had me arriving at the industrial styled 'Gamie Museet'. Looking down into the exhibition space, I could see around 10 exhibitors and 150 attendees.

These community technical conferences are all about making connections, exchanging opinions, sharing experience and also it seems, eating very well!

The schedule for the two days was built around the ebbs and flows of energy throughout the day; a format they've come to through their vast experience putting on these events (40 DoDs this year alone).

The day starts with breakfast, coffee and mingling around the spacious exhibit hall before presentations. There are plenty of opportunities to make new connections and rekindle old ones.

Day One

Monday saw us starting with Mark Burgess, "How we know if IT systems are working well". Mark took us  through the principals of 'Promise Theory' and how people fit into promise theory. Mark explained that often people (who form large parts of promise systems) ask themselves 'am I doing a good job?' which is different from 'am I fulfilling the needs of this larger system?' –  a slight but vital difference.

We then heard from Jon Arild Tørresdal, who spoke about his experience of a "DevOps Journey". His presentation drew on Jez Humble's book, "Continuous Delivery."

Wisdom from Jon's talk included revelations in process like: "Never roll back," "No login" and "No Branches". He explained that if branches don't get in your way, you may not be trying to move fast enough.

Ignite Talks

A coffee break followed,  further 30 minute presentations, then short form talk format called Ignite Talks. The premise is that the slides change every 15 seconds for 5 minutes to ensure that things are kept moving.

One of the funniest talks of the conference, most stylistic and certainly most tongue in cheek, was called "How to Kill DevOps (in 5 Minutes)". We were given an overview of the practices that are sure to repress collaboration, minimise communication and thwart agility. Well done Kjetil Jørgensen-Dahl!

Lunchtime arrived and was a chance to sample delicious Norwegian food. I noticed the Norwegian diet seems to consist of 'Veg and Two Meats' rather than the British 'Meat and Two Veg' (vegetarian options also present). I approve.

Open Spaces

Our afternoons were given to the sharing of experience and ideas through 'Open Spaces'. This format was introduced to the uninitiated by the laying out the ground rules. Participants are empowered to freely move around between the six concurrent discussions and contribute in any way they see fit. A pep-talk ahead of the talks if you will.

Once we were all sold on the principle of Open Spaces, we were invited to put in ideas for conversations. Twelve were selected and participants indicated their interest.

The First of these sessions I attended was titled "How to Adopt DevOps." At its peak, the conversation had 25 attendees with around 9 actively contributing. We shared our experience and observations, parallels were drawn to the adoption of Agile 15 years ago in the software industry. We discussed tactics for increasing adoption, referred to the earlier anti-patterns from Kjetil and concluded that there's no one-fit formula, but a toolbox of options. These group discussions were valuable, particularly as queries can be answered and theories can be tested against others experiences.

Evening Event

The afternoon then turned to evening and our drink vouchers were exchanged for beer and wine on site. The social space was furnished with foosball and table tennis. After chatting to some Oslo engineers we took to the foosball table only to learn that two of the four of us had 'misspent youths' playing foosball. Fortunately, they were on opposing teams. My evening concluded after a few light hearted discussions about language, life, tech and whether Wales is used as a standard measurement of area outside of the UK (it's not).

Day Two

Day two followed the same format as the first. Chef's own Jody Wolfborn took to the stage to discuss the feeling many of us have suffered from at one point, 'Imposter Syndrome'. This was an inspiring and frank talk which put those who suffer with this condition in good company, drawing on quotes from Albert Einstein and grand master Yoda… to name a few.

More food, speeches, ignite talks, open spaces and the conference was done. Tweets transmitted, stickers selected and swag stowed. Until next time Oslo, you'll always be my first DevOpsDays and certainly not the last. Thanks to all who put this together, spoke, contributed and attended.

Get Involved

The post Chef at DevOpsDays Oslo appeared first on Chef Blog.

Chef boards the DevOps Express with CloudBees, GitHub, Atlassian and more [feedly]

Chef boards the DevOps Express with CloudBees, GitHub, Atlassian and more

-- via my feedly newsfeed

You may often have more questions than answers as you progress along your DevOps journey. Which tools should I choose? Do these tools work well together? What have other people done in my situation? You're often left Googling to find the right integrations and piece together an architectural solution.

Today, I'm excited to announce that Chef is joining DevOps Express, a new industry initiative comprised of 14 leading DevOps vendors and service providers. Led by CloudBees and Sonatype, and including everyone from Atlassian to GitHub, this initiative is focused on creating solutions that will help you adopt DevOps practices. Specifically, by defining reference architectures and highlighting best practices, supported integrations and solutions, we believe that DevOps Express will simplify and accelerate DevOps adoption for organizations of all kinds.

DevOps Express uses popular technologies spanning multiple solution components to provide a framework for building reference architectures that are better integrated and supported. Creating reliable and actionable reference architectures for organizations will ease DevOps adoption and minimize risk for organizations. For more information on DevOps Express see

DevOps is collaborative by its very nature – it's all about bringing teams together. This includes cultural transformation, breaking down silos between disparate teams, and working together around the common goal of adding value for customers. These principles are just as true for us, the vendors providing tools to help you on your DevOps journey. We too must break down silos and work together to provide more value for you, our common customer.  I'm looking forward to what we'll build.

The post Chef boards the DevOps Express with CloudBees, GitHub, Atlassian and more appeared first on Chef Blog.

Wednesday, September 14, 2016

Microsoft Patch Tuesday - September 2016 [feedly]

Microsoft Patch Tuesday - September 2016

-- via my feedly newsfeed

This post was authored by Jaeson Schultz.

Well it's Microsoft Patch Tuesday, again, and that must mean we are girding our systems against another round of security vulnerabilities. This month Microsoft has released fourteen (14) bulletins covering fifty (50) security vulnerabilities. There are seven bulletins in the set whose severity is considered "Critical". These "Critical" bulletins affect Internet Explorer, Microsoft Edge, Microsoft Graphics Component, Microsoft Exchange Server, Microsoft Office, OLE Automation for VBScript Scripting Engine, and the Adobe Flash Player. The remaining seven bulletins impact products such as Silverlight, Windows, Windows Kernel, Windows Lock Screen, Windows Secure Kernel Mode, Windows SMBv1 Server, and the Microsoft Windows PDF Library.

Bulletins Rated Critical

Microsoft bulletins MS16-104, MS-105, MS16-106, MS16-107, MS16-108, MS16-116, and MS16-117 are rated as Critical in this month's release.

MS16-104 and MS-105 are this month's Internet Explorer and Microsoft Edge bulletins, respectively. These bulletins address a total of twenty-two (22) vulnerabilities comprised primarily of memory corruption and information disclosure vulnerabilities. Six (6) vulnerabilities are shared, affecting both IE and Edge. The most critical vulnerability affecting both products is a memory corruption vulnerability, CVE-2016-3295, concerns how objects are handled in memory. By directing the user to a specially crafted web page, an attacker could achieve remote code execution.

MS16-106 addresses a handful of vulnerabilities in Microsoft Graphics Component. The most severe vulnerability, CVE-2016-3356, affects how the Windows Graphics Device Interface (GDI) handles objects in the memory. An attacker could achieve remote code execution by directing the victim to a specially crafted web page, or by inducing the victim to open a specially crafted document file.

MS16-107 fixes thirteen vulnerabilities in Microsoft Office. The majority of vulnerabilities are memory corruption vulnerabilities, plus a security feature bypass, and a spoofing vulnerability. The most critical vulnerability in this set is CVE-2016-3357. If an attacker can convince their victim to open a specially crafted MS Office file, then remote code execution is possible.

MS16-108 resolves three vulnerabilities in Microsoft Exchange. Regular readers of the Talos blog might remember back in July when we discussed several vulnerabilities that Talos identified in Oracle's Outside In Technology. Oracle's Outside-In is a software library that is used to help parse a multitude of file types. By creating a custom file, an attacker could achieve remote code execution.

MS16-116 addresses a scripting vulnerability in Window OLE Automation for VBScript Scripting Engine. To exploit this vulnerability and execute code on the victim's machine the attacker would have to convince their victim to visit a compromised or malicious website. Please take note that according to Microsoft two updates must be installed in order to be protected from the vulnerability: both this update and the update contained in bulletin MS16-104.

MS16-117 updates the Adobe Flash libraries contained within Internet Explorer and Microsoft Edge. This bulletin fixes all twenty-nine (29) of the vulnerabilities identified by Adobe Security Bulletin APSB16-29. Honestly, there has been such a steady stream of vulnerabilities identified in Adobe Flash, that users would be wise to take steps that will hinder Flash from running in their web browser unsupervised.

Bulletins Rated Important

MS16-109 addresses a single vulnerability in how Microsoft Silverlight allocates memory for inserting and appending strings in StringBuilder. By inducing a victim to view a custom silverlight application, remote code execution can be achieved.

MS16-110 resolves four vulnerabilities in Microsoft Windows. By exploiting the vulnerabilities addressed by this bulletin an attacker could potentially elevate privileges, brute force a user's NTLM password hash, conduct a denial of service attack, or even execute arbitrary code with elevated privileges.

MS16-111 fixes a handful of privilege elevation vulnerabilities in Windows Kernel. The vulnerabilities are all privilege escalation vulnerabilities, and can be triggered by an attacker executing a custom-designed application on a system.

MS16-112 addresses a single vulnerability in Windows Lock Screen. There are certain situations when a user's Windows lock screen may load web content. An attacker, having physical access to the victims locked computer, could either connect the computer to a malicious WiFi hotspot, or insert a mobile broadband adaptor into the victim machine. After exploiting this vulnerability an attacker could run code on the victim machine.

MS16-113 resolves a single information disclosure vulnerability concerning how Windows Secure Kernel Mode handles objects in memory. An attacker who is locally authenticated can exploit this vulnerability by running an application on the target system. Note that this information disclosure vulnerability alone would not be sufficient to compromise a system. An attacker would have to exploit this vulnerability along with other vulnerabilities in order to do so.

MS16-114 resolves a single remote code execution vulnerability in Windows Server Message Block 1.0 (SMBv1) Server. To exploit this vulnerability, an attacker would first need to authenticate to the SMBv1 server and also have the ability to open files on the victim's SMBv1 server.

MS16-115 fixes a pair of information disclosure vulnerabilities in Microsoft Windows PDF Library. The vulnerabilities concern how Windows PDF Library handles objects in memory. By successful exploitation of these vulnerabilities, an attacker could gain additional information which can be used to further compromise a target system.


Talos has released the following Snort Rules in response to these bulletins disclosures by Microsoft and Adobe. Please note that these rules are subject to change pending new vulnerability information. For the most up to date information, refer to your FireSIGHT Defense Center or

  • Microsoft Bulletin SIDs: 40129, 40146, 40035-40036, 40073-40080, 40082-40124, 40127-40128, 40132-40145, 40147-40150
  • Adobe Bulletin SIDs: 40151-40181