Hi!

The git-buildpackage config includes these two attributes:
- upstream-vcs-tag
- upstream-signatures

See in context at e.g.
https://salsa.debian.org/debian/dh-make/-/blob/master/lib/debian/gbp.conf.ex

I was wondering if Guido, as the git-buildpackage maintainer was open
if these two fields could be read from debian/upstream/metatada
directly? These fields are not really something that is decided by the
gbp users' preference, but attributes that depend on what upstream
does or does not do.

Also, as these fields don't exist in DEP-12 yet, I was wondering if
Jelmer as the owner of https://dep-team.pages.debian.net/deps/dep12/
would be open to add these fields there?

This would feel like a very natural place to document how and where
upstream publishes releases.

See also related https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1111114.

I agree this would be useful to support as an upstream metadata field.

This seems to be more of a git workflow policy rather than an upstream metadata field.
If upstream signs releases, the presence of a debian/upstream/signing-key.asc
and configuration in debian/watch (pgpsigmangle) indicates whether the presence
of the signature is mandatory. I'm also hesitant of bringing information
about the upstream *tarball* into debian/upstream/metadata, as that is a role
debian/watch already plays.

(Maybe you mean signing of upstream tags rather than upstream tarballs? That is
not what "upstream-signatures" in git-buildpackage appears to be about based
on my reading of https://salsa.debian.org/debian/dh-make/-/blob/master/lib/debian/gbp.conf.ex)

Cheers,

Jelmer

Great!

Please see Bug#1111115 and new uscan v5. The debian/watch might become
obsolete and go away if the metadata is available in other files.

No I meant this gbp option.

There is currently no gbp option to check that tags are signed. That
is however a good remark, and the name of the field could be clarified
if made available in debian/upstream/metadata. Perhaps
'release-signatures: yes' and 'vcs-git-tag-signatures: yes'.

Can we keep these (upstream-vcs-tag, upstream tarball details) as separate
discussions in that case? Upstream VCS information is already in
debian/upstream/metadata and upstream vcs tag information isn't stored
in any standard debian/ control files yet so that seems like a much more
s natural fit. I'd rather not tie the fate of these two together.

There is a lot of other data about the upstream tarball(s) in debian/watch,
and pre-existing tooling and debian/watch files that use it.
Signatures are just a one part of that, and I don't think it makes
sense to *just* move the signatures to debian/upstream/metadata. E.g.
the following debian/watch bits are relevant:

FWIW I think there is value in separating out the information about the
canonical upstream source location from the configuration on how to generate
a debian .orig.tar.gz (which I think is something that debian/watch
currently mixes), but also expect it is a much larger discussion
to have.

Cheers,

Jelmer

Hi all!

+1 for this

One can already figure this out by checking the existence of
debian/upstream/signing-key.asc. Why duplicate this here?

Can't uscan do what I mentioned above? i.e., set the default value of
Pgp-Mode based on the existence of such file

Bye :)

On the question if this gbp.conf option is really needed or if use of
signatures can be implied by the key:

I wonder if we really can make this assumption?

I think we can assume for sure that this file contains one or more
keys that the Debian maintainer has checked and chosen to trust as
being legit keys upstream uses for signing. But can we also assume it
means that these keys are only for checking upstream tarball
signatures, and not e.g. git commit or tag signatures? And that if
this file exists, that it would mean that upstream always publishes
signatures on every release immediately starting from the first new
upstream import after this file was created?

Maybe we can assume so, I am not sure. But we should maybe have it
recorded as a design decision and assumption in the Debian Policy.

Well, that's the upstream key relevant for this package. According to
<https://wiki.debian.org/debian/upstream#debian.2Fupstream.2Fsigning-key.asc>,
it's used only by uscan. If it isn't used to verify upstream code
signatures, it shouldn't be there.

If upstream signs tags with a specific OpenPGP key, and I'm verifying
tags, I'll put that key there. Same with tarballs.

Typically, tarballs and tags are signed with the same OpenPGP key
anyway. Sometimes, though, tags are signed with SSH keys, but we don't
support that anyway.

But in any case, gbp's upstream-signatures option specifies whether to
check signatures, it's a boolean. How would it help here?

One reasonable behaviour for tools which use d/upstream/signing-key.asc
would be to enable signature checking by default if the file exists,
fail if the signature does not verify, and warn if the signature is
missing (or fail here too, maybe).

In any case, I think I'm not understanding your concerns, nor how a new
d/upstream/metadata field would help :/

To make any decisions here we would need the input from Guido, who is
for sure very busy at the moment, but hopefully can comment on this
some day.

Hi,

I didn't yet get what is the upside of moving things is and what the
proposals for

- how pattern replacement would work (afaik there's no item in
  upstream/metadata that needs it) but mabye i missed it?
- how the user would specify which one to use (e.g. when to prefer
  gbp.conf over uptream/metadata or how to disable it in general

So from gbp's view it is the simplest to leave things as is for now
as we don't gain anything for the users but have yet another migration
to take care of.

I'm certainly not against it but someone would need to ensure safe and
comfortable migration for users.

Cheers,
 - Guido

If we can agree to have the description of upstreams in this one file,
we can avoid duplicating the same configuration of for
git-buildpackage and uscan in two different places. The latest uscan
has started to read debian/upstream/metadata if there is no
debian/watch, and is likely to rely to on that file for signature and
tag checks in the future if it was possible, meaning if Jelmer agrees
to extend DEP-12 to have new fields in the upstream file and you agree
that a future version of gbp could read the values from there if they
are missing from gbp.conf. Sure, there is no gain immediately for
git-buildpackage but there is a gain in standardizing gbp practices so
all tools doing similar things can have a single source of truth
describing what the upstream is like.

I'm sorry to say that I have two qualms about this.
(Writing to #1111115 re git-buildpackage and #1111114 re uscan.)

Firstly, the spec for DEP-12 doesn't actually contain these fields yet
and discussions are ongoing.  But, more fundamentally:

YAML is a very bad format.  It is extremely complicated, has
bizarre footguns eg the Norway problem [1] and implementations have a
poor security record.  We don't want every packaging tool that
manipulates upstream git information to have to run a YAML parser.
IMO it is a shame that DEP-12 used YAML rather than deb822. [2]

I am very much in favour of having the upstream tag format information
in a central place rather than a tool-specific file.  But I don't
think DEP-12 is the right place.  (And we should drive this by
implementing first in places like uscan and gbp and doing the design
discussions afterwards.)

I think probably what we should have is a new DEP for a single
additional single-stanza deb822 file that exists only in the source
tree and is ignored by dpkg-source, with a list of fields in that DEP.
It wouldn't be restricted to upstream metadata.  It could contain
structured information about maintainer packaging workflows, for
example.  (Some fields might promote from this source-tree-only file,
if and when we discover that they need wider use.)

Thanks for your attention.

Ian.

[1] https://www.bram.us/2022/01/11/yaml-the-norway-problem/

[2] Other human-friendly data languages are available.  I'm quite a
fan of TOML, personally.  But in Debian we usually use deb822.
deb822, for all its quirks, is easy to parse, and we have much good
tooling for it.