Fix an error in the validation code when the public key is in a
nonstandard location. The check command fails and the key is
incorrectly assumed to be expiring.
SECURITY ISSUE: Attempted to make RSA PKCS#1v1.5 decryption more
constant time, to protect against Bleichenbacher vulnerabilities. Due to
limitations imposed by our API, we cannot completely mitigate this
vulnerability and a future release will contain a new API which is
designed to be resilient to these for contexts where it is required.
Credit to Hubert Kario for reporting the issue. CVE-2020-25659
Otherwise we get warnings like 'level=warning msg="failed to start
br_netfilter module"' in k3s's logs.
Adding modprobe to k3s's PATH fixes the warning at least. I'm not
certain if it fixes any real issue or not.
I re-verified that the git-tree state looks good after
the trouble addressed in commit 89023c38fcef
(by the same approach - comparison to a "clean rebase").
I was actually a little surprised that simple git merge
did the right thing this time.
The one thing I can't fix is that some of staging commits are now
reachable from master even though they're not really applied in there
yet, but that's just temporary effect until the next merge to master.
I certainly don't envy any archeology hitting these commit ranges
(e.g. bisections).
I made a mistake merge. Reverting it in c778945806b undid the state
on master, but now I realize it crippled the git merge mechanism.
As the merge contained a mix of commits from `master..staging-next`
and other commits from `staging-next..staging`, it got the
`staging-next` branch into a state that was difficult to recover.
I reconstructed the "desired" state of staging-next tree by:
- checking out the last commit of the problematic range: 4effe769e2b
- `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken
merge commit and its revert from that range (while keeping
reapplication from 4effe769e2)
- merging the last unaffected staging-next commit (803ca85c209)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
