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.
I re-verified that the git-tree state looks good after
the trouble addressed in commit 89023c38fc
(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 c778945806 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: 4effe769e2
- `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 (803ca85c20)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
I think there was a silent (i.e. semantic) merge conflict between PR #101139 and
PR #100456. This commit should fix the error, which manifests as follows:
error: undefined variable 'boolToString' at /home/kkini/src/nixpkgs/lib/types.nix:552:42
This reverts commit c778945806.
I believe this is exactly what brings the staging branch into
the right shape after the last merge from master (through staging-next);
otherwise part of staging changes would be lost
(due to being already reachable from master but reverted).
When using the Modern config from the Mozilla SSL config generator,
the `ssl_ciphers` parameter does not need to be set
as only TLSv1.3 is permitted and all of its ciphers are reasonable.
Treat it the same as IPv4 (I'm tempted to disable IPv4 by default);
this is the only option I still need to set manually to enjoy IPv6-only
networks including printer discovery!
Otherwise extraction fails for what I consider a common type of data;
note how both packages are required as binwalk uses `sasquatch` as
well as `unsquashfs`.
