The results from the testers came back to me. Publishing a Perl module comes with the automated CPAN tester cycle.
In short, the Ubuntu based Linux failed, while the Debian variant went ok. The reason of the Ubuntu failures is because the missing libxmlsec1-dev library. There are also testers on freebsd, mswin32, solaris and openbsd; but some of them have very few testers available so the results take more time to pop up. I myself tested the module on Ubuntu 22.04 LTS with perl 5.34 and it worked after I did a *sudo apt-get install libxmlsec1-dev*. Apparently the xmlsec-dev is more core in the Debian branch. The Debian image I have in my environment did require installing libxmlsec1-dev, though. I did a test on a FreeBSD 12.3 image with perl 5.32. The installing after *pkg install xmlsec1-1.2.34* (latest!) should have worked, but my package failed at first. FreeBSD setup all third party the stuff under the */usr/local/* branch and I didn't add that to the #include search. The README states that xmlsec is a requirement. There are a couple of artifacts available to install external requirements along with a perl module, but I dislike them IMHO. They are prompt to get your module working but mess up everything else. Some recommend doing static linking. Other languages such as ruby and python favors setting up separated virtual environments. I also discard both options, since crypto and SSL stuff should be system-wide. -----Mensaje original----- De: Aleksey Sanin <[email protected]> Enviado el: miércoles, 24 de agosto de 2022 7:37 Para: Erich Strelow <[email protected]>; [email protected] Asunto: Re: [xmlsec] Perl module for xmlsec set to publish Fantastic! I've added a link to the docs and website will be updated after next release as well: Thanks! Aleksey On 8/23/22 4:49 PM, Erich Strelow wrote: > Finally, I uploaded the perl module binding I announced back in 2020. > > I just recently restarted work on this. I reached the point in which the > module just about does what I expected as a first release. > > The app I was working on had to do with xml representations of accounting > ledgers. The tax authority in the country where I live encourages a system in > which your accounting ledgers are stored in some digital archive as signed > xml documents. The signee must use a X509 certificate issued by a CA, which > un turn must be recognized by the tax authority. The subject of the X509 can > be the company CFO, the accountant or just some previously enrolled clerk. > > So, the glue perl script here must perform a series of pre-press > transformations on the document, transfer the data in and out the archive, > serve as a backend for a web app for previewing and approval of the ledgers; > and perform the xml signature and verification. > > An early version of this app I did back in the 2000's issued a system call > for the xmlsec utility after dumping the document. But, since libxml was my > XML library of choice anyway, I always felt I was double-parsing all the time. > > As for the module, some design comments: > > * There's already a very mature libxml perl module, so the xmlsec methods > accepts already parsed xml documents as perl objects. > * perl can use interpolation in function names, so the one cheap trick I did > was to dynamically construct something like xmlSecTransformRsaSha1Id from the > string 'rsa-sha1'. I had to write a lot of stub C calls, but it worked. This > helped simplify the template construction on the perl side. > * The idea was to identify tampered documents, so I took advantage of the > error callback feature in the verify method in order to keep the reason why a > document failed. > > I tested the module in Debian and RH variants. I lost my Windows development > device a couple of weeks ago when some guys stole my backpack. I expect to > have one later. > > _______________________________________________ xmlsec mailing list [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec
