Re: [RFC] General Resolution to deploy tag2upload
Helmut Grohne writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> Thanks for reminding. While I've seen arguments in favour of the
> weaknesses of sha1 not affecting our use much, the xz-incident changes
> the weights of those arguments for me. I am now wondering whether we can
> be more proactive about changing the hash function used by git. For new
> repositories, this seems as simple as git init --object-format=sha256.
It is an important feature of most of the best Debian git workflows
that the Debian git branch is a descendant of the upstream git. It's
been a while since I looked at the git plans for sha25 transition. Is
it the case that a whole project and all its forks needs to change all
at once? (That's a very undesirable property, obvously.)
> I note that use of weak hashes in the current tag2upload is not a
> fundamental blocker but something that I expect proponents to work on in
> case the GR passes. Would one of the proponents confirm that they see
> this as worth spending their time on (on the condition that the GR
> passes)?
I do not have any plans to try to help push git's hash transition, in
upstream git, or on Salsa. (I did have a go a number of years ago,
but my sketch of a workable transition plan was rejected by the
upstream git maintainers, who at the time instead seemed intent on
adopting an inferior model which would make transition much more
awkward.)
On the other hand, when the dependencies are sorted out, I will
certainly make sure that better hashes can be used with tag2upload,
and develop and deploy appropriate barriers to use the old hashes
where they oughtn't to be appearing.
> I think you this depends on the bigger picture. When the /usr-merge
> transition was started, it was repeatedly sold as opt-in, but it really
> was not meant as opt-in. Maybe tag2upload is similar. While the mail
> thread suggests that it does not have to be used, I wouldn't be
> surprised to be talking about terminating non-git uploads later. Once
> that happens, we'd back to one path of issuance and that one path is
> tag2upload then. It is not entirely clear whether this is the vision or
> not and to me this vision would make the argument for tag2upload
> stronger due to the reason you give.
Well, I do have a vision. However, unlike the proponents of usrmerge,
I do not intend to force my views on maintainers and users.
Personally I do see tag2upload as a next step in a more complete
Debian git transition.
I do expect tag2upload to become very popular very quickly, simply
because it's so convenient. I'm also hoping that we can get it (and
dgit) supported for uploads to securit.d.o and do something about
with-binaries uploads. I want everyone to have the option of using
tag2upload, for every upload.
If tag2upload becomes very popular, and always possible, we might make
it possible for a maintainer to declare that a particular package
ought not to be uploaded with a raw .dsc - or perhaps for a PGP key
owner to declare that such and such a key will only be used for
tag2upload uploads.
I can't see Debian abolishing the ability to upload a raw source
package any time in the foreseeable future.
> We only really have two ways of changing the upload process. Either we
> temporarily add a new process and later remove the old process or we do
> a flag-day transition. I guess that most of us agree that doing a
> flag-day transition from .dsc uploads to git-debpush would not pass
> muster. So we have little options but adding it if we agree that the
> upload process needs changes.
Quite so.
> > And we also remove the Debian Maintainer role as dak would no longer
> > know who uploaded the package? Debian is larger than only Debian
> > Developers.
>
> This is a policy aspect. When we need to revoke a key used for uploading
> this happens via keyring maintainers as far as I understand, but in
> urgent cases it is ftp master who can also deny upload rights more
> quickly than via a keyring update. In moving to tag2upload as a service
> external to ftp, we partially move this capability from ftp master to
> the entity running tag2upload (DSA afaiui). Is there a sensible way to
> leave this policy aspect with the ftp team when using the tag2upload
> service? In effect, I'm asking whether ftp could somehow provide an
> authorization oracle to be used by tag2upload.
tag2upload leaves this policy with the ftpmaster team. It uses the
archive keyrings and dak's list of Debian Maintainers.
So there is no change here.
> > If only one could use regular git instead of a custom, non-standard VCS
> > built on top of Git that makes some workflows impossible and team
> > maintenance harder by not supporting publishing intermediate work. :-(
>
> Even though the people behind the tag2upload work are the same as dgit,
> the tag2upload service has been carefully designed to actually work with
> most maintainer views. It also uploads to dgit, but I think tag2upload
> would also work if that dgit part were skipped (please correct me if I'm
> wrong about this). Hence, tag2upload provides a very important value to
> me: I then get a an authentication chain from the Debian archive signing
> key to the actual git object used for uploading. That is a property that
> I would formerly only get from using dgit and only for the dgit view.
> With tag2upload, we would be authenticating actual maintainer tags of
> maintainer histories on salsa from the archive signing key. To me, this
> is a significant step affecting my workflows in a positive way.
I think this exchange contains a fundamental misunderstanding about
what dgit is. It's not a "custom nonstandard VCS built on top of
git". IHNI what "not supporting publishing intermediate work" refers
to. The expected way for an uploader to use dgit is to replace the
upload step with `dgit push-source`, not to replace Salsa.
If there is a custom nonstandard VCS built on top of git in this
picture, it's git-buildpackage.
Helmut's reference to "the dgit part" doesn't seem to make any sense
to me. tag2upload uses dgit to convert the git branch to a canonical
form (ie, a form treesame to `dpkg-source -x`), and then build a
source package from that.
Both dgit and tag2upload publish the git information (both forms)
and the .dsc to their respective servers (*.dgit.d.o, ftp.d.o).
None of that could or should be skipped.
dgit (the program) is needed here because it's the only program that
can reliably convert every suitable git branch to a .dsc. (It often
does much of its work by calling git-buildpackage, but sadly, that is
by no means everything that needs sorting out and fixing up.)
Ian.
--
Ian Jackson <ijackson@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.
Reply to: