jamespwilliams

The advice suggesting storing config in environment variables isn’t great security-wise if your config contains secrets. From systemd docs:

> Note that environment variables are not suitable for passing secrets (such as passwords, key material, …) to service processes. Environment variables set for a unit are exposed to unprivileged clients via D-Bus IPC, and generally not understood as being data that requires protection. Moreover, environment variables are propagated down the process tree, including across security boundaries (such as setuid/setgid executables), and hence might leak to processes that should not have access to the secret data.

The former reason is systemd-specific, but the latter isn’t. There are some more reasons in https://movingfast.io/articles/environment-variables-conside....

> Mostly used to recodesent null

Is this line the victim of an overeager s/pre/code/g I wonder…

> iThenticate®

Unexpected place to see latin1 -> utf8 mojibake

Are there any legitimate reasons to have a particular file both as an input to a pipe and as an output? I wonder whether a shell could automatically “sponge” the pipe’s output if it detected that happening.

Offa’s Dyke goes through my hometown.

Devil’s Pulpit is a great spot on the path, you get a great view of Tintern Abbey, near the start of the walk. https://www.visitdeanwye.co.uk/things-to-do/devils-pulpit-p1...

I guess they’re referring to AES-ECB, which is notoriously weak at encrypting images (it’s weak in general of course, just most obviously with respect to images): https://words.filippo.io/the-ecb-penguin/.

But I don’t think the same is true of the other AES cipher modes.

I use alacritty every day, it’s the best terminal emulator I’ve come across.

That said, it’s not perfect. For example it lacks font ligature support, and there appears to be no prospect of that being implemented. I don’t care about ligatures that much anyway, so no big deal for me, but for others it is.

My experience using terminal emulators is that they are all flawed in at least one way. Whether it’s lack of true colour support; lack of ligature support; weird text rendering; weird colours; confusing configuration; etc. I feel like a terminal supporting all of those things must be possible, but I haven’t come across it yet.

I recently found an example shell session in the documentation for mysqlimport that uses ed: https://dev.mysql.com/doc/refman/8.0/en/mysqlimport.html

Shameless plug for https://vimcolorschemes.com/jamespwilliams/bat.vim

I think nearly everything at AWS uses s2n and not OpenSSL these days

Michelin also gives out an award for 'good quality, good value restaurants', called the Bib Gourmand, which is worth looking into. Bib Gourmand restaurants are often still a bit more expensive than the average restaurant in a place, but are generally of very very good quality and value for money.

I don’t read anything celebratory in GP’s comment. And:

> which is 100% his fault with no justification despite any provocation

is at odds with your overall argument.

Do you agree that storing passwords in plain text is a problem?

My point is that storing passwords in a way compatible with using Digest authentication is essentially equivalent to storing your passwords in plain text, at least with respect to your own site’s authentication.

Digest auth itself isn't very good though really, even ignoring the obvious problems of not using HTTPS.

In the most secure configuration of digest auth, the server stores MD5(username:realm:password), and to authenticate, the server sends server_nonce, and the client sends back client_nonce and MD5(MD5(username:realm:password):server_nonce:client_nonce). The nonces are used to avoid a replay attack. The server MD5s its stored hash with server_nonce:client_nonce and checks if it matches against what the client sent.

But if those stored hashes get leaked, an attacker can use them to authenticate. You're in a better position than storing plaintext passwords, because the underlying cleartext probably won't be leaked (they're hashed with MD5, so it's not certain), so your users' credentials can't be used in future credential stuffing attacks, etc. But the attacker still has their credentials on your site.

In the other configurations of digest auth, the server ends up storing plaintext passwords (or reversably-encrypted passwords, which is just as bad).

See also https://en.wikipedia.org/wiki/Digest_access_authentication#D...

Using HTTPS + Basic Auth is far more secure, and (arguably) easier at this point.

GitHub pages are served with Access-Control-Allow-Origin: *, so the SOP doesn’t apply.

They also don’t set a CSP header, which opens up the opportunity to exfiltrate data by other means, e.g having the browser load an image on your.site/$password.jpg.

Also scroll on the mousewheel to increase/decrease the radius of points to warp.

And also check out the Style menu! I like some of the alternative colour schemes.

The level of detail in this is impressive.

This seems very useful!

The behaviour of auto-imports https://github.com/CZ-NIC/pz#auto-import seems bit scary:

> Caveat: When accessed first time, the auto-import makes the row reprocessed. It may influence your global variables. Use verbose output to see if something has been auto-imported.

It sounds like this could cause some very subtle bugs. Maybe a strong and clear warning when a line is being reprocessed would help.

Reminds me of https://en.m.wikipedia.org/wiki/Bouba/kiki_effect

Whoops! Thanks, I've fixed it.

https://beerba.se/augustiner-bra-u-ma1-4nchen/ there’s an encoding problem here (UTF-8 has been interpreted as Latin-1 at some point)

(edit: turns out it's a problem with the upstream data! interesting https://github.com/midzer/beerbase/issues/1)

In the era of neovim, you can get very far with very few plugins.

Put together neovim, nvim-treesitter and nvim-lspconfig (which are both "official" plugins), and fzf.vim, and you end up with a decent IDE with only one non-official plugin.

Less plugins = less to go wrong, easier to reason about, less configuration needed, more zen.

It's a nice touch that the logo is done with pure HTML and CSS (well, other than the triangle, which is an SVG, albeit a simple one), so you can copy the text

There’s also Hesiod (HS) records: https://jpmens.net/2012/06/28/hesiod-a-lightweight-directory...

When I migrated from Lastpass to Bitwarden, I was able to import the Lastpass export without any transformation needed, if I recall correctly.

Smartcards e.g Yubikeys help with this. You store the key on the smartcard, then use ssh-agent to have the smartcard perform whatever cryptographic operations are necessary. On Yubikeys at least, the keys can never leave the smartcard, by design.

> it wasn’t a benign teratoma after all, but rather a malignant cancer called synovial sarcoma [..] Heart cancer? Who the hell gets heart cancer?! Is this some kind of horrible metaphor?

For context: https://academic.oup.com/icvts/article/11/4/490/652739. Fewer than 20 cases described in the literature of this particular kind of cancer.

Cool, but breaks the back button because it pushes to the history stack on each scroll

It’s partially the result of the 2007 cyberattacks they endured. After that, they started taking cybersecurity very seriously.

https://www.bbc.com/news/39655415

Agreed. Being able to drop seamlessly into an imperative style is very useful.

I’m someone who isn’t an experienced functional programmer, or that deeply knowledgeable about type systems and category theory etc, but OCaml is still approachable to me, I feel I can get stuff done in it. I didn’t feel that way with Haskell - I tried, but found the number of ways to do things overwhelming, and a lot of it felt very theoretical. Of course, Haskell’s pureness is an impressive and interesting feature; but it isn’t for me.

OCaml also has much better systems programming abilities compared with Haskell, IMO. It feels like OCaml is the Rust of the functional programming world (and this is no accident, the Rust compiler was first implemented in OCaml in fact).

This is all completely subjective of course.

On mobile, there’s no padding between the text on this page and the borders of the screen, which makes it a bit hard to read