Re: UPDATE: net/kdeconnect-kde
On Fri Nov 12, 2021 at 06:04:47PM +0100, Rafael Sadowski wrote:
> On Sat Sep 11, 2021 at 08:10:51AM +0200, Rafael Sadowski wrote:
> > Update kdeconnect-kde to 21.08.1 and switch to x11/kde-applications.
> > kdeconnect is part of KDE Gear now. Unfortunately we have to disable two
> > plugins because they depends on Wayland.
> >
> > Does it make sense to do this update WITHOUT the two plugins?
> >
> > Feedback, OK?
> >
>
> New diff with the following changes:
>
> - Add missing dependencies, spotted by Ingo
> - Fix homepage
> - Remove py2
>
> For test, you need an up-to-date ports tree.
>
> OK?
Ping
>
> diff --git a/net/kdeconnect-kde/Makefile b/net/kdeconnect-kde/Makefile
> index b8facbea237..e4489b07b9a 100644
> --- a/net/kdeconnect-kde/Makefile
> +++ b/net/kdeconnect-kde/Makefile
> @@ -2,46 +2,51 @@
>
> COMMENT =KDE app that allows your devices to communicate
>
> -V = 1.4.1
> -DISTNAME = kdeconnect-kde-${V}
> +DISTNAME = kdeconnect-kde-${MODKDE_VERSION}
>
> -SHARED_LIBS += kdeconnectcore 1.0 # 1.4
> -SHARED_LIBS += kdeconnectinterfaces1.0 # 1.4
> -SHARED_LIBS += kdeconnectsmshelper 0.0 # 1.4
> +SHARED_LIBS += kdeconnectcore 2.0 # 1.4
> +SHARED_LIBS += kdeconnectinterfaces2.0 # 1.4
> SHARED_LIBS += kdeconnectpluginkcm 0.0 # 1.4
>
> CATEGORIES = net
>
> -HOMEPAGE = https://invent.kde.org/network/kdeconnect-kde
> +HOMEPAGE = https://kdeconnect.kde.org
>
> MAINTAINER = Ingo Feinerer
>
> # GPLv2+
> -PERMIT_PACKAGE =Yes
> +PERMIT_PACKAGE = Yes
>
> WANTLIB += ${COMPILER_LIBCXX} ICE KF5Auth KF5AuthCore KF5Bookmarks
> WANTLIB += KF5Codecs KF5Completion KF5ConfigCore KF5ConfigGui
> WANTLIB += KF5ConfigWidgets KF5CoreAddons KF5DBusAddons KF5I18n
> WANTLIB += KF5IconThemes KF5ItemViews KF5JobWidgets KF5KCMUtils
> -WANTLIB += KF5KIOCore KF5KIOFileWidgets KF5KIOWidgets KF5Notifications
> KF5People
> -WANTLIB += KF5Service KF5Solid KF5WidgetsAddons KF5XmlGui Qt5Concurrent
> -WANTLIB += Qt5Core Qt5DBus Qt5Gui Qt5Network Qt5Quick Qt5Qml Qt5Widgets
> +WANTLIB += KF5KIOCore KF5KIOFileWidgets KF5KIOGui KF5KIONTLM KF5KIOWidgets
> +WANTLIB += KF5Notifications KF5People KF5Service KF5Solid KF5WaylandClient
> +WANTLIB += KF5WidgetsAddons KF5WindowSystem KF5XmlGui Qt5Concurrent
> +WANTLIB += Qt5Core Qt5DBus Qt5Gui Qt5Network Qt5Qml Qt5QmlModels
> +WANTLIB += Qt5Quick Qt5QuickControls2 Qt5WaylandClient Qt5Widgets
> WANTLIB += Qt5X11Extras Qt5Xml SM X11 Xext Xtst c fakekey m qca-qt5
> +WANTLIB += wayland-client
>
> -MASTER_SITES = ${MASTER_SITE_KDE:=stable/kdeconnect/${V}/}
> +MASTER_SITES =
> ${MASTER_SITE_KDE:=stable/release-service/${MODKDE_VERSION}/src/}
>
> -MODULES =devel/kf5 \
> +MODULES =x11/kde-applications \
> + devel/kf5 \
> lang/python
> -MODPY_VERSION = ${MODPY_DEFAULT_VERSION_2}
>
> BUILD_DEPENDS = devel/gettext,-tools \
> + devel/kf5/qqc2-desktop-style \
> devel/kf5/kirigami2
> +
> RUN_DEPENDS =devel/desktop-file-utils \
> devel/kf5/breeze-icons \
> devel/kf5/kirigami2 \
> + devel/kf5/qqc2-desktop-style \
> sysutils/sshfs-fuse \
> sysutils/sshpass \
> x11/gtk+3,-guic
> +
> LIB_DEPENDS =devel/kf5/kauth \
> devel/kf5/kbookmarks \
> devel/kf5/kcmutils \
> @@ -58,13 +63,17 @@ LIB_DEPENDS = devel/kf5/kauth \
> devel/kf5/kjobwidgets \
> devel/kf5/knotifications \
> devel/kf5/kpeople \
> + devel/kf5/kpeople \
> devel/kf5/kservice \
> + devel/kf5/kwayland \
> devel/kf5/kwidgetsaddons \
> devel/kf5/kxmlgui \
> devel/kf5/solid \
> security/qca-qt5 \
> x11/libfakekey \
> - x11/qt5/qtdeclarative,-main \
> + x11/qt5/qtdeclarative \
> + x11/qt5/qtquickcontrols2 \
> + x11/qt5/qtwayland \
> x11/qt5/qtx11extras
>
> MODPY_ADJ_FILES =nautilus-extension/kdeconnect-share.py
> diff --git a/net/kdeconnect-kde/distinfo b/net/kdeconnect-kde/distinfo
> index 0eb551f90aa..b5e8b53eaa1 100644
> --- a/net/kdeconnect-kde/distinfo
> +++ b/net/kdeconnect-kde/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (kdeconnect-kde-1.4.1.tar.xz) =
> H1rFjbcdwT3skfV9ei/wC4ojLSw9q0J0vQ+SkIwGV/4=
> -SIZE (kdeconnect-kde-1.4.1.tar.xz) = 440628
> +SHA256 (kdeconnect-kde-21.08.3.tar.xz) =
> MkZjM22xAAFj6ukaY76EtqYUEx7WK9bdZWNjns1b2r0=
> +SIZE (kdeconnect-kde-21.08.3.tar.xz) = 591412
> diff --git
> a/net/kdeconnect-kde/patches/patch-core_backends_lan_compositeuploadjob_cpp
> b/net/kdeconnect-kde/patches/patch-core_backends_lan_compositeuploadjob_cpp
> index c350650a844..bb263dc7343 100644
> ---
> a/net/kdeconnect-kde/patches/patch-core_backends_lan_compositeuploadjob_cpp
> +++
> b/net/kdeconnect-kde/patches/patch-
Ping: [maintainer update] getmail 5.15 -> 5.16
Am Tue, Nov 16, 2021 at 02:26:09PM +0100 schrieb Martin Ziemer:
> This patch updates getmail from 5.15 to 5.16.
>
> Tested on two amd64 systems.
Now three.
Index: Makefile
===
RCS file: /cvs/ports/mail/getmail/Makefile,v
retrieving revision 1.100
diff -u -p -r1.100 Makefile
--- Makefile23 Feb 2021 19:39:28 - 1.100
+++ Makefile16 Nov 2021 13:23:05 -
@@ -2,7 +2,7 @@
COMMENT= IMAP/POP3/SDPS mail retriever
-MODPY_EGG_VERSION= 5.15
+MODPY_EGG_VERSION= 5.16
DISTNAME= getmail-${MODPY_EGG_VERSION}
CATEGORIES=mail
Index: distinfo
===
RCS file: /cvs/ports/mail/getmail/distinfo,v
retrieving revision 1.80
diff -u -p -r1.80 distinfo
--- distinfo23 Dec 2020 07:25:34 - 1.80
+++ distinfo16 Nov 2021 13:23:05 -
@@ -1,2 +1,2 @@
-SHA256 (getmail-5.15.tar.gz) = 1FOAX/w/j+JYbucFczvWZnd+U2kxJf2xSUlNIr0UFio=
-SIZE (getmail-5.15.tar.gz) = 199733
+SHA256 (getmail-5.16.tar.gz) = auj46u+avEZQUMO2TlWjGvvc1Mbt8xl7W1m71WymZ/o=
+SIZE (getmail-5.16.tar.gz) = 180577
Re: [UPDATE] for games/uqm 0.7.0 -> 0.8.0
Kirill Bychkov writes: > On Sat, November 20, 2021 18:53, Tom Murphy wrote: > > Hi, > > > > Here is a diff to update games/uqm from 0.7.0 to 0.8.0. The game > > now compiles under SDL2. > > > > OK? > > > > Thanks, > > Tom > > Reworked diff attached. > - EPOCH restored > - adds V to SUBST_VARS to reduce diffs to PLIST in future > - removes extra distinfo > - sort WANTLIB > > Works fine for me ok bentley@ Since uqm-remix's plist changed (even if not substantially), it needs a bump. The distfiles are unversioned, so don't bother setting REVISION, just update the version to 0.8.0 to bump it.
Re: [UPDATE] for games/uqm 0.7.0 -> 0.8.0
On Sat, Nov 20, 2021 at 10:15:26PM +0100, Stefan Hagen wrote: > Hi Tom, > > Tom Murphy wrote: > > Here is a diff to update games/uqm from 0.7.0 to 0.8.0. The game > > now compiles under SDL2. > > > > OK? > > I don't know how to play this game, but I clicked around and it seems to > run fine. Tested on amd64. > > $ portcheck > both data/3domusic and some of its parents has distinfo > ... > > games/uqm/distinfo should be removed. > > OK sdk@ without parent distinfo. > > Best Regards, > Stefan Hi Stefan, Thanks! I've updated the diff so that removes the parent distinfo. Tom Index: distinfo === RCS file: distinfo diff -N distinfo --- distinfo20 Jan 2015 12:28:31 - 1.16 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,16 +0,0 @@ -SHA256 (uqm/uqm-0.7.0-3domusic.uqm) = xXCF5k2tS934pnmpqirfY/IVbV9sur5jr4BRkDPby4I= -SHA256 (uqm/uqm-0.7.0-content.uqm) = uPbbi6KfBij7HVwjODCJaxn0Qa7jdEvaZx6iZLRNo78= -SHA256 (uqm/uqm-0.7.0-source.tgz) = o2lcX38L5+ycD4DsVpkHs4ICOh/ubmNVMr1Tt7U7siE= -SHA256 (uqm/uqm-0.7.0-voice.uqm) = vMz4AbS6N1lP9iF7KSdE6lhu4tRH6SeASELMrotzyXk= -SHA256 (uqm/uqm-remix-disc1.uqm) = tpdpR0XZOTEejr/91e32kuAQwl15ZuFIEHSUCk0Eh+g= -SHA256 (uqm/uqm-remix-disc2.uqm) = f7tHRBAuMSc+RFmwGhVtoFLsU3wSj+kXk2Q+NIvBut4= -SHA256 (uqm/uqm-remix-disc3.uqm) = 5tifj2bPHfHLJ4/KHpImGxd27mcN/yYTLjPxTb0x6R0= -SHA256 (uqm/uqm-remix-disc4.uqm) = pMgZdxKltyqBx+96KjPqfTrJCrBjySndaOcyilWahtA= -SIZE (uqm/uqm-0.7.0-3domusic.uqm) = 18980671 -SIZE (uqm/uqm-0.7.0-content.uqm) = 11538533 -SIZE (uqm/uqm-0.7.0-source.tgz) = 1562003 -SIZE (uqm/uqm-0.7.0-voice.uqm) = 115143439 -SIZE (uqm/uqm-remix-disc1.uqm) = 50188876 -SIZE (uqm/uqm-remix-disc2.uqm) = 60282662 -SIZE (uqm/uqm-remix-disc3.uqm) = 39924875 -SIZE (uqm/uqm-remix-disc4.uqm) = 86545760 Index: data/3domusic/Makefile === RCS file: /cvs/ports/games/uqm/data/3domusic/Makefile,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Makefile --- data/3domusic/Makefile 30 Aug 2020 10:05:35 - 1.1.1.1 +++ data/3domusic/Makefile 21 Nov 2021 21:37:15 - @@ -2,14 +2,12 @@ COMMENT = ur-quan masters: 3DO music content -V =0.7.0 +V =0.8.0 UQM_ADDON =Yes # packages-specs(7): first digit following hyphen can only be version PKGNAME = uqm-threedomusic-$V DISTFILES =uqm-$V-3domusic.uqm - -REVISION = 6 .include Index: data/3domusic/distinfo === RCS file: /cvs/ports/games/uqm/data/3domusic/distinfo,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 distinfo --- data/3domusic/distinfo 30 Aug 2020 10:05:35 - 1.1.1.1 +++ data/3domusic/distinfo 21 Nov 2021 21:37:15 - @@ -1,2 +1,2 @@ -SHA256 (uqm/uqm-0.7.0-3domusic.uqm) = xXCF5k2tS934pnmpqirfY/IVbV9sur5jr4BRkDPby4I= -SIZE (uqm/uqm-0.7.0-3domusic.uqm) = 18980671 +SHA256 (uqm/uqm-0.8.0-3domusic.uqm) = RM087H6VabQRettNd/FSKJCXJWYmc5GuCWMUhdIx2Lk= +SIZE (uqm/uqm-0.8.0-3domusic.uqm) = 18980671 Index: data/3domusic/pkg/PLIST === RCS file: /cvs/ports/games/uqm/data/3domusic/pkg/PLIST,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 PLIST --- data/3domusic/pkg/PLIST 30 Aug 2020 10:05:35 - 1.1.1.1 +++ data/3domusic/pkg/PLIST 21 Nov 2021 21:37:15 - @@ -3,4 +3,4 @@ share/uqm/ share/uqm/content/ share/uqm/content/addons/ -share/uqm/content/addons/uqm-0.7.0-3domusic.uqm +share/uqm/content/addons/uqm-0.8.0-3domusic.uqm Index: data/content/Makefile === RCS file: /cvs/ports/games/uqm/data/content/Makefile,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Makefile --- data/content/Makefile 30 Aug 2020 10:05:35 - 1.1.1.1 +++ data/content/Makefile 21 Nov 2021 21:37:15 - @@ -2,13 +2,11 @@ COMMENT = ur-quan masters: game content -V =0.7.0 +V =0.8.0 UQM_PACKAGE = Yes PKGNAME = uqm-content-$V DISTFILES =uqm-$V-content.uqm - -REVISION = 6 .include Index: data/content/distinfo === RCS file: /cvs/ports/games/uqm/data/content/distinfo,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 distinfo --- data/content/distinfo 30 Aug 2020 10:05:35 - 1.1.1.1 +++ data/content/distinfo 21 Nov 2021 21:37:15 - @@ -1,2 +1,2 @@ -SHA256 (uqm/uqm-0.7.0-content.uqm) = uPbbi6KfBij7HVwjODCJaxn0Qa7jdEvaZx6iZLRNo78= -SIZE (uqm/uqm-0.7.0-content.uqm) = 11538533 +SHA256 (uqm/uqm-0.8.0-content.uqm) = d9dawl5vt1WjPEujs4p7e8Qfy8AolokbDMmskhS3Lu8= +SIZE (uqm/uqm-0.8.0-content.uqm) = 11547353 Index: data/content/pkg/PLIST === RCS file: /cvs/ports/games/uqm/data/content/pkg/PLIST,v retrieving revision 1.1.1.1
Re: [update] games/taisei: 1.3.1 -> 1.3.2 (+ dep)
Omar Polo writes:
> Omar Polo writes:
>
>> Hello,
>>
>> Please find attached a patch to update taisei to the latest version.
>> 1.3.2 requires a new build-time dependency: math/cglm (tarball
>> attached.)
>>
>> Builds and runs fine on amdgpu.
>>
>> [...]
>
> Sorry for the lack of info, I forgot to mention quite a few things. Let
> me try again:
>
> Here's the changelog for the release:
>
> https://taisei-project.org/news/0013_v1.3.2
> https://github.com/taisei-project/taisei/releases/tag/v1.3.2
>
> It's a maintenance release with bugfix, optimization and minor features
> backported from the 1.4 tree. It should be replay-compatible with the
> initial 1.3.
>
> An extraneous "-O0" gets added before the default CFLAGS "-O2 -pipe" and
> I can't neutralize it. I find out that it's controlled by the meson
> `optimization' option, but can't find where it's actually added.
I found out that this happens with other meson ports (e.g. x11/picom)
so... I guess is fine? The flags ends up being "-O0 -O2 -pipe".
> taisei now requires cglm. It only uses the macros from the headers so
> it isn't linked to the library. math/cglm is:
>
> % pkg_info cglm
> Information for inst:cglm-0.8.4
>
> Comment:
> highly optimized graphics math library
>
> Description:
> cglm is an highly optimized 2D and 3D math library, also know as OpenGL
> Mathematics (glm) for C. cglm provides lot of utils to help math
> operations to be fast and quick to write.
>
> Maintainer: The OpenBSD ports mailing-list
>
> WWW: https://github.com/recp/cglm
>
>
> for some reason outside my understanding meson fails to decipher the
> cglm version, so I neutered the version check.
I've find out that upstream forgot to substitute a variable and the pc
file ended up being slightly odd. With that fixed, games/taisei is
happy.
Updated patch and cglm tarball attached, OK/comments?
Cheers!
Index: Makefile
===
RCS file: /home/cvs/ports/games/taisei/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile23 Feb 2021 19:39:23 - 1.8
+++ Makefile14 Nov 2021 12:59:49 -
@@ -6,7 +6,7 @@ ONLY_FOR_ARCHS =amd64 aarch64 i386
COMMENT = clone of the touhou games
-VERSION = v1.3.1
+VERSION = v1.3.2
DISTNAME = taisei-${VERSION}
PKGNAME = taisei-${VERSION:S/^v//}
@@ -29,6 +29,8 @@ MODULES = devel/meson \
lang/python
MODPY_RUNDEP = No
+
+BUILD_DEPENDS =math/cglm
RUN_DEPENDS = devel/desktop-file-utils \
misc/shared-mime-info \
Index: distinfo
===
RCS file: /home/cvs/ports/games/taisei/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo8 Feb 2020 11:04:15 - 1.2
+++ distinfo14 Nov 2021 12:12:07 -
@@ -1,2 +1,2 @@
-SHA256 (taisei-v1.3.1.tar.xz) = hlg6OnEAk+YwFKWua2glGgacslraBsb41zT4XzGtyYU=
-SIZE (taisei-v1.3.1.tar.xz) = 70763196
+SHA256 (taisei-v1.3.2.tar.xz) = 28BfG1wxmB2HERMKwoM1W3v61AOJX0CWprt+mj1zo7w=
+SIZE (taisei-v1.3.2.tar.xz) = 70481856
Index: pkg/PLIST
===
RCS file: /home/cvs/ports/games/taisei/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST 8 Feb 2020 11:04:15 - 1.4
+++ pkg/PLIST 14 Nov 2021 12:54:13 -
@@ -535,6 +535,7 @@ share/taisei/00-taisei.pkgdir/shader/hea
share/taisei/00-taisei.pkgdir/shader/ingame_menu.frag.glsl
share/taisei/00-taisei.pkgdir/shader/ingame_menu.prog
share/taisei/00-taisei.pkgdir/shader/interface/
+share/taisei/00-taisei.pkgdir/shader/interface/fxaa.glslh
share/taisei/00-taisei.pkgdir/shader/interface/healthbar.glslh
share/taisei/00-taisei.pkgdir/shader/interface/reimu_gap.glslh
share/taisei/00-taisei.pkgdir/shader/interface/spellcard.glslh
@@ -582,6 +583,7 @@ share/taisei/00-taisei.pkgdir/shader/lib
share/taisei/00-taisei.pkgdir/shader/lib/blur/blur9.glslh
share/taisei/00-taisei.pkgdir/shader/lib/defs.glslh
share/taisei/00-taisei.pkgdir/shader/lib/fxaa.glslh
+share/taisei/00-taisei.pkgdir/shader/lib/legacy_compat.glslh
share/taisei/00-taisei.pkgdir/shader/lib/render_context.glslh
share/taisei/00-taisei.pkgdir/shader/lib/sprite_default.vert.glslh
share/taisei/00-taisei.pkgdir/shader/lib/sprite_main.frag.glslh
cglm.tar.gz
Description: Binary data
[PATCH] textproc/ruby-kramdown: activate rexml
This patch activates the dependency on textproc/ruby-rexml in textproc/ruby-
kramdown. This seems needed for www/ruby-jekyll, which I plan to re-add to the
ports tree. This only works for ruby>=3.0, since earlier versions had rexml
included in the base distribution. Should the port just only alow a ruby30
flavor, our should the dependency on textproc/ruby-rexml be dependent on the
ruby flavor? And then the patch would also be needed only for the ruby30
flavor?
Thanks.
Index: Makefile
===
RCS file: /cvs/ports/textproc/ruby-kramdown/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile18 Mar 2021 08:40:41 - 1.14
+++ Makefile21 Nov 2021 19:51:10 -
@@ -11,14 +11,16 @@ HOMEPAGE= https://kramdown.gettalong.org
# MIT
PERMIT_PACKAGE=Yes
-# After Ruby 3.0 is added to ports tree
-#RUN_DEPENDS= textproc/ruby-rexml
-
MODULES= lang/ruby
CONFIGURE_STYLE=ruby gem
+RUN_DEPENDS= textproc/ruby-rexml
+
MODRUBY_TEST= ruby
MODRUBY_TEST_TARGET = ${WRKSRC}/test/run_tests.rb
+
+FLAVORS= ruby30
+FLAVOR=ruby30
.include
Index: patches/patch-_metadata
===
RCS file: patches/patch-_metadata
diff -N patches/patch-_metadata
--- patches/patch-_metadata 21 Aug 2020 21:22:27 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,17 +0,0 @@
-$OpenBSD: patch-_metadata,v 1.1 2020/08/21 21:22:27 jeremy Exp $
-
-Don't require runtime dependency on rexml, not needed
-in Ruby 2.5-2.7 where it is in stdlib.
-
-Index: .metadata
.metadata.orig
-+++ .metadata
-@@ -17,7 +17,7 @@ dependencies:
- - - ">="
- - !ruby/object:Gem::Version
- version: '0'
-- type: :runtime
-+ type: :development
- prerelease: false
- version_requirements: !ruby/object:Gem::Requirement
- requirements:
Re: pkg_add with certificate pinning
I use nginx as a "reverse proxy" which can use keepalives towards the origin server, then point pkg_add there instead of the real origin. Works nicely but I'm just doing that to reduce round trips not for anything to do with trying to hide which packages I'm fetching. -- Sent from a phone, apologies for poor formatting. On 21 November 2021 15:42:48 Fabio Martins wrote: On 2021-11-21 07:55, Marc Espie wrote: On Fri, Nov 19, 2021 at 11:14:34AM +, Yifei Zhan wrote: On 21/11/19 07:35AM, Fabio Martins wrote: > On 2021-11-19 06:57, Yifei Zhan wrote: > > On 21/11/19 06:26AM, Fabio Martins wrote: > > > Sorry if it is a bit off-topic. > > > > > > After reading an article about rogue CA's: > > > > > > https://www.theregister.com/2021/11/19/web_trust_certificates/ > > > > > > I wonder if there is any advantage of using certificate pinning in the > > > process of pkg_add / sysupgrade / pkg_* while updating OpenBSD > > > packages. > > > > > > > OpenBSD does not use PKI/web of trust for integrity validation, thus I > > don't think certificate pinning makes sense for those operations. > > Instead, OpenBSD uses signify(1) with pubkeys in /etc/signify/ for that > > purpose. > > Well said. I believe it would only improve confidentiality, as rogue > middleware appliances would not be able to inspect the content of package > updates. I don't think it makes any meaningful impact on confidentiality. All the packages are public and since encryption doesn't change file size, it's pretty easy for an attacker to match the content you are downloading with the packages on the mirror you connected to. If you don't want others to know what package you are downloading, maybe it's better to run an internal mirror and fetch things from there. something you might want to read: Marc Espie, Advances in OpenBSD packages: https is a lie https://www.openbsd.org/papers/eurobsdcon_2018_https.pdf I still haven't had the time to implement the counter-measures discussed in that talk... most specifically, the proxy that would keep an https connection alive... Indeed, an "always-on" ssl proxy tunnel to the hosts holding the packages, seems to be effective against traffic correlation, thus enabling confidentiality; at the same time the user can disable it any time he wants to. Thinking of HTTP_PROXY in the script can do the job. Downsides: -Resources consumed in the provider holding the packages I took a look into tinyproxy.conf but could not find an option like "keep-the-tunnel-alive". Maybe other proxy package has it. -- Fabio
Re: [Update] cad/kicad and friends to 5.1.12
Tracey Emery wrote: > Hello, > > Here is an update for cad/kicad and cad/kicad-shared, bringing us to > 5.1.12. I couldn't find any release notes, so we'll just call this port > more-better. > > Tested on amd64. > > ok? The usual checks pass on all (sub)packages. I opened a test project and ran through the screens and played around in the PCB editor and rendered it. Works fine on amd64/amdgpu. The kicad-share packages could use NO_TEST=Yes. OK sdk@ Best Regards, Stefan
Re: pkg_add with certificate pinning
On 2021-11-21 14:49, Fabio Martins wrote: On 2021-11-21 13:01, Marc Espie wrote: On Sun, Nov 21, 2021 at 12:24:03PM -0300, Fabio Martins wrote: On 2021-11-21 07:55, Marc Espie wrote: > On Fri, Nov 19, 2021 at 11:14:34AM +, Yifei Zhan wrote: > > On 21/11/19 07:35AM, Fabio Martins wrote: > > > On 2021-11-19 06:57, Yifei Zhan wrote: > > > > On 21/11/19 06:26AM, Fabio Martins wrote: > > > > > Sorry if it is a bit off-topic. > > > > > > > > > > After reading an article about rogue CA's: > > > > > > > > > > https://www.theregister.com/2021/11/19/web_trust_certificates/ > > > > > > > > > > I wonder if there is any advantage of using certificate pinning in the > > > > > process of pkg_add / sysupgrade / pkg_* while updating OpenBSD > > > > > packages. > > > > > > > > > > > > > OpenBSD does not use PKI/web of trust for integrity validation, thus I > > > > don't think certificate pinning makes sense for those operations. > > > > Instead, OpenBSD uses signify(1) with pubkeys in /etc/signify/ for that > > > > purpose. > > > > > > Well said. I believe it would only improve confidentiality, as rogue > > > middleware appliances would not be able to inspect the content of package > > > updates. > > > > I don't think it makes any meaningful impact on confidentiality. All > > the > > packages are public and since encryption doesn't change file size, > > it's > > pretty easy for an attacker to match the content you are downloading > > with the packages on the mirror you connected to. > > > > If you don't want others to know what package you are downloading, > > maybe > > it's better to run an internal mirror and fetch things from there. > > > > something you might want to read: > > > > Marc Espie, Advances in OpenBSD packages: https is a lie > > https://www.openbsd.org/papers/eurobsdcon_2018_https.pdf > > > > I still haven't had the time to implement the counter-measures discussed > in that talk... most specifically, the proxy that would keep an https > connection alive... Indeed, an "always-on" ssl proxy tunnel to the hosts holding the packages, seems to be effective against traffic correlation, thus enabling confidentiality; at the same time the user can disable it any time he wants to. HTTP_PROXY in the script can do. It's more complicated than that... look at my presentation. - you need to put some random data so that the pkgname length isn't guessable. - for initial installs (and updates where the full package changes) you need to play with Byte-Range so that you can't guess which package got installed. A proxy by itself won't help you that much... @Espie Sorry the double-posting. Indeed only a proxy will not solve. I am dissecting your paper. @Espie Trying to come up with a quasi-simple solution, in my tests I couldn't see too much patterns, but I believe you have better tests - GET - X-OpenBSD-Padding does the job, but can be included in the pipeline to add more randomness packages: - pipeline_all ( GET(package) + GET(signatures) + GET(randoms) ) together under same http1.1 connection Per RFC 2616 I don't see a limit on the amount of GET in the same connection https://datatracker.ietf.org/doc/html/rfc2616/ - hoping this solves the need of adding so much padding/garbage/64 blocks, it all depends if the HTTP server answers it in chunks of same / unpredicatble sizes, or if we can force/instruct it to answer in blocks of the same size testing with small packages: (echo -en "GET /pub/OpenBSD/7.0/packages/amd64/yabitrot-0.4p0.tgz HTTP/1.1\nHost: cdn.openbsd.org\nConnection: keep-alive\n\nGET /pub/OpenBSD/7.0/packages/amd64/xzoom-0.4.tgz HTTP/1.1\nHost: cdn.openbsd.org\n\n"; sleep 10) | telnet cdn.openbsd.org 80 > /dev/null + analyzed with tcpdump+wireshark disadvantages: - all the work is done parsing the big tempfile with all GETs / signatures / packages / randoms Is this valid? -- Fabio
Re: [NEW] textproc/ruby-rexml
On Sun, 2021-11-21 at 20:18 +0100, Clemens Gößnitzer wrote: > Attached is a new port, textproc/ruby-rexml. This port is needed to update > textproc/ruby-kramdown, Correction: not update, but activate rexml. > which has in its Makefile: > > # After Ruby 3.0 is added to ports tree > #RUN_DEPENDS= textproc/ruby-rexml > > Since it is included in base Ruby<3.0, I set the ruby flavor to ruby30. Is > this > the correct solution to only build it for Ruby>=3.0? Or is there a better way > which also works if there is then ruby31 and so on? > > Thanks.
[NEW] textproc/ruby-rexml
Attached is a new port, textproc/ruby-rexml. This port is needed to update textproc/ruby-kramdown, which has in its Makefile: # After Ruby 3.0 is added to ports tree #RUN_DEPENDS= textproc/ruby-rexml Since it is included in base Ruby<3.0, I set the ruby flavor to ruby30. Is this the correct solution to only build it for Ruby>=3.0? Or is there a better way which also works if there is then ruby31 and so on? Thanks. ruby-rexml.tgz Description: application/compressed-tar
Re: [UPDATE] for games/uqm 0.7.0 -> 0.8.0
On Sat, November 20, 2021 18:53, Tom Murphy wrote: > Hi, > > Here is a diff to update games/uqm from 0.7.0 to 0.8.0. The game > now compiles under SDL2. > > OK? > > Thanks, > Tom Reworked diff attached. - EPOCH restored - adds V to SUBST_VARS to reduce diffs to PLIST in future - removes extra distinfo - sort WANTLIB Works fine for me uqm.diff Description: Binary data
jitsi-meet for openbsd
Dear all, I am not a developer but am curious if anybody is currently working on porting jitsi-meet to openbsd. If not, please consider this as a feature request :). Thanks for considering! Hakan Duran signature.asc Description: PGP signature
Re: pkg_add with certificate pinning
On 2021-11-21 13:01, Marc Espie wrote: On Sun, Nov 21, 2021 at 12:24:03PM -0300, Fabio Martins wrote: On 2021-11-21 07:55, Marc Espie wrote: > On Fri, Nov 19, 2021 at 11:14:34AM +, Yifei Zhan wrote: > > On 21/11/19 07:35AM, Fabio Martins wrote: > > > On 2021-11-19 06:57, Yifei Zhan wrote: > > > > On 21/11/19 06:26AM, Fabio Martins wrote: > > > > > Sorry if it is a bit off-topic. > > > > > > > > > > After reading an article about rogue CA's: > > > > > > > > > > https://www.theregister.com/2021/11/19/web_trust_certificates/ > > > > > > > > > > I wonder if there is any advantage of using certificate pinning in the > > > > > process of pkg_add / sysupgrade / pkg_* while updating OpenBSD > > > > > packages. > > > > > > > > > > > > > OpenBSD does not use PKI/web of trust for integrity validation, thus I > > > > don't think certificate pinning makes sense for those operations. > > > > Instead, OpenBSD uses signify(1) with pubkeys in /etc/signify/ for that > > > > purpose. > > > > > > Well said. I believe it would only improve confidentiality, as rogue > > > middleware appliances would not be able to inspect the content of package > > > updates. > > > > I don't think it makes any meaningful impact on confidentiality. All > > the > > packages are public and since encryption doesn't change file size, > > it's > > pretty easy for an attacker to match the content you are downloading > > with the packages on the mirror you connected to. > > > > If you don't want others to know what package you are downloading, > > maybe > > it's better to run an internal mirror and fetch things from there. > > > > something you might want to read: > > > > Marc Espie, Advances in OpenBSD packages: https is a lie > > https://www.openbsd.org/papers/eurobsdcon_2018_https.pdf > > > > I still haven't had the time to implement the counter-measures discussed > in that talk... most specifically, the proxy that would keep an https > connection alive... Indeed, an "always-on" ssl proxy tunnel to the hosts holding the packages, seems to be effective against traffic correlation, thus enabling confidentiality; at the same time the user can disable it any time he wants to. HTTP_PROXY in the script can do. It's more complicated than that... look at my presentation. - you need to put some random data so that the pkgname length isn't guessable. - for initial installs (and updates where the full package changes) you need to play with Byte-Range so that you can't guess which package got installed. A proxy by itself won't help you that much... @Espie Sorry the double-posting. Indeed only a proxy will not solve. I am dissecting your paper.
[PATCH] devel/py-esptool
I found this by chance while looking for something else. I don't know if it's
worth the effort to commit this, or if a revision bump is needed.
Thanks.
Index: Makefile
===
RCS file: /cvs/ports/devel/py-esptool/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile2 Nov 2021 00:00:48 - 1.5
+++ Makefile21 Nov 2021 17:55:25 -
@@ -20,7 +20,7 @@ MODPY_SETUPTOOLS = Yes
RUN_DEPENDS += devel/py-serial${MODPY_FLAVOR} \
security/py-aes${MODPY_FLAVOR} \
- security/py-ecdsa${MODPY_FLAVOR} \
+ security/py-ecdsa${MODPY_FLAVOR}
FLAVORS = python3
FLAVOR = python3
UPDATE: Nextcloud-22.2.3
Hello, Update for Nextcloud to 22.2.3: https://nextcloud.com/changelog/#latest22 OK? Comments? Cheers.- -- %gonzalo Index: Makefile === RCS file: /cvs/ports/www/nextcloud/22/Makefile,v retrieving revision 1.4 diff -u -p -r1.4 Makefile --- Makefile16 Nov 2021 16:59:58 - 1.4 +++ Makefile21 Nov 2021 16:00:00 - @@ -1,5 +1,5 @@ # $OpenBSD: Makefile,v 1.4 2021/11/16 16:59:58 gonzalo Exp $ -NC_VERSION=22.2.1 +NC_VERSION=22.2.3 .include Index: distinfo === RCS file: /cvs/ports/www/nextcloud/22/distinfo,v retrieving revision 1.4 diff -u -p -r1.4 distinfo --- distinfo16 Nov 2021 16:59:58 - 1.4 +++ distinfo21 Nov 2021 16:00:00 - @@ -1,2 +1,2 @@ -SHA256 (nextcloud-22.2.1.tar.bz2) = 0BtQt7siUYGiEVGkUYmd0gjfccq4kIhCVaOTR9frvys= -SIZE (nextcloud-22.2.1.tar.bz2) = 130941004 +SHA256 (nextcloud-22.2.3.tar.bz2) = ZqKaakkHOMCr7bZ3y2jHyR+rqz5kGaPJnYtAaJnrlCo= +SIZE (nextcloud-22.2.3.tar.bz2) = 130819469 Index: pkg/PLIST === RCS file: /cvs/ports/www/nextcloud/22/pkg/PLIST,v retrieving revision 1.4 diff -u -p -r1.4 PLIST --- pkg/PLIST 16 Nov 2021 16:59:58 - 1.4 +++ pkg/PLIST 21 Nov 2021 16:00:07 - @@ -2758,6 +2758,7 @@ nextcloud/3rdparty/christophwurst/id3par nextcloud/3rdparty/composer/ nextcloud/3rdparty/composer.json nextcloud/3rdparty/composer.lock +nextcloud/3rdparty/composer.patches.json nextcloud/3rdparty/composer/ClassLoader.php nextcloud/3rdparty/composer/InstalledVersions.php nextcloud/3rdparty/composer/LICENSE @@ -2785,6 +2786,15 @@ nextcloud/3rdparty/composer/package-vers nextcloud/3rdparty/composer/package-versions-deprecated/src/PackageVersions/Installer.php nextcloud/3rdparty/composer/package-versions-deprecated/src/PackageVersions/Versions.php nextcloud/3rdparty/composer/platform_check.php +nextcloud/3rdparty/cweagans/ +nextcloud/3rdparty/cweagans/composer-patches/ +nextcloud/3rdparty/cweagans/composer-patches/LICENSE.md +nextcloud/3rdparty/cweagans/composer-patches/composer.json +nextcloud/3rdparty/cweagans/composer-patches/composer.lock +nextcloud/3rdparty/cweagans/composer-patches/src/ +nextcloud/3rdparty/cweagans/composer-patches/src/PatchEvent.php +nextcloud/3rdparty/cweagans/composer-patches/src/PatchEvents.php +nextcloud/3rdparty/cweagans/composer-patches/src/Patches.php nextcloud/3rdparty/deepdiver/ nextcloud/3rdparty/deepdiver/zipstreamer/ nextcloud/3rdparty/deepdiver/zipstreamer/.gitignore @@ -2979,7 +2989,6 @@ nextcloud/3rdparty/doctrine/dbal/src/Dri nextcloud/3rdparty/doctrine/dbal/src/Driver/SQLSrv/Driver.php nextcloud/3rdparty/doctrine/dbal/src/Driver/SQLSrv/Exception/ nextcloud/3rdparty/doctrine/dbal/src/Driver/SQLSrv/Exception/Error.php -nextcloud/3rdparty/doctrine/dbal/src/Driver/SQLSrv/LastInsertId.php nextcloud/3rdparty/doctrine/dbal/src/Driver/SQLSrv/Result.php nextcloud/3rdparty/doctrine/dbal/src/Driver/SQLSrv/Statement.php nextcloud/3rdparty/doctrine/dbal/src/Driver/ServerInfoAwareConnection.php @@ -3083,6 +3092,9 @@ nextcloud/3rdparty/doctrine/dbal/src/Res nextcloud/3rdparty/doctrine/dbal/src/SQL/ nextcloud/3rdparty/doctrine/dbal/src/SQL/Parser/ nextcloud/3rdparty/doctrine/dbal/src/SQL/Parser.php +nextcloud/3rdparty/doctrine/dbal/src/SQL/Parser/Exception/ +nextcloud/3rdparty/doctrine/dbal/src/SQL/Parser/Exception.php +nextcloud/3rdparty/doctrine/dbal/src/SQL/Parser/Exception/RegularExpressionError.php nextcloud/3rdparty/doctrine/dbal/src/SQL/Parser/Visitor.php nextcloud/3rdparty/doctrine/dbal/src/Schema/ nextcloud/3rdparty/doctrine/dbal/src/Schema/AbstractAsset.php @@ -3169,6 +3181,29 @@ nextcloud/3rdparty/doctrine/dbal/src/Typ nextcloud/3rdparty/doctrine/dbal/src/Types/VarDateTimeImmutableType.php nextcloud/3rdparty/doctrine/dbal/src/Types/VarDateTimeType.php nextcloud/3rdparty/doctrine/dbal/src/VersionAwarePlatformDriver.php +nextcloud/3rdparty/doctrine/dbal/static-analysis/ +nextcloud/3rdparty/doctrine/dbal/static-analysis/driver-manager-retrieves-correct-connection-type.php +nextcloud/3rdparty/doctrine/deprecations/ +nextcloud/3rdparty/doctrine/deprecations/.gitignore +nextcloud/3rdparty/doctrine/deprecations/README.md +nextcloud/3rdparty/doctrine/deprecations/composer.json +nextcloud/3rdparty/doctrine/deprecations/lib/ +nextcloud/3rdparty/doctrine/deprecations/lib/Doctrine/ +nextcloud/3rdparty/doctrine/deprecations/lib/Doctrine/Deprecations/ +nextcloud/3rdparty/doctrine/deprecations/lib/Doctrine/Deprecations/Deprecation.php +nextcloud/3rdparty/doctrine/deprecations/lib/Doctrine/Deprecations/PHPUnit/ +nextcloud/3rdparty/doctrine/deprecations/lib/Doctrine/Deprecations/PHPUnit/VerifyDeprecations.php +nextcloud/3rdparty/doctrine/deprecations/phpcs.xml +nextcloud/3rdparty/doctrine/deprecations/phpunit.xml.dist +nextcloud/3rdparty/doctrine/deprecations/test_fixtures/ +nextclou
Re: pkg_add with certificate pinning
On Sun, Nov 21, 2021 at 12:24:03PM -0300, Fabio Martins wrote: > On 2021-11-21 07:55, Marc Espie wrote: > > On Fri, Nov 19, 2021 at 11:14:34AM +, Yifei Zhan wrote: > > > On 21/11/19 07:35AM, Fabio Martins wrote: > > > > On 2021-11-19 06:57, Yifei Zhan wrote: > > > > > On 21/11/19 06:26AM, Fabio Martins wrote: > > > > > > Sorry if it is a bit off-topic. > > > > > > > > > > > > After reading an article about rogue CA's: > > > > > > > > > > > > https://www.theregister.com/2021/11/19/web_trust_certificates/ > > > > > > > > > > > > I wonder if there is any advantage of using certificate pinning in > > > > > > the > > > > > > process of pkg_add / sysupgrade / pkg_* while updating OpenBSD > > > > > > packages. > > > > > > > > > > > > > > > > OpenBSD does not use PKI/web of trust for integrity validation, thus I > > > > > don't think certificate pinning makes sense for those operations. > > > > > Instead, OpenBSD uses signify(1) with pubkeys in /etc/signify/ for > > > > > that > > > > > purpose. > > > > > > > > Well said. I believe it would only improve confidentiality, as rogue > > > > middleware appliances would not be able to inspect the content of > > > > package > > > > updates. > > > > > > I don't think it makes any meaningful impact on confidentiality. All > > > the > > > packages are public and since encryption doesn't change file size, > > > it's > > > pretty easy for an attacker to match the content you are downloading > > > with the packages on the mirror you connected to. > > > > > > If you don't want others to know what package you are downloading, > > > maybe > > > it's better to run an internal mirror and fetch things from there. > > > > > > something you might want to read: > > > > > > Marc Espie, Advances in OpenBSD packages: https is a lie > > > https://www.openbsd.org/papers/eurobsdcon_2018_https.pdf > > > > > > > I still haven't had the time to implement the counter-measures discussed > > in that talk... most specifically, the proxy that would keep an https > > connection alive... > > Indeed, an "always-on" ssl proxy tunnel to the hosts holding the packages, > seems to be effective against traffic correlation, thus enabling > confidentiality; at the same time the user can disable it any time he wants > to. HTTP_PROXY in the script can do. It's more complicated than that... look at my presentation. - you need to put some random data so that the pkgname length isn't guessable. - for initial installs (and updates where the full package changes) you need to play with Byte-Range so that you can't guess which package got installed. A proxy by itself won't help you that much...
Re: pkg_add with certificate pinning
On 2021-11-21 07:55, Marc Espie wrote: On Fri, Nov 19, 2021 at 11:14:34AM +, Yifei Zhan wrote: On 21/11/19 07:35AM, Fabio Martins wrote: > On 2021-11-19 06:57, Yifei Zhan wrote: > > On 21/11/19 06:26AM, Fabio Martins wrote: > > > Sorry if it is a bit off-topic. > > > > > > After reading an article about rogue CA's: > > > > > > https://www.theregister.com/2021/11/19/web_trust_certificates/ > > > > > > I wonder if there is any advantage of using certificate pinning in the > > > process of pkg_add / sysupgrade / pkg_* while updating OpenBSD > > > packages. > > > > > > > OpenBSD does not use PKI/web of trust for integrity validation, thus I > > don't think certificate pinning makes sense for those operations. > > Instead, OpenBSD uses signify(1) with pubkeys in /etc/signify/ for that > > purpose. > > Well said. I believe it would only improve confidentiality, as rogue > middleware appliances would not be able to inspect the content of package > updates. I don't think it makes any meaningful impact on confidentiality. All the packages are public and since encryption doesn't change file size, it's pretty easy for an attacker to match the content you are downloading with the packages on the mirror you connected to. If you don't want others to know what package you are downloading, maybe it's better to run an internal mirror and fetch things from there. something you might want to read: Marc Espie, Advances in OpenBSD packages: https is a lie https://www.openbsd.org/papers/eurobsdcon_2018_https.pdf I still haven't had the time to implement the counter-measures discussed in that talk... most specifically, the proxy that would keep an https connection alive... Indeed, an "always-on" ssl proxy tunnel to the hosts holding the packages, seems to be effective against traffic correlation, thus enabling confidentiality; at the same time the user can disable it any time he wants to. Thinking of HTTP_PROXY in the script can do the job. Downsides: -Resources consumed in the provider holding the packages I took a look into tinyproxy.conf but could not find an option like "keep-the-tunnel-alive". Maybe other proxy package has it. -- Fabio
Re: pkg_add with certificate pinning
On 2021-11-21 07:55, Marc Espie wrote: On Fri, Nov 19, 2021 at 11:14:34AM +, Yifei Zhan wrote: On 21/11/19 07:35AM, Fabio Martins wrote: > On 2021-11-19 06:57, Yifei Zhan wrote: > > On 21/11/19 06:26AM, Fabio Martins wrote: > > > Sorry if it is a bit off-topic. > > > > > > After reading an article about rogue CA's: > > > > > > https://www.theregister.com/2021/11/19/web_trust_certificates/ > > > > > > I wonder if there is any advantage of using certificate pinning in the > > > process of pkg_add / sysupgrade / pkg_* while updating OpenBSD > > > packages. > > > > > > > OpenBSD does not use PKI/web of trust for integrity validation, thus I > > don't think certificate pinning makes sense for those operations. > > Instead, OpenBSD uses signify(1) with pubkeys in /etc/signify/ for that > > purpose. > > Well said. I believe it would only improve confidentiality, as rogue > middleware appliances would not be able to inspect the content of package > updates. I don't think it makes any meaningful impact on confidentiality. All the packages are public and since encryption doesn't change file size, it's pretty easy for an attacker to match the content you are downloading with the packages on the mirror you connected to. If you don't want others to know what package you are downloading, maybe it's better to run an internal mirror and fetch things from there. something you might want to read: Marc Espie, Advances in OpenBSD packages: https is a lie https://www.openbsd.org/papers/eurobsdcon_2018_https.pdf I still haven't had the time to implement the counter-measures discussed in that talk... most specifically, the proxy that would keep an https connection alive... Indeed, an "always-on" ssl proxy tunnel to the hosts holding the packages, seems to be effective against traffic correlation, thus enabling confidentiality; at the same time the user can disable it any time he wants to. HTTP_PROXY in the script can do. Downsides: -Resources consumed in the provider holding the packages I took a look into tinyproxy.conf but could not find an option like "keep-the-tunnel-alive". Maybe other proxy package has it. -- Fabio
Re: [UPDATE] games/vitetris
Tom Murphy wrote: > Here's an update for games/vitetris. The patch-Makefile has been > updated slightly to accomodate recent changes to it. Compiles, > installs and runs great for me. > > OK? The usual checks pass and it works fine for me on amd64. OK sdk@
Re: [update] games/0ad: 0.0.23b -> 0.0.25b
Am Mon, 15 Nov 2021 10:43:09 +0100
schrieb Omar Polo :
> Omar Polo writes:
>
> > Klemens Nanni writes:
> >
> >> On Mon, Nov 15, 2021 at 01:23:21AM +0100, Omar Polo wrote:
> >>> P.S.: if you're wondering about the `CONFIGURE_ENV += SHELL=sh' is
> >>> because one of the python scripts checked if SHELL is defined and
> >>> raised an error if not instead of defaulting to /bin/sh.
> >>
> >> Just say so in a comment above, otherwise future porters will
> >> scratch their heads again ;-)
> >
> > sure, here's an updated patch
>
> I realized that it doesn't need python 2 anymore (thanks solene@!) so
> I'm dropping the explicit MODPY_VERSION too. It built fine without
> python 2 if I did everything correctly (moved the python executable,
> I know, don't do this at home kids, but I wanted to avoid removing all
> the packages that depends on it just to try the update.) Revised diff
> attached.
>
> Just out of curiosity I tried to build it with --with-native-mozjs and
> it fails with:
>
> ../../../source/scriptinterface/ScriptTypes.h:85:2: error: Your
> compiler is trying to use an untested minor version of the
> SpiderMonkey library. If you are a package maintainer, please make
> sure to check very carefully that this version does not change the
> behaviour of the code executed by SpiderMonkey. Different parts of
> the game (e.g. the multiplayer mode) rely on deterministic behaviour
> of the JavaScript engine. A simple way for testing this would be
> playing a network game with one player using the old version and one
> player using the new version. Another way for testing is running
> replays and comparing the final hash (check
> trac.wildfiregames.com/wiki/Debugging#Replaymode). For more
> information check this link:
> trac.wildfiregames.com/wiki/Debugging#Outofsync
>
> Even if now works (I haven't tested the multiplayer) it may break with
> future mozjs updates (or maybe upstream is exaggerating?) I've
> mentioned this in a comment.
I've played 0ad with Omar for several hours and we found no issues.
Everything was working as expected.
We did play using solely OpenBSD and with OpenBSD + Linux mixed
installations. No interoperability problems found.
Thank you for your work!
> (oh and I sorted LIB_DEPENDS, don't know why fmt ended up in the wrong
> spot)
>
>
> Index: Makefile.inc
> ===
> RCS file: /home/cvs/ports/games/0ad/Makefile.inc,v
> retrieving revision 1.12
> diff -u -p -r1.12 Makefile.inc
> --- Makefile.inc 14 Jun 2021 10:19:46 - 1.12
> +++ Makefile.inc 13 Nov 2021 18:17:39 -
> @@ -4,7 +4,7 @@ ONLY_FOR_ARCHS = amd64 i386
>
> CATEGORIES = games
>
> -V ?= 0.0.23b
> +V ?= 0.0.25b
>
> HOMEPAGE = https://play0ad.com/
>
> Index: base/Makefile
> ===
> RCS file: /home/cvs/ports/games/0ad/base/Makefile,v
> retrieving revision 1.34
> diff -u -p -r1.34 Makefile
> --- base/Makefile 22 Jun 2021 04:34:08 - 1.34
> +++ base/Makefile 15 Nov 2021 09:55:01 -
> @@ -1,31 +1,28 @@
> # $OpenBSD: Makefile,v 1.34 2021/06/22 04:34:08 rsadowski Exp $
>
> -# XXX fix build with icu >=5.9.1 (remove at next update?)
> -CXXFLAGS += -DU_USING_ICU_NAMESPACE=1
> -
> COMMENT =historical real-time strategy game
>
> DISTNAME = 0ad-${V}-alpha-unix-build
> PKGNAME =0ad-${V}
> -REVISION = 3
>
> USE_WXNEEDED = Yes
>
> SO_VERSION = 0.0
> -SHARED_LIBS += mozjs38-ps-release${SO_VERSION}
> +SHARED_LIBS += mozjs78-ps-release${SO_VERSION}
>
> -WANTLIB += ${COMPILER_LIBCXX} GL SDL2 X11 Xcursor boost_filesystem
> -WANTLIB += boost_system c curl enet execinfo gloox iconv icui18n
> -WANTLIB += icuuc m miniupnpc nspr4 ogg openal plc4 plds4 png sodium
> -WANTLIB += vorbis vorbisfile xml2 z
> +WANTLIB += ${COMPILER_LIBCXX} GL SDL2 X11 boost_filesystem
> +WANTLIB += boost_system c crypto curl enet execinfo fmt gloox iconv
> +WANTLIB += icudata icui18n icuuc idn m miniupnpc ogg openal
> +WANTLIB += png sodium ssl vorbis vorbisfile xml2 z
>
> BUILD_DEPENDS = archivers/zip \
> + lang/rust,-main \
> shells/bash
> LIB_DEPENDS =audio/libvorbis \
> audio/openal \
> converters/libiconv \
> devel/boost \
> - devel/nspr \
> + devel/fmt \
> devel/sdl2 \
> graphics/png \
> net/curl \
> @@ -38,7 +35,6 @@ LIB_DEPENDS = audio/libvorbis \
> RUN_DEPENDS =devel/desktop-file-utils \
> games/0ad/data=${V}
> MODULES =lang/python
> -MODPY_VERSION = ${MODPY_DEFAULT_VERSION_2}
>
> COMPILER =
Re: [UPDATE] libstrophe 0.11.0
Hi,
> Upon a closer look I don't think we need to bump the major here,
> bumping only the minor to 3.1 should be enough.
> /usr/src/lib/check_sym libstrophe.so.{3.0,4.0} shows only additions
> and libstrophe seems to exports only opaque structs (e.g. xmpp_conn_t
> etc.)
>
> Otherwise I've been using this (and the profanity update) for a couple
> of days already and it works fine :)
>
> Thanks!
Thank you for importing it. I will read more documentation on check_sym
soon, thanks!
> % /usr/src/lib/check_sym libstrophe.so.{3,4}.0
> libstrophe.so.3.0 --> libstrophe.so.4.0
> Dynamic export changes:
> added:
> xmpp_conn_cert_xmppaddr
> xmpp_conn_cert_xmppaddr_num
> xmpp_conn_get_peer_cert
> xmpp_conn_set_cafile
> xmpp_conn_set_capath
> xmpp_conn_set_certfail_handler
> xmpp_conn_set_client_cert
> xmpp_ctx_set_verbosity
> xmpp_debug_verbose
> xmpp_strndup
> xmpp_tlscert_free
> xmpp_tlscert_get_conn
> xmpp_tlscert_get_ctx
> xmpp_tlscert_get_description
> xmpp_tlscert_get_dnsname
> xmpp_tlscert_get_pem
> xmpp_tlscert_get_string
>
> External reference changes:
> added:
> ASN1_INTEGER_to_BN
> ASN1_STRING_get0_data
> ASN1_STRING_length
> ASN1_STRING_to_UTF8
> ASN1_TIME_print
> BIO_ctrl
> BIO_free
> BIO_gets
> BIO_new
> BIO_new_file
> BIO_s_mem
> BN_bn2hex
> BN_free
> ERR_error_string
> EVP_sha1
> EVP_sha256
> GENERAL_NAMES_free
> GENERAL_NAME_get0_otherName
> GENERAL_NAME_get0_value
> OBJ_create
> OBJ_nid2ln
> OBJ_obj2nid
> OBJ_sn2nid
> PEM_read_bio_X509
> PEM_write_bio_X509
> SSL_CTX_load_verify_locations
> SSL_CTX_use_PrivateKey_file
> SSL_CTX_use_certificate_file
> SSL_get_ex_data
> SSL_get_ex_data_X509_STORE_CTX_idx
> SSL_set_ex_data
> X509_EXTENSION_get_data
> X509_PUBKEY_get0_param
> X509_STORE_CTX_get_current_cert
> X509_STORE_CTX_get_error
> X509_STORE_CTX_get_ex_data
> X509_digest
> X509_get0_signature
> X509_get_X509_PUBKEY
> X509_get_ext
> X509_get_ext_by_NID
> X509_get_serialNumber
> X509_get_version
> X509_getm_notAfter
> X509_getm_notBefore
> X509_verify_cert_error_string
> d2i_GENERAL_NAMES
> sk_num
> sk_value
> sprintf
>
> PLT added:
> xmpp_debug_verbose
> xmpp_jid_bare
> xmpp_strndup
> xmpp_tlscert_free
>
>
>
> > CATEGORIES = net devel
> >
> > Index: libstrophe/distinfo
> > ===
> > RCS file: /cvs/ports/net/libstrophe/distinfo,v
> > retrieving revision 1.4
> > diff -u -p -u -p -r1.4 distinfo
> > --- libstrophe/distinfo 10 Sep 2021 04:30:50 - 1.4
> > +++ libstrophe/distinfo 12 Nov 2021 16:56:58 -
> > @@ -1,2 +1,2 @@
> > -SHA256 (libstrophe-0.10.1.tar.gz) =
> > SRjEcCns3qLeq0sPkzbKSouxLCi3KyzsOX2YZkuUx3E= -SIZE
> > (libstrophe-0.10.1.tar.gz) = 520649 +SHA256
> > (libstrophe-0.11.0.tar.gz) =
> > NgWiDzLXsxkykuI4tBDVleAbHWRRD0LBCNoTwJtgaIo= +SIZE
> > (libstrophe-0.11.0.tar.gz) = 537506
>
--
greetings,
Florian Viehweger
better default for FULLPKGNAME-sub
This is one case where we have to special-case -main, as it's usually
the package with the "simple" name.
but as you guessed, it seems it might set the FULLPKGNAME to the right
value without needing to do a thing in many cases.
Index: bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1561
diff -u -p -r1.1561 bsd.port.mk
--- bsd.port.mk 21 Nov 2021 13:55:10 - 1.1561
+++ bsd.port.mk 21 Nov 2021 14:06:10 -
@@ -635,6 +635,14 @@ FULLPKGNAME- = ${FULLPKGNAME}
PKGSTEM ?= ${FULLPKGNAME:C/-[0-9].*//}
PKGSTEM- = ${PKGSTEM}
.else
+# parse PKGNAME as _STEM/_VERSION, just in case
+_STEM = ${PKGNAME:C/-[0-9].*//}
+. for _s in ${_STEM}
+_VERSION = ${PKGNAME:S/^${_s}-//}
+. endfor
+.if ${MULTI_PACKAGES:M-main}
+FULLPKGNAME-main ?= ${FULLPKGNAME}
+.endif
. for _s in ${MULTI_PACKAGES}
.if defined(FULLPKGNAME${_s})
. if !defined(FULLPKGPATH${_s}) && "${FLAVORS}" != " ${PSEUDO_FLAVORS}"
@@ -644,7 +652,7 @@ ERRORS += "Warning: FULLPKGNAME${_s} def
. if defined(PKGNAME${_s})
FULLPKGNAME${_s} = ${PKGNAME${_s}}${FLAVOR_EXT}
. else
-ERRORS += "Fatal: FULLPKGNAME${_s} is not defined"
+FULLPKGNAME${_s} = ${_STEM}${_s}-${_VERSION}${FLAVOR_EXT}
. endif
.endif
# XXX see comments above for !MULTI_PACKAGES case
Re: new: fonts/zh-wqy-microhei-ttf: another Chinese font from the WenQuanYi project
On 2021/11/21 12:16, Stuart Henderson wrote: > this is ok sthen@ if someone would like to import. oh, too quick - yes I agree with bentley@'s comments.
Re: new: fonts/zh-wqy-microhei-ttf: another Chinese font from the WenQuanYi project
this is ok sthen@ if someone would like to import. On 2021/11/21 11:11, Yifei Zhan wrote: > On 21/11/21 10:12AM, Stuart Henderson wrote: > > On 2021/11/21 10:10, Yifei Zhan wrote: > > > On 21/11/19 02:46AM, Yifei Zhan wrote: > > > > On 21/11/18 04:23PM, Stuart Henderson wrote: > > > > > On 2021/11/18 12:24, Yifei Zhan wrote: > > > > > > Hi, > > > > > > > > > > > > fonts/zh-wqy-microhei-ttf is another Chinese sans-serif font from > > > > > > the > > > > > > WenQuanYi family. It is one of the most widely used open source > > > > > > Chinese > > > > > > sans-serif font and I would like to import it. > > > > > > > > > > I think "beta" should be part of the version number, here is one way > > > > > to do it > > > > > > > > The "beta" part of the version doesn't make much sense to me because > > > > this version was released in 2009 and has been widely used since then. > > > > > > > > I think we should ignore the "beta" part, an update to this seems > > > > unlikely. > > > > > > > > > > friendly ping :) > > > > > > I have a few other ports I would like to submit in order to complete the > > > WenQuanYi font family. > > > > > > > I don't think we should ignore the "beta" part because it is part of the > > version number. > > > > > OK, here is a tweaked version: > > - removed CVS directories > - tweaked whitespace > - version string is now zh-wqy-microhei-ttf-0.2.0beta
Re: new: fonts/zh-wqy-microhei-ttf: another Chinese font from the WenQuanYi project
Stuart Henderson writes: > I don't think we should ignore the "beta" part because it is part of the > version number. I agree.
Re: new: fonts/zh-wqy-microhei-ttf: another Chinese font from the WenQuanYi project
On 2021/11/18 12:24, Yifei Zhan wrote: > fonts/zh-wqy-microhei-ttf is another Chinese sans-serif font from the > WenQuanYi family. It is one of the most widely used open source Chinese > sans-serif font and I would like to import it. @pkgpath in PLIST is not necessary. DESCR should read "easier to read and recognize", not "easier to read recognize". License marker should be Apache 2.0 + GPLv3. Most new font imports don't follow the practice of including language or file format in the package name like "zh" or "ttf". I guess part of the reason is that fonts tend to support multiple locales and provide additional formats like OTF. I would prefer to call it simply "wqy-microhei".
Re: pkg_add with certificate pinning
On Fri, Nov 19, 2021 at 11:14:34AM +, Yifei Zhan wrote: > On 21/11/19 07:35AM, Fabio Martins wrote: > > On 2021-11-19 06:57, Yifei Zhan wrote: > > > On 21/11/19 06:26AM, Fabio Martins wrote: > > > > Sorry if it is a bit off-topic. > > > > > > > > After reading an article about rogue CA's: > > > > > > > > https://www.theregister.com/2021/11/19/web_trust_certificates/ > > > > > > > > I wonder if there is any advantage of using certificate pinning in the > > > > process of pkg_add / sysupgrade / pkg_* while updating OpenBSD > > > > packages. > > > > > > > > > > OpenBSD does not use PKI/web of trust for integrity validation, thus I > > > don't think certificate pinning makes sense for those operations. > > > Instead, OpenBSD uses signify(1) with pubkeys in /etc/signify/ for that > > > purpose. > > > > Well said. I believe it would only improve confidentiality, as rogue > > middleware appliances would not be able to inspect the content of package > > updates. > > I don't think it makes any meaningful impact on confidentiality. All the > packages are public and since encryption doesn't change file size, it's > pretty easy for an attacker to match the content you are downloading > with the packages on the mirror you connected to. > > If you don't want others to know what package you are downloading, maybe > it's better to run an internal mirror and fetch things from there. > > something you might want to read: > > Marc Espie, Advances in OpenBSD packages: https is a lie > https://www.openbsd.org/papers/eurobsdcon_2018_https.pdf > I still haven't had the time to implement the counter-measures discussed in that talk... most specifically, the proxy that would keep an https connection alive...
[UPDATE] x11/menumaker 0.99.12 -> 0.99.14
Greetings,
The attached diff updates x11/menumaker to the latest release.
Upstream, this is just a bug-fix release; no significant changes in port.
All the best
--
Alessandro De Laurenzis
[mailto:jus...@atlantide.mooo.com]
Web: http://www.atlantide.mooo.com
LinkedIn: http://it.linkedin.com/in/delaurenzisIndex: Makefile
===
RCS file: /cvs/ports/x11/menumaker/Makefile,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 Makefile
--- Makefile 2 Nov 2021 00:02:59 - 1.9
+++ Makefile 21 Nov 2021 10:29:17 -
@@ -1,9 +1,8 @@
# $OpenBSD: Makefile,v 1.9 2021/11/02 00:02:59 sthen Exp $
COMMENT = menu generation utility for X window managers
-DISTNAME = menumaker-0.99.12
+DISTNAME = menumaker-0.99.14
CATEGORIES = x11
-REVISION = 0
MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=menumaker/}
Index: distinfo
===
RCS file: /cvs/ports/x11/menumaker/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- distinfo 14 Nov 2020 19:42:41 - 1.3
+++ distinfo 21 Nov 2021 10:29:17 -
@@ -1,2 +1,2 @@
-SHA256 (menumaker-0.99.12.tar.gz) = 46NWYYalqe1Nchwed4ilryQ8jIpFuW/m//PpRYAomww=
-SIZE (menumaker-0.99.12.tar.gz) = 206208
+SHA256 (menumaker-0.99.14.tar.gz) = EeldDnajuFD1ffgbxVYCIr1gFBxXUbbpvQXDzVVg1lo=
+SIZE (menumaker-0.99.14.tar.gz) = 205664
Re: new: fonts/zh-wqy-microhei-ttf: another Chinese font from the WenQuanYi project
On 2021/11/21 10:10, Yifei Zhan wrote: > On 21/11/19 02:46AM, Yifei Zhan wrote: > > On 21/11/18 04:23PM, Stuart Henderson wrote: > > > On 2021/11/18 12:24, Yifei Zhan wrote: > > > > Hi, > > > > > > > > fonts/zh-wqy-microhei-ttf is another Chinese sans-serif font from the > > > > WenQuanYi family. It is one of the most widely used open source Chinese > > > > sans-serif font and I would like to import it. > > > > > > I think "beta" should be part of the version number, here is one way to > > > do it > > > > The "beta" part of the version doesn't make much sense to me because > > this version was released in 2009 and has been widely used since then. > > > > I think we should ignore the "beta" part, an update to this seems > > unlikely. > > > > friendly ping :) > > I have a few other ports I would like to submit in order to complete the > WenQuanYi font family. > I don't think we should ignore the "beta" part because it is part of the version number.
sysutils/kopia: update to v0.9.6
Changelog : https://github.com/kopia/kopia/compare/v0.9.5...v0.9.6
Index: Makefile
===
RCS file: /cvs/ports/sysutils/kopia/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile8 Nov 2021 14:53:13 - 1.4
+++ Makefile21 Nov 2021 09:41:55 -
@@ -3,7 +3,7 @@
COMMENT = simple tool for managing encrypted backups in the cloud
MODGO_MODNAME =github.com/kopia/kopia
-MODGO_VERSION =v0.9.5
+MODGO_VERSION =v0.9.6
MODGO_FLAGS += -tags embedhtml
DISTNAME = kopia-${MODGO_VERSION}
Index: distinfo
===
RCS file: /cvs/ports/sysutils/kopia/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo8 Nov 2021 14:53:13 - 1.4
+++ distinfo21 Nov 2021 09:41:55 -
@@ -241,8 +241,6 @@ SHA256 (go_modules/github.com/dustin/go-
SHA256 (go_modules/github.com/dustin/go-humanize/@v/v1.0.0.zip) =
4BkW4IKmZG6hLXgA13r0MEXCcoT/Kgp340hFCZicwQc=
SHA256
(go_modules/github.com/dustinkirkland/golang-petname/@v/v0.0.0-20191129215211-8e5a1ed0cff0.mod)
= E0BtEnYe6kvIxnOGtkFQso2PgmHdslUEAENxx8Hhn9w=
SHA256
(go_modules/github.com/dustinkirkland/golang-petname/@v/v0.0.0-20191129215211-8e5a1ed0cff0.zip)
= zXxhHs5XgypfBFo+vYBzxyw2p045MnpdH5D+TbFQpEI=
-SHA256 (go_modules/github.com/efarrer/iothrottler/@v/v0.0.3.mod) =
wTsaQzS+kamjF1Cji2Wvr8UL77iY8Tb0Pe/Cap07qxA=
-SHA256 (go_modules/github.com/efarrer/iothrottler/@v/v0.0.3.zip) =
EVdzQHU4FVUZAJGq1eovQwN9wI9ODIp5i3R8e8oXS1g=
SHA256 (go_modules/github.com/envoyproxy/go-control-plane/@v/v0.9.0.mod) =
Lg88WUDGkwvOA/DIzRck3ZPU0wxrHFri7k4wOfAhXAc=
SHA256
(go_modules/github.com/envoyproxy/go-control-plane/@v/v0.9.1-0.20191026205805-5f8ba28d4473.mod)
= Lg88WUDGkwvOA/DIzRck3ZPU0wxrHFri7k4wOfAhXAc=
SHA256
(go_modules/github.com/envoyproxy/go-control-plane/@v/v0.9.10-0.20210907150352-cf90f659a021.mod)
= aAW6axHpQfSLIEsB/XqNCloJFuzXfFl+bhdg18hpD4o=
@@ -1162,8 +1160,8 @@ SHA256 (go_modules/rsc.io/quote/v3/@v/v3
SHA256 (go_modules/rsc.io/quote/v3/@v/v3.1.0.zip) =
tDTLv8MsF7UijQsO3erqib707JvZC1yPxVtk+M4T7rk=
SHA256 (go_modules/rsc.io/sampler/@v/v1.3.0.mod) =
oq5uhUCkC4XldwPMYYuZxbEHU4bZWOiZmg4tTALzpwU=
SHA256 (go_modules/rsc.io/sampler/@v/v1.3.0.zip) =
2iArDagDqyZhq5imgLuk9kEjoyblQMJVgrbNu53BFKo=
-SHA256 (kopia-html-ui.v0.9.5.tgz) =
SAO7YntJL696PsBZGXl/jCc7t24zK1YosOBC/YeYZz0=
-SHA256 (kopia-v0.9.5.zip) = HwW8BMebKAK/D5mZ2+LkIOJSbibxHoEh88uMnBxi074=
+SHA256 (kopia-html-ui.v0.9.6.tgz) =
YGEHn3GDVupZu+AosNFxM0r2VcrtjHdeBCrDbwQgIn8=
+SHA256 (kopia-v0.9.6.zip) = 2izng1L7wEDcmfXSJ9Ghv+P901Xo05zqzZDfsaJZeeU=
SIZE (go_modules/bazil.org/fuse/@v/v0.0.0-20180421153158-65cc252bf669.mod) = 22
SIZE (go_modules/bazil.org/fuse/@v/v0.0.0-20180421153158-65cc252bf669.zip) =
220785
SIZE (go_modules/cloud.google.com/go/@v/v0.26.0.mod) = 27
@@ -1407,8 +1405,6 @@ SIZE (go_modules/github.com/dustin/go-hu
SIZE (go_modules/github.com/dustin/go-humanize/@v/v1.0.0.zip) = 26356
SIZE
(go_modules/github.com/dustinkirkland/golang-petname/@v/v0.0.0-20191129215211-8e5a1ed0cff0.mod)
= 48
SIZE
(go_modules/github.com/dustinkirkland/golang-petname/@v/v0.0.0-20191129215211-8e5a1ed0cff0.zip)
= 22282
-SIZE (go_modules/github.com/efarrer/iothrottler/@v/v0.0.3.mod) = 47
-SIZE (go_modules/github.com/efarrer/iothrottler/@v/v0.0.3.zip) = 11941
SIZE (go_modules/github.com/envoyproxy/go-control-plane/@v/v0.9.0.mod) = 378
SIZE
(go_modules/github.com/envoyproxy/go-control-plane/@v/v0.9.1-0.20191026205805-5f8ba28d4473.mod)
= 378
SIZE
(go_modules/github.com/envoyproxy/go-control-plane/@v/v0.9.10-0.20210907150352-cf90f659a021.mod)
= 581
@@ -2328,5 +2324,5 @@ SIZE (go_modules/rsc.io/quote/v3/@v/v3.1
SIZE (go_modules/rsc.io/quote/v3/@v/v3.1.0.zip) = 2223
SIZE (go_modules/rsc.io/sampler/@v/v1.3.0.mod) = 88
SIZE (go_modules/rsc.io/sampler/@v/v1.3.0.zip) = 14308
-SIZE (kopia-html-ui.v0.9.5.tgz) = 1017832
-SIZE (kopia-v0.9.5.zip) = 3477502
+SIZE (kopia-html-ui.v0.9.6.tgz) = 1017782
+SIZE (kopia-v0.9.6.zip) = 3911345
Index: modules.inc
===
RCS file: /cvs/ports/sysutils/kopia/modules.inc,v
retrieving revision 1.3
diff -u -p -r1.3 modules.inc
--- modules.inc 8 Nov 2021 14:53:13 - 1.3
+++ modules.inc 21 Nov 2021 09:41:55 -
@@ -745,7 +745,6 @@ MODGO_MODULES = \
github.com/dimchansky/utfbom v1.1.1
\
github.com/dustin/go-humanizev1.0.0
\
github.com/dustinkirkland/golang-petname
v0.0.0-20191129215211-8e5a1ed0cff0 \
- github.com/efarrer/iothrottler v0.0.3
\
github.com/envoyproxy/go-control-plane
v0.9.10-0.20210907150352-cf90f659a021 \
github.com/envoyproxy/protoc-gen-validatev0.1.0
\
Re: [UPDATE] libstrophe 0.11.0
Florian Viehweger writes:
> Hi,
>
> this updates libstrophe 0.11.0.
>
> Changes:
> - SASL EXTERNAL support (XEP-0178)
> - Client certificate can be provided for TLS negotiation. If the
> certificate contains a single xmppAddr and JID is not provided with
> xmpp_conn_set_jid(), the xmppAddr is chosen as JID
> - element contains "from" attribute over TLS connections now
> - GnuTLS can be selected optionally with configure script
> - Support for manual certificate verification
> - New API:
> - xmpp_conn_set_client_cert()
> - xmpp_conn_cert_xmppaddr_num()
> - xmpp_conn_cert_xmppaddr()
> - xmpp_conn_set_cafile()
> - xmpp_conn_set_capath()
> - xmpp_conn_set_certfail_handler()
> - xmpp_conn_get_peer_cert()
> - xmpp_tlscert_get_ctx()
> - xmpp_tlscert_get_conn()
> - xmpp_tlscert_get_pem()
> - xmpp_tlscert_get_dnsname()
> - xmpp_tlscert_get_string()
> - xmpp_tlscert_get_description()
> - xmpp_tlscert_free()
>
> I've been running this for a few days on amd64 with the updated version
> of profanity, submitted in a separate mail.
>
> portcheck, 'make lib-depends-check' and 'make test' are happy.
>
> Comments? OK?
>
>
> Index: libstrophe/Makefile
> ===
> RCS file: /cvs/ports/net/libstrophe/Makefile,v
> retrieving revision 1.6
> diff -u -p -u -p -r1.6 Makefile
> --- libstrophe/Makefile 10 Oct 2021 19:53:27 - 1.6
> +++ libstrophe/Makefile 12 Nov 2021 16:56:58 -
> @@ -2,11 +2,10 @@
>
> COMMENT =simple, lightweight XMPP C library
>
> -V = 0.10.1
> +V = 0.11.0
> DISTNAME = libstrophe-${V}
> -REVISION = 0
>
> -SHARED_LIBS =strophe 3.0 # 1.0
> +SHARED_LIBS =strophe 4.0 # 3.0
Upon a closer look I don't think we need to bump the major here, bumping
only the minor to 3.1 should be enough. /usr/src/lib/check_sym
libstrophe.so.{3.0,4.0} shows only additions and libstrophe seems to
exports only opaque structs (e.g. xmpp_conn_t etc.)
Otherwise I've been using this (and the profanity update) for a couple
of days already and it works fine :)
Thanks!
% /usr/src/lib/check_sym libstrophe.so.{3,4}.0
libstrophe.so.3.0 --> libstrophe.so.4.0
Dynamic export changes:
added:
xmpp_conn_cert_xmppaddr
xmpp_conn_cert_xmppaddr_num
xmpp_conn_get_peer_cert
xmpp_conn_set_cafile
xmpp_conn_set_capath
xmpp_conn_set_certfail_handler
xmpp_conn_set_client_cert
xmpp_ctx_set_verbosity
xmpp_debug_verbose
xmpp_strndup
xmpp_tlscert_free
xmpp_tlscert_get_conn
xmpp_tlscert_get_ctx
xmpp_tlscert_get_description
xmpp_tlscert_get_dnsname
xmpp_tlscert_get_pem
xmpp_tlscert_get_string
External reference changes:
added:
ASN1_INTEGER_to_BN
ASN1_STRING_get0_data
ASN1_STRING_length
ASN1_STRING_to_UTF8
ASN1_TIME_print
BIO_ctrl
BIO_free
BIO_gets
BIO_new
BIO_new_file
BIO_s_mem
BN_bn2hex
BN_free
ERR_error_string
EVP_sha1
EVP_sha256
GENERAL_NAMES_free
GENERAL_NAME_get0_otherName
GENERAL_NAME_get0_value
OBJ_create
OBJ_nid2ln
OBJ_obj2nid
OBJ_sn2nid
PEM_read_bio_X509
PEM_write_bio_X509
SSL_CTX_load_verify_locations
SSL_CTX_use_PrivateKey_file
SSL_CTX_use_certificate_file
SSL_get_ex_data
SSL_get_ex_data_X509_STORE_CTX_idx
SSL_set_ex_data
X509_EXTENSION_get_data
X509_PUBKEY_get0_param
X509_STORE_CTX_get_current_cert
X509_STORE_CTX_get_error
X509_STORE_CTX_get_ex_data
X509_digest
X509_get0_signature
X509_get_X509_PUBKEY
X509_get_ext
X509_get_ext_by_NID
X509_get_serialNumber
X509_get_version
X509_getm_notAfter
X509_getm_notBefore
X509_verify_cert_error_string
d2i_GENERAL_NAMES
sk_num
sk_value
sprintf
PLT added:
xmpp_debug_verbose
xmpp_jid_bare
xmpp_strndup
xmpp_tlscert_free
> CATEGORIES = net devel
>
> Index: libstrophe/distinfo
> ===
> RCS file: /cvs/ports/net/libstrophe/distinfo,v
> retrieving revision 1.4
> diff -u -p -u -p -r1.4 distinfo
> --- libstrophe/distinfo 10 Sep 2021 04:30:50 - 1.4
> +++ libstrophe/distinfo 12 Nov 2021 16:56:58 -
> @@ -1,2 +1,2 @@
> -SHA256 (libstrophe-0.10.1.tar.gz) =
> SRjEcCns3qLeq0sPkzbKSouxLCi3KyzsOX2YZkuUx3E=
> -SIZE (libstrophe-0.10.1.tar.gz) = 520649
> +SHA256 (libstrophe-0.11.0.tar.gz) =
> NgWiDzLXsxkykuI4tBDVleAbHWRRD0LBCNoTwJtgaIo=
> +SIZE (libstrophe-0.11.0.tar.gz) = 537506
