In part 1 of this blog data was exfiltrated from a workstation to GitHub using Git. In part 2, we’ll dive into investigating the data on a Windows 10 workstation to determine whether any sensitive data was exfiltrated to GitHub using Git. The investigation focuses on analyzing traces left on the device, excluding network activity logs.
In this two-part blog post, we’ll explore how data exfiltration to GitHub can be carried out from a Windows 10 workstation and how to investigate such incidents. Part 1 focuses on how data can be exfiltrated using Git and GitHub. In Part 2, we’ll dive into forensic techniques to retrieve evidence of data exfiltration and determine what was sent from the workstation.
Struggling with merging multiple repositories together into one (mono) repository? You wanna preserve your valuable git history?
This blogpost will show you how to do this step-by-step.
When you look at how a given organization develops software over time, it’s not uncommon to spot evolutionary patterns that mimic what we see in nature. Particularly where micro services are involved, you might well be able to deduce which services came first, and which were developed later in time, by looking at various subtle variations in project structure, tools, dependencies, build pipelines and deployment descriptors. Later services copy elements from the initial template services, apply variations to fit their needs, and successful variations are again used in future services, or even applied in the original template services.
Variations from service to service are essential to maintaining a vibrant engineering culture, with room for experimentation within appropriate boundaries. Over time however, all the subtle variations can make it harder to reason across services, particularly when you want to apply broader changes.
In this blogpost I’ll outline, and provide various samples of, how I harmonize such diverse micro service landscapes, and the scripts I use to reduce the accidental complexity in maintaining the various variations.
Many projects force their code to be formatted. We use spotless for this purpose. It can check for propper formatting, and also format the code for you. Then build pipeline checks if the code is properly formatted. Failing pipelines due to formatting errors are annoying and cost a lot of time and money. This blog proposes a solution.
Git has some hooks that you can install. Hooks are scripts that are run at specific events such as pre-commit, post-commit, pre-push, prepare-commit-msg, pre-rebase, etc. I created a script that formats the code in the pre-commit hook. It does:
This scripts tracks any of the java or kotlin files in the staging area.
Formats the code using spotless if there are any java/kotlin files.
It adds the files from step 1 again to the staging area, to pick up the re-formatted changes.
The commit now contains formatted code. This saves a lot of time, instead of finding out that the build failed 5 minutes later.
The pre-commit hook looks like:
If you use another formatter, you can easily update the script.
You can install it by running the following command in your repository root:
We have all gotten acquainted with git in the last decade. We have adopted a way of working that has made it easy for all of us to work together in large teams and reduced the times our code changes collided to a minimum. When we do run into problems, they’ve culminated to a single important moment; the merge. We all know the merging feature of git with all its pro’s and con’s. But what about another feature of git: rebase?
