Improve code reviews using pull request templates

Daniel Luque Quintana — Tue, 09 Jul 2019 10:12:55 +0000

At The Neon Project we care about our internal processes: we believe they’re important, we design them meticulously, we use them, and we improve them as we learn from their performance in the real world.

One of the most important processes when developing software is code review, where at least one teammate will review your code. This process improves the quality of the code since, many times, code that seems easy to understand for the author is not as clear for the rest of the team. Everyone involved in the code review learns: learn how to give feedback, learn how your partners think and write code & learn technical details.

To make the code review process as easy and quick as possible, the more context we give our colleagues about what we have done and why, the better. After reviewing the Dev.to Github repository and seeing some pull requests, I thought there was a way to improve our code review process in The Neon Project: using templates for pull requests.

A pull request template is, basically, a file containing markdown text that is added to your pull request description automatically when it is created.

The file must have the name pull_request_template.md. In our case, this file is in a hidden folder named .github, but you can put it wherever you want (more information about Github pull request templates here)

Our template consists of the following parts:

A reminder: as we use Jira for project management, a very useful feature is to link a PR to a Jira issue by adding the issue code to the PR title. This way we can see its status from Jira
Type of PR: consists of 3 checkboxes, indicating whether the pull request is a bugfix, a new feature or a refactor.
Description: a brief description of what we can expect from PR. This part is essential for the person who reviews the code to know, in one pass and briefly, what to expect in the code.
Screenshots (if there are changes of UI): one of the problems of the PR that have visual changes is to know what has changed or what is the final result. In general, the process to execute the code locally and see it won't be fast, the person will have to download the code changes in their machine, have the environment configured, etc. A few simple photos and/or videos will save a lot of time to see what's new. Personally, I use macOS screenshots and Imgur to upload them.
(optional) a gif that describes how it makes you feel: because there's always a good reason to put gifs, right? 🤓

In this simple way, we improve the code review process: more information and context so that code reviewers can understand quickly what they are going to review and thus are able to deploy code more often 🚀

One more thing...

After the announcement that Github has acquired Pull Panda, we have integrated it into our process and we are very satisfied! For those who don't know it, Pull Panda allows you to remember through Slack when a contributor needs to have a PR checked, can assign a reviewer automatically and offers a series of very interesting analytics to know, for example, the average time needed to make reviews or how many took more than 8 hours. And it's free!

That's it, folks. So, how's your code review process? Any advice on how to improve ours?

Certificate Pinning your Android and iOS apps.

Daniel Luque Quintana — Thu, 30 Mar 2017 21:51:17 +0000

When we, developers, are working in the development of any kind of software, we can't forget about security ðŸ”. The minimum security measure we should use is HTTPS as the protocol to share information between a client (in this case, an Android/iOS app) and a server, followed by an updated cryptographic protocol like TLS 1.2 (SSL 3.0 is vulnerable!)
You may think that using an HTTPS is enough but in some cases like banking applications, where sensitive data may be send between our client and our server, could be risky.
By default, when making a TLS connection, the client check two things:

The server's certificate matches the requested hostname.
The server's certificate has a chain of truth back to a trusted root certificate.

What it doesn't do is check if the certificate is the specific certificate you know your server is using, and that's a possible security vulnerability: if the client is compromised and a unsafe certificate is installed, someone could do a man-in-the-middle attack.

The solution to this problem is certificate pinning: storing a certificate on our client to ensure that any SSL request made matches the one our server has. Let me explain you how to do it on both Android and iOS apps.

Â Android

OkHttp lib provide a CertificatePinner class to be added to an OkHttpClient instance. The easiest way to pin a host is turn on pinning with a broken configuration and read the expected configuration when the connection fails.

CertificatePinner certificatePinner = new CertificatePinner.Builder()
         .add("mydomain.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
         .build();
     OkHttpClient client = OkHttpClient.Builder()
         .certificatePinner(certificatePinner)
         .build();

After a request is executed, you'll see this message on the console:

javax.net.ssl.SSLPeerUnverifiedException: Certificate pinning failure!
   Peer certificate chain:
     sha256/afwiKY3RxoMmLkuRW1l7QsPZTJPwDS2pdDROQjXw8ig=: CN=mydomain.com, OU=PositiveSSL
     sha256/klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=: CN=COMODO RSA Secure Server CA
     sha256/grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME=: CN=COMODO RSA Certification Authority
     sha256/lCppFqbkrlJ3EcVFAkeip0+44VaoJUymbnOaEUk7tEU=: CN=AddTrust External CA Root
   Pinned certificates for mydomain.com:
     sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
   at okhttp3.CertificatePinner.check(CertificatePinner.java)
   at okhttp3.Connection.upgradeToTls(Connection.java)
   at okhttp3.Connection.connect(Connection.java)
   at okhttp3.Connection.connectAndSetOwner(Connection.java)

The exception will provide you the server's certificate public key hashes. Paste them on the CertifinatePinner and done! âœ”

CertificatePinner certificatePinner = new CertificatePinner.Builder()
       .add("mydomain.com", "sha256/afwiKY3RxoMmLkuRW1l7QsPZTJPwDS2pdDROQjXw8ig=")
       .add("mydomain.com", "sha256/klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=")
       .add("mydomain.com", "sha256/grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME=")
       .add("mydomain.com", "sha256/lCppFqbkrlJ3EcVFAkeip0+44VaoJUymbnOaEUk7tEU=")
       .build();

iOS

The iOS solution is not so straightforward because you need to store the certificate itself inside your app. In my case, I've used Alamofire as HTTP client lib for Swift.
First, you need to get the server's certificate in .der format and add it to your iOS project.

openssl s_client -showcerts -servername mydomain.com -connect mydomain.com:443
 </dev/null | openssl x509 -outform DER > mydomainCert.der

And now, lets enable certificate pinning: to do it we need both ServerTrustPolicy and SessionManager objects. The first one will define the hostname and certificates that will be used in the process:

var serverTrustPolicies = [
    "mydomain.com": .pinCertificates(
    certificates: ServerTrustPolicy.certificates(),
    validateCertificateChain: true,
    validateHost: true
  ),
]

ServerTrustPolicy.certificates() will return all stored certificates and the booleans will validate the certificate chain and the hostname.
Lastly, create a SessionManager object using this trust policies:

var sessionManager = SessionManager(serverTrustPolicyManager: ServerTrustPolicyManager(policies: serverTrustPolicies!))

Done! âœ”. Just use this sessionManager object to execute request

sessionManager.request("https://mydomain.com/api", method: .get, headers: headers)...

Feedback is welcome! Hope it's useful â˜ºï¸

Sources

OkHttp: https://github.com/square/okhttp/wiki/HTTPS
Alamofire: https://github.com/Alamofire/Alamofire#security

Forem: Daniel Luque Quintana

Improve code reviews using pull request templates

One more thing...

Certificate Pinning your Android and iOS apps.

Â Android

iOS

Sources