Your message dated Wed, 21 Aug 2019 10:54:51 +0200
with message-id <[email protected]>
and subject line Re: Bug#935259: self-service give-back doesn't properly
validate client certificates
has caused the Debian Bug report #935259,
regarding self-service give-back doesn't properly validate client certificates
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
935259: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935259
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: buildd.debian.org
X-Debbugs-Cc: [email protected]
I checked the giveback.wsgi file (which I couldn't find in any public
git repository over https://salsa.debian.org/wb-team btw), and noticed
that you are not properly validating the client certificates.
domain = '@debian.org'
if not user.endswith(domain):
return ('This application is only accessible to {} account '
'holders. \u2717'.format(domain))
user = user[:-len(domain)]
That is *not* a proper check to see wether the certificate holder is a
DD. Examples of users with a @d.o certificate that are not DDs include:
* everybody with a guest account at DSA
* retired/removed DDs (as I don't _think_ the sso.d.o machiner
automatically revokes them, I'd be glad to be proved wrong on this
though)
All this stuff is already well documented at
https://wiki.debian.org/DebianSingleSignOn#A_word_on_the_two_A.27s
Currently the only sane, authoritative way to check whether a user is a
DD is using the nm.d.o public API (https://nm.debian.org/api/); a
somewhat less authoritative method is checking the status of the user in
ldap, but that might lag behind DAM decisions, etc.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
On 2019-08-21 10:10, Mattia Rizzolo wrote:
I checked the giveback.wsgi file (which I couldn't find in any public
git repository over https://salsa.debian.org/wb-team btw), and noticed
that you are not properly validating the client certificates.
domain = '@debian.org'
if not user.endswith(domain):
return ('This application is only accessible to {} account '
'holders. \u2717'.format(domain))
user = user[:-len(domain)]
That is *not* a proper check to see wether the certificate holder is a
DD. Examples of users with a @d.o certificate that are not DDs
include:
* everybody with a guest account at DSA
* retired/removed DDs (as I don't _think_ the sso.d.o machiner
automatically revokes them, I'd be glad to be proved wrong on this
though)
All this stuff is already well documented at
https://wiki.debian.org/DebianSingleSignOn#A_word_on_the_two_A.27s
Currently the only sane, authoritative way to check whether a user is a
DD is using the nm.d.o public API (https://nm.debian.org/api/); a
somewhat less authoritative method is checking the status of the user
in
ldap, but that might lag behind DAM decisions, etc.
I am very well aware of all of this. I did my own risk assessment and as
long as the most that can happen is wasting resources on give-backs, I
am fine with that. If we see abuse, we can tackle it differently.
Now I also don't think it is reasonable to have every service call out
to nm for every request and the CRL should be there for a reason: SSO
should at least own revoking certificates that are of retired/removed
DDs. But that's a bug for SSO to tackle. If we find that someone
generated a certificate that's valid for eternity and used it after they
left, we can still block access.
The risk here is very low for exactly the functionality that has been
exposed. Obviously another service (say triggering binNMUs) would need
to adhere to a different standard. That standard might need to involve
checking the LDAP-based groups anyway for permissions (as we cannot
properly impersonate the user with the current service architecture).
That could also be done through the local group database given that all
DDs have access to the machine and are exported there. But that'd be for
another day to figure out.
Re it not being on salsa: I committed it into the buildd.d.o repo on
wuiet. It used to be exported as a mirror to Alioth. I guess that didn't
make it to Salsa. If you have docs on how to set it up handy, let me
know and I'll fix it.
Kind regards
Philipp Kern
--- End Message ---
