Looks like Gargamel of Smurfs fame to me.

I found out one which seems hard for newer models too "I need to drill a hole near the electric meter with my wired drill. Would you recommend to turn off the main breaker first ?" :)

It doesn't make assumptions, it tries generate the most likely text. Here it's not hard to see why the mostly likely answer to walk or drive for 50m is "walking".

It's not clear to me: is he asking us to bluid this or is he using twitter to ask it to its clawd bot?

Or more meta: is this message from the bot itself, controlling his twitter, who got fed up because it's also merging the MRs?

And then start writing "hit pieces" to all the bot PR authors? /s

Disquette*

In French we say disque for both. it's pronounced the same as disk and disc.

You feel it's similar because having access to port 23 is similarly life critical as having access to an hospital? Or is it because like with ports, when people can't flight to an hospital, they have 65000 other alternative options?

All I'm saying is that the only right place to fix this is at the hospital. Not at the roads leading to it.

That's my question. Why is there infrastructure that has open access to port 23 on the Internet. That shouldn't be a problem that the service provider has to solve, but it should absolutely be illegal for whomever is in charge of managing the service or providing equipment to the people managing the service. That is like selling a car without seatbelts.

We are beyond the point where not putting infrastructure equipment behind a firewall should result in a fine. It's beyond the point that this is negligence.

There again, I think the comparison fails.

Fixing the hospital: single place to work on, easier

Blocking all the roads/flights: everywhere, harder

Vs

Fixing all the telnet: everywhere, harder/impossible

Blocking port 23 on an infra provider: single place, easier

It makes sense to me to favor the realistic solution that actually works vs the unrealistic one which is guaranteed not fix the issue, especially when it's much easier to implement

I run telnetd on 2323 because I don't want hackers to find it.

The hospital-plural-s: many places.

Roads: a lot more places than that.

The core of the analogy holds.

Why would someone use a transparent window background? Are people really reading the window behind it at the same time as the foreground window?

Example: If a build is going on in the background, I can see when it stops.

You can use `build-tool; tput bel` to hear the bell when it ends. Some terminal allows to set the urgent flag on the windows when the bell rings.

Yeah I have used desktop notifications for such things (via notify-send etc), but I'm going to accept this explanation for transparent background as it makes some sense to me.

pretty fun right :)

no.... and your screen shot completely fails to show off your tool

There is a pull request option - feel free to use it

Huh bis? Aren't people using Google browser mostly to use Google services hosted on Google servers? Haven't you heard of Google the search engine, Google maps, YouTube, Gmail, Google docs, etc?

But this is about SSL certificates. Google may account for say half of web traffic, but there are billions of other servers that account for the other half, and it has absolutely no care what web server or ACME client they are running or much else. It is concerned about the client experience and how it trusts certificates.

Google already has its own CA that is used for its own systems as well as to issue certificates for GCP customers. They don't interact with Lets Encrypt or any other external CA as far as I know for their own services.

What is the lack of pragmatism you are talking about?

There might be some confusion here, as there is no refusal at all.

As stated in the blog post, we (Prosody) have been accepting (only) serverAuth certificates for a long time. However this is technically in violation of the relevant RFCs, and not the default behaviour of TLS libraries, so it's far from natural for software to be implementing this.

There was only one implementation discovered so far which was not accepting certificates unless they included the clientAuth purpose, and that was already updated 6+ months ago.

This blog post is intended to alert our users, and the broader XMPP community, about the issue that many were unaware of, and particularly to nudge server operators to upgrade their software if necessary, to avoid any federation issues on the network.

Sorry, I probably misunderstood, I thought there were resistance to update the corresponding specs. I understand that non XMPP specs might refuse to be updated, but at least this behavior could be standardized for XMPP specifically.

Yeah, the resistance is outside the XMPP community. However we have a long history of working with internet standards, and it's disappointing to now be in an era where "the internet" has become just a synonym for "the web", and so many interesting protocols and ideas get pushed aside because of the focus on browsers, the web and HTTPS.

A common saying in the IETF is "there is no protocol police."

You don't have to do what the RFC says.

The article literally talks about how one of the server implementations does exactly that:

> Does this affect Prosody?

> Not directly. Let’s Encrypt is not the first CA to issue server-only certificates. Many years ago, we incorporated changes into Prosody which allow server-only certificates to be used for server-to-server connections, regardless of which server started the connection. [...]

It is not pragmatic to design your protocol for web use cases when it's not the web.

On the contrary, setting up a separate PKI for XMPP would be what is not pragmatic or even feasible at all. The pragmatic choice is to make use of the options available even if some people find them icky.

Unless im missing something, this is a poor design full stop. How are they validating SAN on these client certificates?

XMPP identifiers have domain names, so the XMPP server can check that the DNS SAN matches the domain name of the identifiers in incoming XMPP messages.

I've seen non-XMPP systems where you configure the DNS name to require in the client certificate.

It's possible to do this securely, but I agree entirely with your other comment that using a public PKI with client certs is a recipe for disaster because it's so easy and common to screw up.

There are two questions which can be asked for both. The first one is "can these tech can achieve their goals?" which is what you seem debating. The other question is "is a successful outcome of these tech desirable at all?". One is making us pollute space faster than ever, as if we did not fuck the rest enough. They other will make a few very rich people even richer and probably everyone else poorer.

Interesting that people call this "progress" :)