Re: SECURITY release: MARC::File::XML 1.0.2
On Tue, Jan 21, 2014 at 12:38 PM, Galen Charlton gmcha...@gmail.com wrote: Hi, I have uploaded [1] version 1.0.2 of MARC::File::XML. This is a security release that repairs an XML external entity (XXE) vulnerability. I recommend that all uses of MARC::File::XML upgrade promptly. Here is the change log entry: 1.0.2 Tue Jan 21 17:18:37 UTC 2014 - MARC::File::XML will now die upon parsing a record that declares an external entity and tries to use it. This prevents the potential unwanted disclosure of the contents of files on the server by applications that embed this module. If, for some reason, an application needs to process MARCXML records that contain external entities, set_parser() can be used to force the use of an XML::LibXML parser that is configured to process external entities. The issue was reported by John Lightsey. [1] https://metacpan.org/release/GMCHARLT/MARC-XML-1.0.2 RPMs are available for manual download for Fedora 19 [a] and Fedora 20 [b], but will not be available through the normal updates process until sufficient testing karma has been granted. If you have a Fedora account and can test the packages grant them karma, please do so! a. https://admin.fedoraproject.org/updates/perl-MARC-XML-1.0.2-1.fc19 b. https://admin.fedoraproject.org/updates/perl-MARC-XML-1.0.2-1.fc20 Thanks, Dan
Also packaging Library::CallNumber::LC for Fedora
As the subject says: https://bugzilla.redhat.com/show_bug.cgi?id=830221 is the bug I opened in hopes of getting Library::CallNumber::LC packaged for Fedora. Fingers crossed. -- Dan Scott Laurentian University
Packaging MARC::XML, MARC::Charset, and updating MARC::Record for Fedora
Hey folks: As a Fedora user for a number of years now, I'm tired of hitting CPAN for the basic Perl packages we need for our day-to-day MARC work, so I've filed the following bugs with new or updated SPEC files and SRC RPMs. * Update MARC::Record to 2.0.3: https://bugzilla.redhat.com/show_bug.cgi?id=827801 * Package MARC::Charset: https://bugzilla.redhat.com/show_bug.cgi?id=829860 * Package MARC::XML: https://bugzilla.redhat.com/show_bug.cgi?id=829865 I'm hopeful that I will 1) make it through the gauntlet of package review and 2) get sponsored as a Fedora maintainer of these packages. I'll let you know when / if I have good news :) -- Dan Scott Laurentian University
Re: Moose based Perl library for MARC records
Gah. Replying to all this time instead of just Galen, as I did three hours ago, for my $0.02... 2010/11/11 Galen Charlton gmcha...@gmail.com: Hi, 2010/11/11 Frédéric DEMIANS f.demi...@tamil.fr: Thanks all for your suggestions. I have to choose another name for sure. Marc::Moose seems to be a reasonable choice. But I'm very tempted by a shorter option: MarcX, MarcX::Record, MarcX::Parser, MarcX::Reader::Isis, etc. Any objection? Not from me, but I'm not sure if the CPAN folks will want yet another top-level namespace. I was going to express the same concern. Keeping everything under MARC:: may also make it a tiny bit easier to find the existing alternatives for, well, parsing MARC records. I would +1 MARC::Moose. Also, to be purely pedantic, MARC is an acronym for MAchine-Readable Cataloguing, while Marc is a person's name, so where-ever it ends up, please keep it uppercase. -- Dan Scott Laurentian University
Re: [Patch] Escape marc tag/code/indicators in Marc::File::XML
Was it decided that Bill's escaping output patch would be dropped? I don't see it in CVS yet. It would be nice to see the 0.91 release get pushed out the door, in any case. 0.88 was a long time ago. Dan 2009/4/14 Galen Charlton galen.charl...@liblime.com: Hi, On Tue, Apr 14, 2009 at 3:57 PM, Dan Scott deni...@gmail.com wrote: 2008/10/29 Bill Erickson billserick...@gmail.com: Is anyone planning on applying this patch? It would be a shame to drop it on the floor. I'll take a look at it and apply it, unless somebody beats me to the punch in the next day or two. Regards, Galen -- Galen Charlton VP, Research Development, LibLime galen.charl...@liblime.com p: 1-888-564-2457 x709 skype: gmcharlt -- Dan Scott Laurentian University
Re: [Patch] Escape marc tag/code/indicators in Marc::File::XML
2008/10/29 Bill Erickson billserick...@gmail.com: Hi all, I ran across some gnarly MARC data today, which contained, among other things, MARC codes of . I realized that Marc::File::XML outputs the MARC tags, codes, and indicators without escaping them. This results, in my case, in invalid XML like: subfield code=France/subfield It seems reasonable that, regardless of the (horrible) content of the MARC, marc::file::xml should produce valid XML. Attached is a patch to explicitly escape the values before inserting them into the XML document under construction. I'm not sure if it's the best approach, but it got me up and running again. Thanks, Is anyone planning on applying this patch? It would be a shame to drop it on the floor. -- Dan Scott Laurentian University
Re: [Patch] Escape marc tag/code/indicators in Marc::File::XML
2008/10/29 Bill Erickson [EMAIL PROTECTED]: Hi all, I ran across some gnarly MARC data today, which contained, among other things, MARC codes of . I realized that Marc::File::XML outputs the MARC tags, codes, and indicators without escaping them. This results, in my case, in invalid XML like: subfield code=France/subfield It seems reasonable that, regardless of the (horrible) content of the MARC, marc::file::xml should produce valid XML. Attached is a patch to explicitly escape the values before inserting them into the XML document under construction. I'm not sure if it's the best approach, but it got me up and running again. Any chance of including a sample (horrible) MARC record to include in a testcase? I'm not saying I would build a testcase for MARC::File::XML, but I might build one for File_MARC (PHP)... and a nice horrible MARC record from the wild would help. -- Dan Scott Laurentian University
Re: File::XML small improvement for unimarc guys
On 22/06/07, Paul POULAIN [EMAIL PROTECTED] wrote: Hello world, at line 503 is written : die Unsupported UNIMARC charater encoding [$enc] for XML output; could we set instead : die Unsupported UNIMARC charater encoding [$enc] for XML output for $f, field 100 being .$r-subfield(100 = 'a'); And while you're at it, s/charater/character/ please :) -- Dan Scott Laurentian University
