From scan-admin at coverity.com Sun Sep 1 11:32:27 2019 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 01 Sep 2019 11:32:27 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <5d6bac4b3c6d6_5c772ae0c3490f4c877e8@appnode-2.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRaZSCEJOPR4AEUn0hVASTtlJ23U2ffwbN1LtJbHcOCfQg-3D-3D_wrU9d1VlqIiuL6N0zVMze4Ep-2FR7u99vtLlE-2BlH3ENQBgt-2BAbvAOc0XVStdWsGdTtc3yQYnZWpLd2X6b-2B5wNjMNcfgbxBgpj1Dy1YSSP0ugXrtFHN6BVXaonH3-2F7-2BNT-2B8EcvCSohbsYEuX05cgPcndQJiNrV6rjAh4cgeQm0Da1cdNy6AG-2BNK81tiFCKsOK7DRMxWISQ15rm9Wf8RjiGdudY2i69ZK8CaosREXRFDnXc-3D Build ID: 270833 Analysis Summary: New defects found: 6 Defects eliminated: 11 If you have difficulty understanding any defects, email us at scan-admin at coverity.com, or post your question to StackOverflow at https://u2389337.ct.sendgrid.net/wf/click?upn=OgIsEqWzmIl4S-2FzEUMxLXL-2BukuZt9UUdRZhgmgzAKchwAzH1nH3073xDEXNRgHN6zzUI-2FRfbrE6mNOeeukHUQw-3D-3D_wrU9d1VlqIiuL6N0zVMze4Ep-2FR7u99vtLlE-2BlH3ENQBgt-2BAbvAOc0XVStdWsGdTtc3yQYnZWpLd2X6b-2B5wNjMIAz2vHIVAhdTf7TjQOXxEgV6W3ZUIaCLi2BVb0FvPowF9mXGpLK0TcTS3A7EV8-2B6qxjmJXbQBTgvwDJYL5rS0nqTtVbi-2FXZdwV2dl1rdNVGJ5EzsEfm0-2FpwLaDE86xKflvqJqYnjZxYCwV9l68Wi7E-3D From slink at schokola.de Wed Sep 4 06:50:04 2019 From: slink at schokola.de (Nils Goroll) Date: Wed, 4 Sep 2019 08:50:04 +0200 Subject: TLS sandboxing In-Reply-To: References: Message-ID: That is an interesting exercise, thank you, Dridi. For TLS on TCP, I would hope that passing the session key and file descriptor would work. Have you checked already to which extend this is supported by existing library code? Yet with the H3/QUIC madness on the horizon, I am not sure if connect()ing the SOCK_DGRAM and passing the fd would work. The way I read the QUIC draft, connections are primarily identified by their ID and migrations need to be supported. I have made no coding attempt on my own, but my impression was that the natural implementation the authors had in mind was a recvfrom(2) loop matching packets based on their connection ID with spoof detection. So, Dridi, have you had a closer look yet if/how your idea could work with QUIC? Somehow related: How about having the process owning the private keys also handle all receives into multiple ringbuffers, somehow similar to vsm, but with overrun protection? Nils From phk at phk.freebsd.dk Wed Sep 4 08:02:04 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 04 Sep 2019 08:02:04 +0000 Subject: TLS sandboxing In-Reply-To: References: Message-ID: <53147.1567584124@critter.freebsd.dk> -------- In message , Nils Goroll writ es: >Yet with the H3/QUIC madness on the horizon, No, they actually dealt with this in the design, so that "keyless" operation is more or less the natural architecture for QUIC. If we want to do TCP/TLS, we should also aim firmly for the "keyless" model. I'm hoping we can to raid the hitch source code to build the "keymaster" process. -- 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 scan-admin at coverity.com Sun Sep 8 11:32:57 2019 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 08 Sep 2019 11:32:57 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <5d74e6e9f0ee_23c02ae0c3490f4c87772@appnode-2.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRaZSCEJOPR4AEUn0hVASTtlJ23U2ffwbN1LtJbHcOCfQg-3D-3D_wrU9d1VlqIiuL6N0zVMze4Ep-2FR7u99vtLlE-2BlH3ENQD89lyzISkwdcTN5iCgakcJs3AKKSrK1d31EwDDBM3k10zHP3XQGWCXAfRm5Q9rJUnukAHmxE9-2Bc71i6aEpsUs59ObXC4O6p-2Bt8aq18vgL-2FXHL6crf5iWBdzvCh1E4ut611ysTtn484M-2BdqeaXlKu1wBiuSn8CpdmQqQvsLpt-2FHrSYBk4-2BW52cvnw5gD3WRht4-3D Build ID: 271865 Analysis Summary: New defects found: 6 Defects eliminated: 11 If you have difficulty understanding any defects, email us at scan-admin at coverity.com, or post your question to StackOverflow at https://u2389337.ct.sendgrid.net/wf/click?upn=OgIsEqWzmIl4S-2FzEUMxLXL-2BukuZt9UUdRZhgmgzAKchwAzH1nH3073xDEXNRgHN6zzUI-2FRfbrE6mNOeeukHUQw-3D-3D_wrU9d1VlqIiuL6N0zVMze4Ep-2FR7u99vtLlE-2BlH3ENQD89lyzISkwdcTN5iCgakcJs3AKKSrK1d31EwDDBM3k17bGYw2BvNIWHGnrjSR28lLmKMJYxPK8b60f3CQ-2BOJ4cckwHRNnpMqlMsYKhBrusU3RKqG7eGI7z4So00chr1yh-2FIilkFBDd4E5iBh247CJeAqXhblfWZFWMvi41guT2YBzKxep61O7iXLEU04ujAvM-3D From phk at phk.freebsd.dk Mon Sep 9 17:23:18 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 09 Sep 2019 17:23:18 +0000 Subject: Release 6.3 on next monday Message-ID: <12120.1568049798@critter.freebsd.dk> We decided today that the 2019-09-15 release will happen next monday and be called 6.3. It will *not* be a long-term-support ("LTS") release. Effectively immediately, we are in code freeze as far as source code, but welcome any contribution pertaining to documentation and release engineering. -- 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 Mon Sep 9 18:17:22 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 09 Sep 2019 18:17:22 +0000 Subject: VDD19Q3 wiki page Message-ID: <12310.1568053042@critter.freebsd.dk> Please contribute: https://github.com/varnishcache/varnish-cache/wiki/VDD19Q3 -- 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 scan-admin at coverity.com Sun Sep 15 11:34:07 2019 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 15 Sep 2019 11:34:07 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <5d7e21aef36da_48e42ae0c3490f4c877d4@appnode-2.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRaZSCEJOPR4AEUn0hVASTtlJ23U2ffwbN1LtJbHcOCfQg-3D-3D_wrU9d1VlqIiuL6N0zVMze4Ep-2FR7u99vtLlE-2BlH3ENQA5HY2CZPaBi53mTuUZ41jWv3lQ5N6TWzcldjh2yV0BySQIIuLh9jdz-2BJo6nkNG8VJE5iBpYR8yhxhCNRSKeCPEbrf95xSjJMFWSLYJzrVxbZ8vNILpzTUQ1ElMxALL0aK35G-2BW7d6JyXerhH7Zgn-2FeMPHh7tU-2Fbhg0d4JdyAQW9sfmM-2BckCU2it285B6cGgk4-3D Build ID: 272792 Analysis Summary: New defects found: 6 Defects eliminated: 11 If you have difficulty understanding any defects, email us at scan-admin at coverity.com, or post your question to StackOverflow at https://u2389337.ct.sendgrid.net/wf/click?upn=OgIsEqWzmIl4S-2FzEUMxLXL-2BukuZt9UUdRZhgmgzAKchwAzH1nH3073xDEXNRgHN6zzUI-2FRfbrE6mNOeeukHUQw-3D-3D_wrU9d1VlqIiuL6N0zVMze4Ep-2FR7u99vtLlE-2BlH3ENQA5HY2CZPaBi53mTuUZ41jWv3lQ5N6TWzcldjh2yV0ByXbLa0MwMX9qyKb2MaO-2FejPzOmCp137aWPmEY0mKiYCbhhCv0Z80-2F8iA71FVxmIV9dstBNnqodwXM-2BKctE3LKlJRX5HZ8TWwUSicLi-2F9nlHRiv5pH0MxvJKneTK7C-2Fu0tLIfvfOuAi7bBEm4R66QBtQ-3D From geoff at uplex.de Mon Sep 16 12:35:51 2019 From: geoff at uplex.de (Geoff Simmons) Date: Mon, 16 Sep 2019 14:35:51 +0200 Subject: [varnishcache/varnish-cache] explicit_bzero() causing havoc (#3051) In-Reply-To: References: Message-ID: <7b7463af-bd3f-8cfe-acb9-d231cfaa37ab@uplex.de> On 9/16/19 13:37, Poul-Henning Kamp wrote: > Solved in #3057 Repeating my comment in github on the commit (to make sure that everyone can see it): The EXPLICIT_BZERO check is still AC_REQUIRE'd in varnish.m4, from VARNISH_PREREQ and _VARNISH_CHECK_DEVEL, which are used in VMOD development. Since it's not defined now, this leads to a cascade of error messages when autogen.sh is called for a VMOD. Apparently these can be ignored -- I can now compile without a workaround for ZERO_OBJ. Thank you, I will stop screaming into the abyss now. It's worth pointing out, however, that Colin Percival concluded in his blog that not even this solution guarantees that the memset call won't be optimized out: https://www.daemonology.net/blog/2014-09-05-erratum.html But this gets us much closer to something that will work on most platforms. It's OpenSSL's solution for wiping keys in memory, so one hopes that it works most of the time. -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From geoff at uplex.de Mon Sep 16 12:42:53 2019 From: geoff at uplex.de (Geoff Simmons) Date: Mon, 16 Sep 2019 14:42:53 +0200 Subject: [varnishcache/varnish-cache] explicit_bzero() causing havoc (#3051) In-Reply-To: <7b7463af-bd3f-8cfe-acb9-d231cfaa37ab@uplex.de> References: <7b7463af-bd3f-8cfe-acb9-d231cfaa37ab@uplex.de> Message-ID: <3a6646b7-bba4-2189-ef6f-845aa9350ac3@uplex.de> On 9/16/19 14:35, Geoff Simmons wrote: > > The EXPLICIT_BZERO check is still AC_REQUIRE'd in varnish.m4, from > VARNISH_PREREQ and _VARNISH_CHECK_DEVEL, which are used in VMOD > development. Since it's not defined now, this leads to a cascade of > error messages when autogen.sh is called for a VMOD. I might have mixed my message, so to emphasize, this is a bug that should *not* go into a new release. Best, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From phk at phk.freebsd.dk Mon Sep 16 14:31:47 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 16 Sep 2019 14:31:47 +0000 Subject: [varnishcache/varnish-cache] explicit_bzero() causing havoc (#3051) In-Reply-To: <7b7463af-bd3f-8cfe-acb9-d231cfaa37ab@uplex.de> References: <7b7463af-bd3f-8cfe-acb9-d231cfaa37ab@uplex.de> Message-ID: <99724.1568644307@critter.freebsd.dk> -------- In message <7b7463af-bd3f-8cfe-acb9-d231cfaa37ab at uplex.de>, Geoff Simmons write s: >The EXPLICIT_BZERO check is still AC_REQUIRE'd in varnish.m4, from >VARNISH_PREREQ and _VARNISH_CHECK_DEVEL, which are used in VMOD >development. Since it's not defined now, this leads to a cascade of >error messages when autogen.sh is called for a VMOD. Ticket please, that is out of my comfort area. >It's worth pointing out, however, that Colin Percival concluded in his >blog that not even this solution guarantees that the memset call won't >be optimized out: > >https://www.daemonology.net/blog/2014-09-05-erratum.html I took that as more of a judgement of the sanity of the ISO-C committee and compiler writers in general, as a problem we need to deal with. >But this gets us much closer to something that will work on most >platforms. It's OpenSSL's solution for wiping keys in memory, so one >hopes that it works most of the time. Ohh God! Now you just inspired all "cyberforces" to start implementing compiler optimizations... :-) -- 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 geoff at uplex.de Mon Sep 16 16:18:05 2019 From: geoff at uplex.de (Geoff Simmons) Date: Mon, 16 Sep 2019 18:18:05 +0200 Subject: [varnishcache/varnish-cache] explicit_bzero() causing havoc (#3051) In-Reply-To: <99724.1568644307@critter.freebsd.dk> References: <7b7463af-bd3f-8cfe-acb9-d231cfaa37ab@uplex.de> <99724.1568644307@critter.freebsd.dk> Message-ID: On 9/16/19 16:31, Poul-Henning Kamp wrote: > >> The EXPLICIT_BZERO check is still AC_REQUIRE'd in varnish.m4, from >> VARNISH_PREREQ and _VARNISH_CHECK_DEVEL, which are used in VMOD >> development. Since it's not defined now, this leads to a cascade of >> error messages when autogen.sh is called for a VMOD. > > Ticket please, that is out of my comfort area. devnexen wrote to me that he has a PR up to fix that. https://github.com/varnishcache/varnish-cache/pull/3062 Looks like the PR will fix the problem. But it didn't make it into the release? Then there's a somewhat buggy varnish.m4 in 6.3.0. The workaround is to just ignore the error messages, but they're going to be annoying to look at from now on. Best, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From phk at phk.freebsd.dk Mon Sep 16 16:26:19 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 16 Sep 2019 16:26:19 +0000 Subject: [varnishcache/varnish-cache] explicit_bzero() causing havoc (#3051) In-Reply-To: References: <7b7463af-bd3f-8cfe-acb9-d231cfaa37ab@uplex.de> <99724.1568644307@critter.freebsd.dk> Message-ID: <421.1568651179@critter.freebsd.dk> -------- In message , Geoff Simmons write s: >But it didn't make it into the release? Then there's a somewhat buggy >varnish.m4 in 6.3.0. The workaround is to just ignore the error >messages, but they're going to be annoying to look at from now on. It's not a LTS release so we'll survive... -- 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 devnexen at gmail.com Tue Sep 17 10:01:47 2019 From: devnexen at gmail.com (David CARLIER) Date: Tue, 17 Sep 2019 10:01:47 +0000 Subject: [varnishcache/varnish-cache] explicit_bzero() causing havoc (#3051) In-Reply-To: <421.1568651179@critter.freebsd.dk> References: <7b7463af-bd3f-8cfe-acb9-d231cfaa37ab@uplex.de> <99724.1568644307@critter.freebsd.dk> <421.1568651179@critter.freebsd.dk> Message-ID: Hi agreed here "no duress, no stress" the PR can wait :-) Regards. On Mon, 16 Sep 2019 at 16:26, Poul-Henning Kamp wrote: > > -------- > In message , Geoff Simmons write > s: > > >But it didn't make it into the release? Then there's a somewhat buggy > >varnish.m4 in 6.3.0. The workaround is to just ignore the error > >messages, but they're going to be annoying to look at from now on. > > It's not a LTS release so we'll survive... > > -- > 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. > _______________________________________________ > varnish-dev mailing list > varnish-dev at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev From scan-admin at coverity.com Sun Sep 22 11:33:50 2019 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 22 Sep 2019 11:33:50 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <5d875c1e82279_66cc2ae0c3490f4c87782@appnode-2.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRaZSCEJOPR4AEUn0hVASTtlJ23U2ffwbN1LtJbHcOCfQg-3D-3D_wrU9d1VlqIiuL6N0zVMze4Ep-2FR7u99vtLlE-2BlH3ENQCj3JV0KnVWGHXNP55l4wQjSYrO0juLVP4GHNEiUzLjetouP9Lc5FPl9Dy0UxC6AC2LkpXoIuZlkon1rkSdj0KXdR-2B-2BYV8nt-2Bsbtm6zDNpgSZwb2H5gxywNCgXkyOXV3ItxuhC-2FElRN4LP5gk9MfWLBVjrfL846Vvl5TSSMlsVwAAPPLviEeQClLPQi8Fpwx7Q-3D Build ID: 273737 Analysis Summary: New defects found: 6 Defects eliminated: 11 If you have difficulty understanding any defects, email us at scan-admin at coverity.com, or post your question to StackOverflow at https://u2389337.ct.sendgrid.net/wf/click?upn=OgIsEqWzmIl4S-2FzEUMxLXL-2BukuZt9UUdRZhgmgzAKchwAzH1nH3073xDEXNRgHN6zzUI-2FRfbrE6mNOeeukHUQw-3D-3D_wrU9d1VlqIiuL6N0zVMze4Ep-2FR7u99vtLlE-2BlH3ENQCj3JV0KnVWGHXNP55l4wQjSYrO0juLVP4GHNEiUzLjeuCti-2BA4LjSg-2BRN-2BFRSTPP-2BhOtmqPuxLqSkBNooFEGZG-2FvnAfZWYhkb6I4H2OH0wAMeQ1GHIwJANVR391G9PuRuN60TsuM32wCBn4V5OBsHrmD8t3SZYLv1OBBuBb8lHzUyi7Q2OOtoZqYG2ZF-2Ba4jI-3D From dridi at varni.sh Mon Sep 23 07:37:01 2019 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 23 Sep 2019 07:37:01 +0000 Subject: TLS sandboxing In-Reply-To: References: Message-ID: Hi Nils, On Wed, Sep 4, 2019 at 7:57 AM Nils Goroll wrote: > > That is an interesting exercise, thank you, Dridi. Thanks for reading. > For TLS on TCP, I would hope that passing the session key and file descriptor > would work. Have you checked already to which extend this is supported by > existing library code? I haven't, I really only had a short window to think about this and give it a try, and I burned a large amount of that spare time to play with asciinema... > Yet with the H3/QUIC madness on the horizon, I am not sure if connect()ing the > SOCK_DGRAM and passing the fd would work. The way I read the QUIC draft, > connections are primarily identified by their ID and migrations need to be > supported. I have made no coding attempt on my own, but my impression was that > the natural implementation the authors had in mind was a recvfrom(2) loop > matching packets based on their connection ID with spoof detection. > > So, Dridi, have you had a closer look yet if/how your idea could work with QUIC? Not at all. The proposed model falls short as soon as you have any kind of key renegotiation, except that being a UDS you could in theory pass the fd back and forth whenever you need private key privileges. I really really don't like the idea of a two-way channel though. > Somehow related: How about having the process owning the private keys also > handle all receives into multiple ringbuffers, somehow similar to vsm, but with > overrun protection? No opinion, I haven't thought about this. I'm literally back today and will be away again for the rest of the week. I will reply in greater details to Poul-Henning's response. Dridi From dridi at varni.sh Mon Sep 23 08:14:28 2019 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 23 Sep 2019 08:14:28 +0000 Subject: TLS sandboxing In-Reply-To: <53147.1567584124@critter.freebsd.dk> References: <53147.1567584124@critter.freebsd.dk> Message-ID: On Wed, Sep 4, 2019 at 8:02 AM Poul-Henning Kamp wrote: > > -------- > In message , Nils Goroll writ > es: > > >Yet with the H3/QUIC madness on the horizon, > > No, they actually dealt with this in the design, so that "keyless" > operation is more or less the natural architecture for QUIC. > > If we want to do TCP/TLS, we should also aim firmly for the "keyless" model. > > I'm hoping we can to raid the hitch source code to build the "keymaster" process. I have given more thought to this and I'm torn between "this is 2019 and we still don't support HTTPS" and the very good reasons why we don't. However I still think we should support it and I gave a tiny bit more thoughts to this. First, in-kernel TLS is coming, and while it will likely take forever to become ubiquitous *cough* enterprise linux *cough* in the long run it will probably be our best option: we keep our usual read and write[v] calls and nothing changes for us. Until then though, we might want to add support for "session operations" to replace the read/write[v] calls with SSL_read/SSL_write[v] for example. Ideally that would be with a vmod-openssl that later could compete with a vmod-ktls or vmod-other_tls_library, possibly written by third parties *cough* uplex? *cough* since we can't reasonably support them all ;-) With customizable session operations, we can now also replace other calls like accept or connect. That might be our cue to add session subroutines in VCL. But once we have that we circle back to handshakes. And I very much agree that a keyless approach would be best. However this is still 2019 so I think we should own it, and not rely on a third party. We should provide a comprehensive solution, for either HTTPS or http/3, and therefore we should provide a minimalist keyserver implementation. Whether it is a new varnishkeyserver program, or a new varnishd -k flag with a 3rd long-lived varnishd process, possibly working with a socketpair like my MXC thought experiment, I think we should provide that. Have a nice VDD! Dridi From dridi at varni.sh Mon Sep 23 09:15:03 2019 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 23 Sep 2019 09:15:03 +0000 Subject: [VDD] VSL query extensions In-Reply-To: References: Message-ID: Greetings, Just a quick word to say that with the release of 6.3 the following extensions are now part of the VSL query language: On Mon, May 7, 2018 at 8:08 AM Dridi Boukelmoune wrote: > > 1) Multi-line queries > > When someone wishes to capture logs for multiple reasons, they need > to OR them, possibly with brackets. Instead the proposal is to support > one query per line, ignore empty lines, and treat tokens starting with > '#' as comments. > > Example: > > varnishlog -q '(my-first-query) or (my-second-query)' > varnishlog -q ' > my-first-query > my-second-query > ... > ' > > 2) Read queries from a file > > Similar to reading varnishncsa's format from a file: > > cat >bad-things.txt < # internal errors > RespStatus >= 500 > > # backend problems > ... > > # internal incident 4253 > ... > > # varnish issue 1799 > ... > EOF > varnishlog -Q bad-things.txt Dridi From lagged at gmail.com Mon Sep 23 21:18:03 2019 From: lagged at gmail.com (Andrei) Date: Tue, 24 Sep 2019 00:18:03 +0300 Subject: TLS sandboxing In-Reply-To: References: <53147.1567584124@critter.freebsd.dk> Message-ID: Is Varnish finally going to start supporting https so we no longer have to offload/completely replace it with nginx? On Mon, Sep 23, 2019, 11:16 Dridi Boukelmoune wrote: > On Wed, Sep 4, 2019 at 8:02 AM Poul-Henning Kamp > wrote: > > > > -------- > > In message , Nils > Goroll writ > > es: > > > > >Yet with the H3/QUIC madness on the horizon, > > > > No, they actually dealt with this in the design, so that "keyless" > > operation is more or less the natural architecture for QUIC. > > > > If we want to do TCP/TLS, we should also aim firmly for the "keyless" > model. > > > > I'm hoping we can to raid the hitch source code to build the "keymaster" > process. > > I have given more thought to this and I'm torn between "this is 2019 > and we still don't support HTTPS" and the very good reasons why we > don't. However I still think we should support it and I gave a tiny > bit more thoughts to this. > > First, in-kernel TLS is coming, and while it will likely take forever > to become ubiquitous *cough* enterprise linux *cough* in the long run > it will probably be our best option: we keep our usual read and > write[v] calls and nothing changes for us. > > Until then though, we might want to add support for "session > operations" to replace the read/write[v] calls with > SSL_read/SSL_write[v] for example. Ideally that would be with a > vmod-openssl that later could compete with a vmod-ktls or > vmod-other_tls_library, possibly written by third parties *cough* > uplex? *cough* since we can't reasonably support them all ;-) > > With customizable session operations, we can now also replace other > calls like accept or connect. That might be our cue to add session > subroutines in VCL. > > But once we have that we circle back to handshakes. And I very much > agree that a keyless approach would be best. However this is still > 2019 so I think we should own it, and not rely on a third party. We > should provide a comprehensive solution, for either HTTPS or http/3, > and therefore we should provide a minimalist keyserver implementation. > Whether it is a new varnishkeyserver program, or a new varnishd -k > flag with a 3rd long-lived varnishd process, possibly working with a > socketpair like my MXC thought experiment, I think we should provide > that. > > Have a nice VDD! > > Dridi > _______________________________________________ > varnish-dev mailing list > varnish-dev at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Mon Sep 23 22:02:27 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 23 Sep 2019 22:02:27 +0000 Subject: TLS sandboxing In-Reply-To: References: <53147.1567584124@critter.freebsd.dk> Message-ID: <19133.1569276147@critter.freebsd.dk> -------- In message , Dridi Boukelmoune writes: >I have given more thought to this and I'm torn between "this is 2019 >and we still don't support HTTPS" and the very good reasons why we >don't. However I still think we should support it and I gave a tiny >bit more thoughts to this. Absolutely, all such decisions needs to be revisited as circumstances change. >First, in-kernel TLS is coming, Yes, and about f**king I might add... (See also: https://people.freebsd.org/~gallatin/talks/euro2019.pdf) Unfortunately, the kernel people only seem to want to do the easy part :-( https://reviews.freebsd.org/D21277 >But once we have that we circle back to handshakes. And I very much >agree that a keyless approach would be best. However this is still >2019 so I think we should own it, and not rely on a third party. I'm not in any hurry to add crypto code to our plate in any way shape and form. The primary reason is that as far as I know there are *at best* 1? persons in the project with skills which *approximate* what would be required. The secondary reason is that neither of them are particularly eager to add another job to their workload. I can *possibly* be persuaded that we can handle session keys, and I will be perfectly happy to point at a 3rd party keyserver packages and say "that's where you get your keys from". -- 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 scan-admin at coverity.com Sun Sep 29 11:35:14 2019 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 29 Sep 2019 11:35:14 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <5d9096f2a257_43212ae0c3490f4c87788@appnode-2.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRaZSCEJOPR4AEUn0hVASTtlJ23U2ffwbN1LtJbHcOCfQg-3D-3D_wrU9d1VlqIiuL6N0zVMze4Ep-2FR7u99vtLlE-2BlH3ENQDrWJcCq7w8nONJ38wwX9iWAiNey2BYD7A01oSMIeN8yXpj0b4taG2fN-2F9WBbvWoyjGIbRBtBmrw-2Bt9QZQx1w1R55QbtvE8aWyJHtvJi7H-2BemvZwBGFIsJP1TSu1NWMYJ5zcoxTEJLUrdYrJ33SG-2BKJI1ZPle6SMqdkvYXuZiZhfK3X2LtwvoGOFWTfDbmLdPA-3D Build ID: 274564 Analysis Summary: New defects found: 7 Defects eliminated: 11 If you have difficulty understanding any defects, email us at scan-admin at coverity.com, or post your question to StackOverflow at https://u2389337.ct.sendgrid.net/wf/click?upn=OgIsEqWzmIl4S-2FzEUMxLXL-2BukuZt9UUdRZhgmgzAKchwAzH1nH3073xDEXNRgHN6zzUI-2FRfbrE6mNOeeukHUQw-3D-3D_wrU9d1VlqIiuL6N0zVMze4Ep-2FR7u99vtLlE-2BlH3ENQDrWJcCq7w8nONJ38wwX9iWAiNey2BYD7A01oSMIeN8yQnJkRnG13wsn8owMADkm0qlQtenES9wxiIIEE5R4aCnkEiHd33NY85shci6oQNn6uAs7g2ppieQqhyGFiroqvCYs7tQTrGFh37QOj2G4tOczz0SEpUS4rvq14-2FCkb0JZWWanwd-2FscgFY5Nm4LwLvy4-3D