Adam Majer <ad...@zombino.com> writes: > On 7/7/24 21:53, Russ Allbery wrote:
>> I consider it an ethical obligation as someone who works in security to >> object whenever people make these types of absolute statements about >> security properties. Security is almost always a trade off. You can >> usually get more security by trading off functionality, up to the >> obvious end point of securing a computer by turning it off. The best >> point to occupy on that trade-off curve is a hard question that always >> involves more factors than only security. > It was not an absolute statement, but simply a consequence where I tend > to trust NIST recommendation over handwaving arguments. This is > especially true since I'm no cryptographer and have to rely on other > experts for these recommendations. That makes very good sense to me. Since you don't have expertise in this field, that's exactly what I would recommend you do. That is definitely the safest approach. Since I do have expertise in this area, my analysis was more complex than trying to extrapolate from NIST guidance. > Furthermore, did you read what was written in the Bitcoin repo link? > It's simply adding a hash to the signed tag. Since this proposal here > for push-to-upload is to use a script to generate the tag anyway, adding > additional hash to the message is kind of a "no-brainer" --- it doesn't > cost anything! It does cost something: it requires custom code and local configuration and requires us to use Git differently than everyone else uses Git. You may or may not care about that cost, but it's a cost. I didn't get into this because I think it's beside the point, but since you're asking explicitly: I am also quite dubious of that specific approach because it's adding an additional hash to only one specific type of Git object, piecemeal, in a helper script that seems to only be used by that one repository (and which they seem to have subsequently dropped). If we're going to add richer hashes in a custom layer on top of Git, we should use git-evtag or some other similarly comprehensive solution that has thought through all of the implications, not try to apply hacks and bandaids like that. git-evtag was discussed earlier, so I won't go into the arguments there again. > Anyway, I've been forwarded this commit in git upstream recently. > https://github.com/git/git/commit/6ccf041d1d73d69d05118f739c80f83c86caf0d6 Great! Hopefully this will mean GitLab will add support in the near future. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
