On Tuesday 20 January 2009 01:29, Daniel Cheng wrote: > 2009/1/20 Matthew Toseland <toad at amphibian.dyndns.org>: > > 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. > > Ugh. How can you sure the wxWebkit code better then the FMS code? > You have to review it anyway. > > Reviewing code find problem and *fix it*. > If all of the reviewers say "hey, i have review it. it's bad. let's > throw it away", > then we should have thrown away all code in freenet repository long ago.
Incremental review and incremental feedback really helps. > > > 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. > > [...] > >> > >> > 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 > > No body care how many daemon running in the background. > The point is: how do we present it? > > Everything is HTML, just add a link or a iframe or a form....... > > > 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 > > In case if you haven't heard it: > FMS have web interface long time ago, you don't need a news reader! Ok. > > > 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. > > ugh. > just pop up the fms homepage right in the face of the user after installation. > case solved. Then they won't see the Freenet homepage! > > >> 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 > > I didn't see any C string manipulation function in the FMS code then i > last checked > (except the sqllite thing... i just trust it to be good enough). Even > if there are some, it's very easy to remove them. Some unmaintained code which somedude pulled in used scanf badly iirc, resulting in a serious vulnerability. > > Review from start is means quality? > Let's see the freetalk code: > > trunk/freenet/src/freenet/support/TransferThread.java line 57 and line > (see > http://www.google.com/codesearch/p?hl=en#KYLvKSOdAFc/trunk/freenet/src/freenet/support/TransferThread.java&q=mthread.interr > package:http://freenet\.googlecode\.com&l=57 ) > > Setting the interrupt flag for currentThread() and clean it > immediately -- what's the point? > I have posted this on the devl@ list for a few times, yet *new* code > using this pattern are written. > This make me suspect he never know what interrupt() means. This does not introduce a security risk, but talk to p0s about it. > > This is what p0s write for WoT/Freetalk. > > > 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. > > FMS gives HTML too. > It can be integrated if you really want. > > FMS is not non-fixable. You just don't care about it. We don't bundle jSite, Thaw or Thingamablog either, even though they are written in Java. Because they are separate, non-integrated, standalone applications that we don't have control over and don't have the resources to review. FMS could conceivably be somewhat less separate in that FMS could link to the freenet web interface and vice versa, but given that we have Freetalk, which is integrated properly and has a better architecture, why bother? -------------- 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/20090121/0611b782/attachment.pgp>
