[NEW] security/gitleaks

2024-05-17 Thread lux 
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

2024-05-24 Thread lux 
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

2023-11-12 Thread lux 
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

2023-11-14 Thread lux 
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

2023-03-11 Thread lux 
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

2023-03-15 Thread lux 
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

2023-03-17 Thread lux 
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

2023-03-17 Thread lux 
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

2023-03-18 Thread lux 
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

2023-03-29 Thread lux 
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

2023-03-29 Thread lux 
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

2023-03-29 Thread lux 
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

2023-04-11 Thread lux 
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

2023-04-14 Thread lux 
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

2023-04-16 Thread lux 
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

2023-04-16 Thread lux 
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

2023-04-16 Thread lux 
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

2023-04-27 Thread lux 
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

2023-04-30 Thread lux 
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

2023-05-05 Thread lux 
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

2023-05-11 Thread lux 
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

2023-05-16 Thread lux 
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

2023-05-18 Thread lux 
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

2023-05-18 Thread lux 
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

2023-05-18 Thread lux 
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

2023-09-09 Thread lux 
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

2023-09-10 Thread lux 
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

2023-10-01 Thread lux 
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

2023-10-11 Thread lux 
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

2023-10-11 Thread lux 
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

2023-10-18 Thread lux 
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

2023-06-10 Thread lux 
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

2023-06-11 Thread lux 
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

2023-07-30 Thread lux 
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

2023-07-31 Thread lux 
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.