cert-manager maintainter chiming in to say that yes, cert-manager should support IP address certs - if anyone finds any bugs, we'd love to hear from you!
We also support ACME profiles (required for short lived certs) as of v1.18 which is our oldest currently supported[1] version.
We've got some basic docs[2] available. Profiles are set on a per-issuer basis, so it's easy to have two separate ACME issuers, one issuing longer lived certs and one issuing shorter, allowing for a gradual migration to shorter certs.
As an active maintainer of cert-manager (which is CNCF graduated), I can shed some light here. It's not just "give away trademarks for nothing"!
The CNCF pays for cert-manager's testing, web hosting and infrastructure costs and they paid for a professional security audit of the project. We get marketing help, exposure, talks, booths and other bits too. When we graduated last year, we got popcorn!
What I personally like too is that the CNCF provide a kind of "business continuity" aspect for open source, which is something I think about a lot. If the current maintainers got hit by an asteroid at an in-person event, there are CNCF people in our testing infra account and in GitHub who can log in and save the project. At the end of the day businesses have continuity plans for their projects, and for open-source projects of cert-manager's size it makes sense to do the same - and the CNCF neatly solves that problem for us.
They might try - that's why it's important if you're generating + committing generated code that you also have a CI step that runs before merging anything which ensures that the generated code is up-to-date and rejects any change request where generated code is out of date.
Mostly this helps with people simply forgetting to re-run the generator in their PR but it's a useful defence against people trying to smuggle things into the generated files, too!
Plug (but it's open source and free - and mentioned in the article!): We've been trying to address this in Kubernetes with trust-manager. [1] Trust bundles need to be a runtime concern and they need to support trusting both the old a new version of a cert to safely allow for rotation. It's pretty simple but it seems to work well!
trust-manager also supports pulling in the Mozilla trust bundle which most Linux distros (and therefore most containers) use!
Handling trust of private [2] certificates is done poorly generally across many orgs and platforms, not just Kubernetes. There are lots of ways of shooting yourself in the foot - particularly when it comes to rotating CA certificates. I think there's a lot of space here for new solutions here!
[2] I try to avoid "self-signed" in this use case because its literal meaning is that the certificate signs itself using its own key, which is what root certificates do. The Let's Encrypt ISRG X1 root certificate is self-signed but it's definitely not what I'd call a 'private CA'; see https://letsencrypt.org/certificates/
Having the communication in cleartext also makes it much easier for attackers to interfere with!
Sure, they can't modify the .deb without failing signature verification, but they _can_ inject arbitrary delays in downloads or interfere with anything else which isn't signed (e.g. HTTP headers)
Plus, if a vulnerability was discovered in the signing tool which enabled signature verification bypass with a certain signature format, HTTP makes it easy for attackers to perform that attack.
TLS shouldn't be optional for installing packages today IMO - the extra guarantees it provides are worth it even with signature verification enabled.
This is super interesting; we had a fairly long discussion about whether or not to add this action to cert-manager[1], and ended up rejecting it in part because it increased the risk of supply-chain attacks and that risk wasn't, in our opinion, outweighed by the potential benefit of catching more spelling mistakes.[2]
For me, I think there's a wider point here that GitHub Actions are pretty scary in terms of these kinds of attacks. Pre-packaged actions are easy to add to a project but come with risks, as this security advisory shows! There are a few aspects to Actions which made me a little uneasy in terms of my threat models when building software, and personally I've tended to avoid them.
This mirrors my experience, too. Building a simple RPM isn't too bad, even if spec files are a little arcane. Packaging for the AUR isn't super complicated as far as I've seen.
The "standard" way to build even the simplest deb file seems super overcomplicated whenever I've tried to do it, with layers of complexity, shims and fudges.
For most simple stuff you just want to specify a bit of metadata, a couple of install scripts and specify "X goes in /usr/bin/X, Y goes in /usr/share/...".
I tend to find that fpm (https://fpm.readthedocs.io/en/latest/) does that for me, and I now use it for building my own deb files pretty much everywhere.
Do you have an example of a situation where a problem in systemd required you to patch the source and recompile, or are you just making a general statement?
Specifically a problem that couldn't be fixed by changing systemd unit files?
(I don't mean for this to sound in bad faith; I'm genuinely curious as a user of systemd)
I currently have a messy side project[1] where I'm writing bare-metal RISC-V machine code (i.e. writing in hex after assembling instructions by hand) targeting the SiFive HiFive1. QEMU is handy for testing since it supports that board pretty well - it lets me skip the "code upload" step and just run a binary with gdb right away.
I did a similar thing with the Raspberry Pi a few years ago, but the QEMU support wasn't great back then which made debugging incredibly hard. I think the support has improved a lot since then, so I should probably give it another go.
As others have said, if you're gonna be reaching that kind of timeout, the use case would come under this caveat I mentioned:
> assuming the task isn't hugely inappropriate
We have a couple of cases where reasonably small files (< 100MB but it'd work with larger) need to be downloaded from one place and placed in another, potentially with an ETag check to prevent redundant uploads/downloads. Lambda is perfect for that.
My experience with serverless (mostly AWS Lambda) is that I've found 3 major use cases where it's been a very successful choice:
1. as a cron-style job (e.g. download a file every hour and put it in S3, or connect to a DB and do some smaller processing task)
2. as a responder to (or processor of) cloud-based events (e.g. receiving from a stream, reacting to an instance shutdown notification or an alarm)
3. as a backend for a small REST API (especially for heavily cacheable APIs)
For all 3 cases, assuming the task isn't hugely inappropriate and you've got a bit of infrastructure-as-code lying around which can be repurposed, serverless has lead to a massive time saving for me for several tasks, for very little money and with basically no maintenance effort required.
There's definitely a tendency towards smaller tasks, though. Ultimately serverless necessarily means giving up control of your infrastructure and removing a lot of customization or specialization options; that means that at a certain scale or level of complexity, it just isn't an appropriate choice either for cost or performance reasons - but that's fine, it doesn't have to solve all problems. It has its niche, and it's quite easy to go from a quick Lambda to a container-based or VM-based alternative.
I've been thinking about this sort of thing a lot recently in terms of our heavy use of Troposphere[1] which is a Python abstraction over AWS CloudFormation and how much better that abstraction is than just writing HTML (in the case of this library) or JSON/YAML (in the case of CloudFormation) directly.
Ultimately, for me, it comes down to what makes sometimes complicated declarative code easier to reason about, read and understand - it's a simple as that.
Some things are just _easier_ to write when you've got the power of a Turing-complete language with a decent standard library behind you; if for example you want to dump out a sorted list and then be able to easily update it later, or print a list of links alongside a hash of the contents of their targets.
I guess if you're building a simple website, anything like this tool could be overkill and you'd risk spending more time setting things up - and maintaining it in the future - than you'd be likely to save by using the tool in the first place. But for more complicated output having more tools to use lets you be arguably more declarative; you just change the input data to generate the desired output. You describe and allow automation of the _transition_ from input data to the desired end point.
I could definitely see how libraries like this would be tremendously useful for generating HTML. As it happens for our AWS infrastructure generation we enforce the use of Troposphere everywhere, because in that case the cost of setting up and maintaining it is essentially just copy-pasting an existing Makefile.
I was happy with Namecheap until they redesigned their website and included a tonne of JS which slowed everything down. Doing something as simple as changing an A record became unbearably sluggish, and I tend to think I have a fairly high tolerance for that kind of thing.
I gave them a few months to see if it was teething problems with the new design but it persisted. Eventually I moved everything to gandi, which has been better in every way as far as I can tell - cheaper (for me), better website, better features out of the box.
The Economist has been editorially pro-legalization of cannabis for a long time so any propagandizing agenda you think you're "sensing" just isn't there; in fact their agenda is literally the complete opposite of what you "sensed".
They pretty obviously used "cannabis" here because these products were designed + marketed as legal cannabis replacements or alternatives. They're called "synthetic cannabinoids" for a reason. I hardly think that using "cannabis" as a comparison to "synthetic cannabinoids" is "twisting things", or using "foul language", either.
It's not a question of whether or not it's easy or hard; it's definitely technically doable.
It's a question whether or not it's desirable. I think the consensus is shifting decisively to saying that it _is_ desirable. The question then becomes how you can assert concepts on a type at compile time.
E.g. for a function add(a T, b T) and a type T, how do we assert that a + b is a valid statement? The draft design shows one approach to this.
At the BBC we use mutual TLS extensively in our cloud-deployed applications, across a lot of developers and different teams, for both service-to-service and developer-to-service auth (all devs get a client cert).
It works well for a lot of use cases, not least because most things are doing a TLS handshake anyway when communicating. That means that adding client certs into the mix isn't much of an overhead and you can avoid another authentication/authorization step if your CA hierarchy is well managed and you can trust that a cert which says "Joe Bloggs" is actually Joe's cert. Also obviously it avoids any 3rd parties, like you said!
That said, it only really works for us because a lot of apps are deployed through a centralised tool which adds relatively short-lived certificates to deployments and then automatically redeploys things before their certs expire. That ensures that certs stay valid. We also have a solution to handle revocation in the event that a cert is compromised, which is a massive pain.
So if you spend the time to set everything up it's pretty great, but the cost of setting it up is quite high. You'll also run into problems where you want to use some tool X but it doesn't support mutual TLS and you're forced to either find a different tool or hack in support if that's an option.
A big example of missing support is things like the Application Load Balancer in AWS (or equivalents in other clouds) - they tend not to support mutual auth, which means that you can't really use them and you're forced to use a more traditional load balancer with TLS passthrough and then terminate TLS somewhere else.
If you're on Android, you can do this today with Termux. I believe you can also set up shortcuts (so you could have a home screen widget to open your TXT file).
We also support ACME profiles (required for short lived certs) as of v1.18 which is our oldest currently supported[1] version.
We've got some basic docs[2] available. Profiles are set on a per-issuer basis, so it's easy to have two separate ACME issuers, one issuing longer lived certs and one issuing shorter, allowing for a gradual migration to shorter certs.
[1]: https://cert-manager.io/docs/releases/ [2]: https://cert-manager.io/docs/configuration/acme/#acme-certif...