run0 doesn't implement a configuration language of its own btw (i.e. no equivalent of /etc/sudoers). Instead, it just uses polkit for that, i.e. how we these days usually let unpriv local clients be authorized by priv servers.

Polkit .rules files are quite readable, for the most part, but they're also written in ECMA-262 edition 5 JavaScript! I'm not really thrilled with config files that are executable and might have odd exploitable language features I don't really need. But, whatever you do, don't run it with an argc == 0 .

This means production workloads can rely on the Rekor public instance, which has a 24/7 oncall rotation supporting it and offers a 99.5% availability SLO for the following API endpoints

(Rekor README)

And that is the key reason to stay far, far away: this system is yet another identity service which happens to be supported by software. Like most identity services, they have carefully constructed it to ensure that the user receives no actual proof of identity. That proof resides on a ledger in some cloud server, somewhere, and verifying anything requires queries against the service. This means that the service can:

• Start charging for "blue checkmarks" or for the ability to put entries in the ledger
• Start charging for verification queries
• Decide they don't like you today, then lock you out of either of the above
• Decide what Certification Level you or your organization have today
• Learn how often you commit/push/release, potentially monetizing this data stream
• Learn all the software (or other blobs) you verify at once, giving them insight into your software stack
• Stop existing at any time, leaving its users without anything of value

I don't see the words "distributed" or "federated" anywhere on the tin, with the possible exception of OIDC. But they are in control of what third-party OIDC providers they trust, if any. If their ledgers are not fully distributed, they are only as good as the metal in their hard drives. (And are one ransomware attack away from ruin and oblivion.)

Despite its obvious flaws and shortcomings, the whole point of the GPG Web of Trust is to escape the tyranny of these centralized ID providers. The cost is having to keep something secret—i.e., the key. cosign frees you from this requirement, but you are forever chained to their service. For me, this is not worth the price of admission.

One open problem in source or binary validation is trusted infrastructure—or the lack thereof. Projects that wish to use cloud computing for their builds, and to guarantee that the binary builds come from said cloud, usually have no choice but to trust The Cloud with their precious $identity key. This can leave it exposed to bad actors. The solution to this problem is reproducible builds. If your artifacts can be reproduced, they can be signed on non-cloud hardware that your project maintainers can see, touch, and trust. The solution is not "add yet more cloud servers with yet more keys run by yet another organization, making our system even more fragile and complicated."

But there's usually not a lot of money to be made in making things simpler.

I absolutely do. I climb inside of it, and it takes me to a place where there are canned diced tomatoes.

The Terms & Conditions (PDF warning) for their paid "audit support product" make it clear that they are not providing you with legal representation:

I am not a lawyer, and this is not legal advice... but if you receive a notice from the IRS, and they want to "discuss" or modify your tax returns, you should obtain legal representation right away.

The IRS is attempting to create its own free-file system independently of Intuit et. al. While it probably won't be useful for every tax situation, it may help lower fees for people with simple returns. What does everyone think? Any takers?

Flight controllers in Germany plan to fire the spacecraft's engine in hopes of shaking the pin loose.

I always appreciate problems that can be solved with the application of a good rageshake. Let's hope it works.

That's fair. I also need a car to get to work. The only thing I could do to change this situation would be to change jobs. Changing my housing would not solve the need-car problem.

From the "done that" school of experience, if you find yourself needing a car and do not have one, it's pretty easy to rent one more or less immediately, then buy a permanent car within about two weeks or so. (This does depend on your budget and how picky you are.)

For me, my "choice" of commute method—if you can call it that—depends mostly on speed and safety. If it were nearly as fast and safe to walk or bike, I would probably do that instead.

If you could afford to live in such a place, would you? It is true that places which are both "urbanized" and "nice" tend to command sky-high prices... and the United States already suffers from high housing prices in general.

I'm sure that social media is still a thing in the Netherlands and anywhere else with a lower per-capita traffic fatality rate.

Or the cost, which may be a substantial driver of behavior in today's economy. Owning a car comes with a substantial up-front cost and a recurring expense. My current vehicle—which is a very basic, inexpensive car—still costs me about $0.45 USD/mile to operate. Larger or older vehicles are even more expensive per-mile. I didn't own a car as a teenager, or drive very much at all, for this very reason. I only bought a car when it became absolutely necessary.

The outcome will determine how quickly San Francisco and possibly other cities forge ahead with driverless technology that could remake the world's cities and potentially save some of the 40,000 people killed each year in American traffic crashes....

Per the NHTSA, there were 38,824 traffic fatalities in the United States [p. 5] in 2020. Assuming a population of 329.5 million, that's 11.8 fatalities per 100,000 population. Meanwhile, during that same timeframe in the Netherlands [p. 3], there were 3.8 fatalities per 100,000 population. Both fact sheets cover road users other than automobiles, including pedestrians and cyclists.

If increasing road safety is the ultimate goal, that can be done today using technology, infrastructure, and methods which are well-known and proven. There is no need to wait around for Big Tech or anyone else to reinvent the automobile—only with greater expense and more points of failure.

Unihertz is a GPL violator. As far as I am aware, they do not publish their linux kernel source code as required by the GPLv2. This makes it difficult to perform security audits or to build third-party ROMs. Some versions of the Titan are known to use the Adups FOTA updater. Per the NYT and malwarebytes, Adups is a well-known vector for Chinese spyware. Although Unihertz has assured its users that the offending software has been patched, I find it difficult to trust them.

I would be wary of buying smartphones from Chinese companies. Very, very wary.

Rust has bindgen for this purpose. It uses LLVM to dissect C headers and produce an (unsafe) Rust wrapper for them. The programmer is still responsible for checking over it and writing a higher-level, "safe" Rust API if needed, but bindgen does most of the drudge work.

An i32 has native endianness by default. You can convert it to/from any endianness you want, but arithmetic still needs to happen natively. Rust arguably has better behavior for arithmetic overflow than C.

I frequently tell people that "C is the only ABI, and C++ need not apply." The most portable native libraries are the ones which expose a C interface, regardless of their underlying language.

I wouldn't call the demand latent. "App stores" already distribute a good volume of closed-source shareware apps to end users, and they make a ton of money doing it. The big difference is that they're distributing complete products: a text editor, an email client, a game, etc. These things are ready to use and (should) work out-of-the-box.

On the other hand, many of the repositories on Github are for parts of things: a character set converter, a domain validator, a linear algebra library, etc. If I am a software developer looking for a linear algebra library... and some days I am... a proprietary solution is automatically unattractive. I don't want to deal with a procurement process. I don't want some license restricting what I may do with my software, even if I ultimately intend to sell it. I want to possess source code, and I want to see and debug its innards if I need to. I want to see how active the project is and how likely it is to be around in a few years.

I'm not sure if most devs are like me. If they are, paid software will probably continue to be built out of (permissive) free software preferentially.

That really depends on the project. Big projects certainly have maintenance issues like this. Not all contributors can write code. Most contributors don't know how to write good clean code that's tested and also fits into the greater scheme of the project. It is tough to cultivate and/or attract people like that to a project. Maintainers would not have this issue quite so acutely if they could turn more contributors into maintainers. When I find the magic formula for doing this, I'll be sure to let everyone know...

I don't see how this funding model is at all sound. Most projects don't have a very high contributor : user ratio. This is especially true for many of the little utilities that are often very deep in the dependency tree. Do you use the tzdata timezone file? Probably. Have you ever even looked at the timezone file? Less likely. Have you ever needed to engage with the maintainers of tzdata? Unlikely. The maintainer caused a big stir when he retired, but fortunately he did so in a controlled manner with a transition plan. Projects like this which sit at the bottom of the dependency tree—mostly ignored and unremarked on—are prime candidates for software supply-chain attacks.

Simply putting a wall around your garden of contributors doesn't encourage users to become contributors. On the contrary; it discourages them! Projects which carry a GPL license are required to convey source code if binaries are available. Projects with permissive open licenses (MIT/BSD) may have their source code leaked by any of the subscribers; there's nothing at all illegal about that. If the "source subscription model" is incompatible with open licenses, then projects will either have to deal with that or become closed-source projects. If they do the latter, they will be shut out of other places that only distribute free software.

There are better ways to finance projects. If Microsoft were really serious about this issue, they would add features like a "paid support desk" or "bug/feature bounties." And maybe Big Tech, flush with more new gigadollars than is healthy to have in one place, might elect to funnel some of that money into the things they use. (While I'm dreaming, where is my flying car?)

All this new "feature" is apt to do is to invite forks and community drama. Your users will stop talking to you... because they can't.

There are plenty of other repository hosts out there, and it's easy to migrate.

Ironically, per the original report from Qualys, the inclusion of an additional string library makes this vulnerability worse—not better.

One potential exploit takes advantage of the fancy string library in order to run an injected shared library. To be clear, this isn't the fault of the string library, but its use here does increase the available attack surface.

There are three takeaways here:

1. If you're going to write a SETUID (or setcap) binary, be prepared to face a litany of race conditions, "interesting" POSIX behavior, and very unsafe user input.
2. If you're going to write a SETUID binary, you should subject it to fuzz testing and have an AppArmor or SELinux confinement profile, just in case.
3. If you're going to write a SETUID binary, you should stop, think about your life, and try to find some other way to solve your problem.

Huh? Mailing lists with public web archives are usually very easy to search. They get linked to, indexed, and show up in public search results just like any other page. Not all lists have archives, and not all archives can be searched. In those cases, yeah, that's definitely an issue. Local email archives can be searched very quickly, but they don't benefit from the network effects of large search engines.

Media support is definitely a problem. Most mailing lists and email gateways don't appreciate pushing out large binaries, and Base64 has 36% overhead.

Mailing lists are far from trouble-free, of course. Misconfigured lists are a breeding ground for spam, and they might leak subscriber email addresses too. RBLs and other blacklists can prevent delivery of your precious messages. Spam is a problem everywhere on the internet; the only reliable way to get rid of it is via human moderators armed with buckets and buckets of bleach. Email lists also don't have a really a great way to up-vote content like stackexchange and others. Some might call this a feature. Mailing lists can be harder to post to than "social media" sites for which you already have an account. Again, depending on who you ask, this is also a feature.

These issues aside, I would say that a mailing list with two or three independent, public archives are probably among the most searchable and durable collections out there.