This is my discussion blog. The way it works is that when any pages in this wiki have a discussion page created for them, the discussion pages show up below. Also, any comments on my blog posts also show up here.
As anarcat points out you can probably cover that distance with wifi. In Catalonia we have a huge commons network (guifi.net) of more than 32.000 nodes with 16+ mile links and several optical fiber towns as well.
Don't you have any wifi/wimax (LMDS) provider on your zone? The price and power consumption will be lower and the bandwidth and latency much better.
"a few miles" away seems like something that could be bridged with a high speed WiFi link. at the montreal mesh, we have successfully built a 3km link using 5GHz frequencies. this was done with two Ubiquity Powerbeam M5-400-ISO devices. it's obviously line of sight and unidirectional links, but it works well, from what i've heard.
If you have some wind around, you can have additional power source with wind generator.
See this guy- did an amazing job for couple of bucks http://www.mdpub.com/Wind_Turbine/
as a suplementary to your solar panels
I don't know of any good way to do it. Ideally, git would have a way to signal a redirect from one mirror of a repository to another one, and could learn the new url.
I have created empty repos on github with the same names as the deleted ones, and in their README put the url to use. Not an ideal solution as it could confuse people and scripts.
In my case, all the projects were not hosted on github, only mirrored there (except for github-backup). So, googling will find their websites and git repos still.
do you know of any way to leave a pointer on github to the new location?
You are famous :-) so you can just put the links in your blog, but if anyone at all cares about my hacks they won't find it unless I tell them there.
But I couldn't find any way - the "bio" is only twitter-size, and there's no other text field I see that's independent of the repos themselves so it would survive their removal.
Of course, what we really need to worry about is not ASCII art, but binary firmware published by git repository. The linux firmware repository, for example.
Here's how to use the SHA1 collision generation attack to modify a firmware file so there are two versions, one of which runs a malicious exploit and the other which does not. The good version can be distributed, and then replaced by the bad version without the replacement being noticed.
Identify the first instruction run by the firmware at boot. Replace with a jump to 129 bytes after the current end of the firmware.
Use the resulting file as the input the the collision generation attack. (If you wan to target this being stored in a git repository, include a git blob header in the data used to generate the collision.) Now you have two 128 byte chunks which when appended to the file in #1, result in two different, SHA1-colliding files.
At the end of each of the two different files, append the same payload. Since the SHA1 hash function is in the same state at the end of each file in #2, appending identical data to each file yields new files that also collide.
The payload examines the memory in the 128 byte colliding area. If it sees the "good" version, it runs the instruction that was originally replaced with the jump, and jumps back to the second original instruction. If it sees the "bad" version, it runs the remainder of the payload, the exploit.
Obviously there is some trickiness to do with relative addresses and returning registers to the original state when jumping back in the "good" version etc. But this should be very doable for any assembly programmer; it should even be possible to completely automate it.
@tanmail sorry, you're entirely wrong.
Once the common prefix and the collision data have been fed into SHA1, both the "good" and "bad" SHA1 calculations have the same internal state. So, any common suffix after that will result in the same SHA1.
If you don't believe me (or the paper that says that same thing in a more mathy way), you can easily verify this with the published SHA1 collision files.
@nomeata, I'm sure it would be harder to limit the collision to printable characters. How hard I don't know (even after reading the paper).
AIUI, they're using a SAT solver; it might be that it could be modified to remove solutions that use unprintable characters, and it might only have to work a "little" harder.
Or it might take the obvious worst case of needing to run the collision generator repeatedly until it finally finds a suitable collision.
\, for example) is, AFAIK, much harder than a general collision. I wanted to use a MD5 collision to break Haskell’s type safety via
Typeable, but failed because of that. Also, would the prefix have to have a certain length?
I do not think your idea is applicable as it is, because what you are using here is two files, with a variable part (the first line of ASCII art), a common prefix (everything before that line), but also a common suffix (everything after that line). If your variable part is designed to that the concatenation of the common prefix and that part gives the same hash with the two versions, that will not be the case for the concatenation of the common prefix, that part and the common suffix. Therefore, the two versions of the complete files with not have the same hash, only their first three lines do, but nobody verifies files integrity by taking the hash of its first three lines…
It may be possible to mount such an attack, but I think it would be quite more complicated…
As far as I know, you do not need a 192 byte prefix, it should be able to be any length you choose. "192" does not appear in the paper. The 192 bytes that appear before the good/bad chunk in the SHA1 colliding pdfs consists of the regular header of a pdf document. A prefix consisting of some C code would work just as well.
To make files that result in colliding git blobs, one only has to add at the front of the above prefix eg "blob 5000\0". The SHA1 collision generation attack then proceeds as normal. Once you have its results, you just strip that blob prefix from them, pad them up to the selected size of 5000 (eg by adding more common C code at the end), to get files that can be checked into git and will yeild colliding blobs. The need for the file size to remain fixed is the only real complication here.
neat post. As far as I can tell, you also need to get the SHA calculation in the proper state, though For example, just the two different string parts will not compare equal, you need the 192 bytes of prefix, too. Also, you cannot prefix the blobs with a common prefix and get the same result. So I would think that there is still significant "cryptographic" effort needed to apply this to git.
misterbonnie 7*yLN#!NOK misterbonnie mFMC^&*FMM' misterbonnie | *' _\ misterbonnie | =|MM|\MM but i like misterbonnie \V c_)| putting ascii art misterbonnie |\ __ / in my code :( misterbonnie | __/ misterbonnie \ | misterbonnie \
@Joachim I was aware of haskell-tor when I built this. I chose not to use it for a bunch of reasons including, it does not suppport tor hidden services, it's not been peer reviewed, tor has a much more active development community that's working on a next generation of hidden services amoung other things.
instead of relying on a system installation of tor, have you considered using tor as a library, maybe using the bindings provided by Galois: https://github.com/GaloisInc/haskell-tor
You might also be interested in how this Tor-Hidden-Service based instant messenger does it: https://ricochet.im/
Flatpak and snap don't seem to make it any easier to deal with this than docker does. Probably harder if your app has any unusual dependencies, since if the Flatpack runtime does not include a dependency, you have to bundle the dependency with the app.
Compiler developers should not need to worry about including their compiler in a runtime.
Flatpack might be slightly less of a security nightmare than docker is, due to more finegrained sandboxing, and since the app runtimes can be upgraded.
It seems unlikely they're going to take off though. Docker has already nearly fully occupied their space, and instead of competing with it, flatpak and snap are competing with one-another.
i have a similar concern in a project i'm working on now, which is to run a bunch of tests in one window and showing system logs in another window for convenience. i thought i would use tmux for this because the commandline interface is simple enough to be used like an API. my previous approach to this was to use a multi-interface design with simple functions like "alert", "prompt" or "log" that would send stuff to different places (terminal or gtk windows) depending on the environment, a bit like what debconf is doing, with all the crap that implies (generally: a suboptimal interface everywhere).
as for an irc client, you may be curious to try out
ii: it's a simple
FIFO and filesystem-based irc client that implements basically no user
interface... a little nuts, but sounds like it would be the backend to
the UI you are describing.
this is awesome. :) i have used this in weird cases (which, unfortunately, now include debian jessie ;) and bundle at least one of those binaries next to my git-annex archives...
Trying out I2P is what I would recommend here, because especially if you are interested in filesharing or anonymous mail-services, this would probably be more cost-efficient, it is said to exist inside the FeeBSD ports-collection. So from my perspective TOR is nice for anonymous web-surfing, no idea about onion-services. Some big sites closed their services to TOR-users unfortunately, probably because of DDoS-attacks, some even don't accept connections from filtering proxies anymore. I2P is still in beta-status AFAIK, but probably one day it is going to be fit for real productive use and match up TOR. I2P is a different category, in so far as even the devolpers are anonymous and known by their pseudonyms only.