The simple task of following a bug requires you to:

1. Send an empty email to a special address for the bug.

2. Wait 15-30 minutes for Debian's graylisting mail server to accept your email and reply with a confirmation email.

3. Reply to the confirmation email.

The last time I tried to follow a bug, I never got the confirmation email.

In practically every other bug tracker, following a bug is just pressing a button.

Like most of Debian's developer tooling, the bug tracker gets the job done (most of the time) but it's many times more inconvenient than it needs to be.

Fair points. But without looking at it myself, and for the benefit of people reading along, do you have to do that if you already have an account on the tracker? For instance, it's easy to follow issues on GitHub, but that's after you've jumped through some similar hoops to create an account.

There is no way to create an account for the Debian bug tracker. You have to jump through these hoops every single time you want to follow a bug.

Oh, wow. Yeah. Well, I asked, and now I know!

I really wish we could have both. An interactive web frontend, and the classic email-centric bug tracker, both serving the same data. I think both have its strengths. I suppose that the job is massive given how enormous and fast-moving the first have become.

Yeah but virtually every developer in the world has already jumped through that hoop. They don't need to do it again for every project.

Also the hoop can be as simple as "click here to sign in with <other account you already have>".

I use reportbug to simplify the process of initial reporting, but whole interaction is still far from convenient.

https://tracker.debian.org/pkg/reportbug

I can't find it now but I recently saw a graph of new Debian Developers joining the project over time and it has sharply declined in recent years. I was on track to becoming a Debian Developer (attended a couple DebConfs, got some packages into the archive, became a Debian Maintainer) but I ultimately burned out in large part because of how painful Debian's tooling makes everything. Michael Stapelberg's post about leaving Debian really rings true: https://michael.stapelberg.ch/posts/2019-03-10-debian-windin...

Debian may still be "getting by" but if they don't make changes like this Git transition they will eventually stop getting by.

There are a couple things missing from this:

1. The monitoring client does not ensure that the checkpoint was created recently, so a malicious log can conceal malicious entries from monitors by serving an old checkpoint.

2. Though the age keyserver policy is not configured this way, the post suggests you could create a policy that requires only a minority of witnesses (e.g. 3 of 10) to cosign a checkpoint. If you do this, then monitors have to get checkpoints that are cosigned by at least 8 of the 10 witnesses. Otherwise, a malicious log could present one view to relying parties that is cosigned by one set of witnesses, and a different view to monitors that is cosigned by a different set of witnesses. There is currently no mechanism specified for monitors to get these extra cosignatures, so if you go with a minority policy you'll need to invent your own stuff in order for witnessing to actually accomplish anything.

Fixed (1) in https://github.com/FiloSottile/torchwood/commit/8b61ef967, thank you!

I'll add a note to the part of the article that mentions non-majority policies.

Does this support conditional PUT (If-Match / If-None-Match)?

There's an extension to static-ct-api, currently implemented by Sunlight logs, that provides a feed of just SANs and CNs: https://github.com/FiloSottile/sunlight/blob/main/names-tile...

For example:

  curl https://tuscolo2026h1.skylight.geomys.org/tile/names/000 | gunzip

(It doesn't deduplicate if the same domain name appears in multiple certificates, but it's still a substantial reduction in bandwidth compared to serving the entire (pre)certificate.)

Now that AWS charges for public IPv4 addresses, is it still free if you need to access IPv4-only hosts?

Yeah not free if you definitely need IPv4. AWS has been adding a lot more IPv6 support to their services so hopefully the trend continues in AWS and the broader industry. You can probably get pretty far though if your app doesn't have hard requirements to communicate with IPv4 only hots.

I'll note that the overhead is only on the provider side; from the customer's perspective it's all the same. In contrast, OpenID Connect puts overhead onto the customer (in addition to the provider) which I find unfortunate since I want to provide a good experience.

Google said "general terms of service violation" or unspecified "abusive activities". Google is only involved in the publication of DNS records, not the deployment of certificates. Note that they didn't require us to take any action after the suspension in 2024 to correct this alleged abuse; they just re-enabled access without any further explanation.

They probably shouldn't have suggested doing this in their own documentation then.

Totally agree. But the docs aren't going to guide their model. Contradiction between the reality of a service, monitoring, and docs don't go to "align with the docs" they go to "align docs to reality"

I don't like this. I too have looked like an attack on their models using things inside the customer-side of google, took special relationships to get over this, an ongoing threat to how we relate to them.

(it's not in GCP btw. different arc of the megaplex)

Docs will guide what the courts think though if this gets that far. You can be sure lawyers will bring any documentation that seems to show your case before the judge and demand why they said it worked if it didn't.

I'm not in favor of going to court, but if it does a lawyer doesn't have be very good to think of the above.

So then it seems like different departments are undermining each other’s credibility on a daily basis?

That’s been my experience with Google.

They’re too big and no one has the authority to clean it up. I’m honestly shocked we don’t see more account suspensions.

I’ve migrated my businesses to Microsoft’s cloud offerings and they’re also a clusterfuck, but at least I can get real support people on the phone pretty easily (for now…).

There was that Australian pension fund who had all their data suddenly deleted (not suspended) by Google.

https://www.business-standard.com/world-news/google-cloud-ac...

Just like it supposed to be in a corporation.

Right, and we will be ditching our Google Cloud account this time, but as explained in the post this will come at either a security or a usability cost for our customers, which is why I did not ditch after the first suspension.

I can understand you not ditching after the first suspension but the second suspension should have been the point where you took the choice.

First time is a fluke, second time is a serious wake-up call, third time it's your fault.

Do you really want to reach the point where all your customers have an outage, you have to rush implementing something else (oidc or api keys) AND rush your customers to change your settings?

Second and third suspensions are a week apart. Wouldn’t be enough time to shift customers to a new auth format, specially when most of the burden is on them.

Those are negligible compared to a 100% availability / uptime cost to your business incurred from being a serf to a feudal tyrant with no name or face that enjoys abusing you.

Using GCP, AWS, or Azure is like volunteering to use your own money to rent heavy construction equipment to construct your own jail cell and excavate your own grave.

But hey, at least you get to avoid the capex on the heavy construction equipment, and it's always¹ available!

¹ except for when human error takes it offline for 14 hours straight

You're not just dealing with a massive bureaucracy, you're dealing with a massive automated bureaucracy whose rules aren't explicit, whose algorithms are buggy, and which can destroy your business on a whim with no recourse, without even noticing.