dandarie

For what?

Is that a fact or an opinion?

How about tags/sets?

I can attest winters were definitely colder in the Moldavian part.

I remember two meters of snow, digging tunnels through it and such.

And I remember four distinct seasons. Now it's more like a long summer, a long autumn, and short spring and winter.

> The criticism only applies to users who reused their passwords on other sites, because Edward can still attack those other sites.

Of course, but that's a weakness that concerns the user, not the platform.

It is not a flaw of Facebook's security model.

Yes, he can steal the cookies and new passwords, but still won't have access to user accounts and/or passwords for more than an hour.

So, after Edward is discovered, all sessions are remotely logged off and all accounts created during that hour are blocked, asked to confirm their email, phone or even identity, or deleted.

So, after one hour, Edward is left with nothing more than braggable rights. And personal data of billions, but not their passwords.

You still have to trust your passwords being stored elsewhere, with weak encryption, if at all.

The solution is for docker-compose (or plain docker).

I don't think the reproducibility is out. It's the same app, the same image, the same intended user, you just inject, once, the local user and group ids.

Of course, but really only build once on every machine. The subsequent starts use the cached build, even after reboot.

In fact, docker-compose up -d takes care of the build thing by itself. It's a five second tradeoff for the lifetime of the application.

You start from a base image of your choice. You only build the user replacement part.

You run docker-compose build ONCE and you're set. On my machine, it takes five seconds.

Heck, you can even run docker-compose build everytime you start the application, it will use the cached build and take less than one second.

---

Correction: the docker-compose up -d takes care of the build process the first time it runs.

Literally, it takes more to complain about the issue than build the image ONCE.

> Do I need to set USERID for project foo, or UID? Does it default to 1000 or the author's UID? Oh, someone has a problem with our project, did they remember to set COMPANY_USERID in their bashrc? Oh, wait, they're using zsh, how do you do that there? Oh, but they followed this other project's readme and that set COMPANY_USERID but not COMPANY_GROUPID...

You set it to the output of id -u and id -g. It's two lines. There are definitely lots of things more complex when dealing with docker than this.

You provide the team with a script containing those two lines and a docker-compose wrapper and you're set.

Of course it would have been better not to have to care about these things, but hey, at least you're not installing and configuring 4-5 services to bootstrap an application.

That runs the container as a given usee, but doesn't prevent the container running some processes as a different internal user.

1. Nope, they are not pre-baked. They are built at runtime from env vars on each machine. 2. One step, setting up two vars. They can be set by a build script. Lots of things have build scripts way more complicated than this.

The only tedious thing is you have to adapt this for every image type you run.