(dropping all CC, focusing on the content)
Le vendredi, 28 juin 2024, 08.32:43 h CEST Ansgar ๐ a รฉcrit :
> I'll expand on the here slightly for your benefit:
>
> $ git clone https://salsa.debian.org/rra/tf5.git
> [...]
> $ apt-get source tf5
> [...]
> $ rm -rf tf5/.git tf5-5.0beta8/.pc
> $ diff -Nur tf5 tf5-5.0beta8; echo $?
> 0
>
> If one is really bored:
> $ (cd tf5; sha256sum $(find . -type f | sort) | sha256sum -)
> 8d7820471fb44382a0c752319906064a1276ff18873fb4730dec1319aaf7b459 -
> $ (cd tf5-5.0beta8; sha256sum $(find . -type f | sort) | sha256sum -)
> 8d7820471fb44382a0c752319906064a1276ff18873fb4730dec1319aaf7b459 -
>
> I will leave it as an exercise to you to compare the output and to
> reason about results of different ways to compare both trees.
It looks to me that you have taken (by choice, or by chance) an example that
too conveniently fits what you want to demonstrate: in which the git
repository and the .dsc are treesame. They are often the case, but not always,
as documented in the various git workflows' documentation provided by dgit.
The salsa repo can be patches-applied and not have the debian/patches files,
they'd be created at dgit push-source time.
If I understand your position correctly (please correct me if needed): you
(with a ftpmaster hat) would like all uploads to come with a signed artefact
of hashes corresponding to the set of files as represented by the current
Debian source package format, as accepted by the archive today. And you would
like this artefact's signature be a signature by the human uploader. Did I get
this right?
If I understand dgit and tag2upload correctly, in the cases where the git
repository is treesame to the source package (patches-applied, with debian/
patches file stored in git, as pointed by a tag), this artefact has the exact
same cryptographic value as the git tag, pointing to the git tree, pointing to
the git objects (modulo the SHA-1 vs SHA-256 hash functions choice, which was
clarified elsewhere). One such example is the tf5 source that you used as
example. In that case, would you still want a outside-of-git hash, signed by
the human uploader?
In the cases where the git repository is _not_ treesame to the source package
(patches-applied, but debian/patches not stored in git), uploads are already
possible via dgit push-source (and the human upload signature covers the
source package as it goes in the archive, not the git tree). In that other
case, would you still want a signed artifact of hashes, signed by the human
uploader? And do we both understand that this means that some git repository
layouts would hence not be possible to be uploaded via tag2upload (because it
needs a much heavier git tag client, that builds the final source package,
hashes its contents, and creates the git tag)?
(I have refrained from formulating the questions as explicit to the ftpmaster
delegates "as a team", I merely want to understand Ansgar's position first ).
--
OdyX
