Case Study: Moving To The Pull Request Workflow & Integrating Quality Engineers On The Team For Better Software Quality

By Christopher W. H. Davis, Continuous Improvement Save 40% on Continuous Improvement with discount code jn15ci at manning.com. The book Continuous Improvement walks the reader through the collection and analysis of data to provide metrics that guide the continuous improvement of agile teams. Each chapter ends in a case study outlining the application of this technique with specific types of data. This is an excerpt of a real world scenario from the end of Chapter 4 that shows the reader how to apply source control data toward continuous improvement. We’ve been through how to collect and analyze SCM and CI data so it’s time to see it in action. This real world scenario will show you how this can be applied to your process. The team in question was generating a lot of bugs. Many of them were small issues that likely should have been caught much earlier in the development process. Regardless, every time they would cut a release they would deploy their code, turn it over to the Quality Management (QM) team, and wait for the bugs to come in. They decided to make a change to get to better quality. After discussing the issue. the team decided to try out the pull request workflow. They were already using Git, but developers were all committing their code to a branch and merging it all into master before cutting a release. They decided to start tracking commits, pull-requests and bugs to see if using pull-requests decreased their bug count. After a few sprints they had the graph shown in Figure 1. Figure 1 Bugs aren’t trending down as the team starts doing pull requests. To make trends a bit easier to see, we will divide pull requests and commits by 2 so there isn’t such a discrepancy between the metrics. That is shown in Figure 2. Figure 2 The same data with variance decreases between bugs and other data That makes it a lot easier to see the variance. As you can see from Figure 2 not much changed; even though there is a big dip from bugs from sprint 18 to 19, we aren’t decreasing over time – there was just a big jump in bugs in sprint 18. After discussing it a bit more, the team decided to add some more data points to the mix. To see how much collaboration was happening in the pull requests, they started adding comments to their graphs as well. That resulted in the chart shown in Figure 3. To keep consistent, we’ll divide comments by 2 as well. Figure 3 Adding comments to our graph and finding an ugly trend Figure 3 shows that there aren’t many comments along with the pull request, which implies there wasn’t much collaboration going on at all. Since the bug trend wasn’t changing it looked like the changes to their process wasn’t quite taking effect yet. The workflow itself wasn’t effecting the change they wanted, they needed to make a bigger impact to their process. To do this, they decided to make their developers act like the QM team when they were put on a pull request. The perspective they needed wasn’t just “is this code going to solve the problem?”, but “is this code well-built and what can go wrong with it”? There was some concern about developers getting less done if they had to spend a lot of time commenting on other developers’ code and acting like the QM team. To help coach them, they moved one of their QM members over to the development team and the team agreed that if this could result in fewer bugs then the time spent up front was well spent. They started taking the time to comment on each other’s code and ended up iterating quite a bit more on tasks before checking them in. A few sprints of this resulted in Figure 4. Figure 4 Everything is trending in the right direction! Figure 4 shows that as collaboration between development and quality increased, in this case shown through comments in pull-requests, the number of bugs was going down. This was great news to the team so they decided to take the process one step further. They brought another member of the QM team down to work with the developers on code reviews and quality checks to avoid throwing code over the wall to the QM team. Test Engineers For a long time, the role of the quality department in software has involved checking to make sure features were implemented to spec. That is not an engineering discipline, and as result many people in the quality assurance (QA) and quality management (QM) space were not engineers. To truly have an autonomous team, quality engineering has to be a significant part of the team. The role of the quality engineer, aka QE aka SDET aka Test Engineer has started to become more and more popular. However as quality moves from one state to another in the world of software engineering, this role is not very clearly defined and often you have either someone with an old quality background who recently learned to write code, or you have an expert in test running technology. Neither of these actually works; you need a senior engineer with a quality mindset. As shown in Figure 4, over time commits and pull requests started increasing as well. As the development team started thinking with a quality mindset they started writing better code and producing fewer bugs. Also by combining the QM team with the development team many issues were found and fixed before deploying code out to the test environment. AttachmentSize fig1.jpg18.41 KB fig2.jpg19.04 KB fig3.jpg17.35 KB fig4.jpg20.93 KB

Posted by on 23 February 2015 | 3:25 pm

Go in Action: Exploring the Work Package by By Brian Ketelsen, Erik St. Martin, and William Kennedy

By Brian Ketelsen, Erik St. Martin, and William Kennedy Save 40% on Go in Action with discount code jn15goia at manning.com. The purpose of the work package is to show how you can use an unbuffered channel to create a pool of goroutines to perform and control the amount of work that gets done concurrently. This is a better approach that using a buffered channel of some arbitrary static size that acts as a queue of work and throwing a bunch of goroutines at it. Unbuffered channels provide a guarantee that data has been exchanged between two goroutines. The approach this package takes by using an unbuffered channel allows the user to know when the pool is performing the work and pushes back when it can't accept any more work because it is busy. No work is ever lost or stuck in queue that has no guarantee it will ever be worked on. Let's take a look at the work.go code file from the work package: Listing 1 chapter7/patterns/work/work.go01 // Example provided with help from Jason Waldrip.02 // Package work manages a pool of goroutines to perform work.03 package work0405 import "sync"0607 // Worker must be implemented by types that want to use08 // the work pool.09 type Worker interface {10 Task()11 }1213 // Pool provides a pool of goroutines that can execute any Worker14 // tasks that are submitted.15 type Pool struct {16 work chan Worker17 wg sync.WaitGroup18 }1920 // New creates a new work pool.21 func New(maxGoroutines int) *Pool {22 p := Pool{23 tasks: make(chan Worker),24 }2526 p.wg.Add(maxGoroutines)27 for i := 0; i < maxGoroutines; i++ {28 go func() {29 for w := range p.work {30 w.Task()31 }32 p.wg.Done()33 }()34 }3536 return &p37 }3839 // Run submits work to the pool.40 func (p *Pool) Run(w Worker) {41 p.work

Posted by on 23 February 2015 | 8:13 am

Comparing Spock and JUnit by Konstantinos Kapelonis from Java Testing with Spock

By Konstantinos Kapelonis, Java Testing with Spock Save 40% on Java Testing with Spock with discount code jn15spock at manning.com. In the Java world, there has been so far only one solution for unit tests. The venerable JUnit framework is the obvious choice and has become almost synonymous with unit testing. JUnit has the largest mind share among developers who are entrenched in their traditions and don't want to look any further. Even TestNG which has several improvements and is also fully compatible with JUnit has failed to gain significant traction. But fear not! A new testing solution is now available in the form of Spock. Spock is a testing framework written in Groovy but able to test both Java and Groovy code. It is fully compatible with JUnit (it actually builds on top of the JUnit runner) and provides a cohesive testing package that also includes mocking/stubbing capabilities It is hard to compare JUnit and Spock in a single article, because both tools have a different philosophy when it comes to testing. JUnit is a Spartan library that provides the absolutely necessary thing you need to test and leaves additional functionality (such as mocking and stubbing) to external libraries. Spock has a holistic approach, providing you a superset of the capabilities of JUnit, while at the same time reusing its mature integration with tools and developments environments. Spock can do everything that JUnit does and more, keeping backwards compatibility as far as test runners are concerned. What follows is a brief tour of some Spock highlights. Writing concise code with Groovy syntax Spock is written in Groovy which is less verbose than Java. This means that Spock tests are more concise than the respective JUnit tests. Of course this advantage is not specific to Spock itself. Any other Groovy testing framework would probably share this trait. But at the moment only Spock exists in the Groovy world. Here is the advantage in a visual way, shown in figure 1. Figure 1 Less code is easier to read, easier to debug, and easier to maintain in the long run. Mocking and Stubbing with no external library JUnit does not support Mocking and Stubbing on its own. There are several Java framework that fill this position. This is the main reason that I got interested in Spock in the first place is the fact that it comes full batteries included as mocking and stubbing are supported out of the box. Figure 2 Spock is a superset of Junit I’ll let this example explain: David goes into a software company and starts working on an existing Java code base. He’s already familiar with JUnit (defacto testing framework for Java). While working on the project, he needs to write some unit tests that need to run in specific order. JUnit does not support this. So David also includes TestNG in the project. Later he realizes that he needs to use mocking for some very special features of the software (for example the credit card billing module). He spends some time to research all the available Java libraries (there are many). He chooses Mockito, and integrates it in the code base as well. Months pass and David learns all about Behavior-Driven Development in his local Dev Meeting. He gets excited! Again he researches the tools and selects JBehave for his project in order to accomplish BDD. Meanwhile Jane is a junior developer that knows only vanilla Java. She joins the same company and gets overwhelmed the first day because she has to learn 3-4 separate tools just to understand all the testing code. In an alternate universe David starts working with Spock as soon as he joins the company. Spock has everything he needs for all testing aspects of the application. He never needs to add another library or spend time researching stuff as the project grows. Jane joins the same company in this alternate universe. She asks David for hints on the testing code and he just replies “Learn Spock and you will understand all testing code”. Jane is happy because she has to focus on a single library instead of three. Even though Spock does not offer a full featured BDD workflow (as JBehave), it still offers the capability to write tests understandable by business analysts as shown in the next section. Using English sentences in Spock tests and reports Here is a bad JUnit test (I see these all the time). It contains cryptic method names that do not describe what is being tested. Listing 1 A JUnit test where method names are unrelated to business value public class ClientTest { @Test public void scenario1() #A { CreditCardBilling billing = new CreditCardBilling(); Client client client = new Client(); billing.chargeClient(client,150); assertTrue("expect bonus",client.hasBonus()); #B } @Test public void scenario2() #A { CreditCardBilling billing = new CreditCardBilling(); Client client client = new Client(); billing.chargeClient(client,150); client.rejectsCharge(); assertFalse("expect no bonus",client.hasBonus()); } #A A test method with a generic name #B Non technical people cannot understand test This code is only understandable by programmers. Also if the second test breaks, a project manager (PM) will see the report and know that “scenario2” is broken. This report has no value for the PM since he does not know what scenario2 does exactly without looking at the code. Spock supports an English like flow. Compare the same example in Spock: Listing 2 A Spock test where methods explain the business requirements class BetterSpec extends spock.lang.Specification{ def "Client should have a bonus if he spends more than 100 dollars"() { when: "a client buys something with value at least 100" #A def client = new Client(); def billing = new CreditCardBilling(); billing.chargeClient(client,150); then: "Client should have the bonus option active" #B client.hasBonus() == true } def "Client loses bonus if he does not accept the transaction"() { when: "a client buys something and later changes mind" #A def client = new Client(); def billing = new CreditCardBilling(); billing.chargeClient(client,150); client.rejectsCharge(); then: "Client should have the bonus option inactive" #B client.hasBonus() == false }} #A Business description of test #B human readable test result Even if you are not a programmer, you can read just the English text in the code (sentences inside quotes) and get the following: Client should have a bonus if he spends more than 100 dollars --when a client buys something with value at least 100 --then Client should have the bonus option active Client loses bonus if he does not accept the transaction --when a client buys something and later changes mind --then Client should have the bonus option inactive This is very readable. A business analyst could read the test, and ask questions for other cases (what happens if the client spends 99.9? What happens if he changes his mind the next day and not immediately?) Also if the second test breaks, the PM will see in the report a red bar with title “Client loses bonus if he does not accept the transaction.” He instantly knows the severity of the problem (perhaps he decides to ship this version if he considers it non-critical) Facts about Spock Spock is an alternative Test Framework written in the Groovy programming language A test framework automates the boring and repetitive process of manual testing which is essential for any large application codebase Although Spock is written in Groovy, it can test both Java and Groovy code Spock has built-in support for Mocking and Stubbing without an external library Spock follows the given-when-then code flow commonly associated with the Behavioral Driven Development paradigm Both Groovy and Java build and run on the JVM. A large enterprise build can run both JUnit and Spock tests in the same time. Spock uses the JUnit runner infrastructure and therefore is compatible with all existing Java infrastructure. For example, code coverage with Spock is possible in the same way as JUnit. One for the killer features of Spock is the detail it gives when a test fails. JUnit only mentions the expected and actual value, where Spock records the surrounding running environment mentioning the intermediate results and allowing the developer to pinpoint the problem with greater ease than JUnit Spock can pave the way for full Groovy migration into a Java project if that is what you wish. Otherwise it is perfectly possible to keep your existing JUnit tests in place and only use Spock in new code AttachmentSize fig1.png28.73 KB fig2.png29.55 KB

Posted by on 19 February 2015 | 8:28 am

MVC JSR 1.0 Snapshots

The MVC JSR is progressing nicely and we have started publishing SNAPSHOT builds. If you want to try them out grab the API JAR from https://maven.java.net/content/repositories/snapshots/javax/mvc/javax.mv... and the Implementation JAR from https://maven.java.net/content/repositories/snapshots/com/oracle/ozark/1... For some samples see the test directory of the Git repo at it://java.net/ozark~sources Let us know what you think! Enjoy!

Posted by on 18 February 2015 | 10:10 am

JavaLand 2015 Early Adopter's Area Preview

JavaLand 2015 Early Adopter's Area With only 25 business days to go until JavaLand 2015, now's a good time to share the plans for the Early Adopter's area and Hackergarten. As at many other Java community conferences, this is a space where anyone can visit and meet with leaders of different parts of the Java ecosystem to see first hand what's new in their own little patch of the Java world. The detail page for this space on the JavaLand website: < http://www.javaland.eu/index.php?id=1786 > lists the individuals who have committed to spend some time in the space. I've been participating in these kinds of spaces for nearly ten years now and it's always very worthwhile for me to interact with the community in this way. The schedule of mini-presentations is still not yet finalized, but the detail page will have the final schedule when it is. In the meantime, I can share an alphabetical snapshot of the current set of individuals and their topics. If I have any commentary to add for each entry, I'll add it. As I prepared the commentary, a theme emerged. Every one of these individuals is passionately advocating for their ideas in the face of some form of challenge. I see individuals who are trying to displace an incumbent technology, trying to overcome some part of the community "not getting" their idea, and fighting the old bugbear of complexity/indifference. This passion makes it worth your time to stop by the early adopter's area. Alex Snaps, Peter Lawrey Alex and Peter are talking about JCache and Data Grids Anatole Tresch Apache Tamaya, Java Configuration, and Money and Currency Anatole has been super determined to make progress on the configuration for Java effort. This effort started out as an Oracle-lead JSR proposal, was transferred to Anatole's employer, Credit Suisse, was declined for consideration in both EE and SE JCP executive committees, and Anatole finally decided to make progress as an Apache Incubator Project. I applaud his tenacity. Andres Almiray Andres is most famous for his involvement in the Griffon desktop application framework, but his passion for this space has lead him to propose JSR-377: A Desktop Application API. Now, I've been around long enough to know that this is a difficult space to occupy, with several attempts at standardization having come and gone (see JSR-295, and JSR-296, and JSR-143). I wish you the best of success with this one, Andres, but it's obviously a tough nut to crack. Dan Allen I know Dan from his productive involvement in JSF 2.0. These days I see him frequently tweeting about Asciidoctor. After having just made a trivial pull request to the HTTP/2 spec and using xml2rfc to do it, I can say there is room for improvement in this space, and I know that Dan can tell you all about it. Ed Burns I'll be here talking about JSF, Servlet, and HTTP/2. Heather Vancura Heather is the heart of the JCP, and therefore has her finger on the pulse of what is happening across the evolution of the entire Java platform. Ivar Grimnstad I don't know Ivar, but he is on the MVC Expert Group, and is thus a great conduit to the development efforts of one of only two new JSRs in Java EE 8. Mani Sarkar, Daniel Bryant I've seen Mani at several conferences over the past couple years, and he epitomizes the passionate Java developer. As the late night tech conversations would dwindle off, he'd always be one of the last ones still talking hard core tech. Mani's the real deal. Mani is talking about OpenJDK, among other things. Roland Huss Roland is talking about JMX and Java EE Management. Please drop by the Early Adopter's Area to catch up with these and other Java community leaders!

Posted by on 16 February 2015 | 6:48 am

Practical Probabilistic Programming: Open universe situations with unknown number of objects by Avi Pfeffer

By Avi Pfeffer Save 40% on Practical Probabilistic Programming with discount code jn15ppp at manning.com. Imagine you are implementing a highway traffic surveillance system. Your goal is to monitor the flow of vehicles along the highway and predict when traffic jams might occur. You have video cameras placed at strategic points. To accomplish your goal, you will need to do two things. First, you will need to infer the vehicles passing at each point, including identifying when the same vehicle passes two different cameras. Second, you need to predict future vehicles that will arrive on the highway and the traffic jams that result. Both of these tasks require reasoning about an unknown number of objects. When you are inferring the vehicles currently on the highway, you don’t know how many vehicles there actually are, and your video images don’t give you a perfect indication of that number. Sometimes, multiple vehicles might be merged in the image, and some vehicles might not be detected at all. And when you’re predicting future traffic jams, you certainly don’t know exactly how many vehicles there will be. A situation where you don’t know how many objects there are is known as an open universe situation (see below for an explanation of the name). An open universe situation is characterized by two properties: You don’t know exactly how many objects there are, such as the number of vehicles. This is called number uncertainty. You are uncertain about the identity of objects. For example, you might be uncertain whether two vehicle images at different sites belong to the same vehicle. This is called identity uncertainty. In this article, I’m going to focus on number uncertainty, which is addressed by variable size arrays. VARIABLE SIZE ARRAYS Figaro’s approach to open universe modeling is to use variable size arrays. A variable size array takes two arguments: an element whose value is the size of the array, and an element generator, which is similar to the element generator for a fixed size array. Figure 1 shows an example of constructing a variable size array. The first argument to the VariableSizeArray constructor is an integer element representing the number of elements in the array. The second argument is the element generator, which is a function from an index into the array to an element definition. In Figure 1, each element in the array is defined by a Beta, so it is a double element. Figure 1: Structure of a variable size array construction What actually happens when you construct a variable size array? Technically, a variable size array is not a single array at all, but rather represents a random variable whose value could be one of many arrays, each of a different length, depending on the value of the number argument. When you invoke VariableSizeArray, you are actually creating a MakeArray element to represent this random variable. All the operations on variable size arrays are actually applied to this MakeArray element. Under the hood, Figaro makes sure that MakeArray is implemented as efficiently as possible to ensure the maximum amount of data sharing between the arrays of different size. In particular, shorter arrays are prefixes of longer arrays and use the same elements. As a programmer, all this is taken care of for you and you don’t have to worry about it, but I want to make sure you know what a MakeArray is because you might encounter this type sometimes. OPERATIONS ON VARIABLE SIZE ARRAYS What can you do with a variable size array? Pretty much everything you can do with a fixed size array, but there are some important differences. In the following examples, vsa will represent a variable size array whose elements are string elements. Getting the element at an index: In principle, vsa(5) will get the element at index 5 (i.e., the sixth element in the array). However, this can be dangerous. You should be sure the array will always have at least six elements to call this method. Otherwise, you are liable to get an IndexOutOfRangeException. Safely getting an optional element at an index: For this reason, Figaro provides a safer way to get at the element at an index. vsa.get(5) returns an Element[Option[String]]. Option[String] is a Scala type that could be Some[String], if there is actually a string, or None if there is no string. vsa.get(5) represents the following random process: Choose the number of elements according to the number argument. Get the fixed size array of the appropriate size. If the array has a least six elements, let s be the value of the element at index 5. Return Some(s). Otherwise, return None. We see that in either case, the random process produces an Option[String]. So the process is represented by an Element[Option[String]]. There are many ways to use an Element[Option[String]] You could pass it, for an example, to an Apply element that does something interesting if the argument is Some(s) and produces a default value if the argument is None. Map the variable size array through a function on values: This is similar to fixed size arrays, except that now Figaro reaches inside the variable size array to the fixed size arrays it points to, and then reaches inside the fixed size arrays to the actual values. For example, vsa.map(_.length) produces a new variable size array, in which each string is replaced by its length. Chain the variable size array through a function that maps values to elements: Again, this is similar to fixed size array, and again Figaro reaches inside the variable size array to the fixed size arrays and chains each of the elements in the fixed size arrays through the function. For example, vsa.map((s: String) => discrete.Uniform(s:_*)) creates a variable size array in which each element contains a random character from the corresponding string. In this example, s:_* turns the string into a sequence of characters, and discrete.Uniform(s:_*) selects a random member from the sequence. Folds and aggregates: All the folds and aggregates that are offered for fixed size arrays are also available for various size arrays. For example, vsa.count(_.length > 2) returns an Element[Int] representing the number of strings in the array whose length is greater than two. You can understand this as randomly choosing a fixed size array according to the number argument, and then counting the number of strings in that array whose length is greater than two. Again, consult the Scaladoc to see all the folds and aggregates that are defined. EXAMPLE: PREDICTING SALES OF AN UNKNOWN NUMBER OF NEW PRODUCTS In this example, we’re going to imagine that we’re planning the R&D investment of our company in the coming year. Higher R&D investment leads to more new products being developed, which leads to higher sales. However, at the time of making the investment, we do not know exactly how many new products will be developed for a given level of investment. Therefore, we use a variable size array to represent the new products. The model is defined as follows: It takes as argument rNDLevel, which is a double representing the level of R&D investment. The numNewProducts element, which represents the number of new products that are developed as a result of R&D, is an integer element defined by Geometric(rNDLevel). A geometric distribution characterizes a process that goes on for a number of steps. After each step, the process can terminate or it can go on to the next step. The probability of going on to the next step is provided by the parameter of the geometric distribution (in this case, rNDLevel). The value of the geometric process is the number of steps before termination. The probabilities of the number of steps decrease geometrically by a factor of rNDLevel each time. The higher the rNDLevel, the longer the process is likely to go on, and the more new products will be developed. We create a variable size array called productQuality, representing the quality of each of the new products. The number argument of this variable size array is numNewProducts. The element generator is the function that maps an index i to Beat(1, i + 1). The expected value of Beat(1, i + 1 is 1/(i + 1), so the product quality tends to decrease as more new products are developed, representing a diminishing return on R&D investment. Next, we turn the product quality into a prediction of the sales of each product. This takes place in two steps. First, we generate the raw sales using a Normal distribution centered on the product quality. However, a Normal distribution can have negative values, and negative sales are impossible, so in the second step, we truncate the Normal distribution and give it a lower bound of zero. These two steps are accomplished using the chain and map methods of VariableSizeArray. Finally, we get the total sales by folding the sum function through the productSalesvariable size array. The full code for the model is shown below. val numNewProducts = Geometric(rNDLevel)               val productQuality =                     VariableSizeArray(numNewProducts, i => Beta(1, i + 1))               val productSalesRaw = productQuality.chain(Normal(_, 0.5))               val productSales = productSalesRaw.map(_.max(0))               val totalSales = productSales.foldLeft(0.0)(_ + _) You’ve just seen an example where probabilistic programming lets you implement quite a rich process in just a few lines of code. AttachmentSize fig1.jpg57.62 KB fig2.jpg34.12 KB

Posted by on 14 February 2015 | 4:22 am

Explicit trust manager for self-signed certificates

We consider client devices (e.g. Android) connecting to a Java server for secure networking. Say we have stringent authentication requirements, and so decide to use client-authenticated SSL sockets, using self-signed client certificates.  Explicit Trust Manager: Safer self-signed client certificates for private servers. Part of "The Final Quadrilogy." Preamble: In a previous blog entry, I announced the Final Quadrilogy on Java SSL, covering keytool, KeyStore, and X509TrustManager. This article is a shortened version of the Explicit Trust Manager part of that quadrilogy. Server CA-signed certificates are typically used for the authentication of public servers. However, our clients must trust our private server exclusively, and not any server certificate issued by some CA. So we need our own CA specific to our server, and none other. Client Actually we are primarily concerned with client authentication, and we want to automate the deployment and enrollment of new devices. Self-signed certificates enable automation, but is this at the cost of security? Rogue certificates Self-signed peer certificates in a truststore are effectively root CA certificates. Consequently, a rogue certificate can be issued using a compromised client's keystore, by abusing the client key as a trusted CA key, to exploit the server's trust, as follows. $ keytool -keystore keystore.jks -alias mykey -gencert -validity 365 -rfc \    -infile rogue.csr -outfile rogue.signed.pem -dname "CN=clientx"where keytool is used sign a CSR for a rogue certificate, using our compromised keystore. Alternatively, one could use openssl. The rogue certificate would be trusted by virtue of being signed by a trusted certificate. Let's fix that! Custom trust manager So for a private server, we should trust only client certificates that are explicitly imported into our truststore, irrespective of their certificate chain. For this purpose, we implement a custom X509TrustManager. public class ExplicitTrustManager implements X509TrustManager {    final private Map certificateMap = new HashMap();    public ExplicitTrustManager(KeyStore trustStore) throws GeneralSecurityException {        for (String alias : Collections.list(trustStore.aliases())) {            X509Certificate certificate = (X509Certificate) trustStore.getCertificate(alias);            String commonName = Certificates.getCommonName(certificate.getSubjectDN());            certificateMap.put(commonName, certificate);        }    }    ...}where we build a map of our trusted certificates for lookup by their common name. We implement the methods required for an X509TrustManager.     @Override    public X509Certificate[] getAcceptedIssuers() {        return new X509Certificate[0];    }    @Override    public void checkClientTrusted(X509Certificate[] chain, String authType)            throws CertificateException {        checkTrusted(chain);    }    @Override    public void checkServerTrusted(X509Certificate[] chain, String authType)            throws CertificateException {        throw new CertificateException("Server authentication not supported");    }where we return an empty list of accepted issuers, so our trust manager applies to all certificates. We delegate checkClientTrusted to the following method.     private void checkTrusted(X509Certificate[] chain) throws CertificateException {        if (chain.length == 0) {            throw new CertificateException("Invalid cert chain length");        }        X509Certificate trustedCertificate = certificateMap.get(                Certificates.getCommonName(chain[0].getSubjectDN()));        if (trustedCertificate == null) {            throw new CertificateException("Untrusted peer certificate");        }        if (!Arrays.equals(chain[0].getPublicKey().getEncoded(),                trustedCertificate.getPublicKey().getEncoded())) {            throw new CertificateException("Invalid peer certificate");        }        trustedCertificate.checkValidity();    }where we lookup the trusted certificate with the same common name as the peer's key certificate, i.e. the first certificate in the chain. We check the equality of this peer certificate to our trusted certificate, via its public key. This prevents a spoofing attack using a rogue certificate with the same common name. We note that certificates are "revoked" by removing them from the truststore, and restarting our server. Disclaimer: This trust manager is an untested prototype and should not be used in production without further review and thorough testing ;) Server key change When we discover that our server has been compromised, we must generate a new server key. If our clients trust the server certificate specifically, then we must update each client's truststore accordingly. This might be quite a burden. Moreover, we might wish to change our server key periodically anyway. We want a server key change to not affect its clients. So we sign its certificate using an offline CA key, which we create for this purpose. Our private clients trust this CA certificate, which cannot be compromised (except by physical access). In the event that our server is compromised, we generate a new server key, which we sign by transferring its CSR to our CA machine, and returning its signed certificate reply, via USB key. $ keytool -keystore ca.jks -alias ca -gencert -infile server.csr -dname "CN=server.com" \    -validity 365 -rfc -outfile server.signed.pem \    -ext BasicConstraints:critical=ca:false,pathlen:0 \    -ext KeyUsage:critical=keyEncipherment \    -ext ExtendedKeyUsage:critical=serverAuthIn this case, we can perform a server key change whereby our clients are unaffected. Conclusion CA-signed certificates are typically used for the authentication of public servers by any browser. However, we are concerned with client-authenticated devices, connecting to a private server. Our server and each of its clients should exclusively trust each other, and certainly not trust any certificate issued by some public CA. We note that a self-signed client certificate in our server truststore is effectively a CA certificate. Therefore a compromised client keystore can be abused to sign rogue certificates. These are likewise trusted, by virtue of being issued by a trusted certificate. So we implement a custom trust manager that trusts only certificates that are explicitly imported into our truststore, irrespective of their certificate chain. We note that a compromised client keystore can itself be used to spoof that client. Such an attack can be detected by analyzing logs for simultaneous connections, ostensibly from the same client, but from an alternate IP address. We note that rogue certificates can spoof any chosen certificate name, and so present a higher risk. If our server is compromised, the attacker might inject a fraudulent client certificate into our server truststore. However such tampering is overt, and detectable by monitoring our truststore. When we discover that our server is compromised, we must of course change our server key. Since our clients specifically trust our server's certificate, we must update every client's truststore. To avoid this burden, we should use an offline CA key to sign our server certificate. Our clients trust this local CA certificate, and so are unaffected by a server key change. Resources https://github.com/evanx/vellum/wiki - see ExplicitTrustManager.java. Further reading See the Final Quadrilogy on Java SSL. Besides treatment of Public Key Infrastructure from a Java perspective, this series features a minimal Java implementation of Dual Control to satisfy PCI DSS compliance.

Posted by on 13 February 2015 | 10:26 pm

Meteor in Action: Authenticating users with oAuth

By Stephan Hochhaus and Manuel Schoebel, excerpted from Meteor in Action Save 40% on Meteor in Action with discount code jn15met at manning.com. Oftentimes usernames and passwords are not the only option you want to give your users to log into an application. Being able to use an existing account to log into a site lowers the barrier of signing up by not having to type in a single bit of information. Additionally it simplifies using an application by not having to remember additional usernames or passwords. Meteor ships with multiple authentication providers that allow users to use a social network instead of a local username. These networks include: Facebook Github Google Meetup Meteor Developer Account Twitter Weibo All of the above are based on oAuth, a complex way to pass authentication data from one site to another. There are also many community packages available that enable other authentication providers such as LinkedIn or Dropbox. As the fundamentals of working with Auth providers are the same for each provider, we will not need to discuss each. An introduction to oAuth The Open Authentication – or short: oAuth – mechanism has become very popular among web applications since its beginnings in 2007. The main idea behind it is to use a service provider, e.g., Facebook, to authenticate a user and allow a third-party application to access specific information from the authenticated user (access authorization). This could be simply the username or more sensitive information such as friends or a permission to post to the user’s wall. Figure 1: oAuth flow using Facebook as the Service Provider As Figure 1 shows, there are three main ingredients to every oAuth scenario: A Service Provider – e.g. Facebook or Twitter A Consumer – e.g. your Meteor application The user – e.g. an existing Facebook user wanting to log into your Meteor application Many sites on the web can act as a service provider for oAuth. We are going to use Facebook as an example to illustrate the process. Our Meteor application must be connected to Facebook. This is done by creating a new application on Facebook’s developer site. To verify our application is not a malicious script, it will be able to identify itself using the corresponding application ID (App ID) and a secret key (App Secret). These are basically the username and password for our Meteor server process. Once both are connected we can allow users to sign in with their Facebook account. Instead of entering any credentials in our Meteor app, users can now click a button to log them in via Facebook. Assuming they are already logged in on Facebook they will now see a dialog asking them whether they want to share information with the Meteor application. Behind the scenes the Meteor application forwarded the login request to Facebook as the service provider. If the user agrees to share their login information with the Meteor application, then Facebook generates an access token. This token lets the Meteor app know that the user has been authenticated properly and it grants the permissions provided by the user. In the simplest case Meteor may only have read access to the user’s e-mail address. Depending on the configuration settings we could also request more permissions such as posting to the user’s wall. Not all oAuth providers support the same set of permissions, so they must all be individually configured. The advantage of using oAuth is that the consumer application can talk directly with the service provider to exchange data, if permissions exist. That way all Facebook friends, recent Tweets or number of private repos on Github can easily be accessed and added to the user’s profile. Integrating Facebook authentication To integrate oAuth authentication via Facebook in a Meteor app we need to perform the following steps: Add the accounts-facebook package Create a new Facebook application Configure the Facebook integration ADDING ACCOUNTS-FACEBOOK TO AN APPLICATION The first step is to add Facebook as the authentication provider for our application. If the application already supports username/password authentication, it is sufficient to add a single package $ meteor add accounts-facebook This package will not add any templates to the application. Therefore, if accountsfacebook is the only package available in the project you would need to manually call all functionality within your templates. Or you can add the accounts-ui package, which not only provides a login box for use with password authentication, but also for many oAuth services. All oAuth packages require configuration. Just like users, this configuration is stored inside a MongoDB collection. A collection named meteor_accounts_loginServiceConfiguration will be created as soon as the service is configured. Additionally, pending credentials will be stored temporarily as well, which is done in a dedicated collection. This collection is created at server startup already and is called meteor_oauth_pendingCredentials. There is no need to manually access either of these two collections. Meteor will use these internally only and there is no benefit in querying data from them directly. Add a login link in the HTML code Navigate to your HTML file. You can place the login link anywhere you like by simply adding the following code: {{&gt; loginButtons}} This will include the appropriate templates for each user action. CREATING A FACEBOOK APPLICATION If Meteor cannot find a configuration for integration with Facebook, the UI will show a red button labeled “Configure Facebook Login” instead of the regular log in button. Clicking on it will bring up a short configuration guide as well as two fields to provide the application ID and secret. You will need to register yourself as a Facebook developer, which is free of charge but requires you to have a Facebook account. A new Facebook application can be created at https://developers.facebook.com . Under the Apps tab you can add a new application of type Web/WWW. Next you need to assign an application ID. This can be any name that helps you and your users to identify the application. As your users may eventually see the application name it is good practice to use the site name or something that closely describes your application. The actual category for your application and whether it is a test version of another Facebook application do not have any influence on the functionality and can be set to the values that best describe your project. The site URL for a Facebook application that is used with a local development environment should typically be set to http://localhost:3000. The correct URL setting can be taken from the configuration dialog shown by Meteor. Once you have made these settings, Facebook requires a contact e-mail to be set up for the application before you can activate the application. Navigate to the application dashboard on the Facebook Developer site and enter a contact e-mail in the settings section (see Figure 2). Finally you need to activate the application in the Status & Review tab. Figure 2: Settings for a Facebook application to integrate with Meteor An activated Facebook application can be used to authenticate users. The last step to implement logging in via Facebook is to configure the Meteor application. CONFIGURING Open the Meteor application in the browser and click on the Facebook button to bring up the configuration dialog as shown in Figure 3. Figure 3: Configuration dialog for Facebook integration Besides the basic instructions on how to create a Facebook application the configuration dialog lets you add the application credentials (App ID and App Secret) as well as a login style. The default is to use a popup-based dialog, which means the application window will remain when the user logs into Facebook and a new window with the Facebook dialog is opened. In contrast, the redirect-based login style will leave the application, redirect the current browser window to Facebook, and reload the entire application once the authentication was successful. Unless you plan on running your application inside a Cordova container on mobile devices13 it is preferable to use the popupbased login. Save the configuration and users can start logging in via Facebook. Should you have misconfigured the application you can either manually delete the configuration information from the meteor_accounts_loginServiceConfiguration collection inside the MongoDB or simply issue meteor reset to empty all collections. REMEMBER All oAuth configuration is stored inside the application database. Whenever you issue the meteor reset command to empty the database it will also remove all oAuth configuration data from the database. AttachmentSize fig1.jpg20.48 KB fig2.jpg40.99 KB fig3.jpg41.34 KB

Posted by on 12 February 2015 | 6:38 am

My "Final Quadrilogy" on Java crypto, featuring Dual Control for PCI compliance

In 2013, I was a Linux sysadmin, PostreSQL DBA, and erstwhile Java developer for a payment switching company, who was preparing for their first PCI assessment. Besides securing and virtualising their infrastructure - with KVM, virtual firewalls, and ssh forced commands - which kept me quite busy, there was this PCI requirement for "dual control" and "split knowledge" which was a show-stopper.  "The Final Quadrilogy" series: Featuring Dual Control encryption, SSL, keytool, Trust Managers etc "Dual Control" requires that your sysadmin cannot access the keys used to encrypt credit card numbers. Because otherwise the sysadmin could "go rogue" and decrypt all the credit card numbers into plain text for nefarious purposes. I guess it must have happened a few times, hence the requirement. The general solution seems to be expensive "key management servers," but we decided to roll up our sleeves and put a minimal solution in place that would satisfy this PCI requirement. For this I developed an opensource dualcontrol package. We used this code and passed our PCI assessment - yay! In conjunction with developing and testing the code, I drafted the article "Dual Control" on my github wiki. But the problem with the "Dual Control" draft article, is that I got carried away with it, and it became too long, with various tangential ventures in aspects of Java crypto. So I began breaking it up into a series. I split out two smaller articles, namely Local CA and Explicit Trust Manager. The Dual Control article was still a bit too long, and I wanted to subdivide it further, but I never got around to that. Now, after a year, I decided to name and publicise this series... The Final Quadrilogy And so, ladies and gentlemen, I give you, in one fell swoop, The Final Quadrilogy with its four articles, namely Dual Control, Explicit Trust Manager, Client Authentication and Local CA, and hope that you never have need to read any of it, as it's very dry crypto stuff, and rather drawn out. Especially Dual Control and most of all Local CA, which delves into Java SSL crypto quite deeply. Explicit Trust Manager are Client Authentication are at least relatively "short and sweet." In brief, the four articles are as follows: "Dual Control" presents our "dualcontrol" package for satisfying the PCI DSS requirements for "dual control" and "split knowledge" with respect to protecting data-encrypting keys. "Explicit Trust Manager" presents a custom X509TrustManager that only trusts client certificates that are explicitly imported into our truststore, for a secure "private network" of clients connecting to a "private" Java server. In "Client Authentication," we propose a dynamic trust manager to automate certificate enrollment, e.g. where new clients' certificates are imported into an SQL-based dynamic truststore. Finally, "Local CA" discusses how one could setup a local private CA facility to issue client certificates. These four articles are listed on the wiki page: The Final Quadrilogy. Move over Java, here comes Angular and Node Having completed that PCI project by the end of 2013, I got another job in 2014, and had a very busy year, introducing myself to various new technologies, notably AngularJS, Node.js, and Redis, and trying to reinvent myself as a "web developer" of sorts. Consequently I guess my love affair with Java has ended after 15 great years. I've fallen in love with JavaScript, Node microservices, and Redis. In short, I've become one of the following types ;) The industry of one's employment naturally influences one's technology choices. I took employment in the digital news publishing industry, and it changed me. In support of Angular apps, Node offers language homogeneity, JSON nativity and even isomorphism. On top of that, by using Redis as an in-memory database wherever possible, we can improve performance to please our consumers.. For me. there's probably no more Java, no more Tomcat, and maybe even no more SQL. On the upside, I feel positively rejuvenated. I've decided to switch to TypeScript for our next Angular project, and I'm looking forward to AtScript and Angular2 in future, not to mention trying out React. Witherto this blog I don't bear to think that this is my last posting on this blog. If so, then hopefully I saved the best for last, with this crypto quadrilogy, at least for some. Actually in the coming months I may even post a blog article on each of the four articles in this quadrilogy, to make those specific resources easier to find from an SEO perspective. Also I might blog sometime about my last Java pet project, Chronic, which is a multi-tenant cloud-based monitoring system, incorporating some PCI requirements. While it is abandonware, it had some sweet crypto, and is something I might want to re-imagine in Node some day. Until then, find me on twitter: @evanxsummers

Posted by on 7 February 2015 | 11:03 am

RMI Unpluged

I've just finished tuning a client's application where one of the items on the table was to find the source of calls to System.gc(). Using Censum made easy work of understanding the source of the calls. The team I was working with not only missed that these calls to System.gc() where creating havoc with their end users experience, they didn't even realize that something, some where was messing things up! It's not to say that developers are completely oblivious to the issue. Developers have gotten better about not placing calls to System.gc() in their code, but they often still don't see the call being made in their GC logs. One of the confusing causes of unwanted calls to System.gc() comes from Java (typically Java EE) applications that have remote objects, and therefore use RMI. In the early days these calls came into applications at the rate of 1 a minute and as you can imagine, it caused a lot of consternation for those analyzing the performance of Java EE applications making use of Session or Entity beans. After much discussion, the call rate was reduced to the current rate of once an hour. Better but it can still be disruptive as much as it can be useful. Lets expose a little bit of how the JVM works by digging into how RMI plays with the Garbage Collectors. The Remote Procedure Call (RPC) protocol (originally written in C) allowed one process to call an exposed function in another process. The function in the other process was expected to manage all of it’s resourses on it own. For example, if it allocated memory, it was responsible for freeing it. The only piece of management that relied on the “client” doing the right thing was to shutdown the connection. Even then, a broken socket would cause the RPC library to close down the connection on its own. Move forward and we can see that the RPC style of removing is re-implemented in Java with RMI and CORBA. Together, these protocols expose classes that you can instantiate and interact with, in a remote JVM. Without getting in too deeply into how all this works one can quickly see that this leaves us with a problem. In Java, all objects that are unreachable will be garbage collected. For a remote JVM to access an object in our heap we must hold a pointer to that object in the remote JVM's behalf. This implies that to clean up, the remote JVM has to some how signal when it's finished with the remote object. Given the nature of the resources needed to make all this work, the implementors of RMI decided that they should force a call to a collection of tenured space on a regular basis. In practical terms this means, RMI makes regular calls to System.gc(). If you look deep inside RMI you’ll run across the class ObjectTable. That class is responsible for retaining the roots of all objects that support a remote call. All of the objects added to this table are wrapped in a WeakReference. Further more, ObjectTable manages it's own = l) {                        /* Do a full collection.  There is a remote possibility                         * that a full collection will occurr between the time                         * we sample the inspection age and the time the GC                         * actually starts, but this is sufficiently unlikely                         * that it doesn't seem worth the more expensive JVM                         * interface that would be required.                         */                        System.gc();                        d = 0;                    }                    /* Wait for the latency period to expire,                     * or for notification that the period has changed                     */                    try {                        lock.wait(l - d);                    } catch (InterruptedException x) {                        continue;                    }                }            }        } The default value for latencyTarget is 3600000ms. Oddly enough, you can override this by setting your own latency target in code as follows.     public static void main(String[] args) throws Throwable {        System.out.println( “latency target: “ + GC.currentLatencyTarget());        System.out.println("turn on GC");        LatencyRequest request = GC.requestLatency( 1000);        System.out.println( “latency target: “ GC.currentLatencyTarget());        Thread.sleep(6000);        System.out.println("turn off GC");        request.cancel();        Thread.sleep( 6000);    } If you run this code with the flags -verbose:gc and -XX:+PrintGCDetails, you will see a call to System.gc() made once a second for 6 seconds. The output you should see will look something like; latency target: 0turn on GClatency target: 1000[GC (System.gc())  5243K->792K(251392K), 0.0010124 secs][Full GC (System.gc())  792K->582K(251392K), 0.0045390 secs][GC (System.gc())  3203K->678K(251392K), 0.0006147 secs][Full GC (System.gc())  678K->571K(251392K), 0.0108860 secs][GC (System.gc())  1882K->571K(251392K), 0.0006402 secs][Full GC (System.gc())  571K->568K(251392K), 0.0060488 secs][GC (System.gc())  568K->568K(251392K), 0.0003195 secs][Full GC (System.gc())  568K->568K(251392K), 0.0018367 secs][GC (System.gc())  568K->568K(251392K), 0.0005905 secs][Full GC (System.gc())  568K->568K(251392K), 0.0028363 secs][GC (System.gc())  568K->568K(251392K), 0.0003654 secs][Full GC (System.gc())  568K->568K(251392K), 0.0018081 secs]turn off GC If ObjectTable is becomes empty, it will reset the GC latency to 0 which will overwrite your settings and turn off the GC::run method. If another RMI request is made, the target latency will be set to the preset value for RMI. This implies that any settings we make in code are subject to change at any time. A safer way to set the GC latency for RMI is to set the system properties sun.rmi.dgc.client.gcInterval and sun.rmi.dgc.server.gcInterval. Generally I don’t find these extraneous calls to System.gc() to be useful so I often tune down the values to as much as Long.MAX_LONG milliseconds. However, if you are using RMI and tenured is never collected, it’s likely that you want to schedule a Full collection simply to recycle things like file descriptors. File descriptors in particular a special as they are processed with finalization, which means a full GC must run in order for these objects to be inserted into the finalization ReferenceQueue. Final note, there are other sources of JDK internal calls to System.gc(). These include: * Use of FileChannel.map * Use of ByteBuffer.allocateDirect(). The later will make the call if reference processing isn’t keeping up and you are hitting MaxDirectMemorySize. Yet Another Final Note, Yes, I know the Java API spec says that a JVM can ignore calls to System.gc() if it so chooses to. The reality is, in OpenJDK all calls to System.gc() are honoured unless -XX:+DisableExplicityGC is set on the command line. If not, the calls are synchronized resulting in all of the calls being stacked up all running one right after the other.... I have an expercise in my performance tuning workshop that does just this and believe me, it messes things up very badly. People are always looking at me very badly when they finally sort out what is happening. But then, if they were to use Censum. they'd see the problem in seconds! In a note from Charlie Hunt... he kindly pointed out that I forgot to mention that using -XX:+ExplicitGCInvokesConcurrent is an option for CMS and G1 to avoid the single threaded Full GC that typically is triggered with a System.gc() is called. Thanks for reminding me Charlie.

Posted by on 27 January 2015 | 10:44 am