Ihor Radchenko <[email protected]> writes: > Daniel Mendler <[email protected]> writes: > >>>> https://github.com/minad/doom-on-emacs/blob/9d5929335c4080699a2daa153ace2996c905008a/Makefile#L17 >>>> >>>> This way you would get similar guarantees. >>> >>> That would correspond to setting `package-check-signature' to t in the >>> patch. >> >> No, that's not exactly the same. An attacker who compromises the ELPA >> build server can distribute a manipulated tarball with a valid >> signature. You are protected against this if the valid hash is >> hard-coded in the download script. But of course in such a scenario we >> would have bigger problems since the ELPA repositories might have been >> compromised as well. > > Well. I do not think that we should go that far in being paranoid.
My point is not about being paranoid, but about being precise when talking about security-related issues. Note that in my link above the tarball is pulled without user intervention, so in this case I rather prefer the safe solution with the explicit hash check. > If ELPA is compromised, we are doomed anyway. Yes, likely. But we can at least try to make it easy to detect compromise in order to act as soon as possible, e.g., if many users enable `package-review-policy`. > IMHO, the increase of maintenance burden by the need to keep sha up to > date is not worth it. I disagree. When you update the URL to the tarball (or the version) you can also update the hash. This is common practice for instance when updating package recipes in distributions, e.g., in Guix. Daniel
