From nils.goroll at uplex.de  Thu Jun  4 07:27:21 2026
From: nils.goroll at uplex.de (Nils Goroll)
Date: Thu, 4 Jun 2026 09:27:21 +0200
Subject: h2 bomb
Message-ID: <663ed8dd-b851-4b54-929f-08feebd545a1@uplex.de>

Good morning,

has anybody checked if we are affected at all? I would assume that we should be 
pretty safe by how we manage memory, but it would be good to have some certainty.

I am under pressure with another task and can not spend time myself in the 
coming days.

Nils
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x1DCD8F57A3868BD7.asc
Type: application/pgp-keys
Size: 4845 bytes
Desc: OpenPGP public key
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260604/0e5fd52b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260604/0e5fd52b/attachment-0001.bin>

From phk at phk.freebsd.dk  Thu Jun  4 08:13:52 2026
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 04 Jun 2026 08:13:52 +0000
Subject: h2 bomb
In-Reply-To: <663ed8dd-b851-4b54-929f-08feebd545a1@uplex.de>
References: <663ed8dd-b851-4b54-929f-08feebd545a1@uplex.de>
Message-ID: <202606040813.6548DqXK093117@critter.freebsd.dk>

--------
Nils Goroll writes:

I'm on the train, do you have a link or other reference ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Thu Jun  4 08:18:26 2026
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 04 Jun 2026 08:18:26 +0000
Subject: h2 bomb
In-Reply-To: <663ed8dd-b851-4b54-929f-08feebd545a1@uplex.de>
References: <663ed8dd-b851-4b54-929f-08feebd545a1@uplex.de>
Message-ID: <202606040818.6548IQEo093148@critter.freebsd.dk>

Found it:

	https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb

I think the way we manage workspace and HTTP headers is safe against
this.

Have not checked vtest2

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From per.buer at varnish-software.com  Thu Jun  4 08:39:53 2026
From: per.buer at varnish-software.com (Per Buer)
Date: Thu, 4 Jun 2026 10:39:53 +0200
Subject: h2 bomb
In-Reply-To: <202606040818.6548IQEo093148@critter.freebsd.dk>
References: <663ed8dd-b851-4b54-929f-08feebd545a1@uplex.de>
 <202606040818.6548IQEo093148@critter.freebsd.dk>
Message-ID: <CABazqcZ2P9qoYGRQQ0XFtPTCHmAZjOCCUqQmSAZh4OP_bMv9tQ@mail.gmail.com>

I'm pretty sure we aren't vulnerable and our analysis so far seems to
confirm this. Obviously, you can take down a Vinyl instance by hammering
it, but no amplification is happening. Also, we've been in touch with the
Calif guys before and they didn't notify us this time. These individuals
found VSV19, so they know how to reach us.

Per.

On Thu, Jun 4, 2026 at 10:18?AM Poul-Henning Kamp <phk at phk.freebsd.dk>
wrote:

> Found it:
>
>         https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb
>
> I think the way we manage workspace and HTTP headers is safe against
> this.
>
> Have not checked vtest2
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> _______________________________________________
> vinyl-dev mailing list
> vinyl-dev at vinyl-cache.org
> https://vinyl-cache.org/lists/mailman/listinfo/vinyl-dev
>


-- 
Per Buer
Varnish Software
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260604/c5ae5440/attachment.html>

From nils.goroll at uplex.de  Thu Jun  4 08:51:26 2026
From: nils.goroll at uplex.de (Nils Goroll)
Date: Thu, 4 Jun 2026 10:51:26 +0200
Subject: h2 bomb
In-Reply-To: <202606040813.6548DqXK093117@critter.freebsd.dk>
References: <663ed8dd-b851-4b54-929f-08feebd545a1@uplex.de>
 <202606040813.6548DqXK093117@critter.freebsd.dk>
Message-ID: <ddc587dd-2935-4db6-a648-956ed0c20c8c@uplex.de>


> I'm on the train, do you have a link or other reference ?

https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb


-- 

Nils Goroll (he/him)

** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstra?e 32
22301 Hamburg

tel +49 40 28805731
mob +49 170 2723133
fax +49 40 42949753

xmpp://slink at jabber.int.uplex.de/

http://uplex.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x1DCD8F57A3868BD7.asc
Type: application/pgp-keys
Size: 4845 bytes
Desc: OpenPGP public key
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260604/f8c493e7/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260604/f8c493e7/attachment-0003.bin>

From phk at phk.freebsd.dk  Mon Jun  8 08:02:02 2026
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 08 Jun 2026 08:02:02 +0000
Subject: bugwash: I've been double-booked :-(
Message-ID: <202606080802.658822w5018203@critter.freebsd.dk>

I have accidentally been dragged into a nominal 90minute meeting
starting at 14:00 today.

I will try to catch the tail end of the bugwash from on-site.

I'm currently trying to distill my notes on the white whale of
backend-refcount into #4445.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

From nils.goroll at uplex.de  Mon Jun  8 11:40:11 2026
From: nils.goroll at uplex.de (Nils Goroll)
Date: Mon, 8 Jun 2026 13:40:11 +0200
Subject: bugwash: I've been double-booked :-(
In-Reply-To: <202606080802.658822w5018203@critter.freebsd.dk>
References: <202606080802.658822w5018203@critter.freebsd.dk>
Message-ID: <4e348a4c-0d07-4c4e-bfad-3f05f37edd2b@uplex.de>

For walid: I had mentioned this last week: I am on a train back to berlin and 
will need to change to sbahn during bw time, so would prefer to skip anyway.

I left review-work for you, Walid :)

-- 

Nils Goroll (he/him)

** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstra?e 32
22301 Hamburg

tel +49 40 28805731
mob +49 170 2723133
fax +49 40 42949753

xmpp://slink at jabber.int.uplex.de/

http://uplex.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x1DCD8F57A3868BD7.asc
Type: application/pgp-keys
Size: 4845 bytes
Desc: OpenPGP public key
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260608/49283e3f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260608/49283e3f/attachment-0001.bin>

From md at Linux.IT  Mon Jun  8 14:18:07 2026
From: md at Linux.IT (Marco d'Itri)
Date: Mon, 8 Jun 2026 16:18:07 +0200
Subject: Vinyl Cache in Debian
Message-ID: <aibPHyXewL276ISE@bongo.bofh.it>

For those who missed the discussions online: Vinyl Cache is not yet in 
the Debian archive proper because the current git tree of Vinyl Cache is 
incompatible with modern Debian packaging workflows since it uses 
a submodule for vtest2.

Possible solutions are:
a) use a git subtree[1] instead of a submodule
b) just incorporate vtest2 again in the Vinyl Cache tree
c) package vtest2 in Debian as a source-only package
d) have proper vtest2 upstream releases with a stable ABI, which 
    vinyl-cache and haproxy can build-depend on

I would like some feedback from the maintainers about what they expect 
to do about this, if anything, and when.
If this will be solved upstream "soon" then maybe I can just make the 
package skip the tests for a while.

Lacking progress on options a or b, then I will have to try option 
c. It would be easy for me but suboptimal, because I fear that sooner or 
later haproxy will want to use a different version of vtest2).

The current situation is:
- Debian/unstable has Varnish 7.7.3, which I will not update to 8.x
- Debian/experimental has Vinyl Cache 9.0.1, with tests disabled
- I tested in the Debian CI infrastructure a branch[2] of Vinyl Cache
   with vtest2 added back as a patch and it builds

So I am confident that once the vtest2 solution will be solved I will be 
able to immediately upload Vinyl Cache to Debian/unstable (and then 
hopefully make a backport to Debian/stable).


[1] https://www.atlassian.com/git/tutorials/git-subtree
[2] https://salsa.debian.org/varnish-team/vinyl-cache/-/tree/debian/experimental+vtest2

-- 
ciao,
Marco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260608/c9386fb8/attachment.bin>

From dridi at varni.sh  Mon Jun  8 14:28:41 2026
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Mon, 8 Jun 2026 14:28:41 +0000
Subject: Vinyl Cache in Debian
In-Reply-To: <aibPHyXewL276ISE@bongo.bofh.it>
References: <aibPHyXewL276ISE@bongo.bofh.it>
Message-ID: <CABoVN9CPySmo_9=DCWek4kBa1htMbDGdQQ03pbP5V7HLWa-nKA@mail.gmail.com>

On Mon, Jun 8, 2026 at 2:18?PM Marco d'Itri <md at linux.it> wrote:
>
> For those who missed the discussions online: Vinyl Cache is not yet in
> the Debian archive proper because the current git tree of Vinyl Cache is
> incompatible with modern Debian packaging workflows since it uses
> a submodule for vtest2.
>
> Possible solutions are:
> a) use a git subtree[1] instead of a submodule

A drawback listed in the article:

> The responsibility of not mixing super and sub-project code in commits lies with you.

It's probably possible to add guard rails with hooks, with at least a
commit hook on the client side.

After a cursory glance, git-subtree looks like a better compromise
than git-submodule.

> b) just incorporate vtest2 again in the Vinyl Cache tree
> c) package vtest2 in Debian as a source-only package
> d) have proper vtest2 upstream releases with a stable ABI, which
>     vinyl-cache and haproxy can build-depend on
>
> I would like some feedback from the maintainers about what they expect
> to do about this, if anything, and when.
> If this will be solved upstream "soon" then maybe I can just make the
> package skip the tests for a while.
>
> Lacking progress on options a or b, then I will have to try option
> c. It would be easy for me but suboptimal, because I fear that sooner or
> later haproxy will want to use a different version of vtest2).
>
> The current situation is:
> - Debian/unstable has Varnish 7.7.3, which I will not update to 8.x
> - Debian/experimental has Vinyl Cache 9.0.1, with tests disabled
> - I tested in the Debian CI infrastructure a branch[2] of Vinyl Cache
>    with vtest2 added back as a patch and it builds
>
> So I am confident that once the vtest2 solution will be solved I will be
> able to immediately upload Vinyl Cache to Debian/unstable (and then
> hopefully make a backport to Debian/stable).
>
>
> [1] https://www.atlassian.com/git/tutorials/git-subtree
> [2] https://salsa.debian.org/varnish-team/vinyl-cache/-/tree/debian/experimental+vtest2
>
> --
> ciao,
> Marco
> _______________________________________________
> vinyl-dev mailing list
> vinyl-dev at vinyl-cache.org
> https://vinyl-cache.org/lists/mailman/listinfo/vinyl-dev

From phk at phk.freebsd.dk  Mon Jun  8 18:50:31 2026
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 08 Jun 2026 18:50:31 +0000
Subject: Vinyl Cache in Debian
In-Reply-To: <aibPHyXewL276ISE@bongo.bofh.it>
References: <aibPHyXewL276ISE@bongo.bofh.it>
Message-ID: <202606081850.658IoV63006451@critter.freebsd.dk>

--------
Marco d'Itri writes:

> Possible solutions are:
> a) use a git subtree[1] instead of a submodule
> b) just incorporate vtest2 again in the Vinyl Cache tree
> c) package vtest2 in Debian as a source-only package
> d) have proper vtest2 upstream releases with a stable ABI, which
>     vinyl-cache and haproxy can build-depend on

My goal is d)

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From nils.goroll at uplex.de  Tue Jun  9 17:47:03 2026
From: nils.goroll at uplex.de (Nils Goroll)
Date: Tue, 9 Jun 2026 19:47:03 +0200
Subject: Issues with code.vinyl-cache.org
Message-ID: <c7711f4c-0d0f-417f-8ff7-f9f0cf1f9b15@uplex.de>

FYI: There is an issue where essentially pages stay in "public" mode as if the 
user was not logged in.

Probably related to the update I did today.

I will look ASAP, sorry for the inconvenience.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x1DCD8F57A3868BD7.asc
Type: application/pgp-keys
Size: 4845 bytes
Desc: OpenPGP public key
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260609/8f427132/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260609/8f427132/attachment-0001.bin>

From nils.goroll at uplex.de  Tue Jun  9 19:25:04 2026
From: nils.goroll at uplex.de (Nils Goroll)
Date: Tue, 9 Jun 2026 21:25:04 +0200
Subject: Issues with code.vinyl-cache.org
In-Reply-To: <c7711f4c-0d0f-417f-8ff7-f9f0cf1f9b15@uplex.de>
References: <c7711f4c-0d0f-417f-8ff7-f9f0cf1f9b15@uplex.de>
Message-ID: <325e2354-a035-43dd-992c-d25001013bcb@uplex.de>

Should be fixed. The forgejo session cookie now has a different name, hence the 
pass rule in VCL needed adjustment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x1DCD8F57A3868BD7.asc
Type: application/pgp-keys
Size: 4845 bytes
Desc: OpenPGP public key
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260609/98454135/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260609/98454135/attachment-0001.bin>

From nils.goroll at uplex.de  Wed Jun 17 15:30:05 2026
From: nils.goroll at uplex.de (Nils Goroll)
Date: Wed, 17 Jun 2026 17:30:05 +0200
Subject: mgr/worker interface and extensions use case
Message-ID: <698facc6-ec19-4157-a7db-3c484a3f9419@uplex.de>

Hi,

a while back we were discussing a generalization of the mgr/worker interface and 
potential uses from extensions.

Over the past days I have been handling a DoS and it became apparent that being 
able to directly control Linux nftables from VCL (via an extension/vmod) would 
have been helpful.

For obvious reasons, the kernel interface to manipulate nftables requires 
elevated privileges, calling nft_ctx_new() from libnftables as an unprivileged 
user results in

socket(AF_NETLINK, SOCK_RAW, NETLINK_NETFILTER) = 3
sendto(3,..)
recvmsg(3,..)
sendto(3,..)
recvmsg(3,..)
write(2, "Operation not permitted..")

I have not implemented a prototype, but my understanding is that this use case 
would actually need a CAP_NET_ADMIN capable process sending the messages via the 
AF_NETLINK socket.

So either my understanding is wrong and there is a better way, or we could, for 
this potential use case, make good use of the "syscall proxy" idea we had 
discussed in a different context.

Nils
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x1DCD8F57A3868BD7.asc
Type: application/pgp-keys
Size: 4845 bytes
Desc: OpenPGP public key
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260617/ebb38824/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260617/ebb38824/attachment-0003.bin>

From md at Linux.IT  Mon Jun 22 12:15:51 2026
From: md at Linux.IT (Marco d'Itri)
Date: Mon, 22 Jun 2026 14:15:51 +0200
Subject: mgr/worker interface and extensions use case
In-Reply-To: <698facc6-ec19-4157-a7db-3c484a3f9419@uplex.de>
Message-ID: <ajknd8NmqMLegsuq@bongo.bofh.it>

On Jun 17, Nils Goroll <nils.goroll at uplex.de> wrote:

>I have not implemented a prototype, but my understanding is that this 
>use case would actually need a CAP_NET_ADMIN capable process sending 
>the messages via the AF_NETLINK socket.
As we discussed online, I think that it is safer and easier to implement 
firewall management in a standalone and privileged daemon which receives 
requests from Vinyl Cache over a socket.

I have uploaded here a Perl server implementation and a test C client:
https://www.bofh.it/~md/tmp/wip-updater/ .

It still needs a proper name, but I think that it is a reasonable first 
release. It can be easily extended to support nftables and the *BSD 
firewall systems.

It is smart enough to batch requests received in a short time, so under 
attack it will spawn ipset once to update multiple entries.
I know that frequently running an external program from Perl is going to 
be efficient enough because I have been blocking DDoS attacks by running 
ipset for single IPs in a shell script's while loop.

What it needs now is somebody making a vmod client. Maybe first 
prototyped as inline C? (This would also be nice for teaching how inline 
C works, since there is not much "modern" documentation...)

-- 
ciao,
Marco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260622/557568c4/attachment.bin>