On Monday 19 January 2009 15:04, Daniel Cheng wrote: > 2009/1/19 Matthew Toseland <toad at amphibian.dyndns.org>: > > There were at least: > > - A lack of validation on the captchas page which enabled collecting users IP > > addresses. This involved putting newlines into the headers in order to send > > extra headers and in particular redirects, and was actively exploited by > > nextgens to collect IP addresses. Another variant would be to send an > > embeddable but dangerous content type such as flash. You have fixed this? > > Great. > > - A format string vulnerability. I believe this enabled remote code exec, or > > at least a segfault. This was fixed, but it's a great demonstration of why > > you need to be *really* careful when using C/C++ for security critical code. > > > > But the bottom line is FMS cannot be bundled, therefore it is not worth my > > time to review it. FMS is written in C/C++ and therefore would be difficult > > for me to review - I missed the format string vulnerability when I reviewed > > So why the wxWebkit browser be differ? > > FMS is written in C++ already, so you have no choice. > That wxWebkit browser is a new project, why choose a language that you > can't review? > > (no, i am not opposing the wxwebkit. i am just asking for some consistence over > decisions.. i really hope fms can be bundled)
Bundling a customized browser would solve some major problems affecting the security, performance and usability of Freenet. IMHO the alternatives are not acceptable: it is very difficult to have a web interface and make it both secure and fast, without either a custom browser or a browser extension. A custom browser is more controlled and easier to secure. The user would still have a single daemon, and a single point of contact, from which the Freetalk plugin's web interface could be accessed, and likewise with any other functionality that we decide to put in. As regards code review, saces has agreed to commit to our main repository so that I can comment on, and if necessary make changes to, his commits, as they go in. This means I don't have to review a huge blob of code including some parts copied from arcane unmaintained libraries that flagrantly violate any conceivable code quality standards. Good C++ code isn't that far from java - it is a high level language, you don't get buffer overflows, remote code execs etc. Bad C++ code has the exact same issues as bad C code, and is hard to review. FMS' format string vulnerability falls into the latter category. Bundling FMS is completely different to making a custom browser. The code is much harder to review, partly because of code quality and partly because of remoteness. More importantly, FMS is not part of Freenet. Even when we did bundle Thaw and Frost most new users didn't see them. Separate applications are simply not going to work for Freenet: there is enough conceptual overhead that we can't get rid of, introducing even more is just bad. And there is much that can be done in a web based interface to tie things together usefully. If we use a custom browser, we will probably get rid of fproxy - make it a plugin which is not loaded by default. So from the user's point of view, there is only Freenet. > > > 0.2.X - and it cannot be integrated into the fproxy web interface, it > > With the wxWebkit browser using fcp directly, who care fproxy? USERS DO! Especially new users. FREENET MUST BE EASY TO USE. Or nobody will use it. Having 10 separate applications bundled, and having the average new user only exposed to one of them, is a recipe for disaster: they will see fproxy, they will see that it is slow and doesn't let them do enough interesting things, and they use gmail and facebook, they've never used a newsreader in their entire life. It is critical to get new users into the community by providing forums support inside fproxy. Apart from that, plugins can be updated from within Freenet, and Freetalk is split into Freetalk and WoT, on the reasonable assumption that other plugins will also use the web of trust and may want to share identities - this simply isn't possible with the monolithic single-purpose FMS daemon. > > (btw, i seldom use fproxy. > Most of the time i use freenet was on fms / frost. > Having fms page as homepage make more sense for me.) Then you can see why it is critical that new users be able to use forums immediately. > > Also, fms have a web interface before my computer have dead > -- SomeDude is very responsive to feature requests and willing to > discuss about the message format. So what? Either it is part of Freenet, and we are responsible for it, we bundle it, and we integrate it into the main UI which a new user is presented with, or it isn't, and we don't. > > Freetalk keep changing its message formats, that's bad. > I know those are "consent" of IRC discusion -- but it changing > it every few weeks is not a good idea. > Someone know the details should write down a specification -- > in this way we may discuss the pros and cons and SomeDude > may come up with some compatibility. p0s has agreed to record the specs after he gets the current message lists changes working. > > > requires a separate daemon and is written in a different language. And until > > separate daemon -- just a bundling issue. a good startup script fix it all. No it isn't. The architecture of Freetalk is better, separating the WoT out. And there is much scope for integration between different plugins. > > different language -- see above. Different language is a serious problem, especially with C++. It is an acceptable tradeoff in the case of wxFCP or an XULRunner-based frontend, because we can review it from the start and can make whatever changes are needed to ensure code quality (i.e. no printf's, no pointer arithmetic, C string manipulation functions etc!). It is not an acceptable tradeoff with FCP, because it incorporates large chunks of likely insecure, hard to review C code, and because we cannot review it incrementally. How much of this is Not Invented Here syndrome? Well, sometimes NIH is a good thing. If we do not control it, we will not ship it, period. For us to control it, means we have to fork it, and engage in a massive code review before we do. > > > very recently it required a separate newsreader as well, making it extremely > > user hostile. > > > > Freetalk on the other hand can be bundled, and has a better architecture, > > enabling WoT to be used for WoT-based apps other than forums. Thus I have > > been helping p0s with Freetalk. > > ugh. > Let's see how p0s intergrate freetalk with the wxwebkit browser. I don't see what the problem is here. A browser by definition renders HTML. I would expect to keep most of our existing web interface, one way or another - either by keeping a web server (and depriving it of the ability to fetch keys), or by serving the pages over FCP. I have no intention of rewriting the entire user interface into a series of tabbed dialogs, and frankly I have very little ability in that area, and furthermore there is no point - more people use webmail than use dedicated mail clients. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20090119/31cda8b3/attachment.pgp>
