[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; ; ) |
Tim
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).
Tim
signature.asc
Description: This is a digitally signed message part.
- Re: [Bug-wget] 'Saving HSTS entries to' bug, (continued)
- Re: [Bug-wget] 'Saving HSTS entries to' bug, Ander Juaristi, 2016/05/21
- Re: [Bug-wget] 'Saving HSTS entries to' bug, Ander Juaristi, 2016/05/23
- Re: [Bug-wget] 'Saving HSTS entries to' bug, Tim Ruehsen, 2016/05/24
- Re: [Bug-wget] 'Saving HSTS entries to' bug, Ander Juaristi, 2016/05/24
- Re: [Bug-wget] 'Saving HSTS entries to' bug, Ander Juaristi, 2016/05/24
- Re: [Bug-wget] 'Saving HSTS entries to' bug, Tim Ruehsen, 2016/05/24
- Re: [Bug-wget] 'Saving HSTS entries to' bug, Tim Ruehsen, 2016/05/24
- Re: [Bug-wget] 'Saving HSTS entries to' bug, Ander Juaristi, 2016/05/24
- Re: [Bug-wget] 'Saving HSTS entries to' bug, Tim Ruehsen, 2016/05/24
- Re: [Bug-wget] 'Saving HSTS entries to' bug, Ander Juaristi, 2016/05/24
- Re: [Bug-wget] 'Saving HSTS entries to' bug,
Tim Ruehsen <=
- Re: [Bug-wget] 'Saving HSTS entries to' bug, Ander Juaristi, 2016/05/25
- Re: [Bug-wget] 'Saving HSTS entries to' bug, Tim Ruehsen, 2016/05/26