This week's news: Open source voting systems, sigstore components reach GA, and more

Every Wednesday, Nick Chase and Eric Gregory from Mirantis go over the week’s cloud native and industry news on the Radio Cloud Native podcast.

This week, Eric and Cloud Native & Coffee host John Jainschigg discuss:

• Open source voting systems take to the field in New Hampshire

• sigstore's Rekor and Fulcio reach general availability

• The open source Kuma service mesh adds eBPF support in v2.0

• Nvidia open sources PhysX 5.1

• And other stories on the podcast, including malicious PyPi packages, Tim Berners-Lee on web3, and more

Download the podcast from Apple Podcasts, Spotify, or wherever you get your podcasts. If you'd like to tune into the next show live, follow Mirantis on LinkedIn to receive our announcement of the next broadcast.

John: Three towns in New Hampshire—Ashland, Newington and Woodstock—greeted voters with new voting machines whose software is open source. Those towns have small populations, making them reasonable test cases for the new tech.

The software itself is called vxsuite, from a nonprofit called VotingWorks, founded in 2018 by Ben Adida, and is on GitHub in two repos – a main code repo, and a build repo enabling and documenting build (on Ubuntu or Debian VMs) and preparation of installation on real hardware via making a copy of the hard drive of the installed system on a USB stick. The vxsuite supports a range of voting kiosks, as well as tabulating machines, vote-reading wands, and other equipment for automating aspects of accepting and tabulating votes. The main software appears to be largely written in Node.js, which makes a lot of sense for development, but probably begs the question of needing to curate modules very carefully to avoid node-disseminated supply chain attacks or exposure to exploits, though the stand-alone kiosk-based footprint of voting machines offers a different kind of attack surface than, say, a public-facing website. From what we can tell, VotingWorks takes security extremely seriously, however—their codebase includes methods for generating and cryptographically signing code modules for production: an important way of helping to ensure curation and oversight. 

New Hampshire had been using commercial machines from AccuVote since the mid-90s, but that company has announced they won’t be making replacement parts for these any more, starting in 2024. The VotingWorks software is apparently only yet used in a very few places—five counties in Mississippi have implemented the machines so far. Adida believes in gradual cutover—he says: “I think one area where states should model New Hampshire is [to] try it on a small scale in a real election,” he said. “Because when technology transitions are all or nothing, when they're these massive cut overs, they are so risky. That slows down the process tremendously. And it means ultimately that we're not deploying better, more secure, simpler voting technology as fast as we could.”

According to New Hampshire public radio, “after the machines count the ballots on Tuesday, election officials will hold a public hand count in Concord the following day that will cross check how accurate the pilot machines are. If the machines prove to have not had any significant errors, the machines will undergo state and federal verification procedures.”

Eric: The sigstore project reached general availability for two of its core components: Rekor, a transparency log, and Fulcio, a certificate authority public benefit service. 

Overall, sigstore is a project of the Linux Foundation and Open Source Security Foundation, and in our cloud native corner of the industry it’s best known as a tool for container image signing. Big picture, sigstore is meant to address the problem of software verification by issuing certificates through the Fulcio service, and then storing the record of activity in an immutable and transparent ledger with Rekor, with “transparent” meaning that anyone can see that the certified software hasn’t been tampered with. 

Until now, sigstore has been available on a sort of provisional, best-effort basis, but some big projects have been eager to leverage it—back in August, GitHub floated the idea of using it for package signing in npm, but hit some pushback over its not quite being production-ready. Those are no doubt the kinds of worries sigstore is looking to assuage with these version 1.0 GAs, noting in their announcement that “the APIs are stable and will be supported long term.” Now in a new blog post entitled “Why we’re excited about Sigstore general availability,” GitHub confirms that npm will indeed be using sigstore to validate npm packages by connecting them to their source repositories and information on build environment build instructions.

In any case, GitHub also notes that they’re using sigstore to offer keyless signing with GitHub Actions, which is meant to help developers avoid the hassle of regularly rotating private keys. And just for a little full circle effect, they cite Kubernetes as a project currently using this sort of keyless signing.

Eric: Kong announced the 2.0 release of their Kong Mesh and Kuma service meshes, with the big headlines being eBPF support and three “next generation” policy updates. Kong Mesh is the company’s enterprise offering, which is built on top of the open source Kuma, and Kuma in turn is built on top of Envoy. 

As with other recent service meshes’ eBPF integrations, you can now replace iptables with eBPF to handle directing traffic within a cluster. Kong says the new eBPF functionality “can improve the performance of traffic flow latency by up to 12%.” 

As for the policy updates, these are basically an updated approach to policies that makes it easier for teams to apply them more granularly via a new selector mechanism. According to Kong:

“...the new selectors use a `targetRef` system (inspired by GatewayAPI) to select which meshes, services, data plane proxies, etc. are targeted by specific policies. Multiple rules can be specified in the same policy (as supported today) or many different policies can be created targeting different subsets. Our new policy system will merge these all together with the correct precedence rules before calculating and pushing the configuration out to the Envoy dataplane.”

The first three updated policy resource types include MeshTrafficPermission, MeshTrafficLog, and MeshTrafficTrace. You can check out the open source Kuma 2.0 at kuma.io.

John: Nvidia, the best-known maker of GPU hardware, acquired Ageia a decade ago—that company was the original creator of the now-widely-used PhysX physics library. In 2019, Nvidia open sourced PhysX, making it cheaper and easier for game engine, graphics, and other software to consume this powerful toolkit and its SDK, which uses different physics models to simulate the physics of simple and complex moving bodies in varying gravity, fall, and force conditions, and also simulates the behaviors of things like hair, cloth, fire and smoke, light and shade, and many other things.

Expected for two years, a few days back they open sourced the 5.1 version of PhysX on GitHub, under the BSD 3 license, which users clearly prefer. Nvidia Flow, a voxel-based simulation engine, is now bundled with the PhysX SDK in the same GitHub repo, also licensed with BSD 3, and Nvidia Blast will also be added soon. Blast is a Destruction Engine that can use PhysX, designed to simplify “the elements of destruction”—things exploding, flying apart, crumbling, smashing, etc. All this stuff is now part of the open source PhysX product family.

New in PhysX 5.1 is the addition of support for Nvidia Flex, which is a simulation sub-engine that does voxel-based finite element model soft body dynamics—in other words, squishing and stretching things—plus position-based dynamics for simulating liquid, cloth, inflatable objects and the like. They’ve also added new on-GPU collision detection features. 

On CPU features have also been enhanced: PhysX 5.1 users can now define custom geometries, meaning cylinder shapes or implicit block-based worlds can now be supported. So that Minecraft work-alike is even easier to build!

Nvidia says that PhysX’s role has evolved—it used to be focused on video games, and on the console market. But nowadays folks are using it for robotics, autonomous driving, factory automation, deep learning and other stuff. Nvidia will thus no longer provide ports of the engine to video game consoles (though the community is free to create such ports).

Check out the podcast for more of this week's stories.