Hello,

I just caught up on the .orig.tar thread and wanted to note to everyone:

- tag2upload final development, in accordance with the plan agreed with
ftpmaster, is proceeding nicely.
We are writing integration tests for everything, and almost have an
end-to-end test of the whole thing, with its three different nodes.

- tag2upload will improve the situation with .orig.tar because the
tag2upload server will always ensure that the uploaded source package
is prepared using an .orig.tar that dak will be happy with.
It won't matter what you're using locally for, e.g., the purpose of
feeding sbuild.

So, teams and individual maintainers that switch over to tag2upload
will be able to forget about a lot of this stuff.

--
Sean Whitton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

...

- tag2upload will improve the situation with .orig.tar because the
tag2upload server will always ensure that the uploaded source package
is prepared using an .orig.tar that dak will be happy with.
It won't matter what you're using locally for, e.g., the purpose of
feeding sbuild.

So, teams and individual maintainers that switch over to tag2upload
will be able to forget about a lot of this stuff.

As you know I have been testing dgit and reviewing tag2upload, and to
my understanding tag2upload will generate the *.orig.tar.gz tarballs
using dgit which does only uses the debian/latest branch (in DEP14
terminology) and not at all the upstream/latest nor pristine-tar
branches. As pristine-tar is not used, none of the upstream tarball
signatures will be used either.

The phrasing you used in "using an .orig.tar that dak will be happy
with" conveniently hides the details about what the disagreement with ftp-masters was. Also the GR at
https://www.debian.org/vote/2024/vote_002 was posted totally void of
any details of what the disagreement was. Would you mind sheding some
light into this?

I am all for modern workflows and I would love to be able to run "gbp
tag && gbp push" or equivalent to trigger tag2upload automation, but
perhaps not at the cost at decreasing the supply chaing security from
the point we have now? Or maybe I misunderstood still, happy to read
more about it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi and thanks for quick reply,

As you know I have been testing dgit and reviewing tag2upload, and to
my understanding tag2upload will generate the *.orig.tar.gz tarballs
using dgit

(Using 'git deborig', not dgit.)

Right, it is a separate tool in devscripts (https://manpages.debian.org/testing/devscripts/git-deborig.1.en.html).
However you wrote it for dgit and the custom workflow where you
advocate merging from upstream instead more traditional way of keeping
Debian patches clearly separated from upstream by having
debian/patches directory inside of version control.

tag2upload properly archives upstream signatures on upstream git release *tags*, which is an improvement on what we have now, for modern
upstreams.

You are correct that detached signatures on tarballs aren't uploadable. Packages with upstreams where this is more important shouldn't use tag2upload.

And by "aren't uploadable" you mean this is how you designed it and
chose to not use signatures, not that doing it would inherently would
be impossible. Would it by any chance be possible to extend "git
deborig" to check whether debian/upstream/signing-key.* exists, and if
so, generate the tarball using pristine-tar and keep the supply chain
intact? Would you accept patches that implement it?

I know tarballs are falling out of fashion and git tags are the future
- and I also advocate signing tags - but there are a bunch of big and
important projects that don't have a 1:1 mapping of git contents to
what they actually intend to go into Linux distros. For example
various test code / test data might be intentionally omitted from the
tarball, or for example documentation added into the tarball. Also not
all upstreams use git, and the in Debian the git exists only because
the maintainer created if for the sake of being able to manage the
packaging. Then there is also the fact that git hasn't migrated away
from SHA1 fully yet, while the tarball signatures can today be
actually cryptographically secure. Considering git-buildpackage has
all of this already sorted out and it works nicely, and gbp being able
to even do dual git+tarball imports to show the full audit trail, it
is not possible to do in any way. Having such supply chain security
covered by tag2upload is just a bunch of implementation work, right?

In general: I am not willing to spend time retreading the grounds of the disagreement now. I want to work on the programming work to enable this
new feature, instead. Please see the debian-vote archives at the time,
if you really want to know.

Thanks for the pointer - indeed there was a thread with hundreds of
messages, checking it now.

I just want to re-iterate that I like the idea of having DD signed git
tags trigger uploads to Debian. It has many benefits in quality and
security. I just wish we could get it without taking steps backward on
security aspects.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Mon 02 Dec 2024 at 10:07pm -08, Otto Kekäläinen wrote:

As you know I have been testing dgit and reviewing tag2upload, and to
my understanding tag2upload will generate the *.orig.tar.gz tarballs
using dgit

(Using 'git deborig', not dgit.)

which does only uses the debian/latest branch (in DEP14 terminology)
and not at all the upstream/latest nor pristine-tar branches. As
pristine-tar is not used, none of the upstream tarball signatures will
be used either.

tag2upload properly archives upstream signatures on upstream git release *tags*, which is an improvement on what we have now, for modern
upstreams.

You are correct that detached signatures on tarballs aren't uploadable. Packages with upstreams where this is more important shouldn't use
tag2upload.

The phrasing you used in "using an .orig.tar that dak will be happy
with" conveniently hides the details about what the disagreement with ftp-masters was. Also the GR at
https://www.debian.org/vote/2024/vote_002 was posted totally void of
any details of what the disagreement was. Would you mind sheding some
light into this?

Well, I can say for certain that the disagreement with ftp-master had
nothing to do with the .orig.tar stuff I am mentioning here.

So, there is definitely no "convenient hiding" going on.

I think your use of "convenient hiding" may involve assuming bad faith
on my part. I would ask you not to do that.

In general: I am not willing to spend time retreading the grounds of the disagreement now. I want to work on the programming work to enable this
new feature, instead. Please see the debian-vote archives at the time,
if you really want to know.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmdOtn8ZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQEZTD/4t6lHAUUi2PAQFj6Tpsu3u 7ewuLMVUhoqiQOxKL1Hvmsir4QGlZAkZ7rGyXRpS/lxzKvTxVFezYHsXZ9TvlZKr 5Cw+AGNP2MYnQwxxRdavctZx6aMiACqdjAQ2alPHAMAbdlKoOVurlqHGocezQP0P YJtGcQfs60ufTZmug8+yh5w7z1rx9SffG1ZpXhILcXFpAkrJmzdpiVVp9RwQBQgQ DgFUconpfTIywU7/0eqAVdc11prR37KBV3tfLxzEO9CHotyDdvkmJIWml5AEagQN sb61H2VmwE5sZFM6Wz+pYWO1J9225aXvq9vWbWwlKU17FMR/Gue8+gDiKF3blGPw PLVpBIk1iW43LCUmwfzGLTWxw6X4gGfrMTjAI+T6nt24BLXtVN/VF3SAoV3NlJm5 56C8PQCWBXhDNcjlHf3VUFPFHMKgC7uzh3TeernyjDuliUPqtdRS0k4Z63nwPeLl imJcdjXDLWRIkHFR6CL6azheEfwCREpNjxxeCb5LSDwxxIyAHMKkhKEfLJKpcNiE ypdjEvKe12A9Wh2UiirS1C943X8RMrn8w8udI2rhFWxdoeKblOSDn9PbgE5JpimE 9mBptfjXzu5lOOXiECEM1bWTexDo/Wncko9TDummg1JSzVXaViYOJ/xyE+jKoBV+ OhcItE470JNw0tAy4A4ILA==p1cL
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

Sean Whitton <spwhitton@spwhitton.name> writes:

Hello,

On Mon 02 Dec 2024 at 10:07pm -08, Otto KekΣlΣinen wrote:

As you know I have been testing dgit and reviewing tag2upload, and to
my understanding tag2upload will generate the *.orig.tar.gz tarballs
using dgit

(Using 'git deborig', not dgit.)

Will tag2upload (or git-deborig) be improved to allow upload of the
proper upstream orig.tar together with its signature?

You are correct that detached signatures on tarballs aren't uploadable. Packages with upstreams where this is more important shouldn't use tag2upload.

That seems like a serious limitation to me.

/Simon

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZ07ZiBQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFonL1AQCEk4xIIGNBgVPTU0JY98DUEBRXbnAo E4VNTecHpfpmzQEAnTt9cDkS+La2o5qapCZNIgQg0dRSHXFuVbYVzXwc7A4=UIKt
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Tue 03 Dec 2024 at 11:12am +01, Simon Josefsson wrote:

Sean Whitton <spwhitton@spwhitton.name> writes:

Hello,

On Mon 02 Dec 2024 at 10:07pm -08, Otto Kekäläinen wrote:

As you know I have been testing dgit and reviewing tag2upload, and to
my understanding tag2upload will generate the *.orig.tar.gz tarballs
using dgit

(Using 'git deborig', not dgit.)

Will tag2upload (or git-deborig) be improved to allow upload of the
proper upstream orig.tar together with its signature?

Possibly, yes, but it's not a priority for the current design. We're
targeting packages with git-native upstreams, where there is no such
thing as "the proper" upstream orig.tar. E.g. GitHub upstreams with
tarballs generated by their releases page, but signed tags as primary.

--
Sean Whitton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Tue 03 Dec 2024 at 12:04am -08, Otto Kekäläinen wrote:

And by "aren't uploadable" you mean this is how you designed it and
chose to not use signatures, not that doing it would inherently would
be impossible. Would it by any chance be possible to extend "git
deborig" to check whether debian/upstream/signing-key.* exists, and if
so, generate the tarball using pristine-tar and keep the supply chain
intact? Would you accept patches that implement it?

I don't think I can give a quick answer to that. There are a lot of
details. Let us get the first version deployed first :)

--
Sean Whitton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)