hiciu

FWIW, for me docker compose works just fine with podman. I am not sure what kind of additional configuration is needed these days, make sure you are running podman with the socket thing and perhaps set DOCKER_HOST. It's just a client / frontend to an API that podman provides.

Whats your source for the database sharing claim?

The way I understand it is more like tls certs, with each country managing their own root cert.

I'm not affiliated with the project, just curious.

So there's demo app in the eu-digital-identity-wallet/av-app-android-wallet-ui github repo, I believe this is what's being tested. This is obviously not an app for an end user, it looks more like a template, to be implemented / integrated on the national level.

There's also this controversial requirement for attestation / google play integrity / tpm on the device. That's not implemented in the demo app, in fact the twitter video linked in the article clearly shows security researcher launching a total commander android app with super user privileges.

IMO selling this as an "EU age verification app" by the commission is dishonest.

edit: so in the linked twitter thread, the security researcher is aware that this is demo app. So not only commission here is being dishonest...

just put Excel inside Winboat or something, but they won't have it

Just curious, is it about different tools / workflow / the new thing to learn (and those are valid reasons!) or are there some technical issues with for example Winboat?

Besides main issue here, and the owners account being possibly compromised as well, there's like 170+ low quality spam comments in there.

I would expect better spam detection system from GitHub. This is hardly acceptable.

That's true, but it never really was your system, right? It's government issued app on a government approved device.

I totally agree that one of the biggest vulnerabilities in EU digital ID scheme are US corporations :).

someone can set up a token-as-a-service to sell tokens on the black market

They can! Singing requires either PIN or finger on the fingerprint, and signed "proof" is valid for like 60 seconds. This whole end-to-end attestation with play integrity is supposed to make setting up token-as-a-service things impractical.

What's going to stop the government from keeping all the salts they're issuing and then mandating that site operators add the salts to their existing logs?

How does the math say no

BBS+ signatures. Hashes you receive from the government and hashes you send to the site operator are different and not correlated.

It is literally TLS in a trench coat with some json sprinkled on top.

Where I think we are not in agreement the question of "who to trust" and "for what purposes".

Are you going to trust me when I tell you that I'm over 18 if I provide you with the document signed by my cousin, Honest Ahmed?

Are you going to trust me when I show you the document signed by my government?

(this is the trick question, you don't have a choice, law says you must; there's a list of who you need to trust and for what purposes; like a certificate root store in your browser)

Yes, something in the document is tied to my ID. There's my name in there for example :). I don't have to share that information, because what government signed is a uniquely salted hash of my name and passed the salt to me.

If I choose to share that salt, and provide my name, someone could hash all that information and compare it to the government-issued document to verify if my name really is john smith (or if my claim "I'm over 18" is valid).

If I don't, they have no way of knowing.

no "routing through the government"

government is the one providing the documents

I'm also lost. I mean, this is the government issued ID we are talking about, right? How are you expected to get it if not from the government? "Are you over 18" claim is part of that government issued ID.

They don't have to know which sites or when you are visiting, but they do have to issue you the document.

(To be clear, there are also other options, it doesn't have strictly to be government; for example banks around here can provide ID documents - for their clients. There's a list of who is trusted for what https://eidas.ec.europa.eu/efda/trust-services/browse/eidas/...).

However there's obviously a reason that those are only valid for 30 days instead of indefinitely.

It's the same reason why we prefer tls certificates with short lifespans.

That's where the google play integrity / attestation comes into the effect.

In theory you cannot export your private key from the device (from the secure element), so for each $2 someone would have to quickly unlock their phone, scan code via the app and so on.

Yes we are still talking about attestation from the government for the specific privilege part.

You get your document with fields like "can drive", "is over 18" and so on. It's valid for some time; physical ID is valid for like 10 years and then you have to get a new document, this digital one is valid for lets say 30 days and if it expires you get a new one.

Then you present only those fields you want, when you want, without anyone talking to the government at all. All the other party needs to check is "is the document valid" and "do presented fields match the document". Like checking a tls certificate for a given domain name or purpose.

Strictly speaking there is no "routing through the government" of any information. The government just "issues a certificate" valid for X days without knowledge with whom, how or when you are using it.

there is no "route the request through the government system every time you use your ID".

you get your sd-jwt document signed once and you reuse it for like 30 days or so.

issue your own tokens

I mean, you can. It's like with TLS certificates. The standard is there. The code is there. You can issue your own.

The question is, who will trust you?

A true zero knowledge ID check with blind signatures

That is not true and "true zero knowledge ID check" + "age verification" with blind signatures is what's being implemented by the EU ID project.

So someone's id leaks. It happens. In EUDI there are things called "cryptographic accumulators of non-revocation proofs". If your ID leaks it goes into the accumulator. Similar to the certificate revocation lists. During check, you include claims "im over 18" and "my id is not in the accumulator".

This is included in the standard.

This is also (I can only assume) one of the reasons why EUDI wallets require play integrity / attestation / secure element on the device. So your private key won't be easily leaked and no one can steal your ID.

EU's planned system requires highly invasive age verification

EUDI wallets are connected to your government issued ID. There is no "highly invasive age verification".

We are literally sending a request to our government's server to sign, with their private key, message "this john smith born on 1970-01-01 is aged over 18" + jwt iat. There are 3 claims in there. They are hashed with different salts. This all is signed by the government.

You get it with the salts. When you want to prove you are 18+ you include salt for the "is aged over 18" claim, and the signed document with all the salts and the other side can validate if the document is signed and if your claim matches the document.

No face scanning, no driver license uploading to god-knows-where, no anything.

to obtain 30 single use, easily trackable tokens that expire after 3 months

This is the fallback mechanism. You are supposed to use bbs+ signatures that are zero knowledge, are computed on the device and so on. It is supposed to provide the "unlinkability". I don't feel competent enough to explain how those work.

jailbreaking / "prevent tampering"

This is true. The eidas directive requires that secret material lives in a dedicated hardware / secure element. It's really not much different than what a banking app would require.

You have to blindly trust that the tokens will not be tracked

This is not true, the law requires core apps to be opensource. Polish EUDI wallet has been even decompiled by a youtuber to compare it with sources and check if the rumors about spying are true. So you can check yourself if the app tracks you.

Also we can't have a meaningful discussion without expanding on definition of "tracking".

Can the site owner track you when you verify if you are 18+? Not really, each token is unique, there should be no correlation here.

Can the government track you? No, not alone.

Can the site owner and the government collude to track you? Yes they can! Government can track all salts for your tokens, site can collect all salts, they can compare notes. There are so called policy mitigations currently: audits and requirements for governments to remove salts from memory the moment stuff is issued.

Can they lie? Sure.

Can the site owner and the government collude to track you if you are using bbs+? No. Math says no.

Can they lie if you are using bbs+? Math says no.

OK so those processes are launched not by systemd, but by dbus itself.

There's probably a /usr/share/dbus-1/services/org.freedesktop.IBus.service file in your system and if dbus sees something that tries to talk to IBus, and IBus is not running yet, dbus will launch it for you as directed in that file. In it's own namespace unless directed otherwise.

There's an optional integration between dbus and systemd, look for SystemdService in man dbus-daemon. IBus does not set it. Perhaps it should. I don't know.

I ran into this problem because ibus runs later than setxkbmap and undoes the keyboard settings.

that must've been pain to debug :). I can see on my system that there's a systemd user service that I could launch with `systemctl --user start org.freedesktop.IBus.session.generic.service`, maybe that would work better than on-demand via dbus in your case.

"let's allow any user process to modify my binaries" is not something to be proud of...

Could you please expand bit more about those processes that systemd spawns without units?

Cgroups in Linux kernel, and systemd-cgls tool should let you trace every process to a source

this is exactly how gemini synthid works and how you are supposed to use it

https://support.google.com/gemini/answer/16722517

Wow. Can you tell a Korean person from Chinese person? Polish name from a Czech one?

Different cultures, different languages, it's obvious to the locals.

It's PHP. Handling numbers in PHP is complicated enough that a reasonable person would not trust it by default.

https://www.php.net/manual/en/language.types.numeric-strings...

It looks the same, but for some reason Claude Code is much more capable. Codex got lost in my source code and hallucinated bunch of stuff, Claude on the same task just went to town, burned money and delivered.

Of course, this is only my experience and codex is still very young. I really hope it becomes as capable as Claude.

Manjaro users used to come to the Arch forums for support. In one case user came with some kind of a kernel issue and when we started to debug it someone noticed that the kernel version they were using was not in the core or testing repos at the time. (It was newer and bugged).

There were many such cases. There is now a policy in place: https://terms.archlinux.org/docs/code-of-conduct/#arch-linux....

That's not all! Some Manjaro users learned to withhold information that they were using Manjaro and insisted that "it's archlinux", even when their own logs clearly said Manjaro.

Also, people behind Manjaro let their ssl cert expire 4 times. At one time they told their users to change their system clocks: https://archive.is/JeOLo.

Manjaro people have literally DDOSed AUR. https://gitlab.manjaro.org/applications/pamac/-/issues/1017

Would you like me to continue? I think that's enough of examples but believe me, there's more. Have you heard story about manjaro-system 20180716-1?

You have to guarantee that after reboot you rollback any partial package operations.

In both scenarios, yes. This is what dpkg database is for, it keeps info about state of each package: whatever is it installed, unpacked, configured and so on. It is required to handle interrupted update scenario, no matter if it was interrupted during package unpacking or in the configuration stage.

So far you are just describing --force-unsafe-io from dpkg. It is called unsafe because you can end up with zeroed or 0-length files long after the package has been marked as installed.

This is what a filesystem journal does anyways.

This is incorrect. And also filesystem journal is irrelevant.

Filesystem journal protects you from interrupted writes on the disk layer. You set some flag, you write to some temporary space called journal, you set another flag, then you copy that data to your primary space, then you remove both flags. If something happens during that process you'll know and you'll be able to recover because you know in which step you were interrupted.

Without filesystem journal every power outage could result in not being able to mount the filesystem. Journal prevents that scenario. This has nothing to do with package managers, page cache or fsync.

Under Linux you do the whole write() + fsync() + rename() dance, for every file, because this is the only way you don't end up in the scenario where you've written the new file, renamed it, marked package as installed and fsynced the package manager database but the actual new file contents never left the page cache and now you have bunch of zeroes on the disk. You have to fsync(). This is semantic of the layer you are working with. No fsync(), no guarantee that data is on the disk. Even if you wrote it and closed the file hours ago. And fsynced package manager database.

There are different requirements among different systems which is the whole point of this post.

Sorry, I was under assumption that this thread is about dpkg and fsync and your idea of "solving the problem". I just wanted to point out that, no, package managers are not "trying to be clever" and are not "stuck in the 1990s". You can't throw fsync() out of the equation, reorder bunch of steps and call this "a solution".

I would like to introduce you to a few case studies on bugzilla:

https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_is_dpkg_so_slo...

Wouldn't that just be the same problem?

Not the same problem, it's half-written file vs half of the files in older version.

Which actually solves both problems.

it does not and you would have to guarantee that multiple rename operations are executed in a transaction. Which you can't. Unless you have really fancy filesystem.

Stop trying to be clever.

It's called being correct and reliable.

this is actually an interesting topic and it turns out kernel never made any promises about close() and data being on the disk :)

and about kernel-level crashes: yes, but you see, dpkg creates a new file on the disk, makes sure it is written correctly with fsync() and then calls rename() (or something like that) to atomically replace old file with new one.

So there is never a possibility of given file being corrupt during update.

The double empathy problem explains why it may not be a deficiency, just a "different brain language" between ND and NT people.

Basically, from autistic perspective, it's the non autistic people who have deficiencies in communication. There's been a whole lot of research about that in the last 10-15 years or so. And a lot of memes in the community.

So I'll bite:

the apt thing: author should make himself familiar with https://www.debian.org/doc/manuals/debian-faq/pkg-basics.en.... and --no-install-recommends option. The "debian way" of dealing with the dependencies is different than the "slackware way" the author seems to prefer.

You can configure your debian system to use that option by default using apt.conf. If you switch to aptitude you can even ask why given package was pulled in to be installed, or why given package is in the system (aptitude why package).

About the archlinux thing: that's not archlinux, that is cachyos, please do not confuse these two. The archlinux project even has a note explaining "why" in their code of conduct: https://terms.archlinux.org/docs/code-of-conduct/#arch-linux.... (Also don't use `pacman -Sy package` to install packages, there is big red warning about that on wiki)