POSIX.1-2024; HTTP Observatory’s New Digs; Portier

Two updated and one new (to me) resource on this Friday edition of the Drop.

---

TL;DR

(This is an AI-generated summary of today’s Drop using Sonnet via Perplexity.)

• POSIX.1-2024 Standard was published in June, featuring updates like 64-bit time_t, enhanced locking mechanisms, and improved memory allocation. The 4,000+ page document covers various aspects of operating system interfaces [https://ieeexplore.ieee.org/document/10555529].
• Mozilla’s HTTP Observatory, a tool for analyzing web server security configurations, has been relocated and redesigned. It evaluates websites based on security features and assigns scores [https://developer.mozilla.org/en-US/observatory].
• Portier is a self-hostable, password-less login service that acts as an intermediary between websites and third-party authentication providers, offering a streamlined login experience using email addresses [https://portier.github.io/].

---

POSIX.1-2024

The POSIX.1-2024 Standard was published in late June. In previous Drops, we’ve talked about POSIX (Portable Operating System Interface) from a few different angles, and now folks have a new opportunity to look at entire, fresh, new (well, updated) 4,000+ page (O_O) standard. Well, most folks will be able to do that soon, but it’s stuck behind an IEEE paywall, for now.

I do recommend folks poke at it a bit when it does come out, and look for a plethora of posts across the blogosphere that usually swell up after release time. Authors with various POSIX special interest areas will go into deep dives on what has been added/changed.

Today, y’all get two things (below). One is (hopefully) a less daunting breakdown of the sections covered in the standard. The other is a list of some things I found notable after a very quick series of diff‘s and rg‘s.

1. Introduction and Scope: (kind of self-explanatory)
2. Conformance: This section details the requirements for implementation conformance, including POSIX conformance and XSI conformance. It also covers application conformance and language-dependent services for the C programming language.
3. Definitions and Concepts: A large portion of the document is dedicated to defining terms and concepts used throughout the standard. This includes everything from basic computing terms to specific POSIX-related concepts.
4. General Concepts: This section covers broader topics such as file system organization, process management, memory management, and internationalization.
5. File Format Notation and Character Sets: The standard defines file format notations and specifies character sets, including the portable character set and character encoding rules.
6. Locale: Detailed information on locale definition and internationalization, including specifics on various locale categories (LC_CTYPE, LC_COLLATE, LC_MONETARY, etc.).
7. Environment Variables: Definitions and usage of environment variables in POSIX-compliant systems.
8. Regular Expressions: Comprehensive coverage of regular expression syntax and semantics, including both basic (BRE) and extended (ERE) regular expressions.
9. Directory Structure and Devices: Information on standard directory structures and device interfaces.
10. General Terminal Interface: Specifications for terminal I/O interfaces and control.
11. Utility Conventions: Guidelines for the syntax and behavior of utility programs.
12. Shell Command Language: Detailed specifications for the shell command language, including syntax, built-in utilities, and job control.
13. System Interfaces: This extensive section covers a wide range of system programming interfaces, including process control, file I/O, memory management, inter-process communication, networking, and more.
14. Headers: Definitions of standard C language headers and their contents.
15. Utilities: Specifications for standard utility programs and commands.
16. Rationale: Explanations and background information on the design decisions made in the standard.

If you’ve never read through any decent portion of a POSIX standard, I’d suggest starting the sections identified in bullets 4, 8, 11, 12, and 15 (unless you’re doing very low-level work on POSIX systems). We’ll likely cover some of those (that we have not already covered in various Drops) in-depth in the fall.

When it comes to new or changed items, these seemed to be significant to my biased (focused on safety and resilience) eyes:

1. 64-bit time_t: The 2038 32-bit time_t issue has been addressed, effectively canceling the “Y2K38” problem.
2. Enhanced locking mechanisms:
   • F_OFD_GETLK, F_OFD_SETLK, and F_OFD_SETLKW are added for per-file-descriptor advisory locks, addressing issues with process-scope locks.
3. Improved memory allocation:
   • reallocarray() is introduced to reallocate arrays with a multiplication check to catch overflows.
   • aligned_alloc() from C11 is added for allocating memory with specified alignment.
4. Enhanced randomness generation:
   • getentropy() function is added to obtain cryptographically secure random data.
5. Internationalization improvements:
   • <libintl.h> header is standardized, including key interfaces from gettext.

There are, of course, many more changes/additions to the internals.

When it comes to things you and I may use more frequently:

• set -o pipefail is now a POSIX standard (meaning it will eventually work across all shells that claim to be POSIX compliant).
• The section on Awk has been updated to account for the “recent” update to the venerable data wrangler.
• cd -e is safer as it checks for existence before changing directories and fails with a status and message.
• head -c is standardized across POSIX systems. It lets us output a specific number of bytes from the beginning of a file or input stream, rather than a number of lines.

I’ll be watching for more changes that others notice.

Let me re-encourage y’all to at least poke at some of the aforementioned sections, and keep the standard around (when it’s free) to reference when doing shell ops.

HTTP Observatory’s New Digs

Mozilla’s HTTP Observatory got a new home and a redecoration!

If you’re not familiar with it, it’s an open-source project that conducts comprehensive analyses of web server configurations, focusing on critical security headers and protocols.

The Observatory’s methodology involves assigning an initial score of 100 to each website, which is then adjusted based on the implementation of various security features. Penalties are applied for missing or misconfigured protections, while bonus points are awarded for exemplary security practices, allowing scores to potentially exceed 100. This scoring system, while inherently subjective, is grounded in industry expertise and aims to incentivize the adoption of cutting-edge web security technologies.

Key areas of evaluation include Content Security Policy (CSP) implementation, HTTP Strict Transport Security (HSTS) configuration, and protection against cross-site scripting (XSS) attacks. The Observatory also assesses the proper use of secure cookies and the deployment of advanced features like subresource integrity.

If you’ve never tried it out before, I do suggest carving out five minutes to do so. And, if you want to know the “how”, check out the repo.

Portier

Portier is a new (to me) self-hostable login service that is not password-based. It sits between a website/webapp and 3rd-party services like Google Sign-In to provide humans who use your kit a pretty nice login experience, without ever needing a new password.

This is how it works:

1. Someone Initiates Login: A visitor taps a website and selects “Log in”. Instead of entering a password, they enter their email address.
2. Website Requests Authentication: The website sends an authentication request to its Portier broker (a self-hosted or cloud-hosted service).
3. Broker Verifies Email: The Portier broker checks if the email domain supports OpenID Connect (e.g., Google accounts). If so, it redirects to that provider. If not, it falls back to email verification.
4. Email Verification (if needed): For email verification, the broker sends a one-time link to the individual’s email address.
5. Visitor Confirms: The visitor taps the link in their email, which opens in their browser and redirects back to the Portier broker.
6. Broker Issues Token: Upon successful verification, the broker issues a signed JSON Web Token (JWT) containing the visitor’s verified email address.
7. Website Validates Token: The website receives and cryptographically verifies the JWT from the broker.
8. User Logged In: If the JWT is valid, the website considers the visitor authenticated and logs them in.

The demo is a great showcase of how it works.

NOTE: this service only covers the authentication part. You need to handle the authorization bits.

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev ☮️