chromium/hstspreload.org

`StatusPendingAutomatedRemoval` is missing from some state transitions

Opened this issue · 0 comments

There are two locations that handle a StatusPendingRemoval but do not handle StatusPendingAutomatedRemoval:

The Submit endpoint checks that a domain meets the preload requirements, and if it does, updates its status to StatusPending if appropriate. StatusPending means the domain is not currently on the preload list, but it should be added to the list on the next update. If a domain has StatusPendingAutomatedRemoval, it hits the default in the switch statement and returns an error. It should be handled the same as StatusPendingRemoval, as both of those statuses convey that the domain should be removed from the preload list.

The existing logic for the Submit endpoint appears to be incorrect when handling the StatusPendingRemoval state. That state is treated the same as StatusUnknown, StatusRejected, and StatusRemoved, which is to transition the domain to the StatusPending state. This means that a StatusPendingRemoval (or StatusPendingAutomatedRemoval) domain, which is one that is on the preload list but met the requirements for (automated) removal, and has now passed the checks for being on the list, will have its status changed to one that means the domain currently isn't on the preload list but it should be (StatusPending). Instead, its status should be changed to StatusPreloaded: if a domain was pending removal but now no longer should be removed, there is no action to take or any pending state.

The Remove endpoint checks if a domain meets the requirements for immediate removal from the preload list. If a domain that is pending automated removal meets the immediate removal criteria, then it should be updated to StatusPendingRemoval.

PR #250 is a good starting point for fixing the Submit endpoint, though a behavior change is needed for both pending removal statuses.