Manage GitHub Actions Artifact Storage

If you are reading this post, I hope you have already faced the error: "Create Artifact Container failed: Artifact storage quota has been hit. Unable to upload any new artifacts". If not and if you are about to set up GitHub actions for your repository, read this article before you start to avoid facing the above error down the line.

Image Credits: Pixabay@Pexels

GitHub: the famous code hosting platform stretches beyond being just a hosting platform. GitHub Actions is one such addition that automates workflows in a repository. Though GitHub is generous enough to provide free storage and computing power, there is a limit on your free meal. For more details about the quota, refer to the official document.

Product	Storage	Minutes (per month)
GitHub Free	500 MB	2,000
GitHub Pro	1 GB	3,000
GitHub Free for organizations	500 MB	2,000
GitHub Team	2 GB	3,000
GitHub Enterprise Cloud	50 GB	50,000

GitHub Quota

This article focuses on the storage limitation though similar precaution has to be taken on computation too. Let's say you have a pretty active development team or a community that keeps pushing changes every hour. Suppose your workflow builds an uber jar and packs them into docker containers using two workflow operations; you may choose to upload the uber jar to the artifact storage at the end of the build operation and download it in the deploy operation. However, if your account is a GitHub Free account (with a 500 MB storage limitation) and your uber jar size is around 100 MB, you can only have five artifacts in the artifact storage. If you didn't clear the previous builds, your sixth build will fail to upload the artifact with the following error: Create Artifact Container failed: Artifact storage quota has been hit. Unable to upload any new artifacts.

Read More

Install Oracle JDK 18 on Linux

Even though OpenJDK is available in Linux repositories, some applications strictly require Oracle Java Development Kit. This article shows you how to manually install Oracle JDK $java_version on your Linux system. This article uses JDK $java_version$java_update_no to demonstrate the installation. In the provided commands, replace the version specific paths and file names according to your downloaded version.

Version specific installation guides are available here:

• Install Oracle JDK 8 on Linux
  
• Install Oracle JDK 11 on Linux
• Install Oracle JDK 17 on Linux
• Install Oracle JDK 18 on Linux (The latest version)
  
• Install the latest Oracle JDK on Linux (Permanent link to install the latest version)
  

Oracle provides deb and rpm installers

If your Linux distribution is using DEB package format like Debian, you can download and install the jdk-$java_version$java_update_no_linux-x64_bin.deb file using the following command:

sudo dpkg -i jdk-$java_version_linux-x64_bin.deb

If your  Linux distribution is using RPM package format like Cent OS, you can download and install the jdk-$java_version_linux-x64_bin.rpm file using the following command:

sudo rpm -ivh jdk-$java_version_linux-x64_bin.rpm

However, this article explains the manual installation method which is applicable for all Linux distributions out there. Personally, I prefer the manual installation because I have more control over the changes made in the system.

Read More

Run Apache NiFi Cluster in Docker with SSL Enabled

Welcome to the fourth article in the series of Apache NiFi. The last article explained how to set up an Apache NiFi Docker container with a self-signed SSLcertificate. This article addresses the next pain point: how to create an Apache NiFi cluster in Docker with SSL enabled. Unlike HTTP cluster, setting up Apache NiFi cluster with SSL enabled in Docker introduces a new challenge: Hostname verification.

For added security, if HTTPS connection is enabled, Apache NiFi will verify the Hostname of requests. Therefore each request sent to Apache NiFi must have a predefined hostname. Not only the external requests, but peer-to-peer communication of NiFi nodes in a cluster also go through HTTPS and are subject to hostname verification. If the hostname provided in the HTTPS request does not match the hostname defined in the SSL certificate, NiFi will throw a javax.net.ssl.SSLPeerUnverifiedException.

If you are traditionally deploying Apache NiFi: individual servers with known IP addresses, it is easy to create certificates with those IP addresses. However, in a dynamic environment like Docker, the hostname of a container is defined at the runtime if you need flexible scaling options. Since Docker doesn't provide an option to define the hostname pattern in a scalable cluster, we have to stick to hard-coded Apache NiFi containers with predefined hostnames to create a cluster. The disadvantage of this method is that it is hard to scale up/down a cluster with hard-coded containers. Instead, you can also set up an HTTP cluster and create a load balancer with HTTPS frontend and SSL Termination between the client and NiFi UI. However, in this article, we will stick to the SSL configuration at the cluster level.

Read More

Run Apache NiFi in Docker with SSL Enabled

The last two articles in the Apache NiFi series discussed how to run Apache NiFi standalone server and NiFi cluster in Docker. However, those are far from production-ready because they are not secured. The next step in setting up a secured NiFi cluster is spinning up an Apache NiFi instance with SSL enabled in Docker. Though we are moving towards production-ready, this article will use self-signed certificates. In production, you should not use a self-signed certificate. In addition, you may also require additional safety measures like firewall and proxy.

Read More

Run Apache NiFi Cluster in Docker

The last article on Apache NiFi: Run Apache NiFi in Docker was for those who want to start playing with Apache NiFi. Though it was a good start to play with NiFi, it is far from production deployment. This article introduces the second stage of deployment: a NiFi cluster running in Docker using Docker Compose.

To begin with, you must have Docker installed in your system and also install Docker Compose as we are going to use Docker Compose to setup the Apache NiFi cluster. 

Read More

Resume Tips for Software Engineers in North America

Years ago as an international student preparing my resume to get my first job in Canada, I had a lot of questions and I did search a lot on how to make a resume that fits Canadian employer's requirements and style. Things have changed. Eventually, I got offers from some high tech companies and landed in a good job and now I am interviewing candidates who are like I was a couple of years ago. After looking at more and more resumes, I decided to share my experience here with a hope that will make someone's life better.

For whom this article is for? Well! for anyone looking for a new job in Canada. Especially if you are  new immigrant who has no idea about what Canadian employers are looking for, this article is tailored to your requirements. Though my experience is limited to Canada the companies I applied for are mostly US-based companies so I hope it can be applied anywhere in North America. This article is targeting only those who are in the software industry. I don't know how much it will overlap with other industries. The rest of the article is divided into two topics: 1. Resume Sections, 2. Resume Format. The first topic covers what to include and not to include in your resume and the second topic provides some formatting tips to make your resume get you a call from the recruiter.

Read More

Log4J 2.17.0 is Vulnerable to RCE. Upgrade to 2.17.1

I know the wish list of all Java developers for Santa starts with "No more Log4J vulnerabilities". However sometimes even Santa cannot fulfill all your wishes. A new security vulnerability was found in Log4J 2.0-alpha7 to 2.17.0 excluding 2.3.2 and 2.12.4.

The new vulnerability allows Remote Code Execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code.

Unlike the CVE-2021-44228 that triggered the domino effect of Log4J vulnerabilities, CVE-2021-44832 is marked as a moderated risk since it requires access to your Log4J configuration. For those who don't know, projects using Log4J with the CVE-2021-44228 vulnerability can be exploited by submitting modified HTTP requests. On the other hand, CVE-2021-44832 requires direct access to the Log4J configuration for an outsider. If somebody got the access to your system to modify the Log4J configuration, you are already doomed. Therefore, you may not need to rush to apply the patch if your system is already secure enough.

Similar to CVE-2021-44228 and CVE-2021-45105, CVE-2021-44832 also affects log4j-core only.

The CVE-2021-44832 issue particularly hasn't affect Log4J 1.x versions. However, Log4J 1.x is not maintained anymore and do not expect any security patches in case if a security vulnerability is found in the future. Based on Java versions, upgrade to the latest version with the fix for all known security vulnerabilities so far.

Java Version	Latest Log4J Version
Java 8 and later	Log4j 2.17.1
Java 7	Log4j 2.12.4
Java 6	Log4j 2.3.2

The latest Log4J versions in the above table have fixed the issue by limiting JNDI data source names to the java protocol.

Let me repeat the process for developers to identify the vulnerable Log4J versions.

Run the following command from your project folder.

mvn dependency:tree

Any Log4J dependency with a version less than 2.17.1 is most likely vulnerable or unmaintained. Maven central repository has a new column with the number of vulnerabilities in each Log4j version.

If you encounter any vulnerable Log4j versions as your direct dependencies defined in your pom file, or in your parent pom file, upgrade them immediately. Remember by defining the following dependency in your pom file, you can override the dependency defined in your parent pom file.

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.17.1</version>
</dependency>

 

Image Credits: Google

A vulnerable Log4J library can be buried under a multi-level dependency tree. If any of your libraries are using a vulnerable dependency, look for their latest fixed versions or talk to your security team.

Read More

Goodbye Log4j

ALERT Dec 16th 2021: How to Fix Log4J Vulnerability.

 

ALERT Dec 18th 2021: Log4J 2.16.0 is vulnerable to DoS attack. Switch to 2.17.0. For more details: Log4J 2.16.0 is Vulnerable to DoS. Switch to 2.17.0.

 

ALERT Dec 29th 2021: Log4J 2.17.0 is vulnerable to RCE attack. Switch to 2.17.1. For more details: Log4J 2.17.0 is Vulnerable to RCE. Upgrade to 2.17.1. 

This article is an old post introducing SLF4J. You can still refer it to learn more about SLF4J. For Log4J vulnerability related posts, check these links:

• How to Fix Log4J Vulnerability
• Log4J 2.16.0 is Vulnerable to DoS. Switch to 2.17.0.
• Log4J 2.17.0 is Vulnerable to RCE. Upgrade to 2.17.1.
  

 

After seeing so many students in last four years, I have decided to write this article about the new loggers which are widely being used by the industry. Almost all the university students I have seen are familiar with Log4j 1.x (at least heard about it) but most of them even did not hear about SLF4J and Logback. The purpose of this article is introducing SLF4J and Logback and convincing you towards them. Before getting into the topic, be informed that Log4j 1.x is not being maintained after August 5, 2015 and Ceki Gülcü the developer of Log4j came up with the new tools SLF4J and Logback. Technically, Logback is an enhanced successor of Log4j and performs better than Log4j.

He did a good job, but we have to move forward.

Read More

Log4J 2.16.0 is Vulnerable to DoS. Upgrade to 2.17.0.

ALERT: Log4J 2.17.0 is vulnerable to RCE attack. Switch to 2.17.1. For more details: Log4J 2.17.0 is Vulnerable to RCE. Upgrade to 2.17.1.

Dear Java Developers, cancel your holiday plans. Another Log4j vulnerability was reported on December 16th Thursday and a new Log4j version is released with the patch on December 18th Saturday. Log4J 2.16.0 is no longer safe.

The new vulnerability independently discovered by Hideki Okamoto of Akamai Technologies, Guy Lederfein of Trend Micro Research working with Trend Micro’s Zero Day Initiative, and another anonymous vulnerability researcher allows denial of service attack on systems using Log4j 2.0-beta9 to 2.16.0. Remember that Log4j 2.16.0 was released last week to fix the CVE-2021-44228 vulnerability and chances are high for most of the Java projects already being upgraded to Log4j 2.16.0 which is vulnerable to DoS attack now.

Similar to the previous vulnerability, the CVE-2021-45105 doesn't mean everyone using Log4j 2.0-beta9 to 2.16.0 is vulnerable. This uncontrolled recursion from self-referential lookups bug affects only if your Log4j configuration has Context Lookups like ${ctx:loginId} or $${ctx:loginId}. Though removing such context lookups where they originate from sources external to the application such as HTTP headers or user input is one way to solve the issue, it is recommended to replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC). Instead, you can upgrade to the latest Log4j version 2.17.0.

Similar to CVE-2021-44228, CVE-2021-45105 also affects log4j-core only.

Last Friday, Google published a blog post claiming more than 35,000 Java packages in the Maven Central repository are affected by Log4j vulnerability. By the time of publishing that article only 5000 artifacts were patched. That leaves 30,000 packages hanging around with vulnerable Log4j dependency. Google also mentioned that in more than 80% of the packages, the vulnerability is more than one level deep, with a majority affected five levels down (and some as many as nine levels down). This makes fixing them hard as a package maintainer you have to rely on your dependency maintainer to publish a fixed version.

Coming to the projects you have control over, you have to go through the same cycle once more to upgrade all your Log4j dependencies to the latest version 2.17.0.

Let me repeat the process for developers to identify the vulnerable Log4J versions.

Run the following command from your project folder.

mvn dependency:tree

Any Log4J dependency with a version less than 2.17.0 is most likely vulnerable or unmaintained. Maven central repository has a new column with the number of vulnerabilities in each Log4j version.

If you encounter any vulnerable Log4j versions as your direct dependencies defined in your pom file, or in your parent pom file, upgrade them immediately. Remember by defining the following dependency in your pom file, you can override the dependency defined in your parent pom file.

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.17.0</version>
</dependency>

 

Image Credits: Google

A vulnerable Log4J library can be buried under a multi-level dependency tree. If any of your libraries are using a vulnerable dependency, look for their latest fixed versions or talk to your security team.

Read More

How to Fix Log4J Vulnerability

ALERT 1: Log4J 2.16.0 is vulnerable to DoS attack. Switch to 2.17.0. For more details: Log4J 2.16.0 is Vulnerable to DoS. Switch to 2.17.0.

ALERT 2: Log4J 2.17.0 is vulnerable to RCE attack. Switch to 2.17.1. For more details: Log4J 2.17.0 is Vulnerable to RCE. Upgrade to 2.17.1.

 

Log4j security vulnerability has stolen the sleep of developers over the last week. Though it is a little late, this article explains how to identify if your project is using Log4j and how to fix the problem. Let's start with the problem description: In Apache Log4j2 versions up to and including 2.14.1 (excluding security release 2.12.2), the JNDI features used in configurations, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.

 

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

Though the Log4j you are using in your project is vulnerable doesn't mean that your project is vulnerable. If you are behind a firewall with no external access or if you don't log any user inputs, chances to attack your system are slim. However, it doesn't mean you can relax since it is always a best practice to fix vulnerabilities in the project regardless of whether you are affected or not.

Read More

Run Apache NiFi in Docker

Running Apache NiFi in Docker is a simple and hassle-free process if you know the port to access. This article explains how to get Apache NiFi running in Docker on a Linux machine. If you don't have already, install Docker first.

Read More

Install Oracle JDK 17 on Linux

Even though OpenJDK is available in Linux repositories, some applications strictly require Oracle Java Development Kit. This article shows you how to manually install Oracle JDK $java_version on your Linux system. This article uses JDK $java_version$java_update_no to demonstrate the installation. In the provided commands, replace the version specific paths and file names according to your downloaded version.

Version specific installation guides are available here:

• Install Oracle JDK 8 on Linux
  
• Install Oracle JDK 11 on Linux
• Install Oracle JDK 17 on Linux
• Install Oracle JDK 18 on Linux (The latest version)
  
• Install the latest Oracle JDK on Linux (Permanent link to install the latest version)
  

Oracle provides deb and rpm installers

If your Linux distribution is using DEB package format like Debian, you can download and install the jdk-$java_version$java_update_no_linux-x64_bin.deb file using the following command:

sudo dpkg -i jdk-$java_version_linux-x64_bin.deb

If your  Linux distribution is using RPM package format like Cent OS, you can download and install the jdk-$java_version_linux-x64_bin.rpm file using the following command:

sudo rpm -ivh jdk-$java_version_linux-x64_bin.rpm

However, this article explains the manual installation method which is applicable for all Linux distributions out there. Personally, I prefer the manual installation because I have more control over the changes made in the system.

Read More

Install MySQL 8 on Ubuntu/Linux Mint

Ubuntu official software repository provides MySQL 5.x which can be installed by following the article: Install MySQL with phpMyAdmin on Ubuntu. However the latest release of MySQL: 8.x, requires you to manually add the software repository into your system which makes the installation process little tricky. This article walks you through the end-to-end installation process of MySQL 8.

Read More