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.
