That's how I learned a pretty important lesson about software engineering that still informs how I work to this day.
"A layer of abstraction on top of a stateful legacy system often doesn't result in a simpler system, it just introduces exciting new failure possibilities. This especially applies when the owners of the legacy system have no responsibility over the abstraction layer."
Instead of just having to track the arch repos, you suddenly have those and Manjaro's own stuff (and own package manager tool etc.), which is another point of failure. Every new bit of technology is another part that can fail.
You could even browse it if you used a browser who still treats you like an adult and allows you to ignore certificate warnings.
That way, even if some of your automation is borked (or if you don't have any), you'll at least be reminded.
Though with this being pushed, feels like nobody will have much choice, but automate: https://www.digicert.com/blog/tls-certificate-lifetimes-will...
The state of our industry is such that there will be a lot of people arguing for this absurdity in the replies to me. (or I'll be flagged to death).
Package integrity makes sense, and someone will make the complicated argument that "well ackshually someone can change the download links" completely ignoring the fact that a person doing that would be quickly found out, and if it's up the chain enough then they can get a valid LE cert anyway, it's trivially easy if you are motivated enough and have access to an ASN.
https://news.ycombinator.com/item?id=20472179
I'll take enforced HTTPS for absolutely everything, thank you very much. Preferably with certificate pinning and similar aggressive measures to thwart any attempts to repeat this.
* Caddy's complexity (especially when it comes to TLS) is not arbitrary, it's to meet the needs of auto-renewal and ... y'know, hosting sites on TLS.
* Caddy's SDLC is not, as far as I understand it, especially rapid.
* Implying that "military grade" is some level of encryption beyond the minimum level of encryption you would ever want to use is silly.
* The Manjaro website is not "the equivalent of a poster", and in fact hosts operating system downloads. Operating system integrity is kinda important.
You may have reasonable arguments for sites that are display only, do not out-link, and do not provide downloads, but this is not one of those circumstances.
The key property of SSL that is useful for tamper resistance is that it’s hard to do silently. A random ASN doing a hijack will cause an observable BGP event and theoretically preventable via RPKI. If your ISP or similar does it, you can still detect it with CT logs.
Even the issuance is a little better, because LE will test from multiple vantage points. This doesn’t protect against an ISP interception, but it’s better than no protection.
The Manjaro team has also caught flak for a bunch of other stuff. There's a page or two our there that detail the issues, which I'm too lazy to link here.
But let's just say this isn't their first rodeo.
It's exactly the opposite to what happens if the the main ad server for a company in the ad serving business looks at things.
Or another example:
From an inventory management perspective, it's ok to be out of stock for low margin items b/c the opportunity cost is low.
https://manjarno.pages.dev/ (hasn't been updated yet)
but seriously, sudo crontab -e, @monthly cerbot renew
No excuses.
* There is a stack overflow page from 2016 filled with solutions for Busybox, so I'd say 'all' rather than 'some' but someone out there is hosting a webserver on a potato, so better safe than sorry.
[0] ping.archlinux.org
