Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Paul Wise]

On Thu, 2021-06-24 at 23:30 +0800, Tian Qiao wrote:

> I will suggest to upstream, remove these binary dependencies in
> subsequent code refactoring, and use some assembler libraries
> instead, such as Keystone. Thanks!

Switching to different dependencies shouldn't be necessary, just not
including the dependencies in the git repository and instead including
them in the Windows binary packages. Alternatively just run the
dependencies at build time and include the build results in the binary
packages for each platform.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Tian Qiao]

> On Jun 24, 2021, at 7:54 AM, Paul Wise  wrote:
> 
> On Thu, 2021-06-24 at 00:46 +0800, Tian Qiao wrote:
> 
>> Besides, "nasm.exe" and "objdump.exe" are provided for the
>> convenience of Windows users.
> 
> I suggest upstream should remove these from the source code and only
> distribute them with their Windows binary packages. The build process
> for the Windows binary packages could download the files.
> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise

I will suggest to upstream, remove these binary dependencies in subsequent code 
refactoring,
and use some assembler libraries instead, such as Keystone. Thanks!

Regards,

—
  Tian

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Paul Wise]

On Thu, 2021-06-24 at 00:46 +0800, Tian Qiao wrote:

> Besides, "nasm.exe" and "objdump.exe" are provided for the
> convenience of Windows users.

I suggest upstream should remove these from the source code and only
distribute them with their Windows binary packages. The build process
for the Windows binary packages could download the files.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Tian Qiao]

Sorry, I made a mistake in my previous reply. 

Since pocsuite3 is written in Python, it works out of the box with Python 
version 3.x on any platform.
If the user uses it on Linux, the system's "nasm" and "objdump" will be used. 

Besides, "nasm.exe" and "objdump.exe" are provided for the convenience of 
Windows users.

Lintian’s warning is source-contains-prebuilt-windows-binary, and it suggested 
that:
Check if upstream also provides source-only tarballs that you can use as the 
upstream distribution instead.
If not, you may want to ask upstream to provide source-only tarballs.
(https://lintian.debian.org/tags/source-contains-prebuilt-windows-binary)

> On Jun 23, 2021, at 11:47 PM, Tobias Frost  wrote:
>> 
>> 
>>> On Jun 23, 2021, at 8:52 PM, Paul Wise  wrote:
>>> 
>>> How were these files created? It looks like they are generated from the
>>> assembly files in the src/ subdirectory. All generated files should be
>>> built from source at build time, and preferably removed from the
>>> upstream source repository and tarballs, or the Debian tarball.
>>> 
>>> -- 
>>> bye,
>>> pabs
>>> 
>>> https://wiki.debian.org/PaulWise
> 
> Both "nasm" and "objdump" are available in Debian, so you can Recommend: or
> Depends: on them (read up the differences in the Debian Policy and decide 
> whats
> more appropiate). Or do the build at package build-time…
> 
> Well, no. Debian policy is that everything has to be built from its sources.
> (So you need to do that at either build time or runtime.)
> 
> -- 
> tobi

Thanks pabs & tobi for the valuable suggestion.

Best Regards,

— Tian

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Tobias Frost]

On Wed, Jun 23, 2021 at 10:21:34PM +0800, Tian Qiao wrote:
> Hi pabs
> 
> > On Jun 23, 2021, at 8:52 PM, Paul Wise  wrote:
> > 
> > On Wed, 2021-06-23 at 18:32 +0800, Tian Qiao wrote:
> > 
> >> On Jun 23, 2021, at 1:06 AM, Tobias Frost wrote:
> >> 
> >>> shellcodes/data/linux/*bin
> >>> - Are they rebuilt during package build?
> >> 
> >> these are similar to static resources, which help users quickly build
> >> shellcode when writing exploit script.
> >> So won’t rebuild during package build.
> > 
> > How were these files created? It looks like they are generated from the
> > assembly files in the src/ subdirectory. All generated files should be
> > built from source at build time, and preferably removed from the
> > upstream source repository and tarballs, or the Debian tarball.
> > 
> > -- 
> > bye,
> > pabs
> > 
> > https://wiki.debian.org/PaulWise
> 
> If these files do not exist, they will be generated at runtime, and the
> corresponding code is at:
> https://github.com/knownsec/pocsuite3/blob/master/pocsuite3/shellcodes/generator.py
> 
> One problem is that some tools are used to generate machine code
> through assembly code, such as nasm, objdump. If these tools do not
> exist on the users system, it is necessary to use pre-generated ones.

Both "nasm" and "objdump" are available in Debian, so you can Recommend: or
Depends: on them (read up the differences in the Debian Policy and decide whats
more appropiate). Or do the build at package build-time…
 
> Although these tools are provided in the upstream source code, but
> there will be copyright conflicts and lintian warnings will be triggered.

Can you expand on the copyright conflicts and lintian warnings?

> So I've ask upstream to provide source-only tarballs, While available at:
> https://github.com/knownsec/pocsuite3/releases 
>  

Can you expand? (I seems that upstream does have a dfsg tarball... Is that what 
you mean?)
(For sure you can also do the repacking using Files-Excluded: in d/copyright 
and an matching
d/watch file; it is strictly not necessry that upstream does it; OTOH it sure 
makes sense
to ask upstream to remove non-free things generally, but that should benefit 
everyone. not
only for "dfsg-repacking." (TL;DR: Possibly I got that wrong)

> So, I think it's necessary to keep them.

Well, no. Debian policy is that everything has to be built from its sources.
(So you need to do that at either build time or runtime.)

-- 
tobi

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Tian Qiao]

Hi pabs

> On Jun 23, 2021, at 8:52 PM, Paul Wise  wrote:
> 
> On Wed, 2021-06-23 at 18:32 +0800, Tian Qiao wrote:
> 
>> On Jun 23, 2021, at 1:06 AM, Tobias Frost wrote:
>> 
>>> shellcodes/data/linux/*bin
>>> - Are they rebuilt during package build?
>> 
>> these are similar to static resources, which help users quickly build
>> shellcode when writing exploit script.
>> So won’t rebuild during package build.
> 
> How were these files created? It looks like they are generated from the
> assembly files in the src/ subdirectory. All generated files should be
> built from source at build time, and preferably removed from the
> upstream source repository and tarballs, or the Debian tarball.
> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise

If these files do not exist, they will be generated at runtime, and the
corresponding code is at:
https://github.com/knownsec/pocsuite3/blob/master/pocsuite3/shellcodes/generator.py

One problem is that some tools are used to generate machine code
through assembly code, such as nasm, objdump. If these tools do not
exist on the users system, it is necessary to use pre-generated ones.

Although these tools are provided in the upstream source code, but
there will be copyright conflicts and lintian warnings will be triggered.
So I've ask upstream to provide source-only tarballs, While available at:
https://github.com/knownsec/pocsuite3/releases 
 

So, I think it's necessary to keep them. Thanks for attention and advice!

Regards,

—
  Tian

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Paul Wise]

On Wed, 2021-06-23 at 18:32 +0800, Tian Qiao wrote:

> On Jun 23, 2021, at 1:06 AM, Tobias Frost wrote:
> 
> > shellcodes/data/linux/*bin
> > - Are they rebuilt during package build?
>  
> these are similar to static resources, which help users quickly build
> shellcode when writing exploit script.
> So won’t rebuild during package build.

How were these files created? It looks like they are generated from the
assembly files in the src/ subdirectory. All generated files should be
built from source at build time, and preferably removed from the
upstream source repository and tarballs, or the Debian tarball.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Tian Qiao]

Hi tobi

> On Jun 23, 2021, at 1:06 AM, Tobias Frost  wrote:
> 
> shellcodes/data/linux/*bin
> - Are they rebuilt during package build?
> 
these are similar to static resources, which help users quickly build shellcode 
when writing exploit script.
So won’t rebuild during package build.

Thank you for being patient and helping me improve, I do appreciate it.
I have fixed the problems you mentioned in the new upload.
I am requesting to join the Debian Security Tools Team now. 

thanks again.

Regards,

—
  Tian

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Tobias Frost]

Control: tags -1 moreinfo

Hi Tian

(As this a python package, and I'm not fluent in python, I won't sponsor
this upload. Nethetheless I hope you find the review handy.)

Possibly you want to reach out to the Python team i[1] or pkg-security team [2]
for an sponsor and maybe team-maintainance.
[1] https://wiki.debian.org/Teams/PythonTeam
[2] https://wiki.debian.org/Teams/pkg-security


Reviewing: 

- d/patches series should be removed if there are no patches.

- d/changelog: 
You need to file an ITP bug and close it in the changleog.
(See https://mentors.debian.net/intro-maintainers and 
https://wiki.debian.org/WNPP)
That triggers lintian warning "initial-upload-closes-no-bugs"

- d/watch:
seems not to work: Mentors page says:
 A watch file is present but doesn't work
warnings:   Tag pattern missing version delimiters () in debian/watch, 
skipping:
https://github.com/knownsec/pocsuite3/releases/download/v1.7.6/pocsuite3-1.7.6+dfsg.tar.gz

- pocsuite3/thirdparty/*:
 - There are many third-party libraries embedded in the code; At least a few of
   them are already packaged for debian, so you use the ones in Debian when
   building the package and remove those convenience copies in e.g d/clean
- thirdparty/oset: 
  Seems to be from
  http://code.activestate.com/recipes/577624-orderedset/#  MIT licensed, in
  contracditction what is declared in d/copyright.  (That means, you need to do 
a
  complete copyright file review to have d/copyright correct)

- Package FTBFS in a clean pbuilder environment:

dh clean --with python3 --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
install -d 
/build/pocsuite3-1.7.6/debian/.debhelper/generated/_source/home
pybuild --clean -i python{version} -p 3.9
I: pybuild base:232: python3.9 setup.py clean 
Traceback (most recent call last):
  File "/build/pocsuite3-1.7.6/setup.py", line 14, in 
from pocsuite3 import __version__, __author__, __author_email__, __license__
  File "/build/pocsuite3-1.7.6/pocsuite3/__init__.py", line 10, in 
from .lib.core.common import set_paths
  File "/build/pocsuite3-1.7.6/pocsuite3/lib/core/common.py", line 20, in 

import chardet
ModuleNotFoundError: No module named 'chardet'
E: pybuild pybuild:353: clean: plugin distutils failed with: exit code=1: 
python3.9 setup.py clean 
dh_auto_clean: error: pybuild --clean -i python{version} -p 3.9 returned exit 
code 13
make: *** [debian/rules:6: clean] Error 13
dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2
I: copying local configuration
E: Failed autobuilding of package

shellcodes/data/linux/*bin
- Are they rebuilt during package build?

(The review might be incomplete, I ran out of time)

Cheers,
--
tobi

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Tian Qiao]

Control: tags -1 -moreinfo

> On Jun 18, 2021, at 4:28 PM, Tobias Frost  wrote:
> 
> Control: tags -1 moreinfo
> 
> Once ready, please reupload to mentors and remove the moreinfo tag.
> 
> -- 
> tobi


Hello.

pocsuite3_1.7.6-1 is now at https://mentors.debian.net/package/pocsuite3/ 


Please let me know if there is any other mistakes, thanks !

Regards,

—
  Tian

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Tian]

> On Jun 18, 2021, at 8:59 PM, Tobias Frost  wrote:
> 
> On Fri, Jun 18, 2021 at 10:59:18AM +, Paul Wise wrote:
>> On Fri, Jun 18, 2021 at 8:30 AM Tobias Frost wrote:
>> 
>>> I suggest to read [1] and all linked documents, and recreate the package.
>>> You'll find dh_make(1) from the package dh-make useful to generate boiler 
>>> plate
>>> templates for the debian directory. Those templates needs to be hand-edited
>>> afterwards, many of them wont be needed: you'd rm them… To get hints, you 
>>> may
>>> take a look a similar packages as well
>> 
>> The packages generated by stdeb are usually much closer to a final
>> package than those generated by dh-make, so I would suggest to fix the
>> existing packaging instead of starting from scratch.
> 
> I've just ran dh_make on it and did an diff: IMGO dh_make did a far
> better job than that from the dsc of that RFS. However, that is my bikeshed 
> color.
> 
>> 


Thank you for your attention and suggestions, I will fix these problems and 
recreate the package. Have a good day !

Regards,
--
fenix

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Tobias Frost]

On Fri, Jun 18, 2021 at 10:59:18AM +, Paul Wise wrote:
> On Fri, Jun 18, 2021 at 8:30 AM Tobias Frost wrote:
> 
> > I suggest to read [1] and all linked documents, and recreate the package.
> > You'll find dh_make(1) from the package dh-make useful to generate boiler 
> > plate
> > templates for the debian directory. Those templates needs to be hand-edited
> > afterwards, many of them wont be needed: you'd rm them… To get hints, you 
> > may
> > take a look a similar packages as well
> 
> The packages generated by stdeb are usually much closer to a final
> package than those generated by dh-make, so I would suggest to fix the
> existing packaging instead of starting from scratch.

I've just ran dh_make on it and did an diff: IMGO dh_make did a far
better job than that from the dsc of that RFS. However, that is my bikeshed 
color.

> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Paul Wise]

On Fri, Jun 18, 2021 at 8:30 AM Tobias Frost wrote:

> I suggest to read [1] and all linked documents, and recreate the package.
> You'll find dh_make(1) from the package dh-make useful to generate boiler 
> plate
> templates for the debian directory. Those templates needs to be hand-edited
> afterwards, many of them wont be needed: you'd rm them… To get hints, you may
> take a look a similar packages as well

The packages generated by stdeb are usually much closer to a final
package than those generated by dh-make, so I would suggest to fix the
existing packaging instead of starting from scratch.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Tobias Frost]

Control: tags -1 moreinfo

Hi Tian,

thanks for volunteering and starting to contribute to Debian!

On Wed, Jun 16, 2021 at 11:10:08PM +0800, Tian wrote:


>  pocsuite3 (1.7.5-1) unstable; urgency=low
>  .
>* source package automatically created by stdeb 0.10.0

Unfortunatly the quality of packages generated by some generator usually
not adequate for inclusion in Debian. If you check the mentors page
of the package [1], you'll see that there are many issues…

I suggest to read [1] and all linked documents, and recreate the package.
You'll find dh_make(1) from the package dh-make useful to generate boiler plate
templates for the debian directory. Those templates needs to be hand-edited
afterwards, many of them wont be needed: you'd rm them… To get hints, you may
take a look a similar packages as well

[1] https://mentors.debian.net/package/pocsuite3/
[2] https://mentors.debian.net/intro-maintainers/

Once ready, please reupload to mentors and remove the moreinfo tag.

-- 
tobi

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Tian]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "pocsuite3":

 * Package name: pocsuite3
   Version : 1.7.5-1
   Upstream Author : fenix from knownsec 404 team 
 * URL : http://pocsuite.org
 * License : GPL2.0
 * Vcs : https://github.com/knownsec/pocsuite3
   Section : python3

It builds those binary packages:

  pocsuite3 - an open-sourced remote vulnerability testing framework.

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/pocsuite3/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pocsuite3/pocsuite3_1.7.5-1.dsc

Changes for the initial release:

 pocsuite3 (1.7.5-1) unstable; urgency=low
 .
   * source package automatically created by stdeb 0.10.0

Regards,
-- 
  fenix