From scan-admin at coverity.com Sun Nov 3 11:38:13 2019 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 03 Nov 2019 11:38:13 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <5dbebc24a85d8_60f02ae0c3490f4c877ad@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-2BlH3ENQBnw-2FwkmLsGOuBMJzwx-2FY5VYQAbLAwWjWiQT5-2FctmiaHuXmv8SlLT-2FlHpobGSlQvw9clsHHSb-2B2GrBS0lLacamlgFZzO-2BRw3HDCaHt4DgHEbuWdzYu65260GJAO69Nx1wMm7WKaScNL0-2BRZSsUfDczjq-2Fp6KEwwFoDbRNBUKmSUTpUzASnymFyeQRo5KXpsdd4-3D Build ID: 279677 Analysis Summary: New defects found: 0 Defects eliminated: 11 From pyunyh at gmail.com Mon Nov 4 02:32:07 2019 From: pyunyh at gmail.com (pyunyh) Date: Mon, 4 Nov 2019 11:32:07 +0900 Subject: base64 blob.decode() default error handling Message-ID: <20191104022721.GA9074@michelle> Hi, In order to validate client supplied base64 encoded string I have a VCL something like the following. if (blob.length(blob.decode(BASE64, 0, req.http.Sec-WebSocket-Key)) != 16) { return (synth(400, "Bad Request")); } If the Sec-WebSocket-Key header has a badly encoded string VCL will generate a "503 VCL failed" response. It's somewhat hard to generate a 400 repsonse in this case, since very little thing can be done in vcl_synth(). As you know resp.status can be overriden as well as resp.reason in vcl_synth() but all state tracking made so far is completely lost in vcl_synth() so there is no way to know where the vcl_synth() is called from which context. What is proper way to handle this case? If there is a way to override arguments passed to synth() with return(fail) during base64 decoding this will address the issue. I think this can be easily solved with inline C but it it would be better to have a VCL method as vcc_allow_inline_c is disabled by default. Thanks. From slink at schokola.de Sat Nov 9 12:34:13 2019 From: slink at schokola.de (Nils Goroll) Date: Sat, 9 Nov 2019 13:34:13 +0100 Subject: a case for vmod VARARGS Message-ID: Hi, I would just like to mention that we are working on a vdp/vfp to exec arbitrary external filter programs. Before you shout "it's unsafe" or "performance will suck": Yes, you are right, and I totally agree, but we got very good reasons: The application is extremely low traffic, the filter is quite costly (in the order of seconds per invocation) and we will highly benefit from address space isolation (due to a high number of 3rd party libraries used by the filter we are going to use, so we are convinced that it will leak memory and contain wild pointers). That said, we would like to support a syntax similar to myvdp.set_args("some", "argument", " and more ", blob.encode(HEX, whatever.get())); for which we could abuse STRING_LIST or some (bound) list of optional/default value arguments right now, but actually real VARARGS would be much better/cleaner. Could we extend the .vmod interface by something like $Function VOID foo (STRING, ...) which would turn into a va_args argument of the previous type? Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From geoff at uplex.de Sat Nov 9 16:02:21 2019 From: geoff at uplex.de (Geoff Simmons) Date: Sat, 9 Nov 2019 17:02:21 +0100 Subject: a case for vmod VARARGS In-Reply-To: References: Message-ID: On 11/9/19 13:34, Nils Goroll wrote: > > Could we extend the .vmod interface by something like > > $Function VOID foo (STRING, ...) > > which would turn into a va_args argument of the previous type? It's worth pointing out that the variable arg syntax in the VMOD function call is one thing, and the way it gets handed off the C function implementing is another. There are some choices. A function call as above could be seen in C as varargs. But if it's STRING, the C function could see the args as STRANDS. That would be almost perfect for our external exec/pipe filter use case, because the array of strings can be handed off the one of the "v" forms of the exec() family (it just needs the NULL member on the end). We don't have something like STRANDS for foo(INT,...) etc, but a general solution could be for the VMOD varags of type T to be translated to an array of T in C. That wouldn't work if you want to have differing data types in the vararg list. But it seems to me that if you know the types in advance, you could just declare them explicitly. VMOD varags as C varargs would work well if you intend to hand off the args to a C function that takes a va_list parameter (something like vfprintf). Maybe a good option would be to declare in VCC whether you want the VMOD varargs to become C varags or an array of TYPE. So IMO +1 to vararg syntax in VMOD declarations, and consider the options for translating the varargs to C. 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 scan-admin at coverity.com Sun Nov 10 11:37:59 2019 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 10 Nov 2019 11:37:59 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <5dc7f69722a73_4a3a2ae0c3490f4c877c0@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-2BlH3ENQAkdymWpw6nBaE2H5Hn9bWmifi5RLYxphrDdTcuW1H6omYXS8EZBF7OSoapdCjd4Jk3nDHzrpYOZSE-2BRayuYfg2YbtQvtub0y1dchAga4YNlvCOwEQGDc6mrqoqha0Sm31WqDUg0He4NEdoz56tOeQEdyHoONK2IeCqo5seTriEmB-2BsXu9C8eZ7ktoyZpjC8Yg-3D Build ID: 280549 Analysis Summary: New defects found: 0 Defects eliminated: 11 From slink at schokola.de Sun Nov 10 13:37:41 2019 From: slink at schokola.de (Nils Goroll) Date: Sun, 10 Nov 2019 14:37:41 +0100 Subject: a case for vmod VARARGS In-Reply-To: References: Message-ID: On 09/11/2019 17:02, Geoff Simmons wrote: > So IMO +1 to vararg syntax in VMOD declarations, and consider the > options for translating the varargs to C. I agree and I did not intend to imply that we needed to use C varargs. An arrays appears to be a good option. Also I think that restricting varargs to be of a single type should be fine, because we already got optional arguments and default values. Nils From phk at phk.freebsd.dk Wed Nov 13 22:11:01 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 13 Nov 2019 22:11:01 +0000 Subject: http-core status for IETF 106 (Singapore) (fwd) Message-ID: <20504.1573683061@critter.freebsd.dk> Time to start reading... ------- Forwarded Message From: "Roy T. Fielding" Date: Wed, 13 Nov 2019 12:03:27 -0800 To: "ietf-http-wg at w3.org Group" Subject: http-core status for IETF 106 (Singapore) > On Oct 25, 2019, at 3:00 PM, Tommy Pauly wrote: > > Our draft agenda for IETF 106 is available here: > > https://github.com/httpwg/wg-materials/blob/gh-pages/ietf106/agenda.md I assume everyone noticed that the -06 drafts for http-core were published last week: https://tools.ietf.org/html/draft-ietf-httpbis-semantics-06 https://tools.ietf.org/html/draft-ietf-httpbis-messaging-06 https://tools.ietf.org/html/draft-ietf-httpbis-cache-06 We will be discussing those at the Monday afternoon meeting in Singapore. https://datatracker.ietf.org/meeting/106/agenda#2019-11-18-080000 Diffs since 05 can be seen at https://httpwg.org/http-core/diffs/diff_semantics_05_to_06.html https://httpwg.org/http-core/diffs/diff_messaging_05_to_06.html https://httpwg.org/http-core/diffs/diff_cache_05_to_06.html and a frankenRFC diff of all changes since the last consensus RFCs, rearranged according to the current draft structure to show just the word changes: https://httpwg.org/http-core/diffs/diff_semantics_frfc_to_06.html https://httpwg.org/http-core/diffs/diff_messaging_frfc_to_06.html https://httpwg.org/http-core/diffs/diff_cache_frfc_to_06.html As always, the best way to track our work is on github at https://github.com/httpwg/http-core and especially the list of commits and open issues: https://github.com/httpwg/http-core/commits/master https://github.com/httpwg/http-core/issues For this meeting, we will probably focus on the issues marked with the label "discuss" https://github.com/httpwg/http-core/labels/discuss (which are still being added to, so speak up if you want to discuss something). The following 28 issues have been closed since the last meeting in Montreal: https://github.com/httpwg/http-core/issues?utf8=%E2%9C%93&q=is%3Aissue +is%3Aclosed+closed%3A%3E2019-07-19+sort%3Acreated-asc with the bulk of text changes being about - refactoring the byte ranges grammar to be extensible (#196, #212 - moving trailer fields to Semantics (#16, #117) - moving payload body requirements to Semantics (#159, #202) - moving retries to idempotent methods (#27, - adding a port registration (#36) - adding a min supported URI length (#169) - incorporating the remaining RFC2818 (HTTP over TLS) text (#236) - replacing "cacheable by default" with heuristically cacheable (#54, #242) - defining requirements on caching incomplete responses (#25, #221) See the "Changes since ..." sections at the end of each draft for a brief summary of what has been changed. We currently have 60 open issues remaining on the list, though 15 are editorial and many others have only small bits left to do before closing. Cheers, ....Roy T. Fielding Senior Principal Scientist, Adobe ------- End of Forwarded Message From scan-admin at coverity.com Sun Nov 17 11:38:15 2019 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 17 Nov 2019 11:38:15 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <5dd13126c9078_38d2ae0c3490f4c87789@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-2BlH3ENQDTGU2kGLCA5CplqIRq0OGlJMbyqBjRC-2FRaR64g76QWrBVhP30eK1csNC5IVgm-2F1LdZFg6oB3JGUFKoyZcAdY46ac0vPws4RCBW84IFcdVLi5kWPz5caKW1cnv5SITSqbVgfv4Z9TcQ6azAgzEd7WbagZvkVKwvZ71jgzboNltC9wYgROSUev9OdC4qsUTIlSE-3D Build ID: 281433 Analysis Summary: New defects found: 0 Defects eliminated: 15 From dridi at varni.sh Wed Nov 20 19:20:55 2019 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 20 Nov 2019 19:20:55 +0000 Subject: Not attending the 2019-11-25 bugwash Message-ID: Greetings, I will probably be in transit at the time of the bugwash so I will work with Nils to get the requested draft for #3134. If we manage to finish the proposal in time, he will speak on our behalf during the bugwash. Dridi From scan-admin at coverity.com Sun Nov 24 11:38:46 2019 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 24 Nov 2019 11:38:46 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <5dda6bc633552_69862ae0c3490f4c877e8@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-2BlH3ENQAzsGgHSQ2wNB-2B9We-2BLUXpcd-2FEy7smHWUWhEaN4GhX2v7cng7c8OW9K36dXEUAuYj651nXGx6QVhHf4HtSK9Eb2V87LWUE9bWp6eQ49loMX6huGL2kt9CKiC8vr-2FvF5E2gblche7KRzplGopoSdBNOnXpTbebTJ0EwxsicvXDk0WpM51AxIn6Bzp8p45ZQ4-2FoA-3D Build ID: 282658 Analysis Summary: New defects found: 0 Defects eliminated: 15