Publish a readonly chain of all firmware builds that you have ever produced. Equivalent to a adding the firmware blob of every release version to a git commit history. Encourage other people to monitor that log.
Then have the current firmware verify that its own hash, and the hash of the new firmware is in the commit history for the release log.
Firstly this is an attempt to split the core java libraries into pieces so you will be able to use only the pieces you need. eg; $ apt-get install java-headless. Due to the existing definitions of packages and classes, this could not be simply done by splitting the existing classes along package boundaries, a new abstraction was required.
Second, with Java's existing access controls of public, private, protected and default. There are quite a few occasions when the language forces you to make an implementation detail of your code public, which you would rather leave inaccessible to 3rd parties. Modules essentially demotes "public", and adds a new explicit "really public".
Based on our research, we recommend that the affected operating systems:
- Increase the size of the stack guard-page to at least 1MB, and allow
system administrators to easily modify this value (for example,
grsecurity/PaX introduced/proc/sys/vm/heap_stack_gap in 2010).
This first, short-term solution is cheap, but it can be defeated by a
very large stack-based buffer.
- Recompile all userland code (ld.so, libraries, binaries) with GCC's
"-fstack-check" option, which prevents the stack-pointer from moving
into another memory region without accessing the stack guard-page (it
writes one word to every 4KB page allocated on the stack).
This second, long-term solution is expensive, but it cannot be
defeated (even if the stack guard-page is only 4KB, one page) --
unless a vulnerability is discovered in the implementation of the
stack guard-page or the "-fstack-check" option.
That was one of the recommendations. Finding large stack allocations, in setuid binaries, that don't write to the allocated memory is hard.
If his system worked at all, it's likely to only work on his test inputs. Sure it can compress these few video inputs and output something like them again. But what does it look like if I give it some random other randomly selected video?
Everyone loves to blame NBN problems on the copper. While I agree that building fiber to the node is stupid, that's not the biggest problem with the NBN. The pricing model of the NBN means that only huge ISP's can compete on price, by massively oversubscribing. To compete you need a very large number of customers in each geographic area, so you can reduce your CVC charge per person. CVC? Well there are 3 costs associated with leasing a line from the NBN. First is the customer end, with difference price tiers per connection speed. Perfectly understandable. Second is a per-port cost in a central location for the cable into the ISP equipment, about $200 a month per Gbps ethernet port. Again, nothing wrong with that, seems perfectly reasonable. The third cost is the Connectivity Virtual Circuit (CVC), and it's outright extortionate. $14.50 per month (or thereabouts) for each Mbps the ISP wants to light up. So if you want to use a 100Mbps connection 24/7, it will cost your ISP $1450 a month to provide it.
We're supposed to be building a great big fiber network to cover the country, with enough capacity to meet our needs for the next 100 years. So, WTF are we treating *bandwidth* as a scarce, expensive resource?
My other gripe with telecommunications in Australia is about the way telstra gouge everyone who wants to communicate with their customers. But that's another story...
So long as you don't end up with something like Australia's NBN, where most of your expense of using these interconnection points is not per port but per MBit/s per month to lease bandwidth over that last mile.
When an application is drawing stuff, there's plenty of cases where you have to wait for round trips from the application to the XServer too. Plus the application, X and window manager can all manipulate the same properties of a window, so there are plenty of cases where you can't be certain what will actually happen.
I prefer to think of wayland returning to the unix philosophy of doing one thing and doing it well. It takes over the job of rendering multiple windows on a single desktop, and forwarding mouse and keyboard events to applications. Everything else is out of scope. Is Wayland doing that job well? Maybe, but I'm not an expert.
If you want to display an application that talks X11, or connect to another server via RDP or VNC, do that with another program. If you want to innovate in this space, go ahead. Build a GTK or Qt remoting protocol or something. Having a clean separation between network protocol and display compositing should help the ecosystem in the long run. I will say that the X11 wayland client isn't that good, I've seen plenty of weird bugs when using old applications.
The big challenge to adoption is the conversion of existing applications. Even if you are using a high level toolkit, there are bound to be a few X11 library calls hanging around.
I'd like to suggest something like trevisor, a hypervisor for a single guest VM. Where the user enters a passphrase on boot, and the encryption keys are only stored in debug registers. Though this probably needs some additional work to be production ready.
We have modified this tool to remove capacity more slowly and added safeguards to prevent capacity from being removed when it will take any subsystem below its minimum required capacity level
Yeah, they have apparently made this screw up much harder to repeat.
In SVN a commit is final. This encourages developers to leave unfinished work in their work folder without creating a commit until they are "done". So you need a separate backup process for your work folder for any changes that take time to complete. Plus you often end up with a monolithic commit with a bunch of changes. Then how do you review those changes before pushing upstream?
git rebase gives you a solution to this problem. Whenever I think I've made progress towards solving a problem I can create a commit. If I discover that one of those changes isn't right, I create a new commit with the fixup. Then when I'm "done" with the change, I can rebase in order to produce a series of patches that someone else can more easily review. At any time, if I encounter a bug that I want to push upstream. I can rebase my entire branch first to push the bug fix to the bottom, then push that commit without needing to create a new local branch.
At any time I can use git to push my incomplete work to a private server or my own work branch on a team server. Both for backup purposes and for collaboration.
This is why git is not vulnerable in this specific instance. In git all objects are prepended with their type, in this case "blob". Of course if you had $100k (-ish) to burn, you could repeat this attack on a file that does start with "blob" to break git.
However you don't need to do this. This attack depends on reaching an intermediate state with specific properties in order to massively reduce the search space. Any attempt to hash a file that reaches one of these states can be detected and rejected. If you swap to using https://github.com/cr-marcstevens/sha1collisiondetection for all SHA-1 calculations, every instance of this attack can be detected and rejected.
Also I mis-spoke slightly and spotted my error after checking the paper again. The first pair of blocks have half of the same bytes, but produce an internal state with only 6 bytes of differences. The second pair of blocks, again only differ in half of their bytes, and exactly cancel out those 6 bytes of differences. See Table One on page 3 for the actual byte values.
Google produced two pdf's that differ in some binary data near the beginning of the file. The SHA-1 hash routine processes data one block at a time, updating its internal state. There are two consecutive blocks that differ between the pdf's. The first pair of blocks produce an internal state where half of the bytes are the same. The second pair of blocks then produce an identical state. The remainder of the pdf files is the same.
So you can use these two pdf prefixes and append whatever data you want to them to produce your own pair of files. Pdf includes a programming language for rendering content. Within this language you can inspect the earlier bytes of the file to detect which version of the file you are rendering, and make some visual changes. So while there are only a few bytes that are different, you can make two pdfs that display different content.
Nobody has invested the time to produce a new hash collision, but someone has already automated the production of duplicate pdf's based on this work.
(If you run git blame on serval mesh's source code, you'll find my name on about 80% of the code)
Serval mesh uses Wifi and Bluetooth to share files and communicate securely. But it can't bypass google's removal of IBSS from Android. We've kept the code that turns on IBSS on some Android handsets version 2.3.3 or lower. If you really want a mesh network between phones, you can still get your hand on some old ones...
Android's bluetooth & Wifi-Direct stack are a buggy mess. It's far too easy to stumble over a bug that prevents you from getting any data through. Plus both API's are built around having the user confirm each and every connection. Almost completely useless for building a self organising network.
Then there's Wifi. Sure you can turn most phones into a hotspot... If you use reflection to call a hidden API. The carrier hasn't done anything to disable it. And in some cases, only if you have a functional cellular data service. But there's no easy way to tell if there are other nearby devices waiting to connect to you....
The main problem with this new weather app is that nobody will have it installed when they need it. Getting emergency weather information is not going to motivate people to use this app day to day and form the adhoc networks that are needed for it to work. Also this article and the summary is crap, IBM did not invent mesh networking.
Slashdot Mirror
AI Inside
Publish a readonly chain of all firmware builds that you have ever produced. Equivalent to a adding the firmware blob of every release version to a git commit history. Encourage other people to monitor that log.
Then have the current firmware verify that its own hash, and the hash of the new firmware is in the commit history for the release log.
There are two things I'd add to your description.
Firstly this is an attempt to split the core java libraries into pieces so you will be able to use only the pieces you need. eg; $ apt-get install java-headless. Due to the existing definitions of packages and classes, this could not be simply done by splitting the existing classes along package boundaries, a new abstraction was required.
Second, with Java's existing access controls of public, private, protected and default. There are quite a few occasions when the language forces you to make an implementation detail of your code public, which you would rather leave inaccessible to 3rd parties. Modules essentially demotes "public", and adds a new explicit "really public".
Malcolm Turnbull confirms he uses Wickr, WhatsApp instead of unsecure SMS technology
Based on our research, we recommend that the affected operating systems:
- Increase the size of the stack guard-page to at least 1MB, and allow system administrators to easily modify this value (for example, grsecurity/PaX introduced /proc/sys/vm/heap_stack_gap in 2010).
This first, short-term solution is cheap, but it can be defeated by a
very large stack-based buffer.
- Recompile all userland code (ld.so, libraries, binaries) with GCC's "-fstack-check" option, which prevents the stack-pointer from moving into another memory region without accessing the stack guard-page (it writes one word to every 4KB page allocated on the stack). This second, long-term solution is expensive, but it cannot be defeated (even if the stack guard-page is only 4KB, one page) -- unless a vulnerability is discovered in the implementation of the stack guard-page or the "-fstack-check" option.
That was one of the recommendations. Finding large stack allocations, in setuid binaries, that don't write to the allocated memory is hard.
... from other architects.
All other uses of the building are secondary. If architect awards factored in occupant approval, then buildings would be more useful.
If his system worked at all, it's likely to only work on his test inputs. Sure it can compress these few video inputs and output something like them again. But what does it look like if I give it some random other randomly selected video?
That's assuming that this new pixel can be manufactured at the same scale. If you can make normal RGB pixels smaller, then this will never take off.
Everyone loves to blame NBN problems on the copper. While I agree that building fiber to the node is stupid, that's not the biggest problem with the NBN. The pricing model of the NBN means that only huge ISP's can compete on price, by massively oversubscribing. To compete you need a very large number of customers in each geographic area, so you can reduce your CVC charge per person. CVC? Well there are 3 costs associated with leasing a line from the NBN. First is the customer end, with difference price tiers per connection speed. Perfectly understandable. Second is a per-port cost in a central location for the cable into the ISP equipment, about $200 a month per Gbps ethernet port. Again, nothing wrong with that, seems perfectly reasonable. The third cost is the Connectivity Virtual Circuit (CVC), and it's outright extortionate. $14.50 per month (or thereabouts) for each Mbps the ISP wants to light up. So if you want to use a 100Mbps connection 24/7, it will cost your ISP $1450 a month to provide it.
We're supposed to be building a great big fiber network to cover the country, with enough capacity to meet our needs for the next 100 years. So, WTF are we treating *bandwidth* as a scarce, expensive resource?
My other gripe with telecommunications in Australia is about the way telstra gouge everyone who wants to communicate with their customers. But that's another story...
So long as you don't end up with something like Australia's NBN, where most of your expense of using these interconnection points is not per port but per MBit/s per month to lease bandwidth over that last mile.
When an application is drawing stuff, there's plenty of cases where you have to wait for round trips from the application to the XServer too. Plus the application, X and window manager can all manipulate the same properties of a window, so there are plenty of cases where you can't be certain what will actually happen.
I prefer to think of wayland returning to the unix philosophy of doing one thing and doing it well. It takes over the job of rendering multiple windows on a single desktop, and forwarding mouse and keyboard events to applications. Everything else is out of scope. Is Wayland doing that job well? Maybe, but I'm not an expert.
If you want to display an application that talks X11, or connect to another server via RDP or VNC, do that with another program. If you want to innovate in this space, go ahead. Build a GTK or Qt remoting protocol or something. Having a clean separation between network protocol and display compositing should help the ecosystem in the long run. I will say that the X11 wayland client isn't that good, I've seen plenty of weird bugs when using old applications.
The big challenge to adoption is the conversion of existing applications. Even if you are using a high level toolkit, there are bound to be a few X11 library calls hanging around.
That was a year ago and nothing changed...
"I disapprove of what you say, but I will defend to the death your right to say it" ... privately.
I'd like to suggest something like trevisor, a hypervisor for a single guest VM. Where the user enters a passphrase on boot, and the encryption keys are only stored in debug registers. Though this probably needs some additional work to be production ready.
We have modified this tool to remove capacity more slowly and added safeguards to prevent capacity from being removed when it will take any subsystem below its minimum required capacity level
Yeah, they have apparently made this screw up much harder to repeat.
Now build something like this into the base of an electric wheelchair.
In SVN a commit is final. This encourages developers to leave unfinished work in their work folder without creating a commit until they are "done". So you need a separate backup process for your work folder for any changes that take time to complete. Plus you often end up with a monolithic commit with a bunch of changes. Then how do you review those changes before pushing upstream?
git rebase gives you a solution to this problem. Whenever I think I've made progress towards solving a problem I can create a commit. If I discover that one of those changes isn't right, I create a new commit with the fixup. Then when I'm "done" with the change, I can rebase in order to produce a series of patches that someone else can more easily review. At any time, if I encounter a bug that I want to push upstream. I can rebase my entire branch first to push the bug fix to the bottom, then push that commit without needing to create a new local branch.
At any time I can use git to push my incomplete work to a private server or my own work branch on a team server. Both for backup purposes and for collaboration.
You want a revision number? Simple;
$ git rev-list HEAD | wc -l
Assuming everyone is on the same branch of course....
(Obligatory XKCD)
This is why git is not vulnerable in this specific instance. In git all objects are prepended with their type, in this case "blob". Of course if you had $100k (-ish) to burn, you could repeat this attack on a file that does start with "blob" to break git.
However you don't need to do this. This attack depends on reaching an intermediate state with specific properties in order to massively reduce the search space. Any attempt to hash a file that reaches one of these states can be detected and rejected. If you swap to using https://github.com/cr-marcstevens/sha1collisiondetection for all SHA-1 calculations, every instance of this attack can be detected and rejected.
Also I mis-spoke slightly and spotted my error after checking the paper again. The first pair of blocks have half of the same bytes, but produce an internal state with only 6 bytes of differences. The second pair of blocks, again only differ in half of their bytes, and exactly cancel out those 6 bytes of differences. See Table One on page 3 for the actual byte values.
Google produced two pdf's that differ in some binary data near the beginning of the file. The SHA-1 hash routine processes data one block at a time, updating its internal state. There are two consecutive blocks that differ between the pdf's. The first pair of blocks produce an internal state where half of the bytes are the same. The second pair of blocks then produce an identical state. The remainder of the pdf files is the same.
So you can use these two pdf prefixes and append whatever data you want to them to produce your own pair of files. Pdf includes a programming language for rendering content. Within this language you can inspect the earlier bytes of the file to detect which version of the file you are rendering, and make some visual changes. So while there are only a few bytes that are different, you can make two pdfs that display different content.
Nobody has invested the time to produce a new hash collision, but someone has already automated the production of duplicate pdf's based on this work.
Bit flipping happens often enough just in stored dns names, that it's worth buying up some bit flipped names.
(If you run git blame on serval mesh's source code, you'll find my name on about 80% of the code)
Serval mesh uses Wifi and Bluetooth to share files and communicate securely. But it can't bypass google's removal of IBSS from Android. We've kept the code that turns on IBSS on some Android handsets version 2.3.3 or lower. If you really want a mesh network between phones, you can still get your hand on some old ones...
Android's bluetooth & Wifi-Direct stack are a buggy mess. It's far too easy to stumble over a bug that prevents you from getting any data through. Plus both API's are built around having the user confirm each and every connection. Almost completely useless for building a self organising network.
Then there's Wifi. Sure you can turn most phones into a hotspot... If you use reflection to call a hidden API. The carrier hasn't done anything to disable it. And in some cases, only if you have a functional cellular data service. But there's no easy way to tell if there are other nearby devices waiting to connect to you....
The main problem with this new weather app is that nobody will have it installed when they need it. Getting emergency weather information is not going to motivate people to use this app day to day and form the adhoc networks that are needed for it to work. Also this article and the summary is crap, IBM did not invent mesh networking.
port 220, irq 7, dma 1.
I do not miss having to diagnose resources conflicts.
Then you should be able to record your time spend helping other people's projects.
Management can't see what they aren't measuring.
Using 1899-12-30 vs 1899-12-31 is due to counting from 1 instead of 0, and screwing up 1900-02-29 in Lotus 1-2-3...