[ivanbakel]

> that wasn't designed to support cryptographic security

An XML library doesn't have to support cryptographic security - it just has to perform XML en/decoding effectively. How can it be a mistake for a project to rely on part of the standard library?

[tptacek]

You write this as if XMLDSIG was straightforward, but people who have worked with XMLDSIG before know that it is not, and people who haven't worked with XMLDSIG should know that they need to research new cryptosystems before slapping them together out of spare parts.

Just to clear it up and state it plainly: it is never reasonable to assume that a given XML library is suitable for building XMLDSIG on top of or alongside.

[eznzt]

I don't know what I'm talking about, but if the XMLDSIG support of encoding/xml does not work properly and no one can fix it, can't they just drop it?

[tptacek]

Drop what? encoding/xml was never a reasonable building block for SAML and XMLDSIG, that was pretty immediately apparent from the library itself, and the Go project never told people they should using encoding/xml this way. They never picked it up in the first place, is what I'm saying.