Secure Coding in Java: Bad Online Advice and Confusing APIs

October 4, 2017

For programmers and software developers, the Internet forums provide a great place to exchange knowledge and seek answers to concrete coding conundrums. Alas, they are not always the source of accurate information.

A group of Virginia Tech researchers has analyzed hundreds of posts on Stack Overflow, a popular developer forum/Q&A site, and found that many of the developers who offer answers do not appear to understand the security implications of coding options, showing a lack of cybersecurity training.

Another thing they discovered is that, sometimes, the most upvoted posts/answers contain insecure suggestions that introduce security vulnerabilities in software,…

Getting Started with Helm on OpenShift

OpenShift Blog

October 4, 2017

Helm needs little introduction as a popular way of defining, installing, and upgrading applications on Kubernetes. But did you know that it’s just as easy to install and use Helm on OpenShift as well? No special magic is required, making it straightforward to use Helm Charts on OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (version >= 3.6) or OpenShift Origin (version >= 3.6).

This post will walk you through getting both the Tiller server and Helm client up and running on OpenShift, and then installing your first Helm Chart. It assumes that you already have the OpenShift oc client installed locally and that you are logged into your OpenShift instance. If you don’t have access to an OpenShift instance right now, you can sign up for free access to the OpenShift Online Starter plan.

Note that this post is solely an illustration of how OpenShift and Helm can run together; Helm is not a technology supported by Red Hat. If you are looking for a Red Hat supported way to define and install applications, please see OpenShift Templates and Ansible.

How to ‘Git’ Your First Contribution to the Open Source Community

David John Coleman II

October 4, 2017

This article contains some of the tips and lessons that I learned in achieving my first successful merged pull request to open source with some examples from my personal experience.

Background: planting the seeds for open-source collaboration

Collaboration is the fulcrum of Holberton School, the full-stack software engineering program in San Francisco where I received my software training. We have learned to manage our software systems and code bases on the Ubuntu distribution of Linux, and we use many other open-source technologies such as MySQL, Docker, VirtualBox, HAProxy, Emacs, GCC, git, and more. With this foundation, as we neared the end of our first 9 months of training, our leaders challenged us to begin contributing to the open source community; I decided to take on this challenge.

“You have to start somewhere”

Unfortunately, most new engineers face many challenges when trying to contribute to the open source software community. In no particular order, these are some of the challenges that I faced in my experience:

1. Contributing Guidelines: Documentation, Style, Methodology:

After the excitement of your first pull request, you may have felt disappointed after seeing an automated message similar to this one from the Linux repository on github:

” Thanks for your contribution to the Linux kernel! Linux kernel development happens on mailing lists, rather than on GitHub… So that your change can become part of Linux, please email it to us as a patch. Sending patches isn’t quite as simple as sending a pull request, but fortunately it is a well documented process.”

Or, you may have been immediately redirected by a personal message from Linus Torvalds himself.

Qwi2hES-92D1_ruVrU1bwAKmVRboces_O4w8nLIe

When you make a pull request without reading the Contributing Guidelines.

Spending hours learning how to properly make a pull-request and properly document the code and pull request can be overwhelming for many. It was overwhelming for me, even though I am certain that learning such practices would improve my own collaborative, engineering, and development skills.

2. Advanced and large code bases:

The reality of entering the world of professional engineers as a student or new engineer presents with the difficulty of having to learn new code. This may include spending hours trying to learn code from immense systems and advanced functions before that you have never seen before being able to meaningfully contribute to the code bases. This presents as a time constraint since most beginners have to spend a lot of time learning and understanding the code.

3. Competition:

There are many people eager to contribute to open source projects, who jump at opportunities to help fix a repository’s listed “issues” or make other minor improvements by refactoring code or fixing grammar mistakes in the documentation. A healthy thought is to not be threatened by such collaborators nor view them as competition. However, as a student seeking your first opportunity to help contribute to open source projects, such people quickly take much of the work that a beginner would be able to help with. In my case, these other contributing engineers inspired some of my competitive instincts, and so after a few ‘losses’ or missed opportunities, I did indeed feel like a defeated loser. Similar to the speed of Stack Overflow’s question response time, which can be within seconds, many open source projects’ issues have someone working to resolve them before I could even understand what the issue was.

Later I learned at DockerCon 2017, that many top companies have paid engineers, whose only job is to contribute to major open-source projects (see below image: Commits of committers per hour). This discouraged me from trying to contribute to major projects in the 1 – 2 hours of free time that I had per day when the professionals were spending 8 hours per day trying to do the same thing. The study, Paid vs. Volunteer Work in Open Source by: Riehle, Riemer, Kolassa, Schmidt, shows that About 50% of all work contributed to the open source software projects in the study occurred on the days Monday to Friday, between the hours 9am and 5pm. This does not prove, but suggests that these contributions were a part of some engineers’ employment.

EiCQ0gMw6rMIKqR6ehx8I8pswO8khUM5i6od91d6

Commits of committers per hour (to open source projects). Source: http://dirkriehle.com/wp-content/uploads/2013/08/paid-v8-final-web.pdf

4. Ghost Repositories

Indeed my first Pull Request to an open source project was to a repository that had no activity for the previous 4-5 months. I saw that the pull request history for the repository had many contributors and successfully merged pull requests, and so I was motivated to contribute to the repository. I was a little concerned that the most recent pull requests had not been merged to master, but I ignored this concern because I assumed that the changes were not accepted for the reason of failing the CI (continuous integration) tests. After I passed the CI tests in my forked repository, I made the pull request. However, I failed the CI test in my pull request to the parent repository, which is when I realized that the current master build, due to the most recent merged pull request to master from April 2017, had code that was responsible for failing the CI tests. I submitted an issue with a notification of this issue along with my pull request that fixed this issue and updated other code. Months later, neither my pull request nor my issue were reviewed nor commented on. I also noticed that the author has no activity on the repository since April 2017 nor has the master branch has been updated. Perhaps, the author is very busy or going through tough times, so there may be a decent explanation. Nevertheless, since I interpreted my first contribution as being entirely ignored by any contributor to the repository, I felt unimportant and defeated.

_nrLE5SpC8NBjzWTJa6a2Z8KUJ6DPtsHyQJ9-18J

Last Merged Pull Request (failed CI tests, 4 months old).

Always a lesson, never a failure

All of the above difficulties, refined my GitHub manual parsing skills so that I focused on these main priorities:

Contribution Tips

Ensure that the repository is open to pull requests from new users.
Ensure that you can handle the contributing guidelines for methodology/ documentation.
Ensure the repository has been recently active in comments and that it has merged pull requests; or if not, at least that the most recent pull request has activity or reasons why it was not merged.
Ensure that you understand the code related to the issues and/ or any of the code anywhere in the code base.
Ensure that you understand at least one of the current issues.

Once you decide to make a contribution

Know how to make a pull request to a repository that you are not an official contributor to (hint: fork the repo).
Ensure the contribution idea provides value (perhaps base it off of an issue).
Start with a small change to evaluate how the repository’s maintainers respond to your pull request.
Keep a clean commit history for your pull request.

$ git commit --amend

This command opens up an interactive editor with the most recent commit message.
Change the message to what you want it to be, then save/quit. Any other additions you have made and added will be added to the most recent commit.
It should be executed after $ git add ….
If the commit that you overwrite is already pushed to a branch on the origin repository, then you will have to run $ git push –force origin [YOUR BRANCH].
Note: if you are making a force push be very careful because you will overwrite the repository you are pushing to. Be sure to make backups if you are unsure of what you are doing.

$ git rebase --interactive HEAD~[NUM]

This command opens up an interactive editor with the most recent ‘NUM’ commits.
Next to each commit, there will be the message “pick”. To remove this commit message, replace “pick” with “squash”. This removes the message and adds the saved code updates to the next previous commit before the squashed commit. Since changes are added to previous commits, you cannot squash the most previous commit from the interactive mode.
Then, save/quit, which will open another interactive editor.
You can optionally write a message in the bottom of this editor or write one comment to replace all of the squashed comments.
Then save/quit again.
Finally, run $ git push –force origin [YOUR BRANCH], to add these changes to another origin repository.
Keep in mind all of the maintainers requests in their review of your pull request and in the repository’s contribution guide (CONTRIBUTING[.md or .txt])
Test your code! Use the Continuous Integration tests. This might mean that you need to include a github integration in the repository that you forked to make your contribution. Test locally and in different environments.

My First Merged PR to Google open source

I first discovered Google’s Open Source Community from a mentor of our program, Nicolas Thiébaud, currently a software engineer at Google. Next, I browsed projects, in Google’s open source github group, written in languages that I was familiar with such as Python. I found a neat project called, ci_edit, which is a text editor with a command line interface. After browsing the repository, I positively confirmed that I could handle all of the points in my lessons learned checklist. I realized that while this was a text editor, it needed to be executed following the absolute path to the executable in the installation directory, or it had to be manually added to the execution PATH. I did consider creating a debian package, but decided not to because I had not done this ever and I thought that it would take more time. So I decided that my first contribution would be to create a bash installation script that would execute bash commands to:

1. Create or update an installation package

2. Add a symbolic link to the executable in PATH.

More of the functionality of the contributions and my explanations can be viewed in the comments of the pull requests:

https://github.com/google/ci_edit/pull/40
https://github.com/google/ci_edit/pull/53

Mistakes and Follow up

Hopefully, when you make your first pull request to the open source community, you will be working with a great team. Thankfully, the people I worked with were very helpful, and so I learned a lot from the suggestions from the maintainer of the repository. Some of the biggests tips were to be more verbose in my documentation, have better secure measures to avoid user error, and to add some better functionality for the user. I did incorporate all these changes; however, there were 2 major bugs (so far discovered) in the first pull request even after it was merged. One of the bugs was due to the methodology that the maintainer made in one of the lines of code, and another was because of an error on my part. Had I spent more time with local testing, I would have found this error. Thankfully, another contributor to the repository found the bug almost immediately and made us aware of it. My second pull request fixed these bugs and updated some of the documentation.

More Lessons Learned

When you make your first pull request, be sure to adequately test your code locally in various environments, incorporate any continuous integration tests, and if possible have a peer review your code. In my case, I believe that my haste to make a contribution before anyone else did and my concern that I would put in too much effort without anyone accepting my update were the main factors that motivated me to skip some of the local tests that I should have been thinking about. Also, if you don’t think the repository is maintained by helpful or currently active people, find a repository that has great collaborators. In my case, Dave Schuyler, @dschuyler, had a very collaborative and supportive way of working with me. He gave suggestions for updating my code, and always interacted respectfully about the problems he saw in my code. Additionally, he actively communicated with me throughout the github.com review process.

Now go forth and maintain some open source code!

Let’s GIT It: Installing GIT on CentOS

October 3, 2017

This will be entirely a tutorial article aiming to walk you through installing GIT on CentOS and integrating it with GITHUB. Wew! Let’s get to it!

What’s GIT?

GIT is a version control tool that helps you to maintain and sync versions of things like files, directories, or code between between developers and teams. People use it to make sure everyone is working on the same version of code, to track changes and maintain progress. GIT is reliable, widely used, open and free! So let’s take you through the setup.

Installing GIT:

There are actually two ways you can set this up:

Method 1

The simplest way to install git is using CentOS’s own YUM package manager and you won’t need any prerequisites for this installation which is nice.

1. Login with root credentials.

2. Use YUM to install it using

yum install git

3. The installation will handle itself automatically, just hit ‘y‘ when prompted.

4. Once GIT is installed you can check the version using

git --version

This basically does it. But let’s keep going and make sure you’re up to date:

Updating GIT

1. You need to know which distro and version you’re running. You can check this quickly with:

uname -a

2. While getting the base version of GIT is simple, you do need a couple of prerequisites. The first is getting RepoForge (formerly RPMForge repository, that you can grab from repoforge.org/use. Find and download the appropriate package for your distro.

3. Once it’s downloaded, you will need to edit the repo and set it to enabled = 1 using

vi /etc/yum.repos.d/rpmforge.repo

4. Finally run the install command to update it

yum install git

As far as this method goes, that’s all there is to it. But as you can see, to use this method you really need to have more information about your system beforehand. However, if you want to use GIT independent of the distro you’re running.

Method 2

In order to use this method, you’ll need a longer list of prerequisites installed.

1. Use these commands to install the prerequisite software

sudo yum groupinstall "Development Tools"

sudo yum install gettext-devel openssl-devel perl-CPAN perl-devel zlib-devel

2. Afterward go to the GITHUB projects releases page and download the latest one:

wget https://github.com/git/git/archive/v2.13.3.tar.gz

You can also rename the file if you like in the same command using:

wget https://github.com/git/git/archive/v2.13.3.tar.gz git.tar.gz

3. Once it’s downloaded, extract it and enter GIT’s root directory /git. Then configure it using the command:

Make Configure ./configure --prefix=/usr/local

4. Now that it’s configured you can finall install it to your system with:

sudo make install

Aaaan you’re good! Now that it’s installed, you can verify which version you’re using:

git --version

Integrating With GITHUB

Finally all that’s left is integrating your local GIT with the GITHUB. To begin, you’ll need to put some information into your local configuration, used to identify your changes in commit messages.

git config --global user.name "Your Name" git config --global user.mail "your@email.here"

Note: Hopefully it’s obvious that you should be using your own infromation in the above script

Now just use the following command to see if your information:

git config --global -e

You can also use

git config --list

Generating SSH Keys:

SSH keys are great because they let you connect to other servers without using your password every single time. Check out our article about other neat things you can do with SSH, since it’s a pretty versatile tool.

For our purposes, we’re going to generate a key and add it to our .ssh directory:

ssh-keygen -t rsa -b 2048 -C "your@email.here" ssh.add ~/.ssh/id_rsa

Now what’s left is adding the pub file (which is id_rsa) to the GITHUB profile.

Adding Pub File to GITHUB

Login to your GITHUB profile, go into your Personal settings page and get to the SSH and GPG keys panel. Name the key in the Title field.

Then open the pub file you created (id_rsa), copy its contents and paste them into the Key textbox in the SSH and GPG keys.

Now that this is done, your local git can now maintain an SSH connection with remote GITS!

Cloning a Repository from GITHUB:

You’ll usually need to get a repository from GITHUB, just due to the nature of what “version control” implies; you need to get the latest version of the materials you’ll be working with.

If you’re connecting to GITHUB using SSH, like we helped you set up above, you’ll be using this command:

git clone ssh://repo path

If you’re not going to be connecting SSH, you can use a universal command:

git clone https:// repo path

That about does it for this article! We went over finding the right file, download, and installation of GIT on your local machine. Then we went over connecting with SSH and cloning a remote repository. If you got any questions about this, or any other article, you can comment here to hit us up on Facebook or Twitter.

Finally, we’ll leave you with a table of common commands you’ll be using with GIT.

-Until next time

by Santosh Kumar D

git clone	Copy repos from remote servers
git add	Add files to your local machine
git status	Get a list of how many files are being committed
git pull	Pull code from remote repo to a local one
git push	Push code from your local repo to a remote one
git rm	Remove files from local repo
git branch -a “remote url”	Create a branch in master
git merge	Merge branches
git reset	Resets your index and working directory to the last time you made a commit
git log	Log of all commits made
git rebase	Merges a side branch into the master branch

How OpenBSD and Linux Mitigate Security Bugs

The Linux Foundation

October 3, 2017

At the upcoming Open Source Summit Europe + ELC Europe 2017, to be held in Prague, Czech Republic, Giovanni Bechis will be delivering a talk focused on tools that help improve software security by blocking unwanted syscalls.

Bechis is CEO and DevOps engineer at SNB s.r.l., a hosting provider and develops web applications based on Linux/BSD operating systems that is mainly focused on integrating web applications with legacy softwares. In this interview, Bechis explained more about his approach to software security.

Linux.com: What’s the focus of your talk?

Giovanni Bechis: The talk will focus on two similar solutions implemented in Linux and OpenBSD kernels, designed to prevent a program from calling syscalls they should not call to improve security of software.

Moby Summit Los Angeles Recap

Moby Project

October 3, 2017

Two weeks ago, member of the Docker team and Open Source community were in Los Angeles for a Moby Project Summit alongside Open Source Summit North America (previously known as LinuxCon). This was the 3rd Moby Summit edition since Solomon Hykes introduced the Moby Project: a new open-source project to advance the software containerization movementat DockerCon 2017 in Austin.

This summit is for container users who are actively maintaining, contributing or generally involved in the design and development of the Moby Project and it’s components: runC, containerd, LinuxKit, Infrakit, SwarmKit, HyperKit, DataKit, VPNKit, Notary, libnetwork, etc.

We followed the same format as previous summits with talks in the morning and birds of a feather (BOF) sessions in the afternoon. Unfortunately the talks were not recorded but you can find the slides below:

How to Docker Compose a Developer Environment: An Open Source Example

Dev.to

October 3, 2017

As we mentioned in a previous blog post, you should strive to have a simple and repeatable way of setting up a dev environment for your project.

In this blog post we are going to go into details of an example from one of the open source projects at Akvo.

IMHO, having a painless way of setting up a dev environment is one of the key aspects to remove some of the friction for contributors to open source projects.

Akvo Lumen Architecture

The project that we are going to look at is called Akvo Lumen, which is an “easy to use data mashup, analysis and publishing platform”.

Why the CDC Wants in on Blockchain

MIT Technology Review

October 3, 2017

“Public health and blockchain really do belong together,” Nasr says. Success depends on the ability of peer organizations—the CDC, state and local health agencies, hospitals and clinics—to collaborate effectively and efficiently, and the “currency” for that collaboration is data, he says. “Moving that data from one peer to another in a secure manner, in a compliant manner, and in a transparent manner—as quickly as possible—is a key part of the business model.”

Blockchains, like those that underlie Bitcoin and other cryptocurrencies, are maintained by networks of computers—instead of a single trusted authority…

Learn How Stripe, Datadog, and MailChimp Monitor Production Deployments at Forge by Sentry

Richard Huffaker

October 3, 2017

The Thrilla in Manila. The Beatles first appearance on Ed Sullivan. The Apollo 11 moon landing. These were all great events, and we’d guess you weren’t able to attend any of them. That’s too bad, because taking part in a great event is significantly better than missing out on it. One of many reasons to attend Forge by Sentry in Napa, CA from Oct. 29th to 31st.

Wait, did we really just compare a software conference to the moon landing? Sure. While we’re at it, it feels fair to point out that tickets to Forge are significantly less expensive than a trip to the moon.

Sentry is bringing leaders in the software industry together for a single purpose: to spend three days diving into technical content on the industry’s future, all while connecting with peers over great food and even better wine. Alright, that’s technically more like three purposes, but attendees get them all with the price of their ticket.

Forge is a single-track conference, ensuring there’s no risk that you’ll miss any of the fantastic speakers we’ve lined up. You’ll hear speakers from Optimizely, Zeit, LightStep, and Muve Health. Click here to check out our full schedule and learn more.

Additionally, many of our own engineers will be on-hand to help you get more from your monitoring experience than ever before. And there’ll be plenty of opportunity to ask questions of both us and our event speakers at the reception (in a wine cave), dinner, and after party that runs throughout the evening on Oct. 30th. Think of it as the smartest Halloween party you’ve ever attended.

YJCA7q-qr_ifYyMN4rHlR4sj56CoAZYXrotfRmFF

Forge takes place at the beautiful Meritage Resort and Spa in Napa Valley, and your ticket includes a one-night stay, as well as shuttle service to and from San Francisco or SFO. The resort is even on Bordeaux road. Why drink wine at home on some regular old street when you can attend Forge and get your wine directly from the source?

Forge is the first conference of its kind: by software developers, for software developers, about the future of building and using software. We hope to see you there!

Behind the Masq: Yet More DNS, and DHCP, Vulnerabilities

Google Security

October 3, 2017

Our team has previously posted about DNS vulnerabilities and exploits. Lately, we’ve been busy reviewing the security of another DNS software package: Dnsmasq. We are writing this to disclose the issues we found and to publicize the patches in an effort to increase their uptake.

Dnsmasq provides functionality for serving DNS, DHCP, router advertisements and network boot. This software is commonly installed in systems as varied as desktop Linux distributions (like Ubuntu), home routers, and IoT devices. Dnsmasq is widely used both on the open internet and internally in private networks.

We discovered seven distinct issues (listed below) over the course of our regular internal security assessments.