> what Immich are doing is extremely dangerous
I've read the article and don't see anything dangerous, much less extremely so. Care to explain?
> what Immich are doing is extremely dangerous
I've read the article and don't see anything dangerous, much less extremely so. Care to explain?
They're auto-deploying PRs to a subdomain of a domain that they also use for production traffic. This allows any member of the public with a GitHub account to deploy any arbitrary code to that subdomain without any review or approval from the Immich team. That's bad for two reasons:
1. PR deploys on public repos are inherently tricky as code gains access to the server environment, so you need to be diligent about segregating secrets for pr deployments from production secret management. That diligence is a complex & continuous undertaking, especially for an open source project.
2. Anyone with a GitHub account can use your domain for phishing scams or impersonation.
The second issue is why they're flagged by Google (he first issue may be higher risk to the Immich project but it's out of scope for Google's safe browsing service).
To be clear: this isn't about people running their own immich instance. This is about members of the public having the ability to deploy arbitrary code without review.
---
The article from the Immich team does mention they're switching to using a non-production domain (immich.build) for their PR builds which does indicate to me they somewhat understand the issue (though they've explained it badly in the article), but they don't seem to understand the significance or scope.
> This allows any member of the public with a GitHub account to deploy any arbitrary code to that subdomain without any review or approval from the Immich team.
This part is not correct: the "preview" label can be set only by collaborators.
> a subdomain of a domain that they also use for production traffic
To clarify this part: the only production traffic that immich.cloud serves are static map tiles (tiles.immich.cloud)
Overall, I share your concerns, and as you already mentioned, a dedicated "immich.build" domain is the way to go.
> This part is not correct: the "preview" label can be set only by collaborators.
That's good & is a decent starting point. A decent second step might be to have the Github Actions workflow also check the approval status of the PR before deploying (requiring all collaborators to be constantly aware that the risk of applying a label is similar to that of an approval seems less viable)
The workflow is fundamentally unable to deploy a PR from a fork, it only works for internal branches, as it relies on the container image being pushed somewhere which needs secrets available in the CI workflow.