This happens if you have some third-party repositories that are still using SHA-1 signatures. A similar error happens with RPM-using distros too. Ideally, the repo owners would fix their repos, but until they do, if you want to accept the risk of them using SHA-1, you can set your own policy about when you'll accept SHA-1 until.

Both apt and rpm use a library that validates using Sequoia, a GnuPG compatible tool & library. It comes with a default policy to start rejecting SHA-1 as a hash from 2026-02-01, but it reads /etc/crypto-policies/back-ends/sequoia.config and accepts that.

So the solution is sudo mkdir -p /etc/crypto-policies/back-ends, and then sudo nano /etc/crypto-policies/back-ends/sequoia.config and pasting in:

[hash_algorithms]
sha1 = 2030-01-01 

That will give the repo owners until 2030 to fix the problem.

A note on security risk: SHA-1 in this case is used for revocation checks, and poses a very minor risk. If the repository's key is compromised, and they revoke it, but before it was revoked the attacker was able to manipulate a request in the right way, they might be able to get a signature that the key is not revoked that is also valid for a certain other time, and then extend how long they can keep using the leaked key.

On the other hand, I've seen tutorials on the Internet on how to solve this problem that amount to telling apt to always pass the validation check (i.e. don't actually validate) using APT::Key::GPGVCommand. For your own benefit, please don't do this, as that just requires using a dodgy mirror to compromise your system.

::: spoiler spoiler He was the instar pupa. :::

Today, lemmy.amxl.com suffered an outage because the rootful Lemmy podman container crashed out, and wouldn't restart.

Fixing it turned out to be more complicated than I expected, so I'm documenting the steps here in case anyone else has a similar issue with a podman container.

I tried restarting it, but got an unexpected error the internal IP address (which I hand assign to containers) was already in use, despite the fact it wasn't running.

I create my Lemmy services with podman-compose, so I deleted the Lemmy services with podman-compose down, and then re-created them with podman-compose up - that usually fixes things when they are really broken. But this time, I got a message like:

level=error msg=""IPAM error: requested ip address 172.19.10.11 is already allocated to container ID 36e1a622f261862d592b7ceb05db776051003a4422d6502ea483f275b5c390f2""

The only problem is that the referenced container actually didn't exist at all in the output of podman ps -a - in other words, podman thought the IP address was in use by a container that it didn't know anything about! The IP address has effectively been 'leaked'.

After digging into the internals, and a few false starts trying to track down where the leaked info was kept, I found it was kept in a BoltDB file at /run/containers/networks/ipam.db - that's apparently the 'IP allocation' database. Now, the good thing about /run is it is wiped on system restart - although I didn't really want to restart all my containers just to fix Lemmy.

BoltDB doesn't come with a lot of tools, but you can install a TUI editor like this: go install github.com/br0xen/boltbrowser@latest.

I made a backup of /run/containers/networks/ipam.db just in case I screwed it up.

Then I ran sudo ~/go/bin/boltbrowser /run/containers/networks/ipam.db to open the DB (this will lock the DB and stop any containers starting or otherwise changing IP statuses until you exit).

I found the networks that were impacted, and expanded the bucket (BoltDB has a hierarchy of buckets, and eventually you get key/value pairs) for those networks, and then for the CIDR ranges the leaked IP was in. In that list, I found a record with a value equal to the container that didn't actually exist. I used D to tell boltbrowser to delete that key/value pair. I also cleaned up under ids - where this time the key was the container ID that no longer existed - and repeated for both networks my container was in.

I then exited out of boltbrowser with q.

After that, I brought my Lemmy containers back up with podman-compose up -d - and everything then worked cleanly.

I'm logging my idea across a series of posts with essays on different sub-parts of it in a Lemmy community created for it.

What do you think - does anyone see any obvious problems that might come up as it is implemented? Is there anything you'd do differently?

There are still some big decisions (e.g. how to do the ZKP part, including what type of ZKPs to use), and some big unknowns (I'm still not certain implementing TLS 1.3 on TPM 2.0 primitives is going to stand up and/or create a valid audit hash attestation to go into the proof, and the proofs might test the limits of what's possible).

Let's say I visit an HTTPS website. There is a decent chance my browser will use TLS1.3 to connect to the server. It will verify the certificate, and establish an ephemeral symmetric key, and transmit an encrypted request, and decrypt the response. It would immediately solve the needs of Uniquonym if I could then generate a zero-knowledge proof that the certificate was signed by a particular CA, and that the transcript of the connection (request and response) met certain parameters.

However, there is a huge gap here. Since my browser, which I can control entirely, negotiated the symmetric key, I can:

1. Encrypt an entirely different request to what I actually sent to the server, and/or,
2. Encrypt an entirely different response from what I actually received from the server.

This response will look equally authentic to a real response - nothing in the TLS1.3 protocol provides non-repudiation to stop me doing that, because it isn't really designed for that.

There are proposals for extensions that, with the cooperation of the server, allow for TLS non-repudiation (e.g. TLS-N). If every government in the world could be convinced to adopt these on servers that prove user identities through their responses, this would enable Uniquonym. However, TLS-N has very limited adoption, and governments looking to monetise their identity systems probably are unlikely to go out of their way to help provide a free alternative. So relying on this option is probably unrealistic!

There are solutions that use multi-party computation to implement TLS to help interactively convince a group of users that a transcript is valid. However, they are relatively slow, don't scale to large groups, and will only convince group members present at the time of the original request - they won't produce a non-interactively verifiable proof. Making this into a non-interactive protocol is outside of what's possible with currently known cryptographic primitives, and unlikely to be feasible (and for the request part would be impossible - arbitrary data could be encrypted, and then state rolled back and the correct data encrypted, with the arbitrary data substituted later).

One alternative is to lean on so-called "trusted computing" - i.e. specialised hardware that can perform operations and produce signed attestations about the process. This is similar to introducing a trusted third party, except that it is owned by the person who wants to verify their identity (but designed so that person doesn't have access to the private keys to create false attestations). Data stays physically local, but there is still trust in the manufacturer of the trusted computing module to ensure keys are adequately protected, and not to sign certificates for fake modules (allowing fake transcripts to be attested to). This puts them in a similar position to governments - they can't unmask a Uniquonym, but they can create multiple fake ones. Since we don't have a clearly better option, this is the current area of research for Uniquonym.

Trusted computing is a controversial choice because the most common application is to reduce users' freedom - the FSF calls it Treacherous Computing. Using it to create pseudonyms to escape censorship and astroturfing manipulation to manufacture consent is turning a technology created mainly for bad uses around and using it for good.

That are multiple types of trusted computing.

One of the easiest options might be to use a Trusted Execution Environment (TEE) like AMD Secure Encrypted Virtualization (SEV) and Intel SGX - which leverage existing CPUs, but let them run in a secure mode that allows access to secrets. However, these are slightly finicky to use, and significantly, many versions of them have been compromised through under-voltage attacks to glitch the CPU. A compromise would allow for arbitrary issuing of fake identities, and due to the Uniquonym being pseudonymous and based on ZKP, it would be nearly impossible to respond.

A more secure option would be to leverage physical TPM 2.0 chips. These are designed to be much more robust against various physical attacks, since they are separate to the main CPU, and typically have features like protective wires set up to destroy the key if decapped and analysed with probes. Thanks to the efforts of Microsoft, who made it mandatory for Windows 11, TPM 2.0 are now fairly common. Note however, that some TPM 2.0 implementations are actually virtual TPMs on top of AMD SEV / Intel SGX, and so secure TPM 2.0 chips suitable for this application might be less common.

One difficulty with using TPM 2.0 is that they provide a limited range of cryptograpic operations. An open research question for Project Uniquonym is whether this is enough to produce an attested TLS 1.3 transcript, with a cipher suite compatible with a sufficient number of servers to be useful, that can used from a zero-knowledge proof.

As explained in https://lemmy.amxl.com/post/709344, government issued identities are an essential building block on top of which uniquonyms are created.

However, there is a diverse range of governments out there, and they all do things differently.

The simplest would be if they all acted like a Certificate Authority - you prove your ID to them, and give them your public key, and they give you a certificate linking your public key to the unique ID. You then publish a document linking your ID number to your public key and a hash of a secret only you know, and including the certificate - this establishes your public real world identity. Later, you publish a message establishing your pseudonym as a hash of the secret and the namespace, with a zero-knowledge proof that a publicly disclosed identity with a valid government certificate exists somewhere in a particular tree, and that the secret matches.

However, most governments do not provide this Certificate Authority service unfortunately, and when they do, access to it is often heavily gated behind barriers to entry on who can use it and for what purpose. It also often has a fee, which would deter uptake. There are some private businesses which specialise in verifying government identities and issuing certificates - but this again has a fee, and introduces an additional trusted third party.

Many governments, however, have some form of online login system and portal (for government services) where people can log in using HTTPS (specifically generally HTTP over TLS1.3 these days), and between the contents of the request and the response, that will be enough to identify an individual uniquely. Leveraging this (combined with a per-country module system for understanding what needs to be proven about the HTTP request and response) would solve the needs for Uniquonyms. This requires a way to prove to others that a TLS1.3 transcript is genuine - which is a very difficult problem - and a topic for a future post.

As discussed in another post, establishing unique real identities is a pre-requisite for applying the cryptographic tools to decouple a real identity from a pseudonymous one to make a uniqonym.

There are some existing solutions for ensuring people only have one identity:

• https://proofofhumanity.id/ is one attempt using photos, videos, and humans vouching for others.
• https://worldcoin.org scans irises and hashes the pattern.
• Most governments around the world register births and assign unique government identifiers to individuals.

There is no perfect solution unfortunately - there are trade-offs.

Use photos and videos as in PoH

The biggest problem with this solution is that it is unlikely to be that hard to make AI generated images and videos (after fine-tuning AI models for the task), and easy to vouch for a bot that vouches for a bot, and so on, until you have hundreds or thousands of identities. As such, it is unlikely to scale well.

Using iris scans as in WorldCoin

This solution attempts to solve for the problem of AI-generated images by using hardware produced and signed by a supposed 'trusted third party'. Anyone could generate an iris image with AI, but the official hardware has proprietary technology to check for liveness. The hardware is physically hardened against attacks, and has a key protected in hardware to sign iris hashes - that links through a certificate chain back to a certificate issued by the "World Foundation".

If you trust the "World Foundation", this solves the AI problem with PoH, and solves the problem to an extent of not trusting a government to do the right thing (except to the extent said government could order the World Foundation to comply, anyway). However, in exchange, it requires trust for WorldCoin - they could create an arbitrary number of identities.

It also has the problem of requiring a large investment to get it worldwide, and is inconvenient to onboard to.

People in general do not trust the World Foundation. While it is a not-for-profit, it is associated with Sam Altman, who famously was able to get the board of OpenAI to resign and replace it with one loyal to him, and transition OpenAI towards being fully for-profit. World Foundation does not have members - only 4 directors who appoint their successors, and have complete control over it.

As such, a solution that already has a perception of being 'creepy' and which relies on a trusted-third party that doesn't seem all that trustworthy can probably be discounted. Another implementation of the same idea is unlikely at this point due to the entry costs.

Another problem is that it has faced legal challenges operating in some countries due to privacy or security trading concerns.

Leveraging government issued identities

This solution relies on governments to decide who is a real person, and then leverages existing infrastructure.

This solution has the upside that it potentially has the lowest barrier to entry - at least in countries where people already prove their identity to the government.

There are a few downsides:

• The government could create lots of fake people and use those identities to create fake prevalence signals (i.e. do the exact thing uniquonyms are supposed to protect against). This could be mitigated to an extent by making uniquonyms per-country - if 50,000 Russian government certified uniquonyms show up on a Ukrainian forum pretending to be Ukrainians, users can just filter them out. Within a country, all of the options require some degree of trust of governments - they could scan all their prisoners irises, or force prisoners to hand over their private keys under any option, and use those to create inauthentic interactions.
• Uniquonyms based on government issued identities would need to be unique per country. Someone with multiple citizenships or relationships with multiple governments might have a uniquonym per country per namespace.
• There are technical complexities around implementation (to be covered in a separate post) unless governments provide a unique key
• There is a trade-off (discussed below) between allowing a government to unmask uniquonyms for users under that government, or not allowing recovery if someone claims a uniquonym using stolen government credentials.

The unmasking vs recovery tradeoff

Suppose someone gets access to your computer while you are logged in to a government website. Suppose you don't yet have a uniquonym in a particular namespace, but the attacker goes ahead and creates one linked to your real identity under their own private key.

This is the uniquonym recovery problem. In an ideal world, after you re-prove your identity to the government, and kick out the identity thief, you'd be able to take over the uniquonym or somehow detach it from your real identity.

However, if this was allowed, the government could do the same without your cooperation - hence unmasking your real uniquonym.

So there is a trade-off to be had between safety from the government as a threat actor, and recovery following actions of non-government threat actors. Due to the design goal of protecting dissidents, the uniquonym architecture plans for now are to disallow recovery in this scenario.

However, this can be limited by making uniquonyms expire and require periodic re-verification (e.g. every 6 months). Then, recovery is to wait 6 months, and claim a uniquonym after that. Other forms of recovery other than someone making a new uniquonym against your identity are more solvable for - e.g. lost private keys could be solved by providing printable backup QR codes that can identify a uniquonym, but have enough information to enable recovery. These would have the risk that a government raid of a dissident could uncover it and lead to the dissident's pseudonym being found - but that is still a better threat posture if they have no way to identify the dissident's real identity if they limit their actions to online.

Why the plan for uniquonyms is to leverage government identities

All the options have some drawbacks - there is no perfect option unfortunately.

However, robustness against AI-generated alts is almost certainly needed for uniquonyms to be a success, and reliance on the World Foundation as a trusted third party is not going to fly or be convenient enough for significant uptake.

Therefore, relying on government issued identities, with as many mitigations to the drawbacks as possible applied, is how I plan to take project uniquonym.

For a uniquonym to work, it is necessary for there to be some tie back to ensuring a person can't just create a new one. This requires some kind of way to identify a unique person that is hard to double up. I'll make some separate posts going deeper on this.

Next, it requires a way to prove that within a namespace, that a real identity has no more than one pseudonym linking to it - but without revealing the real identities to anyone. There are a range of different trade-offs here - a topic for another post.

An increasing proportion of our discourse occurs on the Internet - but it is increasingly fractured into echo chambers, which creates divides in society. The biggest cause of this is that if communities open up to dissenting views on polarising topics, it is very difficult to tell what is from an astroturfer / provocateur / troll who posts the same content under 50,000 names (possibly using AI technology), vs what is genuine. If using a uniquonym (a pseudonym that is unique - i.e. one real person can only have one within a particular namespace) brings trust that people are authentic, it should foster more genuine communication and re-unite communities.

One could argue that someone's real name is the ultimate uniquonym. The trouble is that fear of surveillance and persecution also represses people on the Internet in many parts of the world. It is not reasonable to expect real world consequences for online actions if those real world consequences are persecution and the online actions are speaking truth to power. For that reason, a uniquonym is only unique within a namespace (e.g. a particular website, or a perhaps across a fediverse protocol) - and it should not be possible for anyone to work out someone's real identity from a uniquonym, or to correlate uniquonyms across namespaces.

Some degree of compartmentalisation is good for privacy. There could be a convention of accepting several namespaces per protocol - but with a number, where claiming a uniquonym in a lower numbered namespace gives it more credibility. For example, if I have a name in the namespace lemmy_1, I might be more credible than if I have a name in lemmy_53123, which suggests I might have 53,123 other names as well in other numbered namespaces! This will allow people to have some degree of compartmentalisation of different identities, while protecting their real identity, and preventing non-genuine interactions.

Looks like it is also flowing into huge numbers of people using the trams.

The new laws are coming into force in the current election. It is a sweeping change impacting all councils. It makes councils much less representative - it means that one ticket of councillors can have 51% support but 100% of all seats on the council.

Based on the speeches, it sounds like basically everyone was against Labor on this, both the VEC expert recommendation, and also pretty much everyone in state parliament except Labor - see the linked hansard starting from page 30. That said, when the Greens proposed an amendment to it, the Liberals voted with Labor to defeat it, and the single-member ward thing became law.

Stallman was right - non-Free JavaScript does hostile things like this to the user on who's computer it is running.