Slashdot Mirror
P2P Meets Push
meonkeys writes "What if you could securely subscribe to a trusted P2P file broadcaster? Check out konspire! An interesting concept; implemented in C++ and controllable via a cool Web interface ala Mutella."
← Back to Stories (view on slashdot.org)
Pushing files, huh? It's as bad as pushing drugs. Into jail, my little hacker-bee.
Sig for sale or rent. One previous user. Inquire within.
...when it was called IRC. Seriously, this sounds like a traditional IRC channel with XDCC bots. Decentralized (many servers on the same net comprising a single channel) and varied (you can have many varied channels). I mean, it sounds like a cool idea, and a neat proof-of-concept, but is it really needed or useful?
now I don't have to search for porn, porn comes to me.
Je t'aime Stéphanie
I am not interested in "pushed" multimedia, but imagine having your Gentoo packages already pre-fetched for you, whenever there's an update? Emerge and it just starts compiling w/out the download step. Mmmm...
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Am I to understand you start it up, go to bed, and wakeup to having a buncha unknown files on your computer? And this is a good thing?
Now I don't have to manually download crappy rips of my favorite songs, I can have them forced upon me! :-)
No, crappy rips of somebody else's favorite songs will be forced upon you.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
I'm gonna try it now!
Luck favors the prepared, darling.
Especially since in this network, whoever distributes a given file also requested it (at least that's what I am reading out of the documentation), in contrast to other networks, eg. freenet where the fact that you have data on your HD and distribute it to other people does not imply that you requested that data to be there yourself.
(Note: I still think this is a pretty neat concept, though!)
Switch back to Slashdot's D1 system.
without konspire: 8 hours d/ling, compiling software
with konspire: 7h55m compiling software
Wohoo!
(Any input given would be gratefully received btw)
Get your own free personal location tracker
But I refuse to download anything from a website with a black background.
But for server apps, I think it's the wrong choice.
Maybe, but my personal opinion is that in the end it's better to write an application in a language you know really well (but might not be the best thing) than write some hacky fudge job (which will no doubt be really flakey and possibly even more insecure) in a language you don't know just because it's the best one to use.
Avantslash - View Slashdot cleanly on your mobile phone.
Now I don't have to manually download crappy rips of my favorite songs, I can have them forced upon me!
It's called radio.
Some people have a way with words, others not have way.
Hell, with push technology, they could just create pirates on the fly as needed.
The concept of konspire is really cool. It provides a good method of anonymity of the original sender. Pesonally I'd like to see it use the bittorrent method of file delivery because you have the potential of only having to send the whole file once, plus if konspire decides to send the file to a 28.8k modem user first, everybody else will have to wait until that user gets the file before they can receive it, where as bittorrent's method can send to many people simultaneously and still use less bandwidth. The problem with bittorrent is that you know who sent the original files, because you got the .torrent from them, so a combination of both technologies would rule!
I'm not a real doctor, but I recommend beer.
Let's face it, languages with security features are more suitable for servers.
Uh, exactly what security features are you looking for?
I'm assuming you're going to be using the STL... if you're not, well then I hope you're not planning on using any Perl modules or Python libraries either, because otherwise you're really comparing apples and oranges (not that you aren't already, but that's another discussion).
std::string and std::vector take care of most of the security concerns you might have -- presuming you use them properly of course. If you need to deal with pointers and std::auto_ptr isn't useful (which, in general, it's not) then use a smart pointer library -- I highly recommend Boost - I've used it's shared_ptr class and like it. In over a year of serious C++ development we've had exactly one memory related problem -- and that was from me misusing boost (and suspecting I was doing so during development but forgetting about it during testing).
The general concerns with C/C++ are buffer overruns and other memory stomps. If you use the right libraries it's not an issue in either (go look at vsftpd's string functions for an example of what I'm talking about in C). If you're writing insecure C++ code then it's most likely because you're ignoring significant language features (like the STL). It's not a language issue.
When does the technology get pervasive enough to start warranting more useful apps built on top of P2P? Like a way to post resumes, jobs, RFPs, etc.. and be able to query/respond... without needing the 400 job boards out there. Or code snippets, or news services that can survive massive overloads ala 9/11?
meh
Yes, I fully agree. vsftpd is one of the best examples of how to write secure C. As for Kast .. I briefly checked the sources, it's using a lot of code such as:
foo = new[ strlen(bar) + 100 ]; sprintf(foo, "stuff %s", bar);Which is safe only as long as you're careful. And was the author careful enough? No. I'm not touching this thing until the sprintf()s are gone.
So to any given node it is unknown whether the node it's receiving a transmission is the original distributor. But still, the node it is receiving from is a distributor - that's just as illegal, at least in the context of copyright protected works. Especially since in this network, whoever distributes a given file also requested it (at least that's what I am reading out of the documentation), in contrast to other networks, eg. freenet where the fact that you have data on your HD and distribute it to other people does not imply that you requested that data to be there yourself.
...but as a direct consequence of knowing what is in your share, or at least the ability to know that (that is, only the things you're subscribing to). Open relays don't get sued for fraud, 0 day hacked warez servers don't get sued for piracy (arr!) and your DDoS host doesn't get sued for launching DoS attacks because they did not know what was being routed through them.
Freenet is basicly trying to make everyone (except the inserter and the requester, which are difficult to find) be a common carrier (ISPs do caching, so the fact that Freenet caches stuff does not prevent this). Whether that argument will stand up in court is questionable, but this system certainly won't hold up to this defense.
Kjella
Live today, because you never know what tomorrow brings
according to the directions I think you're supposed to go to bed now
Security features in a language attempt (poorly in most cases) to substitute for the programmer having an adequate security mindset. If you rely on the security features of a language, then you're screwed if they're broken. You're relying on the security auditing that has been performed on that language's features, and committing yourself to live or die by it. Have you personally verified that that language's seecurity features are designed well, and strong enough to meet your security requirements? Has someone you trust done so and published the results? If not, why are you relying on it?
My advice is go the opposite direction. Learn about security from a programmer perspective. Accept only libraries and components that have been extensively audited by knowledgeable, trusted sources. Then build your server on top of them in a lower level language that affords you the ability to take direct charge of everything else. Make your server secure by thinking about security in every line you code.
I use C, but the exact choice of language isn't important; the mindset and approach is. This advice applies equally to any other language: Check the return value from EVERY system call, EVERY resource allocation, and EVERY library call. Verify ALL inputs before using them, both for length and for sanity of contents. Before EACH time you write something to any kind of buffer, check that you won't write past the end FIRST. Do all of these things in every function of every module of every application. And if you rely on a language or library feature instead of doing it yourself, you'd better be damn sure that the language or library feature is doing it correctly and completely -- VERIFY this before you deploy your program.
Some may call writing in C a security risk. Inherently, it isn't. C just gives the programmer more rope to either make a better knot or make a better noose, as they see fit. The first ten to twenty lines of nearly every C function I write go like this: return failure if this parameter isn't sane; return failure if that parameter isn't sane; return failure if any persistent context isn't consistent with how we were called; try to allocate all resources required for the function and return failure if any of those allocations failed. Some other languages may automate some of that. But as a security auditor, I'm going to want to see all that. If I can't see it, I'm going to want to examine in detail the implementation of the language features that do it implicitly. If I can't do that, then I can't consider the program secure. Using C helps me audit my code because it forces all security measures to be explicit and spelled out in detail. Yes, that's more work for the programmer. But it's less work and more certainty for the security auditor. That's a tradeoff I'm willing to make.
-----Chaz
"Needles," it reasoned, "often contain medicine."
And, so reasoning, it jammed the rusty needle directly into its ass.
Moral of the story: