magmastonealex

I sort of accidentally stumbled into it when I joined an (at the time) startup as they were just getting into the market. So I don't know that I have anything specific to offer :)

I don't want to name names for companies in the industry, but you can find them in industry publications like Traffic Technology Today, or often as contributors to the standards documents like NTCIP 1202, ITE ATC 5301, etc.

I will say that there are a number of long-standing (40+ years) companies in the industry that seem to still operate the "legacy" way - slow iterations, very small software team, seemingly not much desire for large change. Basically, a hardware company that also happens to sell software.

There are also newer entrants to the market in the past ~decade or so that operate a lot closer to a modern software company - lots of new features coming out, fast-moving software teams, etc.

(again, all opinions are my own here.)

I'd like to think it's become ubiquitous - it has been a while since I've seen a signal without a red clearance configured.

However, the Federal Highway Administration in the US (which sets guidelines, but most states define actual rules at the state level) still says in their Signal Timing Manual [1]

> The use of a red clearance interval is optional, and there is no consensus on its application or duration. [...] there may not be safety benefits associated with increased red clearance intervals.

and goes on to describe how it has negative traffic flow implications.

so I suspect at least some agencies out there still are not using them.

[1]: https://ops.fhwa.dot.gov/publications/fhwahop08024/chapter5....

Unfortunately those fears are well-founded.

The majority of MMUs on the market that I have had a close look at implement safety-critical functionality on a microcontroller with updatable firmware. Some can even be updated over IP. I haven't had the opportunity to dig into if those firmware upgrades are signed or otherwise integrity-protected.

The standard unfortunately does not specify a functional safety standard or other measures to ensure absolute safety.

In theory it would be possible to implement it in discrete logic (or an FPGA or other formally-verifiable process), but as far as I know no manufacturer has done so (I'd love to be wrong!)

Well, the "locked" cabinet generally uses the same key everywhere in North America, which isn't a great start :)

A number of agencies put these controllers directly on the Internet (a search on Shodan for some telltale strings produces concerning numbers of hits).

Others will use one giant flat network across their entire city - so if you get access at once location, you have access to the entire network. This could mean accessing a "rural" or quiet location, but then actually attacking a much busier one.

Now you start to get into the differences between the various standards :)

In NEMA TS2 (and the more modern ITE ATC), the MMU does enforce a yellow clearance time - you need the light to turn yellow for a period of time before a conflicting phase goes green. Usually this is a few seconds. Changing phases rapidly would likely confuse drivers, but in _theory_ shouldn't cause a collision if people respect yellows.

(believe it or not, in some localities a "red clearance" time - all red - is not required and lights will go from yellow in one direction to green in another.)

In CalTrans TEES, I do not believe the standard calls for the MMU to enforce clearance times - the attack you describe would potentially be possible.

This is a great introduction to the mess that is traffic signal controllers!

The reality is perhaps even worse than the article suggests. The majority of signal controllers support the NTCIP "standard" MIBs in addition to the "proprietary" MIBs that are provided through FreeTheMIBs. These "standard" MIBs are defined in standards like NTCIP 1202[1], which are freely available online through the NTCIP group.

These standard MIBs let you set/get all kinds of fun settings... put the lights into flash, change timing settings, set "preempts" to give yourself a green light, and more.

The standard also strongly suggests that all vendors use a default SNMP community name of "public". That means, for any traffic controller you happen to find on a network, you can almost certainly change tons of scary settings without even needing to _exploit_ anything!

I've been working in the industry for quite some time, and it's genuinely scary how poorly secured some of this infrastructure is and how slowly things move when issues are found.

(Disclaimer: I work in the industry, not for any of the companies discussed in the article, and all these views are my own and not those of my employer)

[1]: https://www.ntcip.org/file/2019/07/NTCIP-1202v0328A.pdf

Generally no, this is something from fiction.

I'm mostly familiar with North American traffic signal control, and in those traffic cabinets there is a device known as an "MMU" (Malfuction Management Unit) which acts as a safety monitor for the rest of the traffic cabinet.

That device will catch so-called "conflicts" (two conflicting directions green at the same time) and put the intersection into a fail-safe state (usually flashing red/yellow lights).

There are of course some edge cases where this is technically possible (as long as the cabinet door is open in CalTrans TEES cabinets, you can actually remove the MMU entirely and do whatever you want), and I'm not familiar with safety mechanisms used in other localities.

(Note: I work in the industry, not for any of the companies in this article, and my views are my own).

There is a revocation system in place (the RevokedKeys directive in the sshd configuration file, which seems to be system-wide rather than configured at the user-level. At least, that’s the only way I’ve used it)

I agree with the sentiment though, it is far less extensive than traditional X.509 certificate infrastructure.

Canada Post, the equivalent of the USPS in Canada, offers exactly this service [1]

I've used it for Know-Your-Client type stuff with banks, but it is theoretically open to most if not all businesses. Every time I've needed to interact with it, it's been a straightforward process as a consumer.

[1]: https://www.canadapost-postescanada.ca/cpc/en/business/posta...

C compiled down to eBPF (as implemented with the Linux kernel) is not turing-complete. eBPF has a wide variety of uses from network filtering to hooking into certain syscalls.

The bytecode is theoretically turing-complete, but the verifier present in the kernel ensures that the code contains no loops and accesses no out-of-bounds memory.

With `clang`, you can compile C down to eBPF bytecode. It's a subset of C, with a lot of restrictions, but it is familiar and capable of some remarkable things past just simple packet parsing & filtering.

I'm curious how you'd propose doing that.

If I give you a buffer of 5 bytes:

[0x68 0x65 0x6c 0x6c 0x6f]

there are a ton of ways to interpret that.

    - The ascii string "hello"
    - 5 single-byte integers
    - 2 two-byte integers and 0x6c as a delimiter
    - 1 four-byte integer and ending in the char "o"
    - 1 32-bit float, and one single-byte integer

etc. Or are you hoping for something that will provide you with all the possible combinations? That would produce pages of output for any decently-sized binary blob.

We found that working inside a docker container isn't usually turn-key.

You need to figure out a system to get UID/GIDs in sync between the container and the host (otherwise you mess up permissions of files in your repository. This isn't terribly hard, but is annoying boilerplate to keep writing.

Plus, docker-compose doesn't really offer command discovery. Looking at a docker compose file, I don't know how to run the project's build steps, or run their linter or tests. Having to look that up is, in my opinion, annoying.

In general, we try to provide sane defaults, so that users (and to some extent maintainers) don't need to understand Docker and how it works in order to start using it.

We did find that project as well. It's unrelated though - ours is intended to run on your local machine whereas that one seems intended to run on a server somewhere.

Unfortunate naming collision though :(

Hi Hacker News!

We have been working on a tool called ENVy:

http://envy-project.github.io/ https://github.com/envy-project/envy

ENVy is an environment manager to make working on disparate projects easier. You don't need to worry about what a package is called on your Linux distribution, or figure out how to build for Mac from scratch.

Part of our goal was to make it easier to contribute to open source. We noticed that long contributing guides dissuades casual involvement - if you have to install a bunch of dependencies (that you won't necessarily know how or remember to get rid of), and spend half an hour getting set up, you're not very likely to fix a typo or make a 30 second fix for a personally annoying bug.

There's also some value for business projects - we've found times that you just need to make a "simple" change to another team's codebase, and it turns into a multi-day effort of setting up an environment.

Setup with ENVy is as simple as typing `envy up` for any project you want to work on. Running `envy nuke` removes all traces of that environment. With ENVy, you don't need to hunt down a lint command or how you run the tests. `envy -h` shows you all the commands you can run - or just jump into a shell with `envy shell`.

You can read more about ENVy on our site, but the short version is that we think it'll make it easier for contributors to help out in open-source projects.

If you're interested, you can check out some examples to get up and running:

https://github.com/envy-project/examples

Under the hood, it handles the intricacies of setting up and working within a Docker container - it sounds simple on the surface, but networking, file permissions, and setup can wind up being kind of complicated.

We definitely realize that a critical mass of users and projects is required to have this be a truly useful project, and we've started to open some pull requests in open-source projects to gauge maintainer interest.

I've used this a handful of times, actually!

I've mostly done it to determine a "next" IP address from a large range - i.e, what IP comes after 10.0.0.255, and how can I bound it between 10.0.0.30 and 10.0.1.128?

It's much easier to increment an integer, compare it to other integers, and then convert it back to an string-format IP than it is to implement those operations by "parsing" IP addresses.

> (maybe with some kind of publicly deployed differential gps?)

I believe this is supported/expected in the DSRC specifications. As I understand it, a well-known point, such as a post at a corner of an intersection, is located with high accuracy. A DSRC Roadside Unit can then broadcast GPS corrections to provide significantly higher accuracy to units that are able to receive and use this information.

It does require some infrastructure support, but it's something the specification group has thought of.

One reason is to use infrared remotes with an HTPC.

With LIRC (and now possibly this more performant solution), you could use pretty much any remote you could find with your computer, with cheaply available and DIY receivers.

It's great not to need to use a keyboard and mouse to control something like Kodi, and be able to use the same remote you use for your TV.

Wow, this brings back memories of running the theater in my school. Definitely a different situation, but I like to think we did a good job given what we had.

We didn't really have a budget, just some hand-me-down equipment that came from above sometimes. I and others on my team put together so many hacks to make things work. One memorable time, our light board had broken, but we still needed to run shows.

We didn't have enough time to wait for shipping on a real USB->DMX adapter, nor budget for a new board, so I created a hacked together DMX adapter with a serial to USB adapter and a NAND gate (I put schematics together here, if anyone's interested: https://github.com/magmastonealex/DMXAdapters).

It worked remarkably well for being a bit of a hack, but paired with software like QLC+, had more features than our old light board! It was still in use for controlling special effect lighting when I left, though thankfully not for main lighting and day-to-day use.

Yes, ATSC in North America generally uses MPEG-2 video, in an MPEG-2 transport stream (often with AC-3 as the audio codec).

There are provisions to use h.264 within that transport stream, but I'm not sure if any stations actually broadcast with that.

It's not super clear which blobs are needed for particular devices - and it's different for all of them. I'm not aware of a single place to find what's needed - though the LineageOS device repositories can help a lot.

The plan, especially when it comes to modems and graphics acceleration, is to package these firmware blobs separately. Then, a user can choose at install time if they're alright with non-free blobs running on their phone. This has already been done for many phones for WiFi/Bluetooth chipsets.

This method also has the advantage of letting us move quicker - we don't need to wait years to reverse engineer modem firmware, or be required to spend the time mainlining every device we want to add in order to get the "essential" features for a phone.

(I'm a developer on the project)

The postmarketOS [1] project is trying to fix that. It's effectively creating a unified base layer on top of phones without any Android libraries. There are also lots of efforts to add UIs and other packages as well. In addition, there's a handful of devices that have actually been ported to use the mainline kernel.

By no description is it ready for daily-driver use, but there's been a lot of progress for a project less than a year old.

[1] http://postmarketos.org

I agree. The only advantage ADS-B has is that it doesn't require building an antenna unless you want a lot of range.

I've found that receiving weather satellite images makes for a much more interesting project, and seeing live satellite images tends to interest people a lot more than knowing where planes are.