On Thu, 2017-06-22 at 15:53 +0200, Miklos Vajna wrote:
> Hi,
>
> On Mon, Feb 13, 2017 at 12:50:07PM +, Caolán McNamara dhat.com> wrote:
> > So, do we know enough that the customkeymanage part isn't necessary
> > for
> > any known normal use of xml signing, I mean if we disable it, or
> > buil
Hi,
On Mon, Feb 13, 2017 at 12:50:07PM +, Caolán McNamara
wrote:
> So, do we know enough that the customkeymanage part isn't necessary for
> any known normal use of xml signing, I mean if we disable it, or build
> against a system version that doesn't have it, that the uses we do know
> abou
Caolán McNamara wrote:
> So, do we know enough that the customkeymanage part isn't necessary for
> any known normal use of xml signing, I mean if we disable it, or build
> against a system version that doesn't have it, that the uses we do know
> about continue to work.
>
I have vague recollections
Hi,
On Mon, Feb 13, 2017 at 12:50:07PM +, Caolán McNamara
wrote:
> So, do we know enough that the customkeymanage part isn't necessary for
> any known normal use of xml signing, I mean if we disable it, or build
> against a system version that doesn't have it, that the uses we do know
> abou
On Mon, 2017-02-13 at 10:45 +0100, Miklos Vajna wrote:
> external/libxmlsec/xmlsec1-customkeymanage.patch.1: this is a
> monster, I think this has to do something with smart-card handling,
> but I never got around to actually understand what it does. This is
> the real blocker wrt. building against
Hi,
On Mon, Feb 13, 2017 at 09:14:31AM +, Caolán McNamara
wrote:
> the one that bothers me the most is libxmlsec because we never got the
> modifications upstream or found another way to do whatever it is we do
> to it.
I started to care about this when I added a few more patches (which are
