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.

I think git-debpush could detecct this, if we're prepared to give it
salsa-specific information.

In particular, if the remote is
  git@salsa.debian.org:user/project
then we should check that
https://salsa.debian.org/user/project.git
is reachable via git without athentication.  Or something.

Empirically:

 git-ls-remote  https://salsa.debian.org/dgit-team/dgit.git ''
 # exit status 0, printing nothing

 git-ls-remote  https://salsa.debian.org/dgit-team/no-such-repo.git ''
 # prompts for a username
 # same behaviour for a repo that I think exists privately

Alternative approaches (eg querying the gitlab API) might need more
much-more-gitlab-spdcific information in git-debpush.

To avoid adding latency, this should be done in parallel with the git
fetch.

Ian.

Hello,

I think it is okay for the checks to make use of forge-specific
information like this, so long as we abstract it properly.  We'll want
to be able to easily add Debian's next forge.
to avoid actually prompting, and possibly GIT_ASKPASS=/bin/true.

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 git-debpush@p.d.o publicly archived as a mailing list?

/Simon

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

Simon Josefsson writes ("Bug#1111319: Permissions on your gsasl fork on salsa (was Re: Bug#1111319: git-debpush should somehow perform https repo availability check)"):
is OK.  In fact, salsa is sending a great deal more data to our
webhook than it ought to:
https://salsa.debian.org/salsa/support/-/issues/494
https://gitlab.com/gitlab-org/gitlab/-/issues/558030
But the HTTP transactions are secured via TLS and the tag2upload
service manager that is receiving them has quite a good level of
security.  So yes, it's receiving some confidential information, but
this is only available to Sean and me (and to DSA admins), via the
manager's on-host debug log.

As for the public log: tags pushed to private repositories will be
reported in the public log only if they contain the "[dgit
please-upload]" instruction.  (And even so the only public information
is the timestamp, repo URL, source package name, and version number.)

If you want to discuss this more, this bug report probably isn't the
right place.

OK, just so long as that was intentional.

OK, good.  So I think the check I'm asking for in this bug would sort
this out.

No.  We've been using un-archived private email for "support" type
emails, and the BTS for things where we've identified a possible
improvement in git-debpush and/or the tag2upload service.

Thanks,
Ian.

We believe that the bug you reported is fixed in the latest version of
dgit, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1111319@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ian Jackson <ijackson@chiark.greenend.org.uk> (supplier of updated dgit package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 05 Sep 2025 10:16:53 +0100
Source: dgit
Architecture: source
Version: 13.14
Distribution: unstable
Urgency: medium
Maintainer: Debian tag2upload Delegates <dgit-owner@debian.org>
Changed-By: Ian Jackson <ijackson@chiark.greenend.org.uk>
Closes: 1111319 1111357 1112040 1112134
Changes:
 dgit (13.14) unstable; urgency=medium
 .
   tag2upload service:
   * tag2upload: On source package discrepancies, print a diffstat
     and instructions for a local repro.  Closes: #1111357.
 .
   git-debpush:
   * Check that the repo is accessible via http.  Closes: #1111319.
   * Support --quilt=single.
   * Print the name of the tag we make.  Closes: #1112040.  [Sean Whitton]
 .
   dgit:
   * Improved output on quilt and dsc discrepancy errors:
     show and explain a diffstat, and use the same logic in each case.
 .
   Documentation:
   * More man7 European Portuguese translations.
     Closes: #1112134.  [Américo Monteiro]
   * git-debpush(1): Mention that git-debrebase needs --quilt=linear.
   * git-debpush: Tidy quilt mode information in manpage and usage message.
     [Ian Jackson and Sean Whitton]
   * tag2upload(5): Specify how pristine-tar metadata item will appear.
     [Andrea Pappacoda and Ian Jackson]
 .
   Internal and supporting changes:
   * CI: Fix gitlab-ci-check-sob to work in contributors' forks.
   * tests: t2u-integration: Provide a user_id in json, for new t2usm.
   * using-these: Put absolute directory on PATH; fixes for programs that cd.
   * git-debpush: Code comment fixes.  [Sean Whitton]
Checksums-Sha1:
 0c62613fdb9f017168386c861c97d5fc72ae7df6 2519 dgit_13.14.dsc
 1eba6e09062e25c78f53ddf8f47d0a17ceeed617 823309 dgit_13.14.tar.gz
 6ce05ac1509dda61c53fe86cd2af784f44437a20 1061176 dgit_13.14.git.tar.xz
 16e8df5b16c2232074fb246647e9c2e32a7799e6 18034 dgit_13.14_source.buildinfo
Checksums-Sha256:
 c397c649c14d25e14364283d8d1bd72857a7c0e87f1f5bfa81df01e4cc197ba5 2519 dgit_13.14.dsc
 186de1c81bc297eb70b6de63cab6648a238860cc2c17ee7db027b909d34d5766 823309 dgit_13.14.tar.gz
 038bbd89bb1db7b0154b801966234e984305cc018d9298ce437c7a61c79f2c85 1061176 dgit_13.14.git.tar.xz
 d88c08a07c3e7f11dfe7c3702a4f9cc6a77694820ebc81ac40563e579427f1b2 18034 dgit_13.14_source.buildinfo
Files:
 b4d419682158cb95d3e2ea20707d41c5 2519 devel optional dgit_13.14.dsc
 d451a3706e27299daabd20697901fc36 823309 devel optional dgit_13.14.tar.gz
 6ac77f7fc5cf51aceead90e98fcd0b75 1061176 devel optional dgit_13.14.git.tar.xz
 f0f0e21d7f99173062cc3fc57eb45f3d 18034 devel optional dgit_13.14_source.buildinfo
Git-Tag-Info: tag=2b6eac37e594982e1806038ce543574bf0a82970 fp=559ae46c2d6b6d3265e7cba1e3e3392348b50d39
Git-Tag-Tagger: Ian Jackson <ijackson@chiark.greenend.org.uk>
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEN02M5NuW6cvUwJcqYG0ITkaDwHkFAmi60BQACgkQYG0ITkaD
wHnI3xAAkrvRSLIP6iV9u03Bp/vgNQAvuqXCG/6QiWZZOsQ8bAF0RCN0C1Y+YivW
CsKdhSugNLMqHnFEzjbnTuTTP6U5vlrtTTE132kSP+vRORRlIwqfLRoyGSb/L9+s
Jb8Ozxiql3MaI9YE2Xi9QIAAiTgExb1ptqu5L8hbJXjwBpBHwV6oBa7/00oR5J94
BZT4V4iiKpM1V9KVVm25kmnMvhkR6IL4PkUPhrAy49tHSnQUiCjcHQiZ4UBkH8+C
raSK8c/dVs51sARnctT80Dh3mFqcM1MTFSsJtsrfFA/frS8bsXNKCdAM57ui7RiI
T51yANTuhW5cjhcifjyv6ijzNqxqTDr+LCZNyd/jvWc0Y43J/AvuEmPRuySyPwXy
T34C2pfVSmsKWZw+G49avESRqDXllUToFsq4JIkSU1gUL/SPZIEHKS483p7PBcMT
EWyUR36RDQU0SMgRPjsi0NGT97cOSgDq0ZbFdPSmiqaHPQqsutiZd7FKZyEJuvXA
/W8bfGJl0+sOByBW3skof+0YLBAWGPzzfJfzg+WOc7BndEO4Xx2lkSdBw+yrRAyl
eM8KXeBvTbNp/wHMvcXCOmy2MrrHMlHOwUDRD+bT2Su0iDNsN+RQEv9VilEA3GJe
HdubnasLPkBy9Gc3a70PPmTYdfb4+V/6LX7niHsEYjf/LyIrKyc=
=7i9R
-----END PGP SIGNATURE-----