This breaks the current release (20.09) too, so should be backported if it's accepted.

@nickfraser did you check if the hash changed?

@SuperSandro2000, I did not, but it does build. I assumed it would fail if the hash didn't match the one provided. How do I calculate the hash? I tried the following:

$ wget https://github.com/Mattey40/poly2tri-c/archive/p2tc-0.1.0.tar.gz
$ sha256sum p2tc-0.1.0.tar.gz
ecbc8918b0784624e634bb407d67a14599c21235ad87786ee6a4735d0c015078  p2tc-0.1.0.tar.gz

which is different from the hash provided in default.nix, which had: sha256 = "158vm3wqfxs22b74kqc4prlvjny38qqm3kz5wrgasmx0qciwh0g8";. Am I calculating it correctly? Should I try different mirrors to see if I can find one with a matching hash?

I used this command and got the same hash:

nix-prefetch-url --unpack https://github.com/Mattey40/poly2tri-c/archive/p2tc-0.1.0.tar.gz

@SuperSandro2000 @nickfraser The way the sources were swapped here is problematic imo. The new GitHub repo isn't just a mirror, but a new upstream, which could author malicious releases in the future. There seems not to be any trust relationship between the original project and the new repo here.

Given that the project seems to be not under development anymore I'd suggest to

• use either the Google code archive zip file, as this is where meta.homepage points to. Don't know anything about stability of Google code archives though.
• or to add a comment to the fetchFromGitHub invocation, stating that the repo is not trusted for future releases.

I'm aware that we can't provide very strong guarantees about authorship in Nixpkgs. But just changing src to an untrusted repo should not just happen.

Also pinging the Nixpkgs maintainer @jtojnar here.

The new repo does not look active either. It just contains the same stuff google code exporter spat out.

And I would not particularly trust the original repo either (even if it was owned by the original author) – people do get hacked occasionally. If it is updated in the future, hopefully ofborg will ping me and I will do at least a brief code audit.

Or maybe GEGL will move on to a maintained library before then.

Upstream issue related to this: https://gitlab.gnome.org/GNOME/gegl/-/issues/214#note_1002908

And I would not particularly trust the original repo either (even if it was owned by the original author) – people do get hacked occasionally.

The author being hacked and having a PR with malicious code submitted (no offense nickfraser, its just for the sake of the argument) are very different thread models. We can't do anything about the first one.

As you already made a fork on gitlab.gnome.org, maybe we could just use that one?

The author being hacked and having a PR with malicious code submitted (no offense nickfraser, its just for the sake of the argument) are very different thread models. We can't do anything about the first one.

No offense taken.

@SuperSandro2000 @nickfraser The way the sources were swapped here is problematic imo. The new GitHub repo isn't just a mirror, but a new upstream, which could author malicious releases in the future. There seems not to be any trust relationship between the original project and the new repo here.

That applied to the previous repository as well. My goal was to merely put this library back into a working state, with the hash the same to ensure the PR didn't introduce any new breaking changes. I agree with all the points made above.

@nickfraser Yeah I also somewhat expected that the old repo wasn't trusted as well. Nice to have a working src again. I opened another PR to use @jtojnar's fork.

Backported in 2132156.