I'm keeping up with the perl project. I started linking with a private xmlsec version 1.2.29. Then I switched to whatever xmlsec-devel package was available in my linux distro. It's 1.2.20. The perl glue worked well either way.
I added a XmlSecVersion perl method that points to the XMLSEC_VERSION macro. I almost gave up on the KeyManager. An initial idea of setting up a KeyManager helper object at perl level was discarded. And for some time I thought of narrowing keys to a one-shot only mention on some function arguments. Finally, the main xmlsec perl object is indeed the basic KeyManager itself and I included a KeysStoreSave method that maps to xmlSecCryptoAppDefaultKeysMngrSave. Regards. Erich. -----Mensaje original----- De: xmlsec <[email protected]> En nombre de Aleksey Sanin Enviado el: lunes, 2 de marzo de 2020 14:38 Para: [email protected] Asunto: Re: [xmlsec] Another go on xmlsec perl bindings Thank you! I will add a pointer to it to the xmlsec website. Aleksey On 3/1/20 6:18 PM, Erich Strelow wrote: > A couple of weeks ago I revisited xmlsec somehow by chance. > > One of our vendors was sending invoices with a faulty xmldsig signature. > I used the xmlsec1 command line tool to verify some signatures. As it > turned out, the vendor had managed to sign an ISO-8859-1 encoded xml, > and then e-mail it using us-ascii 7bit. > > Anyway, I noticed that after 12 years there's still no perl module for > xmlsec. I decided to have a go on this. The repository is available at > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Festrelow%2FPerl-LibXML-Sec&data=02%7C01%7Cesf%40moller.cl%7C82c50fe4a19c445f141d08d7bed09a33%7Ca68cc54667a34b1387f4414e9e0b94ef%7C1%7C1%7C637187675470190957&sdata=%2BDqnLW9ZDbgvHP6PNENUCsiFfvRWZCUlvo5MYdPusFk%3D&reserved=0. > > This is still a work in progress. So far I've been able to sign a > "Hello world" xml document. The module is still useless beyond that. > > Others have tried and failed. I might as well fail. > > use XML::LibXML::xmlsec; > > my $signer=XML::LibXML::xmlsec->new(); > > $signer->set_pkey(PEM => 'key.pem', secret => 'the watcher and the > tower'); > > my $doc=XML::LibXML->load_xml(location => 'hello-ready.xml', > load_ext_dtd =>1, complete_attributes=>1,no_network=>1); > > $signer->signdoc($doc, id => "hello", 'id-node' => 'Data', 'id-attr' > => 'id'); > > Some ideas: > > 1. Design principles. > > -The module should interact with XML::LibXML, the main libxml2 > port under perl. Therefore the targeted module name as XML::LibXML::xmlsec. > > -This means a XML::LibXML Document handle might be passed to > xmlsec and work out. > > -If the LibXML Document was ill parsed or is ill formed, xmlsec > should complain and fail. > > -This also means a product of xmlsec signing/encryption should > be usable by XML::LibXML. > > -Instead of a full perl binding of xmlsec, the goal is to produce > a xmldsig signing/encryption perl toolkit using xmlsec. > > -The module should have simple verbs, like sign(), verify(), encrypt(). > > -The arguments should be passed using perl name-value pairs to > allow different formats and options. i.e., the above code should have > been set_pkey(DER => 'key.der'). > > -The module must have a performance at least as good as calling > xmlsec command from perl. > > 2. Motivation. > > -For many years, libxml has been my xml library of choice under perl. > > -The Chilean tax authority has adopted xmldsig for 20 years now. > This means invoices can be exchanged using xmldsig, and even > accounting ledgers are to be archived using xmldsig. > > -I hate calling xmlsec1 from perl. I always feel I'm double > parsing everything. > > 3. Simplifications. > > - So far I'm using XMLSEC_NO_CRYPTO_DYNAMIC_LOADING to reach a > workable toolkit. > > - Still, since allowing different crypto engines is a xmlsec > feature, and there might be compliance issues here, at some point I > have to let it go. > > - I'm favoring the "app" versions of xmlsec functions. > > 4. Use case. > > The sign/encrypt perl script use case should be as follows: > > + > > | > > | > > v > > +--------+---------+ > > | | > > | App layer | > > | | > > +--------+---------+ > > | > > v > > +--------+---------+ > > | | > > | xmlsec | > > | | > > +--------+---------+ > > | > > v > > +--------+---------+ > > | | > > | store or send | > > | | > > +------------------+ > > The app layer should build the XML document using perl LibXML, or DBI, > or some module to fetch data from a legacy system. Whatever. > > In my case, I connect to SQL server. > > The xmlsec layer will sign and/or encrypt the document. The > appropriate key should be selected by any combination of source, target, > contents. > > The store/send layer will save the resulting document in some storage, > or send it to a receiving party, like a customer, vendor, compliance > authority. > > The decrypt/verify perl script would be the opposite: > > + > > | > > v > > +---------+---------------+ > > | | > > | receive or retrieve | > > | | > > +---------+---------------+ > > | > > | > > v > > +---------+---------------+ > > | | > > | xmlsec layer | > > | | > > +---------+---------------+ > > | > > v > > +---------+---------------+ > > | | > > | App layer | > > | | > > +-------------------------+ > > A receive/retrieve should fetch a xml document from storage, or maybe > be the receiving end in a https POST channel. > > The xmlsec should verify the signature. > > The app layer then can consume the xml data using LibXML. > > Regards. > > Erich. > > > _______________________________________________ > xmlsec mailing list > [email protected] > https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.a > leksey.com%2Fmailman%2Flistinfo%2Fxmlsec&data=02%7C01%7Cesf%40moll > er.cl%7C82c50fe4a19c445f141d08d7bed09a33%7Ca68cc54667a34b1387f4414e9e0 > b94ef%7C1%7C1%7C637187675470190957&sdata=8cBLwH41cIPwnzDiLHYFwUuI2 > JeaStTBAF7MxdPFpyw%3D&reserved=0 > _______________________________________________ xmlsec mailing list [email protected] https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.aleksey.com%2Fmailman%2Flistinfo%2Fxmlsec&data=02%7C01%7Cesf%40moller.cl%7C82c50fe4a19c445f141d08d7bed09a33%7Ca68cc54667a34b1387f4414e9e0b94ef%7C1%7C1%7C637187675470190957&sdata=8cBLwH41cIPwnzDiLHYFwUuI2JeaStTBAF7MxdPFpyw%3D&reserved=0 _______________________________________________ xmlsec mailing list [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec
