💬 This is a comment on

Neovim 0.12 News (archive)

Neovim 0.12 was released earlier today. I don’t have enough time just now, but I’m sharing here the list of things from the release page that I want to try first.

Whole new features

Here are new features to replace some plugins and simplify my configuration:

• There is a new 'autocomplete' option. When set, completion suggestions appear in insert mode, without pressing a triggering shortcut. The 'complete' option also gains the ability to call arbitrary functions, as long as they follow the complete-functions interface. These two features combined could replace the many completion plugins that came and went over the years. I certainly hope to use them to remove mini.completion from my config.
  More importantly, they might help the ecosystem to standardize around a common interface for completion sources. At the moment, LSP servers play this role, but a full-blown LSP server implementation in every plugin is quite heavy. For example, crates.nvim supports some completion plugins (nvim-cmp, coq.nvim) and also exposes an LSP server for cross-compatibility support. In the future, such a crate might only implement the complete-functions interface and it could be used as a source by either native nvim completions or plugins.
• The other big highlight of this release is the native plugin manager, vim.pack. It was contributed mainly by Evgeni Chasnovski (known for mini.nvim). His guide of this new component is worth a read. In particular, you can pin plugins to a particular hash, for a version you have audited and update only once you have audited the changes in any new version.
• The default status line was reworked and integrates with vim.diagnostic.status(), vim.ui.progress_status() and an indicator for the new busy state. This will allow me to remove some custom logic to produce diagnostic status (E:2 W:3 for 2 errors and 3 warnings) and maybe even drop my custom status line code entirely.
• I will try to use the MarkSet to make user-placed marks visible in the gutter of the current buffer. I used plugins for that feature in the past, but it should be simple to implement it in configuration with MarkSet now.
• I’ll use vim.net.request() to replace some calls to external commands. It will make the configuration more portable and shorter — it might even be marginally faster, eliminating an external command call.
• 'diffopt' inline and inline:word will provide richer diff at the line level, a bit like delta.
• It’s nice to have native plugins for the undo tree (:Undotree) and to compare whole folders (:DiffTool).
• I plan to use the new treesitter selection shortcuts (an, in, [n and ]n in visual mode) to replace the deprecated treehopper plugin: I don’t really care about jumping to a particular highlight node, visual mode should work better for me.

Polish of existing features

This release introduces some nice performance improvements, for instance on Ctrl+r in insert mode and packadd.

Some handy shortcuts were added:

Finally, the UI was reworked: it is now less coupled with the core. So the core can be :restarted or :connected to with the same UI. The ui2 opt-in should also remove the dreaded “Press ENTER” message. I plan to give it a try and go back to cmdheight=0. Both of these settings are marked experimental, but if they are stable enough for me, I might get one more line for files.

💬 This is a comment on

DNS-PERSIST-01: A New Model for DNS-based Challenge Validation

The Source of Truth

Connecting to a website? Sending an email? Which server¹ you reach depends on DNS records. And CAA or SSHFP records establish trust for public key cryptographic protocols.

DNS records are the source of truth.

DNS API Tokens

Currently, wildcard certificates with Let’s Encrypt require to write an arbitrary string in a DNS record, for every single certificate renewed or issued. In practice, this often involves sharing a write API token to change the DNS. This is risky: should an attacker obtain the token, they can do a lot of damage: hijack traffic (and get valid certificates for it), receive and send emails using the corresponding domain…

And often API tokens are not scoped just to access one domain, through human error or because the provider lacks the feature. Then, they might give access to all domains in an account at the DNS provider and the attacker can move laterally to more targets.

With this in mind, I have not set up wildcard certificates with Let’s Encrypt so far. The risk simply outweighed the gains for the use cases I had. And I’m not alone: agnos was written to address the same concern. And the DNS challenge documentation calls this out: “Keeping API credentials on your web server is risky”.

DNS Challenges Without Tokens

So I’m really excited about this new challenge type, DNS-PERSIST-01. It is a static DNS TXT record that authorizes a particular Let’s Encrypt account² to get certificates, even wildcard ones, for a particular domain. No need to share very sensitive DNS API token!
It also means that Let’s Encrypt clients don’t need to support the API of your DNS provider to emit wildcard certificates. Pick any client and DNS provider you want, including a self hosted one.

Looking forward to this being fully implemented and available to everyone!

💬 This is a comment on

6-day and IP Address Certificates are Generally Available by Matthew McPherrin (via)

Let’s Encrypt has just announced that short-lived¹ certificates are generally available. They can also be used for IP addresses, which is especially useful for DNS over HTTPS. Those certificates could be smaller in the future, if information for validity checks is omitted. However, for now at least, these certificates still include revocation information.

Using Those New Certificates With Caddy

I wanted to give those certificates a try with Caddy. Caddy needs to use the shortlived Let’s Encrypt profile. The profile feature isn’t explicitly mentioned in the docs, but some community posts use a profile directive. This also works in the global configuration:

{
	cert_issuer acme {
		profile shortlived
	}
}

Reloading the Caddy configuration was not enough to prompt an early renewal, so I deleted the underlying certificate files and restarted Caddy:

sudo rm -rf /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/example.com
sudo systemctl restart caddy

And I got a brand new certificate for my domain name, valid only for a few days. It’s marginally smaller² than with the classic profile, mostly because these short-lived certificates also use the new generation hierarchy. But they should be roughly the same size as the tlsserver profile.

Conclusion

With Caddy, certificate renewal should be automated enough that short-lived certificates don’t cause any problems. But I’ll see with this experiment if there are any surprising pain points.

My understanding is that browsers only cache TLS sessions, not certificates: when a full handshake is performed, the full certificate chain is then sent anyway³. So even if the certificate expires more frequently, it is not sent more often. The slightly smaller certificate chain is thus a small net benefit.

💬 This is a comment on

Short URLs: why and how by Derek Sivers

In the Beginning Were Short URLs

I recently read Derek Sivers’s Short URLs: why and how, again. He makes a compelling case for using very short, but meaningful, URLs on your website. Very short here means one or two words at most, or even just 2 to 4 characters. On his website, that’s https://sive.rs/anna, https://sive.rs/plaintext https://sive.rs/1s, or indeed https://sive.rs/su for that particular post. That’s very different from typical URLs like https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/¹ or https://github.blog/changelog/2021-10-11-improved-notification-email-titles-for-issues-and-prs/.

Similarly, before I even read that post, the first few pages I created on my website had similar URLs: /cv or /open-source. Why? It’s easy to remember and you can type it (quickly!). They are also easy to share on the phone or face to face. Someone asks for my CV? Easy, go to cj.rs/cv (Charlie Juliett DOT Romeo Sierra SLASH Charlie Victor² on the phone).

Short URLs also look nice and tight. I even purchased cj.rs to replace joly.pw as the main domain in 2019³.

Derek makes similar points:

He then adds:

I did not really think about those last points⁴, but they make sense as nice complementary benefits.

Losing My Way and Finding It Back

If we were thinking alike about short URLs, then why did I use https://cj.rs/blog/lets-encrypt-caa-records-with-caddy/ for my last blog post? Why did I add the full title at the end of a path that is nested inside blog? Shouldn’t I have used something like letsencrypt-caa or caddy-caa?

Mainly I lost sight of the benefits of concise URLs. And Hugo has nice sections to organise content, set cascading parameters, list related pages…

But regardless of the tool, I certainly think in terms of categories for my pages. I remember things like “I have written this blog post” or “I have created this page at the root to showcase my open source work”.

A bit of hierarchical organisation makes sense even for the user. Some pages share a common theme, but in different categories. For instance, I have a blog post on an Asciinema module for Hugo and the page of that project both pertaining to the same underlying project. So ideally, they would be at cj.rs/hugo-asciinema and cj.rs/blog/hugo-asciinema instead of cj.rs/hugo-asciinema and cj.rs/announcement-hugo-asciinema.

Finally, even when there is only one page on a particular topic, some hierarchy is useful. Something like cj.rs/su can look cryptic in a tweet, whereas cj.rs/blog/su makes more sense. Both can still be easily remembered and typed. And having /blog/ for blog posts leaves space right under / for proper pages on the same topic that may exist later. While there are over one million 4-letter combinations in a-z and 0-9, meaningful words are much rarer. On the same example as above, I’m keeping /asciinema in store for something more closely related to Asciinema in the future. If I had spent that one word on the Hugo module, it would have been gone forever⁵.

Striking a Balance

Moving forward, I’ll revert to much shorter URLs using (for the path part):

• One or two words at the top level, for projects and generally pages that are not blog posts. Think /contact, /rusqlite-migration or /open-source.
• At most one folder, like /blog/ for blog posts. The exception would be multi-parts articles, which could be under /blog/topic/1, /blog/topic/2…
• That list may evolve if there are strong reasons, but I’ll keep in mind the memorability and direct typing benefits.