#1002595 debbugs: get_bug_log can incorrectly return an e-mail body with xsi:type="xsd:long"

Package:
debbugs
Source:
debbugs
Submitter:
Mike Frysinger
Date:
2022-01-01 19:00:03 UTC
Severity:
normal
#1002595#5
Date:
2021-12-25 06:26:00 UTC
From:
To:
Running get_bug_log against this report returns bad response:
https://bugs.debian.org/557671

message #45 will yield:
        <item>
          <body xsi:type="xsd:long">4327390041297022</body>

I get that that bug report has a lot of spam, but debbugs prob shouldn't
ever return a <body> with xsi:type other than xsd:long.
#1002595#10
Date:
2021-12-25 06:41:13 UTC
From:
To:
err, obviously I meant <body> should always have xsi:type of *xsd:string*
#1002595#15
Date:
2021-12-27 20:41:04 UTC
From:
To:
The type of the transmitted data is determined automatically by Perl;
how it does that is described here:
https://manpages.debian.org/bullseye/libsoap-lite-perl/SOAP::Serializer.3pm.en.html#AUTOTYPING
https://manpages.debian.org/bullseye/libsoap-lite-perl/SOAP::Lite.3pm.en.html#TROUBLESHOOTING

Debbugs already disables some of the possible types around here:
https://salsa.debian.org/debbugs-team/debbugs/-/blob/master/cgi/soap.cgi#L49
I suspect it should not disable the auto-detection completely because at
least some of the remaining types are actually needed. This means there
will always remain corner cases where it guesses wrong.

Being prepared for this on the client side is a good idea.
Python-debianbts solves the problem in get_bug_log() by (mostly)
ignoring the xsi:type for message bodies and always converting them to
string.
#1002595#20
Date:
2021-12-31 09:58:49 UTC
From:
To:
it seems like the use of auto-detection was more for quick prototyping
convenience than it should be relied upon long term.  the schema should
be a fixed thing at this point: every response down to the field and its
type should be written in stone.

making every client copy & paste the same set of workarounds for bad server
responses sounds like the wrong trade-off.  at that point, why bother sending
type information in the responses if clients can't rely on them ?

i get that the server is misbehaving now so clients don't have much choice but
to workaround them, but the server response should be fixed nevertheless.
#1002595#25
Date:
2021-12-31 22:21:05 UTC
From:
To:
Happy to accept patches to fix the XML serialization in SOAP. The way
that Debbugs is doing it is clearly not correct, but fixing it isn't
high on my priority list. [Really, it's past time for us to support a
REST interface and abandon the SOAP interface.]
#1002595#30
Date:
2022-01-01 18:58:21 UTC
From:
To:
i've dug around the source a bit.  tbh, the exclusive use of perl makes it
a pretty big barrier for contribution, and so it's unlikely i'll be able to
offer anything substantial.  i was barely able to get it running using the
incomplete/buggy README instructions.

i'm not asking/suggesting it be rewritten in a diff language of course as i
grok the long history and such.  just explaining why it's unlikely i'll be
sending any useful code patches.