Ansgar 🙀 <ans...@43-1.org> writes: > As I said several times before: the implementation has known security > bugs (unless you fixed them). But I guess this is going to get ignored > again anyway...
Could you describe what known security vulnerabilities you believe exist, particularly if they are things that aren't already noted in the security review I posted? It's not very helpful to vaguely refer to security vulnerabilities without being specific and showing the analysis that leads you to that conclusion. This was one of the frustrating things that happened in previous debian-devel discussions as well. > In addition it reintroduces trust in weak cryptographic hashes which > effort was spent to remove. I think this concern is significantly overblown and attempted to explain precisely why I believe that in my security review. I'll also point out that using SHA-256 hashes in *.dsc files does not somehow mean that Debian is no longer trusting SHA-1 hashes, given that most Debian development is done in Git using SHA-1 hashes. I think we're all agreed that switching Git to SHA-256 hashes would be great and, once that work is done, we should take advantage of it, including in tag2upload. > And we also remove the Debian Maintainer role as dak would no longer > know who uploaded the package? dak knows who uploaded the package under the tag2upload proposal. That information is included in the signed source package as described in the specification. > If only one could use regular git instead of a custom, non-standard VCS > built on top of Git that makes some workflows impossible and team > maintenance harder by not supporting publishing intermediate work. :-( What "custom, non-standard VCS" are you talking about? I am not aware of any such thing in the tag2upload proposal. The source package builder supports most common ways that Debian stores source packages in Git. (There is quite a lot of variety here, so it doesn't support all of them, but I think the common ones are reasonably well-covered.) The Git tags have to contain some structured metadata because an unstructured Git tag doesn't provide enough information to securely establish the intent of the tag, and thus there is a tool to conveniently make them. If you want to manually create a signed Git tag following the protocol, you can. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
