[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] 'Saving HSTS entries to' bug

From: Tim Ruehsen
Subject: Re: [Bug-wget] 'Saving HSTS entries to' bug
Date: Tue, 24 May 2016 14:49:27 +0200
User-agent: KMail/4.14.10 (Linux/4.5.0-2-amd64; KDE/4.14.20; x86_64; ; )


On Tuesday 24 May 2016 14:01:36 Ander Juaristi wrote:
> Hi Tim,
> On 24/05/16 13:15, Tim Ruehsen wrote:
> > Hi Ander,
> > 
> > after applying your patch I still see changes in store->table (resp.
> > changes of the contents of the entries) without tagging store as changed.
> > 
> > Everywhere you change something that gets dumped to the disk database
> > *must* set the store->changed flag.
> We only write to the file once - at the end. So that is essentially the
> same as setting the changed flag when something changes in memory.
> But I suspect I'm not following what you say...

I meant e.g. in hsts_match(), you eventually remove an expired entry, but you 
do not set store->changed. Thus on exit, the database wouldn't be updated.
I think it is good to keep the database as small as possible - following 
invocations of wget have less to read.

> > For example:
> > Executing
> > 
> >     wget -d www.yahoo.com
> > 
> > twice shows updating the HSTS database only for the first time (taking a
> > nap of two seconds between) - the max_age should be updated in the
> > database for both invocations.
> That behavior is correct.
> The value of max-age does not change - it remains the same every time
> you send a request. We don't update the file if the values reported
> (max-age, includeSubdomains, etc.) haven't changed since the last time
> we stored them.
> This is the workflow: http://www.yahoo.com --> https://www.yahoo.com -->
> https://es.yahoo.com/?p=us
> And finally, it says:
>     Strict-Transport-Security: max-age=2592000
> And it is always the same.
> Thus, we store it the first time as:
>     es.yahoo.com      0       0       1464090336      2592000
> And don't do anything else unless the Yahoo server sends different
> values. Initially, we only checked whether max-age changed. Now, we also
> check includeSubdomains, since my recent commit 2f1c6a0.

Sounds good, thanks for explaining.
My thought was to update the DB every time we get a STS header, since max_age 
is relative to the current time. But your approach is much more elegant in 
respect to the number of writes (disk&cpu usage).


Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]