GitHub On The Go

It is hard to find anyone that does any kind of software development that doesn’t have some interaction with GitHub. Even if you don’t host your own projects there, there are so many things to study and borrow on the site, that it is nearly ubiquitous. However, when you’ve needed GitHub on the run, you’ve probably had to turn to your phone browser and had a reduced experience. GitHub for Mobile is now out of beta and promises a more fluid phone-based GitHub experience.

In addition to working with tasks and issues, you can also review and merge pull requests. The app sends your phone notifications, too, which can be handy. As you might expect, you can get the app for Android or iPhone in the respective stores.

Continue reading “GitHub On The Go”

Reaching Serenity: Porting Git To A Homebrew Operating System

Life is all about the little joys — such as waking up in the morning and realizing there’s still plenty of time before you have to actually get up. Or getting up anyway to watch a delightful sunrise as the city slowly wakes up, or as [Andreas Kling] chose, porting your favorite development tool to the operating system you wrote.

With the aesthetics of ’90s UI design and the functionality of a simpler 2000s Unix-style system core in mind, and personal reasons to keep himself busy, [Andreas] started SerenityOS a little while back. Of course, writing your own operating system is always a great educational exercise, but it takes a certain amount of commitment to push it beyond an experimental playground phase. So ideally, you’d eventually want to use it as your actual main system, however, as software developer, [Andreas] was missing one crucial component for that: git. Well, he decided to change that and just port it — and as someone who likes to record his hacking sessions, you can watch him along the way.

Admittedly, watching someone tweaking some build tools and compiler settings would normally sound anything but overly exciting, but it adds a few more layers to it when doing so for a work-in-progress OS written from scratch — from digging into libc implementations to an almost reverse engineering approach to the build environment. If you take pleasure in people’s thought process in problem solving and (spoiler alert) their success, you will enjoy watching [Andreas]. On the other hand, if you’re more curious about a fresh approach at a desktop operating system, SerenityOS itself might be worth looking into. Of course, there are other options for that as well.

Continue reading “Reaching Serenity: Porting Git To A Homebrew Operating System”

GitHub Goes GUI-less

Git is a handy tool that many of us are using for more than just software development. Having a cloud-based upstream repository is also surprisingly useful, but until now using GitHub — the most common upstream server — meant firing up a web browser, at least for certain tasks. Now GitHub is releasing a beta version of command-line tools made to manipulate your GitHub repos.

The tools are early release so they mostly focus on issues and pull requests. Of course, git itself will do the normal things like clone and checkout — you’ve always been able to do that on the command line. The example given in the announcement blog post lists all issues with a help wanted label:

gh issue list --label "help wanted"

We noticed that asking to view the issue, while done on the command line, will still open a browser. The tools are still a little early, so this is an excellent time to let the developers know what you’d like or otherwise influence the project.

We were a little surprised it wouldn’t just consume git, so that you’d use the same commands for everything and it would just pass pre-formed commands to git. Of course, that would be pretty easy to write as a shell script wrapper if you were interested in such a thing.

You’d be forgiven for only thinking of git as a way to manage source code revisions, but it’s actually capable of all sorts of interesting tricks.

This Week In Security: Backdoors In Cisco Switches, PGP Spoofing In Emails, Git Ransomware

Some switches in Cisco’s 9000 series are susceptible to a remote vulnerability, numbered CVE-2019-1804 . It’s a bit odd to call it a vulnerability, actually, because the software is operating as intended. Cisco shipped out these switches with the same private key hardcoded in software for all root SSH logins. Anyone with the key can log in as root on any of these switches.

Cisco makes a strange claim in their advisory, that this is only exploitable over IPv6. This seems very odd, as there is nothing about SSH or the key authentication process that is IPv6 specific. This suggests that there is possibly another blunder, that they accidentally left the SSH port open to the world on IPv6. Another possibility is that they are assuming that all these switches are safely behind NAT routers, and therefore inaccessible through IPv4. One of the advantages/disadvantages of IPv6 is that there is no NAT, and all the network devices are accessible from the outside network. (Accessible in the sense that a route exists. Firewalling is still possible, of course.)

It’s staggering how many devices, even high end commercial devices, are shipped with unintentional yet effective backdoors, just like this one. Continue reading “This Week In Security: Backdoors In Cisco Switches, PGP Spoofing In Emails, Git Ransomware”

Easy Git Repository Summaries With Web-git-sum

For those hosting their own git repositories there are a number of solutions for creating convenient web-accessible front ends, but [mitxela] wasn’t quite satisfied with any of them. After trying a number of alternatives and reflecting on his requirements, he realized that all he really needed was a summary page listing the latest commits, and a file tree with a list of branches and tags. To accomplish this, he created web-git-sum. It’s a bash script that runs on git’s post-receive hook and generates only two files: a summary page and an index of the repository. You can see a demo of the output at git.mitxela.com.

[mitxela]’s writeup goes into some detail on how git repositories work, how those repositories are served over HTTP, and covers a few of the different options for providing convenient and accessible web front ends. Not all repositories are alike, and what works well for one may not work or scale well for another.

Intrigued by the idea of a private git server? We covered exactly how to set one up (spoiler: it’s really easy.)

Advanced Techniques For Using Git With KiCAD

For most developers “distributed version control” probably means git. But by itself git doesn’t work very well with binary files such as images, zip files and the like because git doesn’t know how to make sense of the structure of an arbitrary blobs of bytes. So when trying to figure out how to track changes in design files created by most EDA tools git doesn’t get the nod and designers can be trapped in SVN hell. It turns out though KiCAD’s design files may not have obvious extensions like .txt, they are fundamentally text files (you might know that if you’ve ever tried to work around some of KiCAD’s limitations). And with a few tweaks from [jean-noël]’s guide you’ll be diffing and merging your .pro’s and .sch’s with aplomb.

There are a couple sections to the document (which is really meant as an on boarding to another tool, which we’ve gotten to in another post). The first chunk describes which files should be tracked by the repo and which the .gitignore can be configured to avoid. If that didn’t make any sense it’s worth the time learning how to keep a clean repo with the magic .gitignore file, which git will look for to see if there are any file types or paths it should avoid staging.

The second section describes how you can use two nifty git features, cleaning and smudging, to dynamically modify files as they are checked in and out of the repo. [jean-noël]’s observation is that certain files get touched by KiCAD even if there are no user facing changes, which can clutter patch sets with irrelevant changes. His suggested filters prevent this by stripping those changes out as files get checked in. Pretty slick.

Visual Schematic Diffs In KiCAD Help Find Changes

When writing software a key part of the development workflow is looking at changes between files. With version control systems this process can get pretty advanced, letting you see changes between arbitrary files and slices in time. Tooling exists to do this visually in the world of EDA tools but it hasn’t really trickled all the way down to the free hobbyist level yet. But thanks to open and well understood file formats [jean-noël] has written plotgitsch to do it for KiCAD.

In the high(er)-end world of EDA tools like OrCAD and Altium there is a tight integration between the version control system and the design tools, with the VCS is sold as a product to improve the design workflow. But KiCAD doesn’t try to force a version control system on the user so it doesn’t really make sense to bake VCS related tools in directly. You can manage changes in KiCAD projects with git but as [jean-noël] notes reading Git’s textual description of changed X/Y coordinates and paths to library files is much more useful for a computer than for a human. It basically sucks to use. What you really need is a diff tool that can show the user what changed between two versions instead of describe it. And that’s what plotgitsch provides.

plotgitsch’s core function is to generate images of a KiCAD project at arbitrary Git revisions. After that there are two ways to view the output. One is to generate images of each version which can be fed into a generic visual diff tool (UNIX philosophy anyone?). The documentation has an example script to help facilitate setting this up. The other way generates a color coded image in plotgitsch itself and opens it in the user’s viewer of choice. It may not be integrated into the EDA but we’ll take one click visual diffs any day!