Re: quiche security update
Hi,
maybe I was not being clear... it would be ncie to have this in the release.
-Otto
On Wed, Mar 13, 2024 at 08:05:47AM +0100, Otto Moerbeek wrote:
> Hi,
>
> This is a security update to quiche.
>
> See https://github.com/cloudflare/quiche/releases/tag/0.20.1
>
> sthen, naddy, OK?
>
> -Otto
>
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/net/quiche/Makefile,v
> diff -u -p -r1.2 Makefile
> --- Makefile 20 Dec 2023 11:25:58 - 1.2
> +++ Makefile 13 Mar 2024 07:03:03 -
> @@ -3,7 +3,7 @@ COMMENT = library implementing QUIC and
> # ring-v0.17 does not support this arch
> NOT_FOR_ARCHS = sparc64
>
> -V = 0.20.0
> +V = 0.20.1
> PKG_NAME = quiche-${V}
> CATEGORIES = net
> HOMEPAGE = https://github.com/cloudflare/quiche
> Index: distinfo
> ===
> RCS file: /home/cvs/ports/net/quiche/distinfo,v
> diff -u -p -r1.2 distinfo
> --- distinfo 20 Dec 2023 11:25:58 - 1.2
> +++ distinfo 13 Mar 2024 07:03:03 -
> @@ -119,7 +119,7 @@ SHA256 (cargo/windows_i686_msvc-0.48.5.t
> SHA256 (cargo/windows_x86_64_gnu-0.48.5.tar.gz) =
> U9QKvSWD0j5HGP3fHr7ITb/4OBwHyuZ/93aLvxnGcY4=
> SHA256 (cargo/windows_x86_64_gnullvm-0.48.5.tar.gz) =
> C3tSdnhooj1bq3aOOQ3F9cVYJbbTC4bIRP8tx0FARMw=
> SHA256 (cargo/windows_x86_64_msvc-0.48.5.tar.gz) =
> 7ZT85hVxpABoUrc4mgY6uYPALrG7N7R/gnLOktBtlTg=
> -SHA256 (quiche-0.20.0.tar.gz) = cSW8gt3POPv7xpiCzLJyO/tNW/60Jxi4KR0m7AYELjg=
> +SHA256 (quiche-0.20.1.tar.gz) = nEYNjs9sgMBr+bQvkSAe8z+RLiYVqHH/LQ5QGXuQHHE=
> SIZE (cargo/aho-corasick-1.1.2.tar.gz) = 183136
> SIZE (cargo/android-tzdata-0.1.1.tar.gz) = 7674
> SIZE (cargo/android_system_properties-0.1.5.tar.gz) = 5243
> @@ -241,4 +241,4 @@ SIZE (cargo/windows_i686_msvc-0.48.5.tar
> SIZE (cargo/windows_x86_64_gnu-0.48.5.tar.gz) = 801619
> SIZE (cargo/windows_x86_64_gnullvm-0.48.5.tar.gz) = 418486
> SIZE (cargo/windows_x86_64_msvc-0.48.5.tar.gz) = 798412
> -SIZE (quiche-0.20.0.tar.gz) = 681940
> +SIZE (quiche-0.20.1.tar.gz) = 683362
>
Re: HOTFIX games/{bugdom,bugdom2,nanosaur,mightymike,ottomatic,billyfrontier} on sparc64
On 2024/03/13 19:36, Tobias Heider via ports wrote: > > > On March 13, 2024 7:24:26 PM GMT+01:00, Stuart Henderson via ports > wrote: > >On 2024/03/13 12:31, izder456 via ports wrote: > >> Hey ports@- > >> > >> Looks like these ports I take MAINTAINER on fail on sparc64 with the > >> same u8string error, which AFAIK is a C++20 thing. > >> > >> From what it looks like, sparc64 doesn't have a C++20 compiler, so they > >> unfortunately will be broken on that arch. > >> > >> Attached are diffs that adds BROKEN-sparc64 to those ports. > > > >I think something like this would be preferable > > > ># requires C++20 > >COMPILER = base-clang > > > > but then you could also add ports clang and ports gcc right? > they should also support newer c++ versions Could try it, but it seems fairly doubtful that they'll be good enough, c++20 support in gcc 8 was pretty limited (and uses -std=c++2a not -std=c++20), and ports-clang on base-gcc archs uses libestdc++ from gcc 8. (gcc/11 is in the ports tree but can't be used in bulks unless all c++ ports on whichever arch are switched from 8 to 11 otherwise there will be build conflicts).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2024/03/13 12:48:29 Modified files: www/chromium : Makefile www/iridium: Makefile www/ungoogled-chromium: Makefile Added files: www/chromium/patches: patch-media_base_libaom_thread_wrapper_cc www/ungoogled-chromium/patches: patch-media_base_libaom_thread_wrapper_cc Log message: switch over the chromium ports to use multimedia/aom to pick up endbr64 fixes iridium does not need the thread wrapper patch as it does not include that code yet tested by sthen@ and me, ok naddy@
Re: UPDATE FIX: devel/fast_float distinfo
El Wed, 13 Mar 2024 18:08:04 +
Stuart Henderson escribió:
> On 2024/03/13 13:33, Jose Maldonado wrote:
> >
> > Hi list!
> >
> > I've seen a new update to fast_float (library required for the new
> > libplacebo and mpv) that could affect the 7.5 and -current package
> > builds due to a change in the project's Github.
>
> Unimportant for release, it's on the bulk build machines already, and
> is on one of the fallback distfiles sites.
Excellent!
>
> > The change has been added through a commit [1] that fixes a typo in
> > the version of the project in CmakeList.txt, but from upstream
> > instead of creating a new version (6.1.1), they have decided to
> > include the change and keep calling the version as 6.1.0, breaking
> > the old distinfo.
>
> That's a nuisance, it would be helpful if projects wouldn't do that.
It seems like a mistake to me, they should have made a version 6.1.1,
marking the correction with it.
>
> That's not the only change - float_common.h was modified too, so it
> will also need a REVISION bump.
>
> https://github.com/fastfloat/fast_float/commit/55a5b3c8e136a6f55cbb13829f284bdc7150567c
> #include
> #include
> #ifdef __has_include
> - #if __has_include()
> + #if __has_include() && (__cplusplus > 202002L ||
> _MSVC_LANG > 202002L) #include
>#endif
> #endif
>
Sorry, I had not seen such a change in the source.
> > This patch solves the problem and unlocks the port build.
>
> The distfile needs to be renamed via the filename{url}sufx mechanism
> if the contents have changed. Builds are done from machines with
> varying states of the ports tree (it's common to have the build
> machine for one arch on one ports checkout and another on a newer one
> - except for the special case of release builds, this is the normal
> situation). For the main build machines there's a common distfiles
> directory shared over NFS, so it's a problem if one machine fetches a
> new file to match what it needs, while another is still building and
> expecting an old version.
>
> A diff something like this will work, though if there's a new version
> upstream before we're ready to reopen commits we might as well just
> change to that instead.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/fast-float/Makefile,v
> diff -u -p -r1.1.1.1 Makefile
> --- Makefile 13 Feb 2024 19:45:52 - 1.1.1.1
> +++ Makefile 13 Mar 2024 18:00:59 -
> @@ -2,9 +2,11 @@ COMMENT =fast and exact implementation
>
> V = 6.1.0
> PKGNAME =fast-float-${V}
> +REVISION = 0
> GH_TAGNAME = v${V}
> GH_ACCOUNT = fastfloat
> GH_PROJECT = fast_float
> +DISTFILES = fast_float-{v}${V}-0.tar.gz
>
> CATEGORIES = devel
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/devel/fast-float/distinfo,v
> diff -u -p -r1.1.1.1 distinfo
> --- distinfo 13 Feb 2024 19:45:52 - 1.1.1.1
> +++ distinfo 13 Mar 2024 18:00:59 -
> @@ -1,2 +1,2 @@
> -SHA256 (fast_float-6.1.0.tar.gz) =
> qcjKjKfWjC27E0Q0BE+cZs/Uw4PV6Fw2twTTD2voJQY= -SIZE
> (fast_float-6.1.0.tar.gz) = 95974 +SHA256 (fast_float-6.1.0-0.tar.gz)
> = WmKeHxjwN60AFsQerWMOpHHMy832AjntNGbEkdjnyQg= +SIZE
> (fast_float-6.1.0-0.tar.gz) = 96104
>
Thanks for the explanation @sthen. Regarding the possibility of a new
version of fast_float before the new version of 7.5 comes out, this is
unlikely, and we should stick to v6.1.0.
In any case, my initial concern was the fact that the builds packages
would have some problem downloading the distfile and will encounter an
error due to the change of the file, and that this will block the
construction of the packages dependent on it.
Your explanation of how build packages work eliminates this problem,
but leaves us with the problem of package evolution and its strange
decisions when listing versions.
I have tried the change you have made, all work without problem.
--
*
Dios en su cielo, todo bien en la Tierra
Re: HOTFIX games/{bugdom,bugdom2,nanosaur,mightymike,ottomatic,billyfrontier} on sparc64
On March 13, 2024 7:24:26 PM GMT+01:00, Stuart Henderson via ports wrote: >On 2024/03/13 12:31, izder456 via ports wrote: >> Hey ports@- >> >> Looks like these ports I take MAINTAINER on fail on sparc64 with the >> same u8string error, which AFAIK is a C++20 thing. >> >> From what it looks like, sparc64 doesn't have a C++20 compiler, so they >> unfortunately will be broken on that arch. >> >> Attached are diffs that adds BROKEN-sparc64 to those ports. > >I think something like this would be preferable > ># requires C++20 >COMPILER = base-clang > but then you could also add ports clang and ports gcc right? they should also support newer c++ versions
Re: HOTFIX games/{bugdom,bugdom2,nanosaur,mightymike,ottomatic,billyfrontier} on sparc64
On 2024/03/13 12:31, izder456 via ports wrote: > Hey ports@- > > Looks like these ports I take MAINTAINER on fail on sparc64 with the > same u8string error, which AFAIK is a C++20 thing. > > From what it looks like, sparc64 doesn't have a C++20 compiler, so they > unfortunately will be broken on that arch. > > Attached are diffs that adds BROKEN-sparc64 to those ports. I think something like this would be preferable # requires C++20 COMPILER = base-clang
Re: [UPDATE] emulators/dosbox-x-2024.03.01
On 2024/03/08 21:58, SASANO Takayoshi wrote: > Hi, > > here is the diff for dosbox-x 2023.10.06 -> 2024.03.01. This broke the build on i386, esfmu/esfm.c:1849:5: error: inline assembly requires more registers than available "movzbl %b[wave], %%eax \n\t" ^ It's too late to fix for release now.
Re: UPDATE FIX: devel/fast_float distinfo
On 2024/03/13 13:33, Jose Maldonado wrote:
>
> Hi list!
>
> I've seen a new update to fast_float (library required for the new
> libplacebo and mpv) that could affect the 7.5 and -current package
> builds due to a change in the project's Github.
Unimportant for release, it's on the bulk build machines already, and
is on one of the fallback distfiles sites.
> The change has been added through a commit [1] that fixes a typo in the
> version of the project in CmakeList.txt, but from upstream instead of
> creating a new version (6.1.1), they have decided to include the change
> and keep calling the version as 6.1.0, breaking the old distinfo.
That's a nuisance, it would be helpful if projects wouldn't do that.
That's not the only change - float_common.h was modified too, so it will
also need a REVISION bump.
https://github.com/fastfloat/fast_float/commit/55a5b3c8e136a6f55cbb13829f284bdc7150567c
#include
#include
#ifdef __has_include
- #if __has_include()
+ #if __has_include() && (__cplusplus > 202002L || _MSVC_LANG >
202002L)
#include
#endif
#endif
> This patch solves the problem and unlocks the port build.
The distfile needs to be renamed via the filename{url}sufx mechanism
if the contents have changed. Builds are done from machines with
varying states of the ports tree (it's common to have the build machine
for one arch on one ports checkout and another on a newer one - except
for the special case of release builds, this is the normal situation).
For the main build machines there's a common distfiles directory shared
over NFS, so it's a problem if one machine fetches a new file to match
what it needs, while another is still building and expecting an old
version.
A diff something like this will work, though if there's a new version
upstream before we're ready to reopen commits we might as well just
change to that instead.
Index: Makefile
===
RCS file: /cvs/ports/devel/fast-float/Makefile,v
diff -u -p -r1.1.1.1 Makefile
--- Makefile13 Feb 2024 19:45:52 - 1.1.1.1
+++ Makefile13 Mar 2024 18:00:59 -
@@ -2,9 +2,11 @@ COMMENT = fast and exact implementation
V =6.1.0
PKGNAME = fast-float-${V}
+REVISION = 0
GH_TAGNAME = v${V}
GH_ACCOUNT = fastfloat
GH_PROJECT = fast_float
+DISTFILES =fast_float-{v}${V}-0.tar.gz
CATEGORIES = devel
Index: distinfo
===
RCS file: /cvs/ports/devel/fast-float/distinfo,v
diff -u -p -r1.1.1.1 distinfo
--- distinfo13 Feb 2024 19:45:52 - 1.1.1.1
+++ distinfo13 Mar 2024 18:00:59 -
@@ -1,2 +1,2 @@
-SHA256 (fast_float-6.1.0.tar.gz) = qcjKjKfWjC27E0Q0BE+cZs/Uw4PV6Fw2twTTD2voJQY=
-SIZE (fast_float-6.1.0.tar.gz) = 95974
+SHA256 (fast_float-6.1.0-0.tar.gz) =
WmKeHxjwN60AFsQerWMOpHHMy832AjntNGbEkdjnyQg=
+SIZE (fast_float-6.1.0-0.tar.gz) = 96104
UPDATE FIX: devel/fast_float distinfo
Hi list! I've seen a new update to fast_float (library required for the new libplacebo and mpv) that could affect the 7.5 and -current package builds due to a change in the project's Github. The change has been added through a commit [1] that fixes a typo in the version of the project in CmakeList.txt, but from upstream instead of creating a new version (6.1.1), they have decided to include the change and keep calling the version as 6.1.0, breaking the old distinfo. This patch solves the problem and unlocks the port build. Okay? 1.- https://github.com/fastfloat/fast_float/commit/2f3ed44e0668b5536f3acb9bc38ed195f9e32165 -- * Dios en su cielo, todo bien en la Tierra devel_fast_float_v610 Description: Binary data
HOTFIX games/{bugdom,bugdom2,nanosaur,mightymike,ottomatic,billyfrontier} on sparc64
Hey ports@-
Looks like these ports I take MAINTAINER on fail on sparc64 with the
same u8string error, which AFAIK is a C++20 thing.
From what it looks like, sparc64 doesn't have a C++20 compiler, so they
unfortunately will be broken on that arch.
Attached are diffs that adds BROKEN-sparc64 to those ports.
Thanks.
--
-iz (they/them)
> i like to say mundane things,
> there are too many uninteresting things
> that go unnoticed.
izder456 (dot) neocities (dot) org
diff --git mightymike/Makefile mightymike/Makefile
index 0149fc600..49a2e3da7 100644
--- mightymike/Makefile
+++ mightymike/Makefile
@@ -6,6 +6,8 @@ DIST_TUPLE += github jorio MightyMike v${V} .
DIST_TUPLE += github jorio Pomme d57c28e205462e51063e787f9ebddaadff592f1e \
extern/Pomme
+BROKEN-sparc64 = needs C++20 compiler
+
CATEGORIES = games
HOMEPAGE = https://pangeasoft.net/mightymike
diff --git billyfrontier/Makefile billyfrontier/Makefile
index 5462bab38..14e686bb0 100644
--- billyfrontier/Makefile
+++ billyfrontier/Makefile
@@ -6,6 +6,8 @@ DIST_TUPLE += github jorio BillyFrontier v${V} .
DIST_TUPLE += github jorio Pomme 9fae17d7715314a3a20259ac2e87aa500a977695 \
extern/Pomme
+BROKEN-sparc64 = needs C++20 compiler
+
CATEGORIES = games
HOMEPAGE = https://pangeasoft.net/billy
diff --git ottomatic/Makefile ottomatic/Makefile
index 55f9e5297..090e15108 100644
--- ottomatic/Makefile
+++ ottomatic/Makefile
@@ -7,6 +7,8 @@ DIST_TUPLE += github jorio OttoMatic ${V} .
DIST_TUPLE += github jorio Pomme ef94150e2dcec522e3099f4d03a4e8f2639f7232 \
extern/Pomme
+BROKEN-sparc64 = needs C++20 compiler
+
CATEGORIES = games
HOMEPAGE = https://pangeasoft.net/otto
diff --git nanosaur/Makefile nanosaur/Makefile
index 96bcc0c6a..da0d75e85 100644
--- nanosaur/Makefile
+++ nanosaur/Makefile
@@ -6,6 +6,8 @@ DIST_TUPLE += github jorio Nanosaur v${V} .
DIST_TUPLE += github jorio Pomme d57c28e205462e51063e787f9ebddaadff592f1e \
extern/Pomme
+BROKEN-sparc64 = needs C++20 compiler
+
CATEGORIES = games
HOMEPAGE = https://pangeasoft.net/nano
diff --git bugdom2/Makefile bugdom2/Makefile
index 89dc4ad6f..ff6d86bfa 100644
--- bugdom2/Makefile
+++ bugdom2/Makefile
@@ -6,6 +6,8 @@ DIST_TUPLE += github jorio Bugdom2 v${V} .
DIST_TUPLE += github jorio Pomme c6a38eab19a11847024a13f9b3e2af0c2d908c3e \
extern/Pomme
+BROKEN-sparc64 = needs C++20 compiler
+
CATEGORIES = games
HOMEPAGE = https://pangeasoft.net/bug2
diff --git bugdom/Makefile bugdom/Makefile
index f48f280f6..ab17bd59a 100644
--- bugdom/Makefile
+++ bugdom/Makefile
@@ -6,6 +6,8 @@ DIST_TUPLE += github jorio Bugdom ${V} .
DIST_TUPLE += github jorio Pomme ef94150e2dcec522e3099f4d03a4e8f2639f7232 \
extern/Pomme
+BROKEN-sparc64 = needs C++20 compiler
+
CATEGORIES = games
HOMEPAGE = https://pangeasoft.net/bug
Question RE: Failed bulk build standard practice
Hey ports@- already messaged #openbsd about this on libera but for digital record's sake, I wanted to ask here as well. I take MAINTAINER on several ports with no ONLY_FOR_ARCH set. When looking through the bulk build reports in the ports@ lists this morning, I saw that some ports I worked on have failed on hardware I don't have access too. Is there a special practice we do when this occurrs, or is the port just never built into binary at release for that arch? is there something like a blacklist equivalent of ONLY_FOR_ARCH? also- If there isn't enough time to factor in these sort of hotfixes, what is general practice when RELEASE happens, and the ports are version froze in case I need to patch my port because someone on STABLE has experienced breakage? Still new-ish to this ports@ thing, forgive my noobiness :) Thanks, any guidance is much appreciated. -- -iz (they/them) > i like to say mundane things, > there are too many uninteresting things > that go unnoticed. izder456 (dot) neocities (dot) org
Re: Chromium browsers: Meet + webcam = SIGILL?
On 2024/03/12 17:52, Stuart Henderson wrote:
> On 2024/03/12 17:20, Stuart Henderson wrote:
> > On 2024/03/11 17:32, Laurence Tratt wrote:
> > > On Mon, Mar 11, 2024 at 11:14:44AM -0600, Theo de Raadt wrote:
> > >
> > > Hello Theo,
> > >
> > > > With a bit of effort, the address you see:
> > > >
> > > > addr=0x67cb1d220
> > > >
> > > > can be compared in the ktrace to earlier mmap() operations (done by the
> > > > shared library linker ld.so); those mmap are mappings against a file
> > > > descriptor,
> > > > and you can see what library file ld.so opened just previously... then
> > > > we know
> > > > what library still has a BTI issue.
> > >
> > > I will admit to being absolute clueless with kdump output. I'm happy to
> > > try
> > > if someone can give me some hints, but equally if someone wants to look at
> > > the dump, I'm happy to send them on for analysis.
> >
> > I've had a look at this, but there's nothing relevant in kdump output
> > matching close to that address.
> >
> > $ kdump|grep -E '0x67[0-9a-f]{7}'
> > 69377 chrome CALL unveil(0x674f4c86b,0x674ee7079)
> > 69377 chrome CALL pledge(0x674e59cbb,0)
> > 69377 chrome PSIG SIGILL SIG_DFL code=ILL_BTCFI addr=0x67cb1d220
> > trapno=21
> >
> > Educated guess: chromium uses its own bundled copy of aom (AV1 codec;
> > AFAIK it uses dav1d to _de_code AV1 but that's a decoder only, so
> > there's a good chance it uses aom to _en_code) which doesn't have
> > patches for IBT. So I think there's a good chance it's that.
>
> I've managed to get this working with an external webcam - video(4)
> seems broken with the internal cams on T14G3. chromium build uses nasm
> not yasm so we can go with the simple version of the definition.
>
> I've just started a build with the diff, hopefully will be able to
> test runtime tomorrow.
Confirmed this fixes it. Same patch file applies to iridium and
ungoogled-chromium with no offset.
Robert has a different diff to use multimedia/aom instead of the bundled
version which is preferable overall but a bigger change.
> Index: Makefile
> ===
> RCS file: /cvs/ports/www/chromium/Makefile,v
> diff -u -p -r1.772 Makefile
> --- Makefile 6 Mar 2024 12:30:17 - 1.772
> +++ Makefile 12 Mar 2024 17:46:27 -
> @@ -10,6 +10,7 @@ DPB_PROPERTIES+=lonesome
> COMMENT= Chromium browser
>
> V= 122.0.6261.111
> +REVISION=0
>
> DISTNAME=chromium-${V}
>
> Index:
> patches/patch-third_party_libaom_source_libaom_third_party_x86inc_x86inc_asm
> ===
> RCS file:
> patches/patch-third_party_libaom_source_libaom_third_party_x86inc_x86inc_asm
> diff -N
> patches/patch-third_party_libaom_source_libaom_third_party_x86inc_x86inc_asm
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++
> patches/patch-third_party_libaom_source_libaom_third_party_x86inc_x86inc_asm
> 12 Mar 2024 17:46:27 -
> @@ -0,0 +1,24 @@
> +Index: third_party/libaom/source/libaom/third_party/x86inc/x86inc.asm
> +--- third_party/libaom/source/libaom/third_party/x86inc/x86inc.asm.orig
> third_party/libaom/source/libaom/third_party/x86inc/x86inc.asm
> +@@ -66,6 +66,12 @@
> + %endif
> + %endif
> +
> ++%if AOM_ARCH_X86_64
> ++%define _CET_ENDBR endbr64
> ++%else
> ++%define _CET_ENDBR
> ++%endif
> ++
> + %define FORMAT_ELF 0
> + %define FORMAT_MACHO 0
> + %ifidn __OUTPUT_FORMAT__,elf
> +@@ -860,6 +866,7 @@ BRANCH_INSTR jz, je, jnz, jne, jl, jle, jnl, jnle, jg,
> + %endif
> + align function_align
> + %2:
> ++_CET_ENDBR
> + RESET_MM_PERMUTATION; needed for x86-64, also makes disassembly
> somewhat nicer
> + %xdefine rstk rsp ; copy of the original stack pointer, used
> when greater alignment than the known stack alignment is required
> + %assign stack_offset 0 ; stack pointer offset relative to the
> return address
>
Update: salt-3007.0
Hi all,
update to latest greatest salt 3007.0.
I removed the back ported patch for minion keys and additionally added
a login.conf.d file for salt_minion - because per default the minion
dies because it has not enough file descriptors available. With this
file I didn't notice any problems anymore.
--
With kind regards / Með bestu kveðju / Mit freundlichen Grüßen
Uwe Werler
Index: Makefile
===
RCS file: /cvs/ports/sysutils/salt/Makefile,v
diff -u -p -u -r1.184 Makefile
--- Makefile7 Mar 2024 06:14:33 - 1.184
+++ Makefile13 Mar 2024 10:06:55 -
@@ -15,10 +15,8 @@
COMMENT = remote execution and configuration management system
-MODPY_EGG_VERSION =3006.7
+MODPY_EGG_VERSION =3007.0
DISTNAME = salt-${MODPY_EGG_VERSION}
-
-REVISION = 0
CATEGORIES = sysutils net devel
Index: distinfo
===
RCS file: /cvs/ports/sysutils/salt/distinfo,v
diff -u -p -u -r1.68 distinfo
--- distinfo1 Mar 2024 12:02:55 - 1.68
+++ distinfo13 Mar 2024 10:06:55 -
@@ -1,2 +1,2 @@
-SHA256 (salt-3006.7.tar.gz) = 7ZLSG4TrnUefk7qJRoRTQIEX4NwQEGFCFJmejQwhCv0=
-SIZE (salt-3006.7.tar.gz) = 20562663
+SHA256 (salt-3007.0.tar.gz) = Qb+E5x/GVb+KS1LrRA0GIa6WEJaghtIOEy4VEuLt3/g=
+SIZE (salt-3007.0.tar.gz) = 20304228
cvs server: Diffing patches
Index: patches/patch-salt_channel_server_py
===
RCS file: patches/patch-salt_channel_server_py
diff -N patches/patch-salt_channel_server_py
--- patches/patch-salt_channel_server_py7 Mar 2024 06:14:33 -
1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,52 +0,0 @@
-52d98866200384dbaf3dbdecf66de00ff6d2195c fix: Older keys end with a newline,
this breaks minion auth.
-4e72e2f0a57b594c3f7e14cc385a066097a268b2 fix: typo's
-0f4c022fdaabb41962e7fde1baca7bf73122f534 Simply check against cleaned key from
disk.
-ecc39aa994c55b22c10320380abf6bd24529496d Refactor and add some tests
-
-Index: salt/channel/server.py
salt/channel/server.py.orig
-+++ salt/channel/server.py
-@@ -52,6 +52,16 @@ class ReqServerChannel:
- transport = salt.transport.request_server(opts, **kwargs)
- return cls(opts, transport)
-
-+@classmethod
-+def compare_keys(cls, key1, key2):
-+"""
-+Normalize and compare two keys
-+
-+Returns:
-+bool: ``True`` if the keys match, otherwise ``False``
-+"""
-+return salt.crypt.clean_key(key1) == salt.crypt.clean_key(key2)
-+
- def __init__(self, opts, transport):
- self.opts = opts
- self.transport = transport
-@@ -371,7 +381,7 @@ class ReqServerChannel:
- elif os.path.isfile(pubfn):
- # The key has been accepted, check it
- with salt.utils.files.fopen(pubfn, "r") as pubfn_handle:
--if salt.crypt.clean_key(pubfn_handle.read()) != load["pub"]:
-+if not self.compare_keys(pubfn_handle.read(), load["pub"]):
- log.error(
- "Authentication attempt from %s failed, the public "
- "keys did not match. This may be an attempt to
compromise "
-@@ -480,7 +490,7 @@ class ReqServerChannel:
- # case. Otherwise log the fact that the minion is still
- # pending.
- with salt.utils.files.fopen(pubfn_pend, "r") as pubfn_handle:
--if salt.crypt.clean_key(pubfn_handle.read()) !=
load["pub"]:
-+if not self.compare_keys(pubfn_handle.read(),
load["pub"]):
- log.error(
- "Authentication attempt from %s failed, the
public "
- "key in pending did not match. This may be an "
-@@ -536,7 +546,7 @@ class ReqServerChannel:
- # so, pass on doing anything here, and let it get
automatically
- # accepted below.
- with salt.utils.files.fopen(pubfn_pend, "r") as pubfn_handle:
--if salt.crypt.clean_key(pubfn_handle.read()) !=
load["pub"]:
-+if not self.compare_keys(pubfn_handle.read(),
load["pub"]):
- log.error(
- "Authentication attempt from %s failed, the
public "
- "keys in pending did not match. This may be an "
Index: patches/patch-salt_client_ssh_shell_py
===
RCS file: /cvs/ports/sysutils/salt/patches/patch-salt_client_ssh_shell_py,v
diff -u -p -u -r1.7 patch-salt_client_ssh_shell_py
--- patches/patch-salt_client_ssh_shell_py 3 Apr 2023 06:33:06 -
1.7
+++ patches/patch-salt_client_ssh_shell_py 13 Mar 2024 10:06:55 -
@@ -9,7 +9,7 @@ Index: salt/client/ssh/shell.py
quiche security update
Hi,
This is a security update to quiche.
See https://github.com/cloudflare/quiche/releases/tag/0.20.1
sthen, naddy, OK?
-Otto
Index: Makefile
===
RCS file: /home/cvs/ports/net/quiche/Makefile,v
diff -u -p -r1.2 Makefile
--- Makefile20 Dec 2023 11:25:58 - 1.2
+++ Makefile13 Mar 2024 07:03:03 -
@@ -3,7 +3,7 @@ COMMENT = library implementing QUIC and
# ring-v0.17 does not support this arch
NOT_FOR_ARCHS =sparc64
-V =0.20.0
+V =0.20.1
PKG_NAME = quiche-${V}
CATEGORIES = net
HOMEPAGE = https://github.com/cloudflare/quiche
Index: distinfo
===
RCS file: /home/cvs/ports/net/quiche/distinfo,v
diff -u -p -r1.2 distinfo
--- distinfo20 Dec 2023 11:25:58 - 1.2
+++ distinfo13 Mar 2024 07:03:03 -
@@ -119,7 +119,7 @@ SHA256 (cargo/windows_i686_msvc-0.48.5.t
SHA256 (cargo/windows_x86_64_gnu-0.48.5.tar.gz) =
U9QKvSWD0j5HGP3fHr7ITb/4OBwHyuZ/93aLvxnGcY4=
SHA256 (cargo/windows_x86_64_gnullvm-0.48.5.tar.gz) =
C3tSdnhooj1bq3aOOQ3F9cVYJbbTC4bIRP8tx0FARMw=
SHA256 (cargo/windows_x86_64_msvc-0.48.5.tar.gz) =
7ZT85hVxpABoUrc4mgY6uYPALrG7N7R/gnLOktBtlTg=
-SHA256 (quiche-0.20.0.tar.gz) = cSW8gt3POPv7xpiCzLJyO/tNW/60Jxi4KR0m7AYELjg=
+SHA256 (quiche-0.20.1.tar.gz) = nEYNjs9sgMBr+bQvkSAe8z+RLiYVqHH/LQ5QGXuQHHE=
SIZE (cargo/aho-corasick-1.1.2.tar.gz) = 183136
SIZE (cargo/android-tzdata-0.1.1.tar.gz) = 7674
SIZE (cargo/android_system_properties-0.1.5.tar.gz) = 5243
@@ -241,4 +241,4 @@ SIZE (cargo/windows_i686_msvc-0.48.5.tar
SIZE (cargo/windows_x86_64_gnu-0.48.5.tar.gz) = 801619
SIZE (cargo/windows_x86_64_gnullvm-0.48.5.tar.gz) = 418486
SIZE (cargo/windows_x86_64_msvc-0.48.5.tar.gz) = 798412
-SIZE (quiche-0.20.0.tar.gz) = 681940
+SIZE (quiche-0.20.1.tar.gz) = 683362
