Upstream of src:mariadb-mysql-kbs, in addition to signing their
release tags, also publish *.tar.xz.asc detached signatures in their
releases at e.g.
https://github.com/williamdes/mariadb-mysql-kbs/releases/tag/v1.3.0

Old v4 format for debian/watch works fine with this config:

version=4
opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%, \
 pgpsigurlmangle=s%archive/refs/tags/(v[\d\.]+)\.tar\.gz%releases/download/$1/$1.tar.gz.asc%"
\
https://github.com/williamdes/mariadb-mysql-kbs/tags
.*/v?(\d[\d.]*)\.tar\.gz debian

However, using the new v5 format and GitHub template it is not
possible to download the detached signature with any value passed to
Pgp-Sig-Url-Mangle because the GitHub template downloads the releases
from an URL under the domain api.github.com, while the signature is
for download at
https://github.com/williamdes/mariadb-mysql-kbs/releases/download/v1.3.0/v1.3.0.tar.gz.asc

In the old v4 format it was possible to convert
https://github.com/williamdes/mariadb-mysql-kbs/archive/refs/tags/v1.3.0.tar.gz
with manging into
https://github.com/williamdes/mariadb-mysql-kbs/releases/download/v1.3.0/v1.3.0.tar.gz.asc

In the new v5 GitHub template now manging can turn
https://api.github.com/repos/williamdes/mariadb-mysql-kbs/tarball/refs/tags/v1.3.0
into https://github.com/williamdes/mariadb-mysql-kbs/releases/download/v1.3.0/v1.3.0.tar.gz.asc


I also tried other variations on the v5 syntax but didn't get any of
them to work. If this is a user error, please close this bug with an
documentation update to man page
(https://manpages.debian.org/unstable/devscripts/uscan-templates.5.en.html#Github)
showing example of using GitHub template with no signatures, with
signed git tags, and with detached signatures in the GitHub "release".

Le 19/10/2025 à 02:36, Otto Kekäläinen a écrit :
can use this watchfile which works:

Version: 5

Source: https://github.com/williamdes/mariadb-mysql-kbs/tags
Matching-Pattern: .*/v?(\d[\d.]*)\.tar\.gz
Filename-Mangle: s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%
Pgp-Sig-Url-Mangle:
s%archive/refs/tags/(v[\d\.]+)\.tar\.gz%releases/download/$1/$1.tar.gz.asc%

The above is no longer the GitHub template. What is the correct syntax
for the GitHub template to have the signature verified? Or is it by
design that the GitHub template is not compatible with any kind of
signature checking at all?

If so, we should maybe not encourage its use as it will make Debian's
supply-chain security posture less than before.

Le 19/10/2025 à 07:41, Otto Kekäläinen a écrit :

The GitHub template uses api.github.com and not the human readable web
(to workaround pagination), so in this particular case you can't use it.

Le 19/10/2025 à 08:16, Yadd a écrit :
 >
 > The GitHub template uses api.github.com and not the human readable web
 > (to workaround pagination), so in this particular case you can't use
 > it.

One option is to modify uscan to add a "Github-Mode: web" option into
the Github template  to permit to use "Pgp-Sig-Url-Mangle".

Would it be an acceptable solution ?

What about having one template GitHub with no signature checking (the
one now, as it can't do either git tag signatures nor detached
singatures), and then one GitHubSignedTags and one
GitHubSignedReleases?

I think the whole benefit of templates is to avoid individual
maintainers managing various filename and url manglig as on specific
forges the URLs are all standardized. By selecting the correct
template everything would be automatic for that forge+signature type.
Would that make sense?

Le 19/10/2025 à 08:26, Otto Kekäläinen a écrit :

Good idea, I propose also to automatically switch to
GitHubSignedReleases when Pgp-Sig-Url-Mangle is used

Note that the GitHub pagination will break some downloads if many
ignored tags are in top of the list

control: severity -1 normal
thanks

so how is this serious? Is anyone forcing you to use v5?

Sounds good to me!

I have been recently playing with signed stuff and the Github template, and
seems that things are more diverse that I expected. So, It is unclear to me
that a separate GitHubSignedTags template is going to be as useful as
expected.

In particular, I played with [#1120727 devscripts: watch 5 support for
github libarchive] and, apart from a code reorganization to make things
easier to me, required changes to Github template were not that drastic.
However, that did not help with #1118381 or 1118383.

It is unclear to me that there is an easy and robust way to trigger a
given handling from pgp options. I am afraid template might just deal
with "pseudo-standard" cases, but require at least fine-tuning for other
cases.

El lun, 20 abr 2026 a las 0:55, Agustin Martin (<agmartin@debian.org>) escribió:

Hi,

Did not reach something general working for detached signatures in
both maria-db and libarchive, but wrote something that can help with
'mode=git' and 'pgpmode=gittag'. I am attaching the current result of
my tests as a proof of concept. Part that helps with libarchive is
ugly and I think should not be used in that way, since it does not
work with maria-db, but the other things may help.

First there is a template reorganization with three sections. In first
one some variables are defined with defaults for the general case.
Second section tries to modify those defaults for some particular
cases. Finally, in third section assignations are done.

In second section I also set 'mode=git' if 'pgpmode=gittag' and was
not previously set. I think this is reasonable. This part seems to
work (only a warning "warning: refs/tags/v1.3.0
ffa336279080e519c8d9cc7894a444f3476c369f is not a commit!", apparetly
harmless)

Part using 'pgpmode=auto' for libarchive is anything but generat (so
IMHO is not ready) but adding it in case is useful. Some discussion
about this last thing. I have checked both libarchive and mariadb for
detached signatures support and they are different and difficult to
deal with a single set of rules. I do not know how many different
layouts we may have for detached signatures. If only a few and clear
enough, we could use a new template parameter (something like
'Detached-Signature-Layout') to handle one or other. Did not have time
to check more packages with detached signatures.

Anyway, I think that the change in structure is good (and would save
having another template for signed stuff), as well as the 'mode=git'
stuff. If you agree I can prepare a MR with only this part (leaving
detached signatures outside).

Hope this helps,

Hi,

I have opened a MR with this part, stripped of non directly related things
(and fixed, as original file was buggy),

https://salsa.debian.org/debian/devscripts/-/merge_requests/649

Regarding detached signatures, I have been looking at some packages, and
seems that there are at least two layouts, one is what happens with
libarchive, and other what happens with maria-db (may be with variants),
but did not go into details, so may be more complex.

As previously commented, I would suggest a new Github.pm local property,
"Detached-Signature", where values for defined layouts trigger different
behaviors. Currently I have only made it work for libarchive (and only for
'Release-Only: yes), which seems to be the more frequent case, from the
api page there is a pointer to tarball and signed tarball in the same
assets page and with full package-version.ext{.sigext}. Names for this
case is welcome, I thought about "namedboth".

Hope this helps,