Hi Garret, On Wed, Jul 21, 2004 at 10:47:21AM -0400, Garrett Kajmowicz wrote:

On July 20, 2004 09:09 pm, Jorge Arellano Cid wrote:

...

Hi Garret,

OK, I reviewed it an made some changes (now on CVS).

I pondered a long time whether to make a generic function for parsing dpip dialog answers. Something like:

a_Dpiutil_dialog_parse_answer(...)

I created a specific function because in this case a numerical response can be expected, and thus returning a char answer requires the programmer to do more work for this specific value. Modularizing functionality is usually a good idea.

Yes it is! This is sort of a tradeoff... For instance html.c does all its parsing with a function very much like Get_attr_value(). One alternative that I've been thinking of for a long time, is to just parse HTML tags once and return something like a: struct pair { char *attr_name; char *attr_value; }; struct pair *parsed_tag; Or the same pairs in a simple list: char **parsed_tag; with NULL marking the end. The advantage is that tag-parsing is done once, but now the caller has to go through the list to find out what attr_names are present. In the case of the dpip dialogs the current method looked simpler, at least by now...

...

To me it seems that according to the simplicity principle of API design, sticking with Get_attr_value() instead of one custom parsing function per each dpip command is better...

The same logic applies to the a_Dpip_build_command() I was thinking of. The interface for sending data may survive though.

Anyway, the most important point of this patch is that after applying the patch, it seems not to trust even paypal!

For instance:

https://www.paypal.com/en_US/i/icon/secure_lock_2.gif

I have checked this out. I have written a fair bit more code (now I have to merge changes *ugh*). The issue is probably a lack of issuer certificates. Currently the https module checks /etc/ssl/certs.

I'm trying to think of a way to put the directory in the configure script, but that will have to wait a little while.

Don't worry, that can be done later. Let's test it first.

Right now I'm working on allowing self-signed certificates to be accepted long-term. OpenSSL has some weird ideas on how to do things.

BTW, have you given a look to GnuTLS? (It has an OpenSSL compatibility layer and seems better documented).

...

gives me the warning dialog. Is this OK?

Warnings are OK.

Yes, I meant to ask: Is really PayPal sending this image with a certificate that can't be trusted?

I'm adding more and more code in to handle all possible error conditions. Previously there was no warning if there was a problem - just a likely insecure connection. Now the system is warning on everything, and hopefully will be able to deal with a large number of these problems in code giving *useful* error messages. One thing at a time, though.

Side question, do you have a regular Dillo mailing list view-parse-evaluate-and-commit schedule?

No. I try to work based on priorities. But sometimes something of higher priority steps in and things get rescheduled...

I know you prefer smaller patches to larger patches, but it gets a little annoying for me when I submit something and I don't know when it will be reviewed and commited. The time doesn't bother me, but if I know your schedule I can schedule my work appropriately.

My schedule is very hard to predict. Different things come my way everyday, and I have to manage lots of things in different areas. Don't get scared though. This patch took some time to commit because I had to think of things that affect the other plugins. OTOH having a patch in the CVS doesn't give it a lot of exposure. The number of people using Dillo from CVS and testing is smaller than one expects. We usually tend to work on our local trees until something is stable enough for broader testing before making the commit. Things should go faster in the future... Cheers Jorge.-