Closed jamcat22 closed 7 years ago
This looks like a bug to me - I wonder if our scans are accidentally relying on a cached preload list file from week to week. That would explain the delayed data. I'll look into it.
@jamcat22 I deployed a fix for this to production, and I believe this should automatically be fixed up in the next scan. Thanks for noticing this and pointing it out -- it looks like the preload list data had been silently cached since February.
I'll leave this open until the next scan completes and we can verify that the issue is resolved.
@konklone, from what I can tell, the fix deployed appears to have fixed the issue in the most recent scan (July 5th, 2017). I'll go ahead and close this issue as it appears to be resolved. Feel free to reopen if needed.
Thanks!
@jamcat22 Great, thank you for verifying!
It took a bit longer than I expected for this fix to take effect in production, as it turns out we had some annoying infrastructure debt and a) the server's hard disk had filled up, and b) some sslyze
scans were hanging inexplicably (described in https://github.com/18F/domain-scan/issues/138). We may not have noticed these without you noticing the preload staleness, so thank you for reporting it!
I'm a bit confused as to how status checks to determine whether or not sites are listed in the HSTS Preload List are run. Are they run at the same time as the "Last updated" date states, or are they checked on a less frequent basis independently of the other scans?
While looking around Pulse, I've found many sites that have been added to the preload list, but still don't have their statuses changed to reflect the fact. Is this simply fixed with time, or is there something else wrong?
Here are a couple examples which appear as either not preloaded or only preload-ready: ftcefile.gov Pulse status | Preload list position pregunteleakaren.gov Pulse status | Preload list position