The Wayland Machine | BSD Now 179

chris

6 years ago

RSS Feeds:

Become a supporter on Patreon:

– Show Notes: –

Headlines

Wayland is now in the FreeBSD Ports tree

This commit brings Wayland, the new windowing system, into the FreeBSD ports tree
“This port was first created by Koop Mast (kwm@) then updated and improved by Johannes Lundberg”
“Wayland is intended as a simpler replacement for X, easier to develop and maintain. GNOME and KDE are expected to be ported to it.”
Wayland is designed for desktop and laptop use, rather than X, which was designed for use over the network, where clients were not powerful enough to run the applications locally.
“Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers.”
“Please report bugs to the FreeBSD bugtracker!”
It is good to see this project progressing, as it seems in a few generations, high performance graphics drivers may only be actively developed for Wayland.

Call For Testing: xorg 1.18.4 and newer intel/ati DDX

Baptiste Daroussin, and the FreeBSD X11 team, have issued a call for testing for the upgrade to Xorg 1.18.4
Along with it comes newer ATI/AMD and Intel drivers
“Note that you will need to rebuild all the xf86-* packages to work with that
newer xorg (hence the bump of the revision)”
“Do not expect newer gpu supported as this is not the kernel part”, it only provides the newer Xorg driver, not the kernel mode setting driver (this is a separate project)
“If you experience any issue with intel or radeon driver please try to use the new modesetting driver provided by xorg directly (note that fedora and debian recommend the use of the new driver instead of the ati/intel one)”

Error handling in C

“Unlike other languages which have one preferred means of signalling an error, C is a multi error paradigm language. Error handling styles in C can be organized into one of several distinct styles, such as popular or correct. Some examples of each.”
- “One very popular option is the classic unix style. -1 is returned to indicate an error.”
- “Another option seen in the standard C library is NULL for errors.”
- “The latter has the advantage that NULL is a false value, which makes it easier to write logical conditions. File descriptor 0 is valid (stdin) but false, while -1 is invalid but true.”
- “And of course, there’s the worst of both worlds approach requiring a special sentinel that you’ll probably forget to use”
- “Other unix functions, those that don’t need to return a file descriptor, stick to just 0 and -1”
- “Of course, none of these functions reveal anything about the nature of the error. For that, you need to consult the errno on the side”
The article goes on to describe different ways of dealing with the issue, and return values.
There is also coverage of more complex examples and involve a context that might contain the error message
It is really interesting to see the differences, and the pitfalls of each approach

Fixing POSIX Filenames

“Traditionally, Unix/Linux/POSIX pathnames and filenames can be almost any sequence of bytes. A pathname lets you select a particular file, and may include zero or more “/” characters. Each pathname component (separated by “/”) is a filename; filenames cannot contain “/”. Neither filenames nor pathnames can contain the ASCII NUL character (\0), because that is the terminator.”
“This lack of limitations is flexible, but it also creates a legion of unnecessary problems. In particular, this lack of limitations makes it unnecessarily difficult to write correct programs (enabling many security flaws). It also makes it impossible to consistently and accurately display filenames, causes portability problems, and confuses users.”
“This article will try to convince you that adding some tiny limitations on legal Unix/Linux/POSIX filenames would be an improvement. Many programs already presume these limitations, the POSIX standard already permits such limitations, and many Unix/Linux filesystems already embed such limitations — so it’d be better to make these (reasonable) assumptions true in the first place. This article will discuss, in particular, the three biggest problems: control characters in filenames (including newline, tab, and escape), leading dashes in filenames, and the lack of a standard character encoding scheme (instead of using UTF-8). These three problems impact programs written in any language on Unix/Linux/POSIX system. There are other problems, of course. Spaces in filenames can cause problems; it’s probably hopeless to ban them outright, but resolving some of the other issues will simplify handling spaces in filenames. For example, when using a Bourne shell, you can use an IFS trick (using IFS=printf '\n\t') to eliminate some problems with spaces. Similarly, special metacharacters in filenames cause some problems; I suspect few if any metacharacters could be forbidden on all POSIX systems, but it’d be great if administrators could locally configure systems so that they could prevent or escape such filenames when they want to. I then discuss some other tricks that can help.”
“After limiting filenames slightly, creating completely-correct programs is much easier, and some vulnerabilities in existing programs disappear. This article then notes some others’ opinions; I knew that some people wouldn’t agree with me, but I’m heartened that many do agree that something should be done. Finally, I briefly discuss some methods for solving this long-term; these include forbidding creation of such names (hiding them if they already exist on the underlying filesystem), implementing escaping mechanisms, or changing how tools work so that these are no longer problems (e.g., when globbing/scanning, have the libraries prefix “./” to any filename beginning with “-”). Solving this is not easy, and I suspect that several solutions will be needed. In fact, this paper became long over time because I kept finding new problems that needed explaining (new “worms under the rocks”). If I’ve convinced you that this needs improving, I’d like your help in figuring out how to best do it!”
“Filename problems affect programs written in any programming language. However, they can be especially tricky to deal with when using Bourne shells (including bash and dash). If you just want to write shell programs that can handle filenames correctly, you should see the short companion article Filenames and Pathnames in Shell: How to do it correctly.”
Imagine that you don’t know Unix/Linux/POSIX (I presume you really do), and that you’re trying to do some simple tasks. For our purposes we will create simple scripts on the command line (using a Bourne shell) for these tasks, though many of the underlying problems affect any program. For example, let’s try to print out the contents of all files in the current directory, putting the contents into a file in the parent directory:
- cat * > ../collection # WRONG
- cat ./* > ../collection # CORRECT
- cat find . -type f > ../collection # WRONG
- ( set -f ; for file in find . -type f ; do # WRONG
  cat “$file”
  done ) > ../collection
- ( find . -type f | xargs cat ) > ../collection # WRONG, WAY WRONG
Just think about trying to remove a file named: -rf /

News Roundup

OpenBSD ARM64

A new page has appeared on the OpenBSD website, offering images for ARM64
“The current target platforms are the Pine64 and the Raspberry Pi 3.”
“OpenBSD/arm64 bundles various platforms sharing the 64-bit ARM architecture. Due to the fact that there are many System on a Chips (SoC) around, OpenBSD/arm64 differentiates between various SoCs and may have a different level of support between them”
The page contains a list of the devices that are supported, and which components have working drivers
At the time of recording, the link to download the snapshots did not work yet, but by time this airs a week from now, it should be working.

The design of Chacha20

Seems like every few episodes we end up discussing Ciphers (With their o-so amusing naming) and today is no exception.
We have a great writeup on the D & I of the ‘chacha20’ cipher written by “Loup Vaillant”
First of all, is this story for you? Maybe the summary will help make that call:

Quick summary: Chacha20 is ARX-based hash function, keyed, running in counter mode. It embodies the idea that one can use a hash function to encrypt data.

If your eyes didn’t glaze over, then you are cleared to proceed.
Chacha20 is built around stream ciphers:

While Chacha20 is mainly used for encryption, its core is a pseudo-random number generator. The cipher text is obtained by XOR’ing the plain text with a pseudo-random stream:
cipher_text = plain_text XOR chacha_stream(key, nonce)

Provided you never use the same nonce with the same key twice, you can treat that stream as a one time pad. This makes it very simple: unlike block ciphers, you don’t have to worry about padding, and decryption is the same operation as encryption:
plain_text = cipher_text XOR chacha_stream(key, nonce)

Now we just have to get that stream.

The idea that the streams can mimic the concept of a one-time pad does make chacha20 very attractive, even to a non-crypto guy such as myself.
From here the article goes into depth on how the cipher scrambles 512bit blocks using the quarter-round method (A forth of a block or 4 32bit numbers)
Some ascii art is used here to help visualize how this done, in the quarter round-phase, then to the complete block as the 4 quarters are run in parallel over the entire 512 bit block.
From here the article goes more into depth, looking at the complete chacha block, and the importance of a seemingly unnecessary 32byte constant (Hint: it’s really important)
If crypto is something you find fascinating, you’ll want to make sure you give this one a full read-through.

CyberChef – Coming to a FreeBSD Ports tree near you

Dan Langille tweets that he will be creating a port of GCHQ’s CyberChef tool
“CyberChef is a simple, intuitive web app for carrying out all manner of “cyber” operations within a web browser. These operations include creating hexdumps, simple encoding like XOR or Base64, more complex encryption like AES, DES and Blowfish, data compression and decompression, calculating hashes and checksums, IPv6 and X.509 parsing, and much more.”
“The tool is designed to enable both technical and non-technical analysts to manipulate data in complex ways without having to deal with complex tools or algorithms. It was conceived, designed, built and incrementally improved by an analyst in their 10% innovation time over several years. Every effort has been made to structure the code in a readable and extendable format, however it should be noted that the analyst is not a professional developer and the code has not been peer-reviewed for compliance with a formal specification.”
Some handy functions, beyond stuff like base64 encoding:
Network Enumeration (CIDR to list of IPS)
Browser User Agent Parser (what browser is that, based on your HTTP logs)
XOR Brute Force: enter some XOR’d text, and try every possible key to find plaintext. Optionally give it a regex of known plaintext to find the right key.
Calculate the “Shannon Entropy” of the input (how random is this data)
It also has a number of built in regular expressions for common things, very useful
The project is up on github if you want to play with the code

Building Electron and VSCode in FreeBSD11

A patch and set of instructions for building Electron and VSCode on FreeBSD
“Visual Studio Code is a source code editor developed by Microsoft for Windows, Linux and macOS. It includes support for debugging, embedded Git control, syntax highlighting, intelligent code completion, snippets, and code refactoring. It is also customizable, so users can change the editor’s theme, keyboard shortcuts, and preferences. It is free and open-source, although the official download is under a proprietary license.”
“Visual Studio Code is based on Electron, a framework which is used to deploy Node.js applications for the desktop running on the Blink layout engine. Although it uses the Electron framework, the software is not a fork of Atom, it is actually based on Visual Studio Online’s editor (codename “Monaco”)”
It would be interesting to see official support for VSCode on FreeBSD
Has anyone tried VSCode on the FreeBSD Code base?

Beastie Bits

Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv