Yeah, I realized this earlier but forgot about it. I think this is a mild security problem: salsa seems to leak tags pushed to private git repos to the tag2upload service. The webhook configuration should not trigger for private repositories, I think? I doubt anything on salsa could be assumed to stay private, but it seems like a design concern. I don't think the tag2upload service should change, but the webhook on salsa should be fixed to not send non-public tags in the first place.
I tend to use personal forks on salsa for development reasons. Normally these are always public, but sometimes they aren't. I changed my gsasl project to public now. Maybe it was set to private to experiment with a security sensitive upload or something like that, I don't remember. In other projects I tend to experiment with force pushing tags over and over until I'm happy, and I suspect this will work badly with tag2upload if I were to include the magic cookies. I have not ever needed this, but I can see that sometimes you may want that, and having the ability to do that on a private fork may be a feature. As for UX, I think git-debpush pushes to the "right" git remote, at least in my experience. Which sometimes actually isn't the "real" Debian git repository (i.e., Vcs-* URL) but my own private fork, depending on how I checked out the branch. I haven't been surprised by its behaviour, and have learned to use --remote=origin when in doubt. It doesn't really matter which remote "wins" the tag2upload race, since I push the same tag to both places. The tag2upload service COULD check that the Vcs-* URLs match where the tag is being pushed from, and refuse to upload tags from other git repositories, but I also think that these URLs are sometimes just wrong and you still want the tag to trigger tag2upload anyway. This kind of origin authentication is just silly and fragile anyway. Btw, is [email protected] publicly archived as a mailing list? /Simon Ian Jackson <[email protected]> writes: > Ian Jackson writes ("Bug#1111319: git-debpush should somehow perform https > repo availability check"): >> Watching the t2u logs I saw another job failed because the tag was >> 404 where the whole repository was also 404, probably because the repo >> permissions were misconfigured. This has happened several times now. > > The most recent one was job 538, where the web ui reports > > tag fetch failed: problem at forge: fetch tag info: status: HTTP > status client error (404 Not Found) for url > (https://salsa.debian.org/api/v4/projects/99410/repository/tags/debian%2F2.2.2-2) > > The repo URL is > > https://salsa.debian.org/jas/gsasl.git > > which still seems to be unreachable. > > I see that now there's gsasl 2.2.2-3 which succeeded. That seems to > have been partially luck, because that same tag was pushed to both of: > > https://salsa.debian.org/xmpp-team/gsasl.git job 546 > https://salsa.debian.org/jas/gsasl.git job 547 > > within about 10s. When 547 arrived, the service manager saw that it > was a duplicate (by git object id I think), and eventually when 546 > succeeded it decided it didn't need to do 547. > > I think the service is operating correctly here, but I filed #1111319 > about the fact that git-debpush didn't push the upstream tag for your > earlier attempt. > > I'm writing because I think you should be aware that the permissions > on your personal fork are probably-wrong: I could be wrong, but > private personal forks are not a usual practice in my experience. > > Also, do you think git-debpush made a mistake to when it pushed the > earlier tag to your personal fork, rather than to the team repo? > Thanks in advance for helping us improve the git-debpush UX. > > Regards, > Ian.
signature.asc
Description: PGP signature
