From issues-return-81875-archive-asf-public=cust-asf.ponee.io@nifi.apache.org Fri Jul 26 17:04:02 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id DBBE1180676 for ; Fri, 26 Jul 2019 19:04:01 +0200 (CEST) Received: (qmail 43706 invoked by uid 500); 26 Jul 2019 17:04:01 -0000 Mailing-List: contact issues-help@nifi.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@nifi.apache.org Delivered-To: mailing list issues@nifi.apache.org Received: (qmail 43695 invoked by uid 99); 26 Jul 2019 17:04:01 -0000 Received: from mailrelay1-us-west.apache.org (HELO mailrelay1-us-west.apache.org) (209.188.14.139) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 26 Jul 2019 17:04:01 +0000 Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 69272E2F59 for ; Fri, 26 Jul 2019 17:04:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 21E2826603 for ; Fri, 26 Jul 2019 17:04:00 +0000 (UTC) Date: Fri, 26 Jul 2019 17:04:00 +0000 (UTC) From: "Mr TheSegfault (JIRA)" To: issues@nifi.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (MINIFICPP-954) Consider moving the C2 line protocol to Google Protobuf MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/MINIFICPP-954?page=3Dcom.atlass= ian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1= 6893988#comment-16893988 ]=20 Mr TheSegfault commented on MINIFICPP-954: ------------------------------------------ [~bakaid]=C2=A0 I like some of the concepts you present but prior CVEs were= why we moved away from protobuf initially in community discussions.=C2=A0 = I think offloading the testing to protobuf maintainers is a reason to have = Protobuf but I think both will need to exist.=C2=A0 We also considered flat= buffers and capn proto. =C2=A0 I think this ultimately would be either adding protobuf/flatbuffers/capn as= a selectable line format. We have a very simple line format that isn't goi= ng to change ( this is because our line formats are designed to use the RES= TFul API for the complicated stuff ). The line format is simply for sending= a very tiny subset of information. We also want to use the same code for n= anofi, where I think our consumers are more likely to appreciate not includ= ing protobuf. As a result we can add this as an extension ( in fact, I love= the idea ) =E2=80=93 especially since we can mitigate concerns of others b= y having it be configurable in the agent ( and compile time for nanofi ECUs= ).=20 If we went down the route of cap'n proto we can rely on the embedded RPC an= d use that as a separate C2 protocol. I have used Cap'n Proto, for example,= and we could easily define those RPC calls to lessen the load,=C2=A0 but I= would likely change this ticket to exploring alternative protocols/wire fo= rmats and then making a decision as an addition to what we have now as oppo= sed to a replacement. We will be forced to maintain it but we have no choice either as we have us= ers who specifically don't want protobuf and we have released it so we are = forced to maintain it and improve its testing.=20 Keep in mind that whomever tackles this will need to balance maintaining wh= at we already have ( not replacing ) so we then increase what we must test.= We can rely on capn proto or protobuf's tests, but then we still need to p= erform our test in the venn diagram of testing. Would that effort be better= spent improving tests for our work since we already need to do that and mu= st maintain it? I'll leave that question up to the implementor =E2=80=93 but it's certainly= not an affront against doing this work, more a word of caution. I'm glad w= e decided against protobuf at the time, though =E2=80=93 would have made th= at decision again. It was a calculated risk with many thoughts in mind =E2= =80=93 but would love to see something else like protobuf/flatbuffers/capn = . =C2=A0 =C2=A0 > Consider moving the C2 line protocol to Google Protobuf > ------------------------------------------------------- > > Key: MINIFICPP-954 > URL: https://issues.apache.org/jira/browse/MINIFICPP-954 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement > Reporter: Daniel Bakai > Priority: Major > > * Very compact serialized format > * Easy protocol description > * Support for generating parsers for many languages from the proto file > * Has good versioning support > * Thoroughly tested, fuzzed > * Less chance of introducing security vulnerabilities with hand-written = parsers -- This message was sent by Atlassian JIRA (v7.6.14#76016)