Hi Ander, just pushed 0002 and 0003.
> You're right, but the downside is that it could cause a denial of > service. I was being driven by section 14.5 of RFC 6797. If another user > modifies your HSTS file and puts a server that does not have HTTPS > enabled, then you won't be able to contact that server, because wget > will attempt to do it via HTTPS all the time. Yeah, let's do it your way. Did you consider Giuseppe's suggestion ? "can the file_exists_p check just be moved to hsts_file_access_valid that doesn't return an error on ENOENT? In other words, just have here: if (hsts_file_access_valid (filename))" Tim On Friday 08 April 2016 22:33:37 Ander Juaristi wrote: > Hi Tim, > > You're right, but the downside is that it could cause a denial of > service. I was being driven by section 14.5 of RFC 6797. If another user > modifies your HSTS file and puts a server that does not have HTTPS > enabled, then you won't be able to contact that server, because wget > will attempt to do it via HTTPS all the time. > > WDYT? > > On 07/04/16 12:52, Tim Ruehsen wrote: > > On Wednesday 06 April 2016 14:31:17 Juaristi Álamos, Ander wrote: > >> Hi all, > >> > >> Here are some patches for HSTS. > >> > >> - 0001: checks the HSTS database file is not world-writable, and > >> > >> refuses to read it if it is, and disables HSTS. This was in my original > > > > Doesn't it make sense to share the HSTS database globally ? It is > > basically > > global data (domain specific) and not user specific. > > > > Thinking forward, a central (trusted) database/daemon for HSTS entries > > would be nice - sooner or later almost any domain supports HSTS. Each > > process loading/saving a huge file would not be efficient. > > > > Same goes for e.g. cert pinning (but not for cookies which are private > > data). > > > > Regards, Tim
signature.asc
Description: This is a digitally signed message part.
