You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This was introduced to allow us to keep operating when a log serves cached STHs that are smaller than the one we most recently saw (i.e. when they are serving stale STHs from M of N frontend nodes). This prevents us from catching a number of broken log cases.
Instead we should store a list of all STHs we've previously observed and verify the returned STHs against this list (using the existing storage layer to manage the list). This will allow us to spot bad STHs.
The text was updated successfully, but these errors were encountered:
This prevents us from catching a number of broken log cases.
Can you expand on what cases we'd miss? I'm not clear what the bad STHs we'd spot are. A new previously unseen STH for a smaller treesize vs an existing STH for the smaller treesize that we've already seen?
@rolandshoemaker bump on ☝️ ? It would be helpful to have the broken log cases you think this would be helpful with made more explicit (can ct-test-srv as implemented in this repo simulate them for example?)
This was introduced to allow us to keep operating when a log serves cached STHs that are smaller than the one we most recently saw (i.e. when they are serving stale STHs from M of N frontend nodes). This prevents us from catching a number of broken log cases.
Instead we should store a list of all STHs we've previously observed and verify the returned STHs against this list (using the existing storage layer to manage the list). This will allow us to spot bad STHs.
The text was updated successfully, but these errors were encountered: