mirror of
https://git.sr.ht/~seirdy/seirdy.one
synced 2024-11-23 21:02:09 +00:00
Use navlinks to navigate previous posts in series
This requires making <nav> *not* display inline except for the unstyled-list navlinks. This should also do a better job at appeasing reader modes. For the same reason, also make one link a citation
This commit is contained in:
parent
d4951890a5
commit
d8cb28d1db
2 changed files with 9 additions and 5 deletions
|
@ -48,7 +48,7 @@ nav li {
|
|||
|
||||
/* single-line nav on widescreen, multi-line nav on narrow screens */
|
||||
@media (min-width: 24em) {
|
||||
nav li {
|
||||
nav .unstyled-list li {
|
||||
display: inline;
|
||||
}
|
||||
}
|
||||
|
@ -84,5 +84,5 @@ pre {
|
|||
overflow: auto visible;
|
||||
|
||||
/* csslint ignore:end */
|
||||
padding: 0.5rem;
|
||||
padding: 0.5em;
|
||||
}
|
||||
|
|
|
@ -11,8 +11,12 @@ I find it easy to handle views different from my own. I feel more troubled when
|
|||
|
||||
It's no secret that I'm a passionate supporter of software freedom: I've written two posts about how Free, Libre, and Open-Source software (<abbr title="Free, Libre, and Open-Source Software">FLOSS</abbr>) is necessary but insufficient to preserve user autonomy:
|
||||
|
||||
1. [Whatsapp and the Domestication of Users](./../../../2021/01/27/whatsapp-and-the-domestication-of-users.html)
|
||||
2. [Keeping Platforms Open](./../../../2021/02/23/keeping-platforms-open.html)
|
||||
<nav>
|
||||
|
||||
1. **[Whatsapp and the Domestication of Users](./../../../2021/01/27/whatsapp-and-the-domestication-of-users.html)**<br>The phenomenon of user domestication and defense measures: FLOSS, open platforms, and simplicity.
|
||||
2. **[Keeping Platforms Open](./../../../2021/02/23/keeping-platforms-open.html)**<br>How open platforms can lose their openness, and what measures can prevent this. The Web, XMPP, email, and Matrix are examples that highlight both sides of the issue.
|
||||
|
||||
</nav>
|
||||
|
||||
After two posts spanning over 5000 words, I need to add some nuance.
|
||||
|
||||
|
@ -149,7 +153,7 @@ If you want to get started with fuzzing, I recommend checking out [the quick-sta
|
|||
|
||||
A recent example of how fuzzing helps spot a vulnerability in an open-source project is [CVE-2022-0185](https://www.openwall.com/lists/oss-security/2022/01/18/7): a Linux 0-day found by the Crusaders of Rust a few weeks ago. It was discovered using the [syzkaller](https://github.com/google/syzkaller) kernel fuzzer. The process was documented on Will's Root:
|
||||
|
||||
[CVE-2022-0185 - Winning a $31337 Bounty after Pwning Ubuntu and Escaping Google's KCTF Containers](https://www.willsroot.io/2022/01/cve-2022-0185.html)
|
||||
<cite class="h-cite"><a class="u-url p-name" href="https://www.willsroot.io/2022/01/cve-2022-0185.html" rel="cite">CVE-2022-0185 - Winning a $31337 Bounty after Pwning Ubuntu and Escaping Google's KCTF Containers</a> by <span class="h-card vcard"><a class="p-name url fn n" href="https://www.willsroot.io/"><span class="p-nickname">willsroot</span></a></span></cite>
|
||||
|
||||
I _highly_ encourage giving it a read; it's the perfect example of fuzzing with sanitizers to find a vulnerability, reproducing the vulnerability (by writing a tiny C program), _then_ diving into the source code to find and fix the cause, and finally reporting the issue (with a patch!). When source isn't available, the vendor would assume responsibility for the "find and fix" steps.
|
||||
|
||||
|
|
Loading…
Reference in a new issue