Bug#940144: developers-reference: document self-service givebacks in wanna-build section

[Paul Wise]

Package: developers-reference
Severity: wishlist
X-Debbugs-CC: Philiip Kern <***@debian.org>, debian-wb-***@lists.debian.org

In the section about wanna-build, please document the new self-service
givebacks in the wanna-build section of devref:

https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#wanna-build

Here is a copy of the announcement and blog post for your reference:

https://lists.debian.org/msgid-search/***@debian.org

Self-service buildd givebacks
-----------------------------

Philipp Kern has created[1] an *experimental* service that allows Debian
members to perform self-service retries of failed package builds (aka
give-backs). This service aims to reduce the time it takes for give-back
requests to be processed, which was done manually by the wanna-build
admins until now. The service is authenticated using the Debian Single
Signon[2] service. Debian members are still expected to act responsibly
when looking at build failures; do your due diligence and try reproducing
the issue on a porterbox first. Access to this service is logged and logs
will be audited by the admins.

-- Paul Wise

[1] https://debblog.philkern.de/2019/08/alpha-self-service-buildd-givebacks.html
[2] https://sso.debian.org/

https://debblog.philkern.de/2019/08/alpha-self-service-buildd-givebacks.html

Alpha: Self-service buildd givebacks

Builds on Debian's build farm sometimes fail transiently. Sometimes
those failures are legitimate flakes, for instance when an in-
progress build happens to exhaust its resources because of other
builds on the same machine. Until now, you always needed to mail the
buildd, wanna-build admins or the Release Team directly in order to
get the builds re-queued.

As an alpha trial I implemented self-service givebacks as a web
script. As SSO for Debian developers is now a thing, it is trivial
to add authentication in a way that a role account can use to act on
your behalf. While at work this would all be an RPC service, I
figured that a little CGI script would do the job just as well. So
lo and behold, accessing
https://buildd.debian.org/auth/giveback.cgi?pkg=<package>&suite=<suite>&arch=<arch>
with the right parameters set:

You are authenticated as pkern. ✓
Working on package fife, suite sid and architecture mipsel. ✓
Package version 0.4.2-1 in state Build-Attempted, can be given back. ✓
Successfully given back the package. ✓

Note that you need to be a Debian developer with a valid SSO client
certificate to access this service.

So why do I say alpha? We still expect Debian developers to act
responsibly when looking at build failures. A lot of times there is
a legitimate bug in the package and the last thing we would like to
see as a project is someone addressing flakiness by continuously
retrying a build. Access to this service is logged. Most people
coming to us today did their due diligence and tried reproducing the
issue on a porterbox. We still expect these things to happen but
this aims to cut on the round-trip time until an admin gets around
to process your request, which have been longer than necessary
recently. We will audit the logs and see if particular packages
stand out.

There can also still be bugs. Please file them against
buildd.debian.org when you see them. Please include a copy of the
output, which includes validation and important debugging
information when requests are rejected. Also this all only works for
packages in Build-Attempted. If the build has been marked as Failed
(which is a manual process), you still need to mail us. And lastly
the API can still change. Luckily the state change can only happen
once, so it's not much of a problem for the GET request to be
retried. But it should likely move to POST anyhow. In that case I
will update this post to reflect the new behavior.

Thanks to DSA for making sure that I run the service sensibly using
a dedicated role account as well as WSGI and doing the work to set
up the necessary bits.

[Drew Parsons]

Has the self-service wannabuild giveback script been disabled?

It's now rejecting connections, e.g.
https://buildd.debian.org/auth/giveback.cgi?pkg=ga&suite=sid&arch=armel
generates

Forbidden
You don't have permission to access this resource.Reason: Cannot
perform Post-Handshake Authentication.
Apache Server at buildd.debian.org Port 443

My SSO is otherwise working fine, e.g. triggering debci tests at
https://ci.debian.net/user

[Philipp Kern]

Post by Drew Parsons
Has the self-service wannabuild giveback script been disabled?
It's now rejecting connections, e.g.
https://buildd.debian.org/auth/giveback.cgi?pkg=ga&suite=sid&arch=armel
generates
Forbidden
You don't have permission to access this resource.Reason: Cannot
perform Post-Handshake Authentication.
Apache Server at buildd.debian.org Port 443
My SSO is otherwise working fine, e.g. triggering debci tests at
https://ci.debian.net/user

I'm told it was broken by the upgrade of Apache - apparently it can no
longer do per path client certificate authentication. There is a pending RT
ticket from DSA to fix that but I don't think there is anything I can do at
the moment - except turn on SSO for the whole vhost. Maybe that could even
be a workaround for now and we could check if someone is annoyed by that. :)

Kind regards
Philipp Kern

[Sam Hartman]

Philipp> I'm told it was broken by the upgrade of Apache - apparently it can no
Philipp> longer do per path client certificate authentication. There is a
Philipp> pending RT ticket from DSA to fix that but I don't think there is
Philipp> anything I can do at the moment - except turn on SSO for the whole
Philipp> vhost. Maybe that could even be a workaround for now and we could
Philipp> check if someone is annoyed by that. :)

TLS dropped the facilities necessary to do that.
Ultimately you'll need a vhost for stuff that requires client certs and
other vhosts that do not.
The user experience of having a site request client certs when you don't
have one to give is really bad in some browsers.

Client certs really kind of are the unloved step child of web
authentication.

[Mattia Rizzolo]

That being said, tracker, nm and contributors already moved to request
client certificates on the main host.

In their case it didn't really change anything, since they had the
client certificate bit in their <Location /> section.

And yes, the correct approach would be something like OAuth2. Or use
client certificates with some sort of CLI. :/

Then get the sso.d.o team to do that, in a sane way. We are still
waiting for an interface to register guest accounts, that has been ready
for more than a year now but apparently has trouble being deployed.

</rant+ot>

[Simon McVittie]

Post by Paul Wise
https://debblog.philkern.de/2019/08/alpha-self-service-buildd-givebacks.html

...

Post by Paul Wise
As an alpha trial I implemented self-service givebacks as a web
script. As SSO for Debian developers is now a thing, it is trivial
to add authentication in a way that a role account can use to act on
your behalf. While at work this would all be an RPC service, I
figured that a little CGI script would do the job just as well. So
lo and behold, accessing
https://buildd.debian.org/auth/giveback.cgi?pkg=<package>&suite=<suite>&arch=<arch>
You are authenticated as pkern. ✓
Working on package fife, suite sid and architecture mipsel. ✓
Package version 0.4.2-1 in state Build-Attempted, can be given back. ✓
Successfully given back the package. ✓
Note that you need to be a Debian developer with a valid SSO client
certificate to access this service.
Yeah, so Julien helpfully just created auth.buildd.debian.org (thanks
for that!).

To be completely clear about this for those using this bug report as a
stand-in for the requested documentation in devref (like me), it's now at:
https://auth.buildd.debian.org/auth/giveback.cgi?pkg=<package>&suite=<suite>&arch=<arch>

smcv

[Holger Levsen]

Post by Simon McVittie
To be completely clear about this for those using this bug report as a
https://auth.buildd.debian.org/auth/giveback.cgi?pkg=<package>&suite=<suite>&arch=<arch>

I'd be very glad to review(, improve) and merge a patch... ;)

(dev-ref is written in markdown nowadays, so a plaintext patch with the wording
would be sufficient^wwonderful as well.)