Control: severity -1 wishlist Control: retitle -1 want early check for server-side tainting
Hi. I was going through old bugs and found this one: > If one attempts to push a tainted history (because a package was > rejected from NEW, for example), one gets the "History contains > tainted commit" message. If the questionable history is OK, > a dgit push with --deliberately flag will fail with ... > Version 2.1-3 has already been tagged (pushed?) To be clear, I think what happened is this: 1. You (or someone) uploaded something that got REJECTed 2. Later, you made subsequent upload attempt, with in its history that earlier REJECTed upload. 3. The server regarded that as tainted, since it could see it had been REJECTed. 4. You reviewed the situation and decided that the tainted history was proper (which is a matter that this system intentionally leaves to your judgement). 5. You therefore re-tried the very same dgit push from step 2, only with --deliberately-include-questionable-history 6. This failed in the manner you describe. 7. You worked around this by deleting the tag locally and retrying the push. Sadly, I don't see an easy way to avoid this. Whether you say --deliberately-include-questionable-history is encoded in the signed git tag that dgit makes, and whose signature etc. is checked by the server. So to redo the upload with --deliberately involves making a new tag. As a matter of principle, it seems poor practice to make multiple different signed tags with the same tag name. (This is what you did in step 7.) Perhaps you as the user know that this tag hasn't escaped anywhere, but dgit cannot know that. (Even if it tries to delete the tag right after the failure.) A better answer would be for dgit to have somehow detected that this was going to happen *before* it made the signed tag. I don't see a problem in principle with the server providing dgit with a list of tainted object names, or something. But it's not trivial, and it also involves dgit replicating server-side logic. I believe dgit will have printed a message saying you should use a new version number. I think that is probably the better workaround. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
