- Dillo-dev - lists.mailman3.com

dpi send cmd error msg (Re: [Dillo-dev] Re: even more cookies SECURITY)

by corvid＠lavabit.com

I wrote: > Jorge wrote: > > On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote: > > > Do we currently have anything that needs to be > > > fixed/implemented before a release would be sensible? > > > > Not that I remember. The only problem I recall was the error > > message you reported with cookies and later seemed to be working > > somehow. > > a_Dpi_send_blocking_cmd() gets upset when > Dpi_blocking_read() doesn't get anything. > > So in the cookie dpi's srv_parse_tok(), > after the Cookies_set(), I tried putting a > a_Dpip_dsh_write_str(sh, 1, "text"), and > that makes the error msgs go away for me. What if we do the following:

Jan. 20, 2010

experimental patch: gnutls for the https dpi

by corvid＠lavabit.com

Michal wrote: > On Wed, Jan 20, 2010 at 10:52 AM, corvid <corvid(a)lavabit.com> wrote: > > A few hours ago, I started to wonder how much trouble it would be to > > make https.c understand gnutls instead of openssl. > > > > The answer is: If you borrow liberally from the public domain code in > > ? ? ? ? ? ? ? the gnutls manual, then not very much! > > > > So here's a toy for anyone who would like one: > > ?http://www.dillo.org/test/gnutls.0.patch > > What about NSS? > > https://fedoraproject.org/wiki/FedoraCryptoConsolidation > > It might bring even more (FIPS) compared to gnutls. Does gnutls lack it because it requires paying $$ and/or infinite bureaucratic hurdles, or is it a technical matter? The NSS documentation seems to say that applications would no longer have to know where a file full of certificates is because that would all be taken care of by NSS in some centralized thing. Is that the case? _That_ would definitely appeal to me.

Jan. 20, 2010

experimental patch: gnutls for the https dpi

by corvid＠lavabit.com

Jorge wrote: > On Wed, Jan 20, 2010 at 09:52:31AM +0000, corvid wrote: > > A few hours ago, I started to wonder how much trouble it would be to > > make https.c understand gnutls instead of openssl. > > > > The answer is: If you borrow liberally from the public domain code in > > the gnutls manual, then not very much! > > > > So here's a toy for anyone who would like one: > > http://www.dillo.org/test/gnutls.0.patch > > Quite interesting. > > AFAIS from the patch it's doing more or less the same as the > current https dpi. It looks like this dpi's certificate handling > code may be easier to complete with GNU TLS. > > What's the motivation for the switch? - It's pleasing to using something GPLed and not have special linking exceptions in the license. - I get the impression that people are starting to look at openssl a little like they did with gtk1 ("How many programs do I have that still require it? Can I get rid of it?")

Jan. 20, 2010

experimental patch: gnutls for the https dpi

by newman.x＠gmail.com

On Wed, Jan 20, 2010 at 10:52 AM, corvid <corvid(a)lavabit.com> wrote: > A few hours ago, I started to wonder how much trouble it would be to > make https.c understand gnutls instead of openssl. > > The answer is: If you borrow liberally from the public domain code in > ? ? ? ? ? ? ? the gnutls manual, then not very much! > > So here's a toy for anyone who would like one: > ?http://www.dillo.org/test/gnutls.0.patch What about NSS? https://fedoraproject.org/wiki/FedoraCryptoConsolidation It might bring even more (FIPS) compared to gnutls. > Now we'll _have_ to have a release soon, because we're accumulating so > many things to play with after release... Michal

Jan. 20, 2010

display: inline

by Johannes.Hofmann＠gmx.de

On Wed, Jan 20, 2010 at 08:59:12AM -0300, Jorge Arellano Cid wrote: > On Tue, Jan 19, 2010 at 08:17:01PM +0100, Johannes Hofmann wrote: > > On Mon, Jan 18, 2010 at 03:40:31PM -0300, Jorge Arellano Cid wrote: > > > On Tue, Jan 12, 2010 at 06:48:19PM +0100, Johannes Hofmann wrote: > > > > On Tue, Dec 08, 2009 at 06:56:55PM +0100, Johannes Hofmann wrote: > > > > > Hi, > > > > > > > > > > I started to experiment with the real solution, which means that the > > > > > display member of Style determines whether a (Text)block is created > > > > > or a ListItem, or whether just normal text is added. > > > > > The patch is still small, but as the change is pretty > > > > > fundamental, so I decided to put it in a separate repo for now. > > > > > You can find it at: > > > > > > > > > > http://www.flpsed.org/hgweb/dillo_display/ > > > > > > > > > > > > > I've updated this prototype a bit. It works quite well, the only > > > > drawback is the added complexity in html.cc. > > > > In addition to Html_tag_open_*() and Html_tag_clone_*(), there now is > > > > an optional Html_tag_content_*() function for tags that create > > > > widgets or other content. This function is not called in the > > > > display:none case. > > > > The reason for the splitting into Html_tag_open_*() and > > > > Html_tag_content_*() is that styleEngine->setNonCssHints() is > > > > needed before we can get the current style. > > > > Only after that is done, we know the value of the display property > > > > and can decide whether to call Html_tag_content_*() or not. > > > > > > > > I'd like to get this into main line soon if you agree. > > > > Please let me know what you think. > > > > > [...] > > > > - Please don't merge the IPPROTO_TCP patch with it. > > > > If you mean the TCP_NODELAY stuff, it's in the main repo already. > > Normally the TCP stack waits a little until there is enough data to > > send. This is good for throughput but bad for response time. It is > > especially bad for client server stuff like DPI over local loopback. > > It really slows down pages with cookies. > > But I can back it out if you like. It would no longer be necessary > > when we switch back to UNIX domain sockets anyway. > > OK, leave it then. > > BTW, is the connection-number-limit patch in the next release? No, it's not ready yet - unfortunately. We urgently need a connection limit, but it needs to be per remote host, as otherwise dillo can have all of it's 4 connections open to a slow server and then there is no connection left for other servers, e.g. used for other windows or tabs. We alse might need to make a special case for connections to proxies. Ah, and while at it it might be interesting to look into persistent connections... Cheers, Johannes

Jan. 20, 2010

experimental patch: gnutls for the https dpi

by jcid＠dillo.org

On Wed, Jan 20, 2010 at 09:52:31AM +0000, corvid wrote: > A few hours ago, I started to wonder how much trouble it would be to > make https.c understand gnutls instead of openssl. > > The answer is: If you borrow liberally from the public domain code in > the gnutls manual, then not very much! > > So here's a toy for anyone who would like one: > http://www.dillo.org/test/gnutls.0.patch Quite interesting. AFAIS from the patch it's doing more or less the same as the current https dpi. It looks like this dpi's certificate handling code may be easier to complete with GNU TLS. What's the motivation for the switch? -- Cheers Jorge.-

Jan. 20, 2010

display: inline

by jcid＠dillo.org

On Tue, Jan 19, 2010 at 08:17:01PM +0100, Johannes Hofmann wrote: > On Mon, Jan 18, 2010 at 03:40:31PM -0300, Jorge Arellano Cid wrote: > > On Tue, Jan 12, 2010 at 06:48:19PM +0100, Johannes Hofmann wrote: > > > On Tue, Dec 08, 2009 at 06:56:55PM +0100, Johannes Hofmann wrote: > > > > Hi, > > > > > > > > I started to experiment with the real solution, which means that the > > > > display member of Style determines whether a (Text)block is created > > > > or a ListItem, or whether just normal text is added. > > > > The patch is still small, but as the change is pretty > > > > fundamental, so I decided to put it in a separate repo for now. > > > > You can find it at: > > > > > > > > http://www.flpsed.org/hgweb/dillo_display/ > > > > > > > > > > I've updated this prototype a bit. It works quite well, the only > > > drawback is the added complexity in html.cc. > > > In addition to Html_tag_open_*() and Html_tag_clone_*(), there now is > > > an optional Html_tag_content_*() function for tags that create > > > widgets or other content. This function is not called in the > > > display:none case. > > > The reason for the splitting into Html_tag_open_*() and > > > Html_tag_content_*() is that styleEngine->setNonCssHints() is > > > needed before we can get the current style. > > > Only after that is done, we know the value of the display property > > > and can decide whether to call Html_tag_content_*() or not. > > > > > > I'd like to get this into main line soon if you agree. > > > Please let me know what you think. > > > [...] > > - Please don't merge the IPPROTO_TCP patch with it. > > If you mean the TCP_NODELAY stuff, it's in the main repo already. > Normally the TCP stack waits a little until there is enough data to > send. This is good for throughput but bad for response time. It is > especially bad for client server stuff like DPI over local loopback. > It really slows down pages with cookies. > But I can back it out if you like. It would no longer be necessary > when we switch back to UNIX domain sockets anyway. OK, leave it then. BTW, is the connection-number-limit patch in the next release? -- Cheers Jorge.-

Jan. 20, 2010

experimental patch: gnutls for the https dpi

by corvid＠lavabit.com

A few hours ago, I started to wonder how much trouble it would be to make https.c understand gnutls instead of openssl. The answer is: If you borrow liberally from the public domain code in the gnutls manual, then not very much! So here's a toy for anyone who would like one: http://www.dillo.org/test/gnutls.0.patch Now we'll _have_ to have a release soon, because we're accumulating so many things to play with after release...

Jan. 20, 2010

display: inline

by Johannes.Hofmann＠gmx.de

On Mon, Jan 18, 2010 at 03:40:31PM -0300, Jorge Arellano Cid wrote: > On Tue, Jan 12, 2010 at 06:48:19PM +0100, Johannes Hofmann wrote: > > On Tue, Dec 08, 2009 at 06:56:55PM +0100, Johannes Hofmann wrote: > > > Hi, > > > > > > I started to experiment with the real solution, which means that the > > > display member of Style determines whether a (Text)block is created > > > or a ListItem, or whether just normal text is added. > > > The patch is still small, but as the change is pretty > > > fundamental, so I decided to put it in a separate repo for now. > > > You can find it at: > > > > > > http://www.flpsed.org/hgweb/dillo_display/ > > > > > > > I've updated this prototype a bit. It works quite well, the only > > drawback is the added complexity in html.cc. > > In addition to Html_tag_open_*() and Html_tag_clone_*(), there now is > > an optional Html_tag_content_*() function for tags that create > > widgets or other content. This function is not called in the > > display:none case. > > The reason for the splitting into Html_tag_open_*() and > > Html_tag_content_*() is that styleEngine->setNonCssHints() is > > needed before we can get the current style. > > Only after that is done, we know the value of the display property > > and can decide whether to call Html_tag_content_*() or not. > > > > I'd like to get this into main line soon if you agree. > > Please let me know what you think. > > I checked the last repo, and AFAIS it's OK to merge. I agreed with corvid to leave it out until after the release. > > Notes: > > - I agree with corvid on using NULL instead of Html_tag_close_default. Ok. > - There's a comment on *open and *close() function being always > called but there's still a conditional close on display_none. > Please check it. Ok. > - Please don't merge the IPPROTO_TCP patch with it. If you mean the TCP_NODELAY stuff, it's in the main repo already. Normally the TCP stack waits a little until there is enough data to send. This is good for throughput but bad for response time. It is especially bad for client server stuff like DPI over local loopback. It really slows down pages with cookies. But I can back it out if you like. It would no longer be necessary when we switch back to UNIX domain sockets anyway. Cheers, Johannes

Jan. 19, 2010

dillo2.x on Fedora 12

by newman.x＠gmail.com

On Mon, Jan 18, 2010 at 9:17 PM, Globe Trotter <itsme_410(a)yahoo.com> wrote: > Hi, > > Does that mean that Dillo has no hope also because it is based on fltk2? > > Thanks! > T FLTK2 is somewhat dead end from Fedora perspective. There is a bunch of issues in upstream FLTK2 snapshots regarding Fedora package policies. I fixed several of them in Package Review https://bugzilla.redhat.com/show_bug.cgi?id=fltk2 but then lost hope when others appeared... And more, upstream's not willing to fix bugs I found when pushing FLTK2 to Fedora (e.g. they sticked w/ "static" linking). FLTK1.3 (and 1.4) is the way to go, once it's released. I remember, release was scheduled for last summer but postponed. See their mailing list for latest info, they have some 4 items, 2 of them non-trivial, on the list. Michal

Jan. 19, 2010