Please disable signing by default. Generally the right thing to do for
most dpkg-dev users is to have dpkg-buildpackage *not* auto-sign
anything. Almost all dpkg-dev users (except buildds) should test and
check the package *before* signing and uploading the package. We have a
volunteer for adjusting the buildds (in CC) if needed and I volunteer to
adjust any documentation outside of dpkg-dev that needs changing.

Hi!

[ CCing debian-devel to get input from possibly afftected users. ]

The difference between this request and the one about not signing
UNRELEASED builds, is that this one has way greater user impact, and
the latter is supposedly not meant to be signed (in the general case)
anyway.

I guess it's probably a good idea to switch the default, becuse I
assume most maintainers do more test builds than final ones. Or users
who either don't have gpg installed or don't have a gpg key. Although
with the current no-signing-UNRELEASED behaviour, the need for -us -uc
should have dropped in many cases.

In any case, this is about the tool best global default, irrespective of
any future possibility of setting local defaults through a configuration
file or similar.

If most people agree this would be an improvement, and not just an
annoyance, I'm happy to do the change. But there's few things that I'd
want to tackle first:

 * signing would get rafactored into a new program so that users do
   not need to manually mangle the .changes file, rebuild or require
   devscripts for something that was possible out-of-the-box.
 * (possibly) new options would get added to specify signing, although
   there's --force-sign since 1.17.0, which could be used already on
   the buildds.
 * (possibly) wait for a grace period with warnings and the above
   available so that users can switch scripts/programs gracefully,
   before the flag day.

Thanks,
Guillem

* Guillem Jover <guillem@debian.org>, 2013-12-30, 12:27:

ACK
[...]

I took a look at a random build log[0], and it looks like buildds don't
use dpkg-buildpackage for signing, but debsign. (It would be nice if
someone from the wb-team could confirm that this is the case.)


[0] https://buildd.debian.org/status/fetch.php?pkg=dpkg&arch=i386&ver=1.17.5&stamp=1386841160

And also, it should be friendly to non-maintainers who are just trying
to rebuild the package grabbed from Debian. The assumption that the
builder is the maintainer is inadequate to start with.

So I'm in favor of a transition. I also agree that it makes sense to
add a dedicated signing tool in dpkg-dev (merging debsign as dpkg-sign?)
and that this change should dealt together with a general revamp of
dpkg-buildpackage.

Cheers,

I chose to read that as "debsign will move from devscripts to src:dpkg"
and felt happier. I actually don't care if debsign is reimplemented, but
I'd prefer if the Debian package development brain space was not further
complicated with more command line tools to learn[1], so I suggest that
the existing name and arguments are preserved.

[1] or ignore

Hi!

I'd feel very uncomfortable doing that, because it would mean, at least:

 * introducing a core dpkg tool within a different namespace
 * having to parse a devscripts specific configuration file
 * having to support DAK specific .commands signing
 * having to support remote signing

IMO having debsign become a thiner wrapper around this new tool would
be the goal, as it would simplify its code, people not wanting to use
debsign could use the dpkg tool directly, and people not wanting to
learn new stuff could keep using the wrapper w/o regressions.

Thanks,
Guillem

You raise some very valid points and §I appreciate your concerns and
perhaps should rephrase my request so that I'm suggesting subsuming the
most common used features of debsign and perhaps as part of a staged
migration (compat symlink to debsign binary name in the phase 1, real
name dpkg-sign or whatever), to try and avoid further complicating the
debian package development universe.

So dpkg-sign (or dpkg sign if you ever decided to move to internal
namespacing, which seems to be fashionable) with a compatibility symlink
to debsign would resolve this one,

That's more awkward, I'd agree, but you could support the command-line
arguments without supporting the devscripts configuration file. It could
be confusing for those who have relied upon it, though. A more
considered migration would be necessary.

That could be awkward, although the format is very similar (if not
identical) to debian/control and only one header is of interest. I
imagine most people use dcut/dput nowadays[1]

It would be fair enough to stderr "not supported, please use the older
tool in devscripts" and error 1 if such an argument was provided. That
would be pragmatic if (as I suspect) -r is rarely used.
package development tools would continue to grow, meaning people would
use the non-recommended tool if they did not know better (or relied on
documentation which had not been updated).

[1] haven't checked whether they, in turn, rely on debsign.

On the sbuild/buildd side, we have run dpkg-buildpackage with
"-us -uc" by default for years.  If you do enable signing, as is
the case for buildd uploads, we run debsign explicitly after
dpkg-buildpackage completed.  This avoids any need for GPG keys
to be present in the build chroot.  So from the POV of making
"-us -uc" the default, I think that's a good plan and matches
the requirements of the majority of both manual and automated
builds.  And from the POV of having a replacement for debsign,
we can conditionally switch to using it as soon as it becomes
available.


Regards,
Roger

Roger Leigh writes ("Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)"):

Likewise dgit, which does the signing only in "dgit push".  It does it
by itself without the use of debsign or anything from dpkg-dev.

I have no objection to the proposed change to dpkg-buildpackage, or
the moving of functionality from devscripts.

I do of course want debsign's command line interface and functionality
to continue to work in its entirity.  But I also need the arrangements
for making the signature remain part of the defined interface, so that
dgit keeps working: i.e. even if this functionality becomes part of
dpkg-dev, its use should not be mandatory.

Thanks,
Ian.

Hi Jonathan (2014.01.02_19:22:33_+0200)

Aww. I'm a frequent user of -r.
I have better places to build big packages than on my lap, and I prefer
to keep my GPG key in as few places as possible.

But of course, this could be replaced by a new remote signing wrapper.
And, if popular enough, end up in devscripts...

SR

Le samedi, 4 janvier 2014, 19.54:05 Stefano Rivera a écrit :

I concur. I build my packages on a server's sbuild and then debsign -r
from my laptop, then dput from the server.

Please keep this workflow possible with in-archive tools.

Cheers,
OdyX

Indeed, my case here too. -r is crucial for my workflow :-/

(Obviously, assuming devscripts maintainers would agree, I was just
inferring from previous interactions regarding debuild for example; in
any case what happens with debsign would be their decision entirely.)

Honestly, I've been struggling a bit trying to understand this concern,
because to me that reads as suggesting no new features, command-line
options or tools should be added (to dpkg or devscripts or similar
packages), to avoid increasing the packaging tools surface area, when
in this case usage of this tool would be completely optional, and might
make life easier for some people. I don't see either the problem of using
one or the other, or one being more recommended than the other. If a new
tool would get added to dpkg every second week, then I could see it, but
not with the current pace.

If it was just a “hey, please consider creating a single interfaces that
can cover all current usages, and drop the old one if possible”, sure
I'm all for integrating back stuff that has been developed or prototyped
elsewhere, and trying to end up with a single interface by deprecating
the old interface if necessary. In this case though, I think debsign
(and debuild, and other similar wrappers) add value, and have features
that I don't see fit in dpkg proper, or might serve as future playground
to try out new stuff that could get merged back too. So in this case I
don't see its deprecation as desirable (but again that's something for
the devscripts maintainers to decide).

They do, as well as many tools that need to control the signing
process, some mentioned in this thread.

Thanks,
Guillem

Am Sonntag, den 05.01.2014, 15:09 +0100 schrieb Guillem Jover:

I agree with this proposal. It can become a thin wrapper around the new
tool (assuming someone does the work). Then it can either fade away (if
the new tool can replace it completely) or stay forever (like debuild)
if it provides additional features.

Yes, please. The default signing just leads to error messages…
and we nowadays upload source-only anyway, so no builds should
be signed by default, only those explicitly created to publish.