[NEW] security/gitleaks
Hello, Gitleaks is a SAST tool for detecting and preventing hardcoded secrets like passwords, api keys, and tokens in git repos. Gitleaks is an easy-to-use, all-in-one solution for detecting secrets, past or present, in your code. Github: https://github.com/gitleaks/gitleaks Here is a port of gitleaks, and test ok in amd64. ok? gitleaks.tar.gz Description: application/compressed-tar
Re: [NEW] security/gitleaks
On Sat, 2024-05-18 at 11:12 +0800, lux wrote: > Hello, > > Gitleaks is a SAST tool for detecting and preventing hardcoded > secrets like passwords, api keys, and tokens in git repos. Gitleaks > is an easy-to-use, all-in-one solution for detecting secrets, past or > present, in your code. > > Github: https://github.com/gitleaks/gitleaks > > Here is a port of gitleaks, and test ok in amd64. > > ok? ping
Re: [new] textproc/vgrep
On Wed, 2023-10-18 at 21:09 +0800, lux wrote: > On Sat, 2023-09-09 at 17:38 +, Omar Polo wrote: > > On 2023/09/09 23:51:20 +0800, lux wrote: > > > Github: https://github.com/vrothberg/vgrep > > > > > > The built-in grep command in OpenBSD is currently not supported, but it > > > works well with git-grep and ripgrep. I have tested it on AMD64 7.3 and > > > it works fine for me. > > > > Haven't tried the port, but have you tried if removing --color from > > the grep invocation (using a custom patch) works? Looking at the code > > they use --color=auto which our grep (rightly IMHO) doesn't support, > > but quickly looking at the code they don't seem to care about the > > escapes being there. > > > > If you go this route you may also consider changing -Z with --null. > > They seem to assume that -Z is to NUL terminate the file names, while > > in our and other grep(1) implementations is to force grep to behave as > > zgrep, we have --null for that. IIUC --null is more portable than -Z. > > > > > > > Hi, > vgrep now has OpenBSD support[1], I'm repost the port file. > > Thanks. > > [1]: https://github.com/vrothberg/vgrep/releases ping
Re: [new] textproc/vgrep
Hi, On Mon, 2023-11-13 at 11:06 +0100, Omar Polo wrote: > > > So, except the doubt regarding MODGO_VERSION format and why specifiying > v2.7.0 doesn't work (I tried also to append /v2 to MODGO_MODNAME), it's > okay for me to import. > > I think MODGO_VERSION just had to stay ugly: $ curl https://proxy.golang.org/github.com/vrothberg/vgrep/@latest {"Version":"v0.0.0-20231113051520-e0f509f71321","Time":"2023-11- 13T05:15:20Z","Origin":{"VCS":"git","URL":"https://github.com/vrothberg/vgrep","Hash":"e0f509f71321ca6a3650265917b97e010c302a5b "}} I have no other questions. Thank you :-)
[Update] editors/emacs.28.2
Hi ports@: Here is a patch for Emacs.28.2, fixed CVE-2022-45939, CVE-2022- 48337, CVE-2022-48338 and CVE-2022-48339. emacs-28.2.patch Description: Binary data
Re: [Update] editors/emacs.28.2
On Tue, 2023-03-14 at 14:12 +0100, Jeremie Courreges-Anglas wrote: > On Sun, Mar 12 2023, "lux" wrote: > > Hi ports@: > > > > Here is a patch for Emacs.28.2, fixed CVE-2022-45939, CVE-2022- > > 48337, CVE-2022-48338 and CVE-2022-48339. > > Committed with a few tweaks (REVISION bump, links to upstream > commits, > refreshed patches). > > From lux @ shellcodes dot org ^^ Thank you, but my email is lx@shellcodes dot org :-)
[Update] inputmethods/fcitx 5.0.22
Hi, Update for fcitx5 to 5.0.22. Index: Makefile === RCS file: /cvs/ports/inputmethods/fcitx/Makefile,v retrieving revision 1.23 diff -u -p -r1.23 Makefile --- Makefile21 Jun 2022 10:35:49 - 1.23 +++ Makefile18 Mar 2023 02:06:00 - @@ -1,6 +1,6 @@ COMMENT = flexible input method framework -DISTNAME = fcitx5-5.0.15 +DISTNAME = fcitx5-5.0.22 PKGNAME = ${DISTNAME:S/fcitx5/fcitx/} REVISION = 2 @@ -60,10 +60,10 @@ CONFIGURE_ARGS =-DENABLE_WAYLAND=OFF \ - DCMAKE_INSTALL_SYSCONFDIR=${PREFIX}/share/examples CFLAGS += -I${LOCALBASE}/include -I${X11BASE}/include -CXXFLAGS +=-I${LOCALBASE}/include -I${X11BASE}/include +CXXFLAGS +=-I${LOCALBASE}/include -I${X11BASE}/include -lc post-patch: cp ${FULLDISTDIR}/en_dict-20121020.tar.gz \ - ${WRKSRC}/src/modules/spell/dict/ + ${WRKSRC}/src/modules/spell .include Index: distinfo === RCS file: /cvs/ports/inputmethods/fcitx/distinfo,v retrieving revision 1.5 diff -u -p -r1.5 distinfo --- distinfo13 May 2022 15:37:46 - 1.5 +++ distinfo18 Mar 2023 02:06:00 - @@ -1,4 +1,4 @@ SHA256 (fcitx/en_dict-20121020.tar.gz) = xEpdeEeSXuqeTS0EdI1ELNKN2SmaC1cu99kerE9abOs= -SHA256 (fcitx/fcitx5-5.0.15.tar.xz) = ND3w8njcbbSv68d4Zk7kd9m9bAEchEblqonCC7F4bkE= +SHA256 (fcitx/fcitx5-5.0.22.tar.xz) = EyDQ6KizkwqKlW6rgKzu+WJJRhKSNlFb42yLdasEyHg= SIZE (fcitx/en_dict-20121020.tar.gz) = 630491 -SIZE (fcitx/fcitx5-5.0.15.tar.xz) = 1329272 +SIZE (fcitx/fcitx5-5.0.22.tar.xz) = 6831060 Index: pkg/PLIST === RCS file: /cvs/ports/inputmethods/fcitx/pkg/PLIST,v retrieving revision 1.1 diff -u -p -r1.1 PLIST --- pkg/PLIST 13 May 2022 15:37:47 - 1.1 +++ pkg/PLIST 18 Mar 2023 02:06:00 - @@ -176,6 +176,7 @@ lib/fcitx5/ @so lib/fcitx5/libclipboard.so @so lib/fcitx5/libdbus.so @so lib/fcitx5/libdbusfrontend.so +@so lib/fcitx5/libemoji.so lib/fcitx5/libexec/ @bin lib/fcitx5/libexec/comp-spell-dict @so lib/fcitx5/libfcitx4frontend.so @@ -216,6 +217,7 @@ share/fcitx5/addon/classicui.conf share/fcitx5/addon/clipboard.conf share/fcitx5/addon/dbus.conf share/fcitx5/addon/dbusfrontend.conf +share/fcitx5/addon/emoji.conf share/fcitx5/addon/fcitx4frontend.conf share/fcitx5/addon/ibusfrontend.conf share/fcitx5/addon/imselector.conf @@ -283,6 +285,144 @@ share/fcitx5/default/ur_IN share/fcitx5/default/zh_CN share/fcitx5/default/zh_HK share/fcitx5/default/zh_TW +share/fcitx5/emoji/ +share/fcitx5/emoji/data/ +share/fcitx5/emoji/data/af.dict +share/fcitx5/emoji/data/am.dict +share/fcitx5/emoji/data/ar.dict +share/fcitx5/emoji/data/ar_SA.dict +share/fcitx5/emoji/data/as.dict +share/fcitx5/emoji/data/ast.dict +share/fcitx5/emoji/data/az.dict +share/fcitx5/emoji/data/be.dict +share/fcitx5/emoji/data/bg.dict +share/fcitx5/emoji/data/bn.dict +share/fcitx5/emoji/data/br.dict +share/fcitx5/emoji/data/bs.dict +share/fcitx5/emoji/data/ca.dict +share/fcitx5/emoji/data/ccp.dict +share/fcitx5/emoji/data/ceb.dict +share/fcitx5/emoji/data/chr.dict +share/fcitx5/emoji/data/ckb.dict +share/fcitx5/emoji/data/cs.dict +share/fcitx5/emoji/data/cy.dict +share/fcitx5/emoji/data/da.dict +share/fcitx5/emoji/data/de.dict +share/fcitx5/emoji/data/de_CH.dict +share/fcitx5/emoji/data/dsb.dict +share/fcitx5/emoji/data/el.dict +share/fcitx5/emoji/data/en.dict +share/fcitx5/emoji/data/en_001.dict +share/fcitx5/emoji/data/en_AU.dict +share/fcitx5/emoji/data/en_CA.dict +share/fcitx5/emoji/data/en_GB.dict +share/fcitx5/emoji/data/es.dict +share/fcitx5/emoji/data/es_419.dict +share/fcitx5/emoji/data/es_MX.dict +share/fcitx5/emoji/data/es_US.dict +share/fcitx5/emoji/data/et.dict +share/fcitx5/emoji/data/eu.dict +share/fcitx5/emoji/data/fa.dict +share/fcitx5/emoji/data/fi.dict +share/fcitx5/emoji/data/fil.dict +share/fcitx5/emoji/data/fo.dict +share/fcitx5/emoji/data/fr.dict +share/fcitx5/emoji/data/fr_CA.dict +share/fcitx5/emoji/data/ga.dict +share/fcitx5/emoji/data/gd.dict +share/fcitx5/emoji/data/gl.dict +share/fcitx5/emoji/data/gu.dict +share/fcitx5/emoji/data/ha.dict +share/fcitx5/emoji/data/he.dict +share/fcitx5/emoji/data/hi.dict +share/fcitx5/emoji/data/hi_Latn.dict +share/fcitx5/emoji/data/hr.dict +share/fcitx5/emoji/data/hsb.dict +share/fcitx5/emoji/data/hu.dict +share/fcitx5/emoji/data/hy.dict +share/fcitx5/emoji/data/ia.dict +share/fcitx5/emoji/data/id.dict +share/fcitx5/emoji/data/ig.dict +share/fcitx5/emoji/data/is.dict +share/fcitx5/emoji/data/it.dict +share/fcitx5/emoji/data/ja.dict +share/fcitx5/emoji/data/jv.dict +share/fcitx5/emoji/data/ka.dict +share/fcitx5/emoji/data/kab.dict +share/fcitx5/emoji/data/kk.dict +share/fcitx5/emoji/data/kl.dict +share/fcitx5/emoji/data/km.dict +share/fcitx5/emoji/data/kn.dict +share/fcitx5/emoji/data/ko.dict +share/fcitx5/emoji/data/kok.d
[Update] net/proxychains-ng 4.16
Hi, Update for proxychains-ng to 4.16. Index: Makefile === RCS file: /cvs/ports/net/proxychains-ng/Makefile,v retrieving revision 1.5 diff -u -p -r1.5 Makefile --- Makefile11 Mar 2022 19:46:58 - 1.5 +++ Makefile18 Mar 2023 03:42:14 - @@ -1,6 +1,6 @@ COMMENT= redirect programs through one or more proxies -VERSION= 4.15 +VERSION= 4.16 DISTNAME= proxychains-ng-${VERSION} CATEGORIES=net security GH_ACCOUNT=rofl0r Index: distinfo === RCS file: /cvs/ports/net/proxychains-ng/distinfo,v retrieving revision 1.3 diff -u -p -r1.3 distinfo --- distinfo2 Sep 2021 10:36:50 - 1.3 +++ distinfo18 Mar 2023 03:42:14 - @@ -1,2 +1,2 @@ -SHA256 (proxychains-ng-4.15.tar.gz) = yU7d7Ti6oER3Zvbl0OwZY7snx7VbKnizBdb1jhcTiPg= -SIZE (proxychains-ng-4.15.tar.gz) = 49119 +SHA256 (proxychains-ng-4.16.tar.gz) = X2aQgETMDFBPSn5hiuOQyaeNEI0/cT14OeRAaT9Dtec= +SIZE (proxychains-ng-4.16.tar.gz) = 50726 Index: patches/patch-src_libproxychains_c === RCS file: patches/patch-src_libproxychains_c diff -N patches/patch-src_libproxychains_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-src_libproxychains_c 18 Mar 2023 03:42:14 - @@ -0,0 +1,13 @@ +--- /usr/obj/ports/proxychains-ng-4.16/proxychains-ng- 4.16/src/libproxychains.c.orig /usr/obj/ports/proxychains-ng-4.16/proxychains-ng- 4.16/src/libproxychains.c +@@ -729,8 +729,8 @@ + } + + HOOKFUNC(int, getnameinfo, const struct sockaddr *sa, socklen_t salen, +- char *host, socklen_t hostlen, char *serv, +- socklen_t servlen, int flags) ++ char *host, size_t hostlen, char *serv, ++ size_t servlen, int flags) + { + INIT(); + PFUNC();
Re: [Update] inputmethods/fcitx 5.0.22
On Sat, 2023-03-18 at 07:05 +, Stuart Henderson wrote: > > We are currently in release mode so won't be committing routine > updates for now > > That port has a maintainer, please CC them on any changes (I have > CC'd this mail) Ok, thanks. > > > -CXXFLAGS +=-I${LOCALBASE}/include -I${X11BASE}/include > > +CXXFLAGS +=-I${LOCALBASE}/include -I${X11BASE}/include -lc > > That doesn't seem right.. > My fault, thanks again. Index: Makefile === RCS file: /cvs/ports/inputmethods/fcitx/Makefile,v retrieving revision 1.23 diff -u -p -r1.23 Makefile --- Makefile21 Jun 2022 10:35:49 - 1.23 +++ Makefile18 Mar 2023 07:30:52 - @@ -1,8 +1,7 @@ COMMENT = flexible input method framework -DISTNAME = fcitx5-5.0.15 +DISTNAME = fcitx5-5.0.22 PKGNAME = ${DISTNAME:S/fcitx5/fcitx/} -REVISION = 2 SHARED_LIBS += Fcitx5Config 0.0 # 0.0 SHARED_LIBS += Fcitx5Core 0.0 # 0.0 @@ -64,6 +63,6 @@ CXXFLAGS += -I${LOCALBASE}/include -I${X post-patch: cp ${FULLDISTDIR}/en_dict-20121020.tar.gz \ - ${WRKSRC}/src/modules/spell/dict/ + ${WRKSRC}/src/modules/spell .include Index: distinfo === RCS file: /cvs/ports/inputmethods/fcitx/distinfo,v retrieving revision 1.5 diff -u -p -r1.5 distinfo --- distinfo13 May 2022 15:37:46 - 1.5 +++ distinfo18 Mar 2023 07:30:52 - @@ -1,4 +1,4 @@ SHA256 (fcitx/en_dict-20121020.tar.gz) = xEpdeEeSXuqeTS0EdI1ELNKN2SmaC1cu99kerE9abOs= -SHA256 (fcitx/fcitx5-5.0.15.tar.xz) = ND3w8njcbbSv68d4Zk7kd9m9bAEchEblqonCC7F4bkE= +SHA256 (fcitx/fcitx5-5.0.22.tar.xz) = EyDQ6KizkwqKlW6rgKzu+WJJRhKSNlFb42yLdasEyHg= SIZE (fcitx/en_dict-20121020.tar.gz) = 630491 -SIZE (fcitx/fcitx5-5.0.15.tar.xz) = 1329272 +SIZE (fcitx/fcitx5-5.0.22.tar.xz) = 6831060 Index: pkg/PLIST === RCS file: /cvs/ports/inputmethods/fcitx/pkg/PLIST,v retrieving revision 1.1 diff -u -p -r1.1 PLIST --- pkg/PLIST 13 May 2022 15:37:47 - 1.1 +++ pkg/PLIST 18 Mar 2023 07:30:52 - @@ -176,6 +176,7 @@ lib/fcitx5/ @so lib/fcitx5/libclipboard.so @so lib/fcitx5/libdbus.so @so lib/fcitx5/libdbusfrontend.so +@so lib/fcitx5/libemoji.so lib/fcitx5/libexec/ @bin lib/fcitx5/libexec/comp-spell-dict @so lib/fcitx5/libfcitx4frontend.so @@ -216,6 +217,7 @@ share/fcitx5/addon/classicui.conf share/fcitx5/addon/clipboard.conf share/fcitx5/addon/dbus.conf share/fcitx5/addon/dbusfrontend.conf +share/fcitx5/addon/emoji.conf share/fcitx5/addon/fcitx4frontend.conf share/fcitx5/addon/ibusfrontend.conf share/fcitx5/addon/imselector.conf @@ -283,6 +285,144 @@ share/fcitx5/default/ur_IN share/fcitx5/default/zh_CN share/fcitx5/default/zh_HK share/fcitx5/default/zh_TW +share/fcitx5/emoji/ +share/fcitx5/emoji/data/ +share/fcitx5/emoji/data/af.dict +share/fcitx5/emoji/data/am.dict +share/fcitx5/emoji/data/ar.dict +share/fcitx5/emoji/data/ar_SA.dict +share/fcitx5/emoji/data/as.dict +share/fcitx5/emoji/data/ast.dict +share/fcitx5/emoji/data/az.dict +share/fcitx5/emoji/data/be.dict +share/fcitx5/emoji/data/bg.dict +share/fcitx5/emoji/data/bn.dict +share/fcitx5/emoji/data/br.dict +share/fcitx5/emoji/data/bs.dict +share/fcitx5/emoji/data/ca.dict +share/fcitx5/emoji/data/ccp.dict +share/fcitx5/emoji/data/ceb.dict +share/fcitx5/emoji/data/chr.dict +share/fcitx5/emoji/data/ckb.dict +share/fcitx5/emoji/data/cs.dict +share/fcitx5/emoji/data/cy.dict +share/fcitx5/emoji/data/da.dict +share/fcitx5/emoji/data/de.dict +share/fcitx5/emoji/data/de_CH.dict +share/fcitx5/emoji/data/dsb.dict +share/fcitx5/emoji/data/el.dict +share/fcitx5/emoji/data/en.dict +share/fcitx5/emoji/data/en_001.dict +share/fcitx5/emoji/data/en_AU.dict +share/fcitx5/emoji/data/en_CA.dict +share/fcitx5/emoji/data/en_GB.dict +share/fcitx5/emoji/data/es.dict +share/fcitx5/emoji/data/es_419.dict +share/fcitx5/emoji/data/es_MX.dict +share/fcitx5/emoji/data/es_US.dict +share/fcitx5/emoji/data/et.dict +share/fcitx5/emoji/data/eu.dict +share/fcitx5/emoji/data/fa.dict +share/fcitx5/emoji/data/fi.dict +share/fcitx5/emoji/data/fil.dict +share/fcitx5/emoji/data/fo.dict +share/fcitx5/emoji/data/fr.dict +share/fcitx5/emoji/data/fr_CA.dict +share/fcitx5/emoji/data/ga.dict +share/fcitx5/emoji/data/gd.dict +share/fcitx5/emoji/data/gl.dict +share/fcitx5/emoji/data/gu.dict +share/fcitx5/emoji/data/ha.dict +share/fcitx5/emoji/data/he.dict +share/fcitx5/emoji/data/hi.dict +share/fcitx5/emoji/data/hi_Latn.dict +share/fcitx5/emoji/data/hr.dict +share/fcitx5/emoji/data/hsb.dict +share/fcitx5/emoji/data/hu.dict +share/fcitx5/emoji/data/hy.dict +share/fcitx5/emoji/data/ia.dict +share/fcitx5/emoji/data/id.dict +share/fcitx5/emoji/data/ig.dict +share/fcitx5/emoji/data/is.dict +share/fcitx5/emoji/data/it.dict +share/fcitx5/emoji/data/ja.dict +share/fcitx5/emoji/data/jv.dict +s
Re: [Update] inputmethods/fcitx 5.0.22
On Mon, 2023-03-20 at 08:18 +, Yifei Zhan wrote: > On 23/03/18 10:34AM, lux wrote: > > Hi, > > > > Update for fcitx5 to 5.0.22. > > > > Thanks for taking care of it :) > > As Stuart mentioned, we will be focusing on testing existing ports > instead of > updating as the next release is approching. After the release I will > refresh [1] > and try to update the fcitx family and other related packages. > > [1]: https://marc.info/?l=openbsd-ports&m=167134126418231&w=2 > > Hi, ports unlocked. - https://www.mail-archive.com/ports@openbsd.org/msg116966.html
[Update] net/proxychains-ng 4.16
Hi, Update for proxychains-ng to 4.16. Index: Makefile === RCS file: /cvs/ports/net/proxychains-ng/Makefile,v retrieving revision 1.5 diff -u -p -r1.5 Makefile --- Makefile11 Mar 2022 19:46:58 - 1.5 +++ Makefile18 Mar 2023 03:42:14 - @@ -1,6 +1,6 @@ COMMENT= redirect programs through one or more proxies -VERSION= 4.15 +VERSION= 4.16 DISTNAME= proxychains-ng-${VERSION} CATEGORIES=net security GH_ACCOUNT=rofl0r Index: distinfo === RCS file: /cvs/ports/net/proxychains-ng/distinfo,v retrieving revision 1.3 diff -u -p -r1.3 distinfo --- distinfo2 Sep 2021 10:36:50 - 1.3 +++ distinfo18 Mar 2023 03:42:14 - @@ -1,2 +1,2 @@ -SHA256 (proxychains-ng-4.15.tar.gz) = yU7d7Ti6oER3Zvbl0OwZY7snx7VbKnizBdb1jhcTiPg= -SIZE (proxychains-ng-4.15.tar.gz) = 49119 +SHA256 (proxychains-ng-4.16.tar.gz) = X2aQgETMDFBPSn5hiuOQyaeNEI0/cT14OeRAaT9Dtec= +SIZE (proxychains-ng-4.16.tar.gz) = 50726 Index: patches/patch-src_libproxychains_c === RCS file: patches/patch-src_libproxychains_c diff -N patches/patch-src_libproxychains_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-src_libproxychains_c 18 Mar 2023 03:42:14 - @@ -0,0 +1,13 @@ +--- /usr/obj/ports/proxychains-ng-4.16/proxychains-ng- 4.16/src/libproxychains.c.orig /usr/obj/ports/proxychains-ng-4.16/proxychains-ng- 4.16/src/libproxychains.c +@@ -729,8 +729,8 @@ + } + + HOOKFUNC(int, getnameinfo, const struct sockaddr *sa, socklen_t salen, +- char *host, socklen_t hostlen, char *serv, +- socklen_t servlen, int flags) ++ char *host, size_t hostlen, char *serv, ++ size_t servlen, int flags) + { + INIT(); + PFUNC();
[New] security/Nuclei 2.9.0
Hi Nuclei is a fast and customisable vulnerability scanner based on simple YAML based DSL. Nuclei is used to send requests across targets based on a template, leading to zero false positives and providing fast scanning on a large number of hosts. Nuclei offers scanning for a variety of protocols, including TCP, DNS, HTTP, SSL, File, Whois, Websocket, Headless etc. With powerful and flexible templating, Nuclei can be used to model all kinds of security checks. I built a port and tested on OpenBSD. Cheers! <>
Re: [New] security/Nuclei 2.9.0
On Thu, 2023-03-30 at 08:53 +0800, lux wrote: > Hi > > Nuclei is a fast and customisable vulnerability scanner based on > simple > YAML based DSL. > > Nuclei is used to send requests across targets based on a template, > leading to zero false positives and providing fast scanning on a > large > number of hosts. Nuclei offers scanning for a variety of protocols, > including TCP, DNS, HTTP, SSL, File, Whois, Websocket, Headless etc. > With powerful and flexible templating, Nuclei can be used to model > all > kinds of security checks. > > I built a port and tested on OpenBSD. > > Cheers! Ping
Re: [New] security/Nuclei 2.9.0
Hi OP, thanks for helping me test and modify this patch, I compiled successfully and it works. 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.
Re: [New] security/Nuclei 2.9.0
On Sat, 2023-04-15 at 21:02 +0200, Omar Polo wrote: > > 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.) > > Thank you. I'm test is ok. OK?
[security-update] editors/emacs.28.2
Hi, these patches fix CVE-2023-28617, CVE-2023-27985 and CVE-2023- 27986. The release of Emacs 28.3 has hit some snags[1], and I don't think it will be released anytime soon (will not even release), so I'll submit the security patch first. - [1] https://lists.gnu.org/archive/html/emacs-devel/2023-04/msg00262.html <>
Re: [security-update] editors/emacs.28.2
On Sun, 2023-04-16 at 23:58 +0200, Jeremie Courreges-Anglas wrote: > The .desktop patch is so ugly. Yes, I can only think of it as ASCII art..
Re: [New] security/Nuclei 2.9.0 to 2.9.2
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 <>
[Update] net/proxychains-ng 4.16
Hi, Update for proxychains-ng to 4.16, and test ok. Index: Makefile === RCS file: /cvs/ports/net/proxychains-ng/Makefile,v retrieving revision 1.5 diff -u -p -r1.5 Makefile --- Makefile11 Mar 2022 19:46:58 - 1.5 +++ Makefile18 Mar 2023 03:42:14 - @@ -1,6 +1,6 @@ COMMENT= redirect programs through one or more proxies -VERSION= 4.15 +VERSION= 4.16 DISTNAME= proxychains-ng-${VERSION} CATEGORIES=net security GH_ACCOUNT=rofl0r Index: distinfo === RCS file: /cvs/ports/net/proxychains-ng/distinfo,v retrieving revision 1.3 diff -u -p -r1.3 distinfo --- distinfo2 Sep 2021 10:36:50 - 1.3 +++ distinfo18 Mar 2023 03:42:14 - @@ -1,2 +1,2 @@ -SHA256 (proxychains-ng-4.15.tar.gz) = yU7d7Ti6oER3Zvbl0OwZY7snx7VbKnizBdb1jhcTiPg= -SIZE (proxychains-ng-4.15.tar.gz) = 49119 +SHA256 (proxychains-ng-4.16.tar.gz) = X2aQgETMDFBPSn5hiuOQyaeNEI0/cT14OeRAaT9Dtec= +SIZE (proxychains-ng-4.16.tar.gz) = 50726 Index: patches/patch-src_libproxychains_c === RCS file: patches/patch-src_libproxychains_c diff -N patches/patch-src_libproxychains_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-src_libproxychains_c 18 Mar 2023 03:42:14 - @@ -0,0 +1,13 @@ +--- /usr/obj/ports/proxychains-ng-4.16/proxychains-ng- 4.16/src/libproxychains.c.orig /usr/obj/ports/proxychains-ng-4.16/proxychains-ng- 4.16/src/libproxychains.c +@@ -729,8 +729,8 @@ + } + + HOOKFUNC(int, getnameinfo, const struct sockaddr *sa, socklen_t salen, +- char *host, socklen_t hostlen, char *serv, +- socklen_t servlen, int flags) ++ char *host, size_t hostlen, char *serv, ++ size_t servlen, int flags) + { + INIT(); + PFUNC();
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? <>
Re: [Update] net/proxychains-ng 4.16
On Sun, 2023-04-30 at 22:08 +0800, lux wrote: > Hi, > > Update for proxychains-ng to 4.16, and test ok. > > > > Index: Makefile > === > RCS file: /cvs/ports/net/proxychains-ng/Makefile,v > retrieving revision 1.5 > diff -u -p -r1.5 Makefile > --- Makefile11 Mar 2022 19:46:58 - 1.5 > +++ Makefile18 Mar 2023 03:42:14 - > @@ -1,6 +1,6 @@ > COMMENT= redirect programs through one or more proxies > > -VERSION= 4.15 > +VERSION= 4.16 > DISTNAME= proxychains-ng-${VERSION} > CATEGORIES=net security > GH_ACCOUNT=rofl0r > Index: distinfo > === > RCS file: /cvs/ports/net/proxychains-ng/distinfo,v > retrieving revision 1.3 > diff -u -p -r1.3 distinfo > --- distinfo2 Sep 2021 10:36:50 - 1.3 > +++ distinfo18 Mar 2023 03:42:14 - > @@ -1,2 +1,2 @@ > -SHA256 (proxychains-ng-4.15.tar.gz) = > yU7d7Ti6oER3Zvbl0OwZY7snx7VbKnizBdb1jhcTiPg= > -SIZE (proxychains-ng-4.15.tar.gz) = 49119 > +SHA256 (proxychains-ng-4.16.tar.gz) = > X2aQgETMDFBPSn5hiuOQyaeNEI0/cT14OeRAaT9Dtec= > +SIZE (proxychains-ng-4.16.tar.gz) = 50726 > Index: patches/patch-src_libproxychains_c > === > RCS file: patches/patch-src_libproxychains_c > diff -N patches/patch-src_libproxychains_c > --- /dev/null 1 Jan 1970 00:00:00 - > +++ patches/patch-src_libproxychains_c 18 Mar 2023 03:42:14 - > @@ -0,0 +1,13 @@ > +--- /usr/obj/ports/proxychains-ng-4.16/proxychains-ng- > 4.16/src/libproxychains.c.orig > /usr/obj/ports/proxychains-ng-4.16/proxychains-ng- > 4.16/src/libproxychains.c > +@@ -729,8 +729,8 @@ > + } > + > + HOOKFUNC(int, getnameinfo, const struct sockaddr *sa, socklen_t > salen, > +- char *host, socklen_t hostlen, char *serv, > +- socklen_t servlen, int flags) > ++ char *host, size_t hostlen, char *serv, > ++ size_t servlen, int flags) > + { > + INIT(); > + PFUNC(); > ping
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
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
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 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.
[new] textproc/vgrep
Hi ports@, vgrep is a pager for grep, git-grep, ripgrep and similar grep implementations, and allows for opening the indexed file locations in a user-specified editor such as vim or emacs. vgrep is inspired by the ancient cgvg scripts but extended to perform further operations such as listing statistics of files and directory trees or showing the context lines before and after the matches. Github: https://github.com/vrothberg/vgrep The built-in grep command in OpenBSD is currently not supported, but it works well with git-grep and ripgrep. I have tested it on AMD64 7.3 and it works fine for me. vgrep.tar.gz Description: application/compressed-tar
Re: [new] textproc/vgrep
On Sat, 2023-09-09 at 19:38 +0200, Omar Polo wrote: > On 2023/09/09 23:51:20 +0800, lux wrote: > > Github: https://github.com/vrothberg/vgrep > > > > The built-in grep command in OpenBSD is currently not supported, > > but it > > works well with git-grep and ripgrep. I have tested it on AMD64 7.3 > > and > > it works fine for me. > > Haven't tried the port, but have you tried if removing --color from > the grep invocation (using a custom patch) works? Looking at the > code > they use --color=auto which our grep (rightly IMHO) doesn't support, > but quickly looking at the code they don't seem to care about the > escapes being there. > > If you go this route you may also consider changing -Z with --null. > They seem to assume that -Z is to NUL terminate the file names, while > in our and other grep(1) implementations is to force grep to behave > as > zgrep, we have --null for that. IIUC --null is more portable than - > Z. > > Thank you, I've made a patch to remove the --color parameter but still retain the -Z parameter. However, using the --null parameter caused the original program's output to be misaligned. Now the program works fine. Here's the patch content: Index: vgrep.go --- vgrep.go.orig +++ vgrep.go @@ -311,10 +311,9 @@ func (v *vgrep) grep(args []string) { cmd = append(cmd, args...) greptype = GITGrep } else { - env = "GREP_COLORS='ms=01;31:mc=:sl=:cx=:fn=:ln=:se=:bn='" - cmd = []string{"grep", "-ZHInr", "--color=always"} + cmd = []string{"grep", "-ZHInr"} cmd = append(cmd, args...) - greptype = v.getGrepType() + greptype = "BSD" } output, err := v.runCommand(cmd, env) if err != nil { vgrep.tar.gz Description: application/compressed-tar
[new] net/simplehttpserver
Hi ports@, simplehttpserver with in addition a fully customizable TCP server, both supporting TLS. Github: https://github.com/projectdiscovery/simplehttpserver Features: - HTTP/S Web Server - File Server with arbitrary directory support - HTTP request/response dump - Configurable ip address and listening port - Configurable HTTP/TCP server with customizable response via YAML template Thanks. simplehttpserver.tar.gz Description: application/compressed-tar
Re: [new] net/simplehttpserver
On Sun, 2023-10-01 at 17:48 +0800, lux wrote: > Hi ports@, > > simplehttpserver with in addition a fully customizable TCP server, > both supporting TLS. > > Github: https://github.com/projectdiscovery/simplehttpserver > > Features: > > - HTTP/S Web Server > > - File Server with arbitrary directory support > > - HTTP request/response dump > > - Configurable ip address and listening port > > - Configurable HTTP/TCP server with customizable response via YAML > template > > Thanks. > > ping. simplehttpserver.tar.gz Description: application/compressed-tar
Re: [new] net/simplehttpserver
On Wed, 2023-10-11 at 16:39 +0100, Stuart Henderson wrote: > upstream says, "This project is intended for development purposes only; > it should not be used in production". is it really a good thing to have > in ports? > Hi, because this is not a long-term running web service, it is typically used for temporary purposes such as file transfer, testing, etc. As an alternative to the inadequate python -m http.server. The most important aspect is that it provides HTTPS support and concurrency.
Re: [new] textproc/vgrep
On Sat, 2023-09-09 at 17:38 +, Omar Polo wrote: > On 2023/09/09 23:51:20 +0800, lux wrote: > > Github: https://github.com/vrothberg/vgrep > > > > The built-in grep command in OpenBSD is currently not supported, but it > > works well with git-grep and ripgrep. I have tested it on AMD64 7.3 and > > it works fine for me. > > Haven't tried the port, but have you tried if removing --color from > the grep invocation (using a custom patch) works? Looking at the code > they use --color=auto which our grep (rightly IMHO) doesn't support, > but quickly looking at the code they don't seem to care about the > escapes being there. > > If you go this route you may also consider changing -Z with --null. > They seem to assume that -Z is to NUL terminate the file names, while > in our and other grep(1) implementations is to force grep to behave as > zgrep, we have --null for that. IIUC --null is more portable than -Z. > > > Hi, vgrep now has OpenBSD support[1], I'm repost the port file. Thanks. [1]: https://github.com/vrothberg/vgrep/releases vgrep.tar.gz Description: application/compressed-tar
[new] textproc/htmlq
Hi ports@, htmlq is a like `jq' tool, but for HTML. Uses CSS selectors to extract bits of content from HTML files. Github: https://github.com/mgdm/htmlq I'm make a port, and test on AMD64 7.3, works fine for me: $ uname -a OpenBSD openbsd 7.3 GENERIC.MP#1125 amd6 $ curl --silent www.openbsd.org | htmlq title OpenBSD $ curl --silent www.openbsd.org | htmlq --text title OpenBSD $ curl --silent 'https://www.openbsd.org/faq/faq4.html#Download' | htmlq --attribute href a | grep '\.iso' https://cdn.openbsd.org/pub/OpenBSD/7.3/alpha/install73.iso ... Known issues at compile time, cargo will generate a warning when it is compiled: > warning: the following packages contain code that will be rejected by a future version of Rust: html5ever v0.25.1 This warn is about trailing semicolons when using Rust macros (https://github.com/rust-lang/rust/issues/79813) and can be ignored for now. OK to import? Thank you. <>
Re: [new] textproc/htmlq
On Sun, 2023-06-11 at 09:31 +0100, Stuart Henderson wrote: > On 2023/06/10 21:13, lux wrote: > > Hi ports@, > > > > htmlq is a like `jq' tool, but for HTML. Uses CSS selectors to > > extract > > bits of content from HTML files. > > > > Github: https://github.com/mgdm/htmlq > > > > I'm make a port, and test on AMD64 7.3, works fine for me: > > > > $ uname -a > > OpenBSD openbsd 7.3 GENERIC.MP#1125 amd6 > > $ curl --silent www.openbsd.org | htmlq title > > OpenBSD > > $ curl --silent www.openbsd.org | htmlq --text title > > OpenBSD > > $ curl --silent 'https://www.openbsd.org/faq/faq4.html#Download' | > > htmlq --attribute href a | grep '\.iso' > > https://cdn.openbsd.org/pub/OpenBSD/7.3/alpha/install73.iso > > ... > > > > Known issues at compile time, cargo will generate a warning when it > > is > > compiled: > > > > > warning: the following packages contain code that will be > > > rejected by > > a future version of Rust: html5ever v0.25.1 > > > > This warn is about trailing semicolons when using Rust macros > > (https://github.com/rust-lang/rust/issues/79813) and can be ignored > > for > > now. > > > > OK to import? Thank you. > > - Should use crates.inc not modules.inc > > - You have this... > > # for riscv64 and powerpc65, please keep: libc >= 0.2.113 > MODCARGO_CRATES_UPDATE = libc > > but you didn't use an updated libc version in the MKDCARGO_CRATES > lines > > (also typo, should be powerpc64) > > - there's a lot of repetition in pkg_info because you've included > things > in DESCR which are already printed - the contents of COMMENT, and the > website URL which is added automatically from HOMEPAGE: > > $ pkg_info htmlq > Information for inst:htmlq-0.4.0 > > Comment: > like jq, but for HTML > > Description: > Like jq, but for HTML. Uses CSS selectors to extract bits of content > from HTML files. > > For information about how to use this, see > https://github.com/mgdm/htmlq. > > Maintainer: Xi Lu > > WWW: https://github.com/mgdm/htmlq > > - little request, I'd find it easier if you sent tar.gz rather than > zip, > vim's archive viewer is a little nicer for tar.gz (can show all files > in a directory in one screen, rather than having to open them one by > one, which makes it slightly faster to read through when reviewing) > Hi, I fixed, thank you. htmlq.tar.gz Description: application/compressed-tar
[Update] editors/emacs 28.2 -> 29.1
Hi, Emacs 29.1 was released yesterday, I update to 29.1. I attach a port file. Best regards Xi Lu emacs.tar.gz Description: application/compressed-tar
Re: [Update] editors/emacs 28.2 -> 29.1
On Mon, 2023-07-31 at 11:01 +0200, Omar Polo wrote: > > There are a couple of issues: > > - x11/gtk3,-guic needs to be changed to x11/gtk4,-guic (done in diff > below) Hi OP, I apologize, but I couldn't find x11/gtk4,-guic.