Re: [New] security/Nuclei 2.9.2 -> 2.9.3
On 2023/05/19 11:32:49 +0100, Stuart Henderson wrote: > On 2023/05/19 00:25, lux wrote: > > On Thu, 2023-05-18 at 16:44 +0100, Stuart Henderson wrote: > > > > > > I think you misunderstand - nuclei always prints that message even > > > when > > > it has only just downloaded/updated, so there's no chance they are > > > out > > > of date. > > > > > > > Hi, I reviewed the Nuclei code and it is a bug in the upstream code and > > has nothing to do with the build. I will communicate with upstream > > development. Thank you. > > > > Thanks. OK sthen@ to import Imported, thanks!
Re: [New] security/Nuclei 2.9.2 -> 2.9.3
On 2023/05/19 00:25, lux wrote: > On Thu, 2023-05-18 at 16:44 +0100, Stuart Henderson wrote: > > > > I think you misunderstand - nuclei always prints that message even > > when > > it has only just downloaded/updated, so there's no chance they are > > out > > of date. > > > > Hi, I reviewed the Nuclei code and it is a bug in the upstream code and > has nothing to do with the build. I will communicate with upstream > development. Thank you. > Thanks. OK sthen@ to import
Re: [New] security/Nuclei 2.9.2 -> 2.9.3
On Thu, 2023-05-18 at 16:44 +0100, Stuart Henderson wrote: > > I think you misunderstand - nuclei always prints that message even > when > it has only just downloaded/updated, so there's no chance they are > out > of date. > Hi, I reviewed the Nuclei code and it is a bug in the upstream code and has nothing to do with the build. I will communicate with upstream development. Thank you.
Re: [New] security/Nuclei 2.9.2 -> 2.9.3
On Thu, 2023-05-18 at 16:48 +0100, Stuart Henderson wrote: > On 2023/05/18 23:07, lux wrote: > > Also I updated Nuclei to the latest version v2.9.4, and test ok. > > PS: > > The part which requires multiple committers to be involved is the > initial import. Updates can in many cases be done by just one > committer, > especially for 'leaf' ports which don't impact the rest of the ports > tree. > > So, in general if there are small upstream updates while working on > getting a port into shape for import, I think it is better to skip > them > until after the port is committed (unless the changes are > particularly > important). > > Otherwise there is more to re-check each time and things are likely > to take longer.. > > Ok, thank you for your help.
Re: [New] security/Nuclei 2.9.2 -> 2.9.3
On 2023/05/18 23:07, lux wrote: > Also I updated Nuclei to the latest version v2.9.4, and test ok. PS: The part which requires multiple committers to be involved is the initial import. Updates can in many cases be done by just one committer, especially for 'leaf' ports which don't impact the rest of the ports tree. So, in general if there are small upstream updates while working on getting a port into shape for import, I think it is better to skip them until after the port is committed (unless the changes are particularly important). Otherwise there is more to re-check each time and things are likely to take longer..
Re: [New] security/Nuclei 2.9.2 -> 2.9.3
On 2023/05/18 23:07, lux wrote: > > - I always get "[INF] Your current nuclei-templates v9.5.0 are > > outdated. Latest is v9.5.0" - is that just a problem with upstream or > > does it suggest there's a problem with the way that nuclei is built > > in the port? > > Nuclei can download/update templates automatically, or manually using > the `-ut' parameter, so not need built to port. I think you misunderstand - nuclei always prints that message even when it has only just downloaded/updated, so there's no chance they are out of date.
Re: [New] security/Nuclei 2.9.2 -> 2.9.3
Hi, thank you for your reply. On Thu, 2023-05-18 at 09:09 +0100, Stuart Henderson wrote: > - make test fails with "no required module provides package > github.com/projectdiscovery/nuclei/v2". can it be fixed? if not then > maybe NO_TEST is appropriate Not need test, `make test' is only for developers to use for development, so I add the `NO_TEST=Yes'. > > - seems that https://nuclei.projectdiscovery.io/ would make a better > HOMEPAGE Changed. > > - a package with just a single binary is not very user-friendly, > is there any documentation that could be added? if not, then maybe > it's at least worth adding "For information about how to use this, > see https://nuclei.projectdiscovery.io/nuclei/get-started/"; to > pkg/DESCR. > Changed. > - I always get "[INF] Your current nuclei-templates v9.5.0 are > outdated. Latest is v9.5.0" - is that just a problem with upstream or > does it suggest there's a problem with the way that nuclei is built > in the port? Nuclei can download/update templates automatically, or manually using the `-ut' parameter, so not need built to port. Also I updated Nuclei to the latest version v2.9.4, and test ok. Thanks again. Commit? <>
Re: [New] security/Nuclei 2.9.2 -> 2.9.3
- make test fails with "no required module provides package github.com/projectdiscovery/nuclei/v2". can it be fixed? if not then maybe NO_TEST is appropriate - seems that https://nuclei.projectdiscovery.io/ would make a better HOMEPAGE - a package with just a single binary is not very user-friendly, is there any documentation that could be added? if not, then maybe it's at least worth adding "For information about how to use this, see https://nuclei.projectdiscovery.io/nuclei/get-started/"; to pkg/DESCR. - I always get "[INF] Your current nuclei-templates v9.5.0 are outdated. Latest is v9.5.0" - is that just a problem with upstream or does it suggest there's a problem with the way that nuclei is built in the port?
Re: [New] security/Nuclei 2.9.2 -> 2.9.3
On Fri, 2023-05-05 at 23:42 +0800, lux wrote: > On Fri, 2023-04-28 at 01:00 +0800, lux wrote: > > On Sat, 2023-04-15 at 21:02 +0200, Omar Polo wrote: > > > On 2023/04/14 21:30:26 +0800, lux wrote: > > > > On Wed, 2023-04-12 at 21:58 +0200, Omar Polo wrote: > > > > > I haven't tested it, but the build ends with a > > > > > > > > > > : zsyscall_openbsd_amd64.s:213 > > > > > : (syscall/zsyscall_openbsd_amd64.s:213)([...]/go-link- > > > > > 1246028766/go.o: > > > > > : (syscall.libc_syscall_trampoline.abi0)): warning: syscall() > > > > > may > > > > > go > > > > > : away, please rewrite code to use direct calls > > > > > > > > > > which hints that it may broke a runtime. > > > > > > > > > > > > > This warning comes from lib/libc/dlfcn/init.c: > > > > > > > > #if defined(APIWARN) > > > > __warn_references(syscall, > > > > "syscall() may go away, please rewrite code to use direct > > > > calls"); > > > > #endif > > > > > > > > I think we may need to wait for the Go language upstream code > > > > to > > > > make > > > > changes. > > > > > > Yep, it comes since some dependency of nuclei is calling > > > syscall() > > > directly. Don't know how to tell which it is. However, that > > > doesn't > > > imply that the port is broken, it's just a hint that it *might* > > > be > > > so. > > > I haven't tested, beside a very brief test, so can't say for > > > sure. > > > If > > > you've tested it throughfully then it's fine. > > > > > > (this error may even go away when upstream updates their deps.) > > > > > > > > > > Ping. > > > > Update to 2.9.2 > > Ping, and update to 2.9.3 > > Changelog: > https://github.com/projectdiscovery/nuclei/releases/tag/v2.9.3 > > ok? Ping, I tested it with no problem, ok?
Re: [New] security/Nuclei 2.9.2 -> 2.9.3
On Fri, 2023-04-28 at 01:00 +0800, lux wrote: > On Sat, 2023-04-15 at 21:02 +0200, Omar Polo wrote: > > On 2023/04/14 21:30:26 +0800, lux wrote: > > > On Wed, 2023-04-12 at 21:58 +0200, Omar Polo wrote: > > > > I haven't tested it, but the build ends with a > > > > > > > > : zsyscall_openbsd_amd64.s:213 > > > > : (syscall/zsyscall_openbsd_amd64.s:213)([...]/go-link- > > > > 1246028766/go.o: > > > > : (syscall.libc_syscall_trampoline.abi0)): warning: syscall() > > > > may > > > > go > > > > : away, please rewrite code to use direct calls > > > > > > > > which hints that it may broke a runtime. > > > > > > > > > > This warning comes from lib/libc/dlfcn/init.c: > > > > > > #if defined(APIWARN) > > > __warn_references(syscall, > > > "syscall() may go away, please rewrite code to use direct > > > calls"); > > > #endif > > > > > > I think we may need to wait for the Go language upstream code to > > > make > > > changes. > > > > Yep, it comes since some dependency of nuclei is calling syscall() > > directly. Don't know how to tell which it is. However, that > > doesn't > > imply that the port is broken, it's just a hint that it *might* be > > so. > > I haven't tested, beside a very brief test, so can't say for sure. > > If > > you've tested it throughfully then it's fine. > > > > (this error may even go away when upstream updates their deps.) > > > > > > Ping. > > Update to 2.9.2 Ping, and update to 2.9.3 Changelog: https://github.com/projectdiscovery/nuclei/releases/tag/v2.9.3 ok? <>
