Forgot your password?
typodupeerror

Comment Can't blame it all on Private Equity (Score 1) 26

The poor architectural decisions and lack of care when fixing vulnerabilities goes way back, before PE got involved, it seems. Fortinet decided that "encrypting" their appliance filesystem to obstruct researchers was a better use of their time than actually trying to *design* a secure architecture for their systems. Of course, it was a pointless waste of time, because the appliance decrypts itself during boot, so the keys are available.

Another of the VPN vendors had a more recent vulnerability, that turned out to be in the same CGI as another vulnerability reported several years before, just a different parameter. Had they taken security seriously back then, they would have searched for any other places that could be vulnerable, not just implemented a point fix.

And of course, practically every vulnerability discovered in the major VPN providers ends up as a root shell. Because everything is running as root, rather than as a less privileged user.

This is what e.g. OpenSSH does. Someone finds a vuln in OpenSSH, and they scorch the ground! They implement solutions to eliminate entire classes of vulnerability in their code base, so that it can never happen again. They architect their code to reduce impact of any vulnerabilities in a belt-and-braces approach, for example, privilege separation to ensure that the exposed attack surface is mostly in an unprivileged context, rather than root.

Comment Re:One of the strongest temptations... (Score 4, Insightful) 82

...among programmers is to rip it out and start over. I've done this many times, often achieving success
Problem is that old, crufty code works. It may be imperfect and ugly, but it works and has stood the test of time
Ripping it out and starting over is always harder than it appears, often a lot harder
It may fix some old bugs but it often introduces new ones and loses old functionality

This is not ripping anything out, though. This is allowing simultaneous development in both C and Rust, in order to evaluate the benefits of Rust over C in a real-world project. And, based on the progress so far, both Linus and Greg K-H are seeing benefits, or at the very least, wish for the evaluation to continue. It's a bit hard to argue against the people who are arguably doing the largest amount of work on the kernel, and see all the areas that are or could be affected by it.

And yes, in the future there may be incremental migration of functionality into Rust code vs C code. It's certainly not going to be soon, and I seriously doubt that it will be rushed. From everything I have seen, the only way it will happen is from the outside in. Code on the periphery will be implemented in Rust, talking to a C/Rust interface to core C code. Slowly, as C clients of the core C code are replaced with equivalent Rust code, that core C code can be migrated to Rust.

Comment This is not unique to South Africa (Score 1) 19

Network providers in other countries are also attempting to get OTT providers to pay for "transit" across their networks to their own customers.

https://www.lightreading.com/b...

A general discussion about OTT providers in the context of carriers:

https://carritech.com/ott-tele...

And a brief discussion about paying for transit, and partitioning the internet:

https://bgp.tools/kb/partition...

Comment Re:I wish! (Score 1) 158

I'm working on a WiFi Keyboard and Mouse interface, using a Cactus Micro v2 board. This has an atmega32u4, which appears to the PC as a keyboard and mouse, as well as an ESP8266 Wifi microcontroller, which connects to your home wifi and exposes a TCP service to accept K/M events. Connect to it using your phone/tablet, send keystrokes/mouse movements to your PC, view the results via an HDMI over Ethernet extender.

Still in progress, but sounds like it might address your problem.

Comment Re:It's not a networking issue. (Score 1) 384

Indeed, my solution would have involved something like a TP-Link WR703N, running OpenWRT, powered from a USB battery pack. (I'm assuming that each of the pumps is some distance from the next, and you don't want to have Ethernet cables running across the forecourt. The battery pack is optional, I guess you may also have power available at each pump). Configure each mini router with an appropriate IP address on the Ethernet port, and then do Source NAT from the Wifi to that IP address when talking to the pump. Configure the WiFi interface to connect to an AP that you set up centrally, that your laptop will also be connected to. This takes care of the issue of simultaneous connectivity to each pump.

As far as software goes, it sounds like a virtual machine for each is a requirement, so that they can run independently of each other. This *might* end up being the trickiest part, depending on how much configurability you have in the application that actually does the firmware updates.

* If you can specify the IP address of the destination pump in the update software, great, simply bridge or NAT each VM onto the Wifi network set up in step 1. Configure each VM to speak to the IP address of each 703N, and perform the update. Done.
* If each VM needs to have the corresponding IP to the pump's, things get a little trickier, and you may need to have another layer of NAT to get this to work. I suspect that you would run into issues with the number of private networks that your Virtualisation software supports, in this case.

Comment Laser cutting directions! (Score 4, Insightful) 59

Breathless excitement!

The achievements in the rest of this paper far outweigh the existence of a tablet built on this foundation.

They've created their own 64-bit processor! They've implemented a compiler for it! They've ported FreeBSD to it! That's some seriously impressive stuff!

But the leader has to be the laser cut tablet assembly. :-(

Slashdot Top Deals

What hath Bob wrought?

Working...