Andre

Seems like a fair point and also I added you to the wiki permissions.

Thanks
Joe

On Sun, Jul 17, 2016 at 9:01 AM, Andre <[email protected]> wrote:
> All,
>
> I don't have write access to the wiki so I ended up not being able to write
> the comment over there but I wanted to make a very basic comment.
>
>
> The current package security mechanism proposes using MD5 and SHA1 hashing
> algo's for pom's and adoc's.
>
> Be mindful that for ages the general guidance is that both algorithms
> should not be used in regulated systems (i.e. government, banking, health,
> etc) across multiple jurisdictions out of security concerns:
>
> http://csrc.nist.gov/groups/ST/hash/policy.html
> https://web.archive.org/web/20131113032317/http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx
> https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html
> http://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls
> https://threatpost.com/sloth-attacks-up-ante-on-sha-1-md5-deprecation/115807/
>
> I understand most of discussion around the ciphers still floats around its
> use in PKI and TLS comms and that the scenario is well far fetched for
> NiFi's (unless the previous holders of the copyright decided to use the
> open source repo... 8D )
>
> But considering how easy it is to use SHA2 or SHA3, may I suggest we
> revisit the choice of algorithms?
>
> Cheers
>
> On Thu, Jul 14, 2016 at 7:43 AM, Matt Foley <[email protected]> wrote:
>
>> Okay, that's why I sent the email first :-)
>>
>> I talked with Oleg offline, and clarified that his concern is that there
>> are many user requirements expressed in the first four sections, and that
>> any decreases in scope from what's expressed there should be done with full
>> community consensus, and there hasn't been enough discussion with enough
>> participants yet to achieve that consensus.
>>
>> So for now, I'll just edit the material I added.  I'll move Section 5 into
>> Section 3 without removing anything except redundancy, and expand the
>> current Section 6 to make it easier to discuss the individual points that
>> obviously need more discussion, like the Browse/Discovery experience and
>> Dependency Management.
>>
>> Any further thoughts or concerns are welcome.
>>
>> Thanks,
>> --Matt
>> ________________________________________
>> From: Oleg Zhurakousky
>> Sent: Wednesday, July 13, 2016 10:53 AM
>> To: Matt Foley
>> Cc: [email protected]; Bryan Bende; Mark Payne; Brandon DeVries; Joe
>> Witt; Aldrin Piri
>> Subject: Re: External Repositories (aka Extension Registry) for
>> Dynamically-loaded Extensions
>>
>> Matt,
>>
>> Due to “other tasks” I personally haven’t been able yet to follow
>> everything that’s going on, nor had I have a chance to look at the POC you
>> and Puspendu have created, so I think global update of the page would be
>> too early at the moment as it doesn’t really capture all of the concerns
>> and there are certainly quite a few vey common concerns that need to be
>> addressed outside of what I was able to extract from recent interaction.
>> I will do my best to go through all the comments by the end of next week.
>>
>> Cheers
>> Oleg
>>
>> > On Jul 13, 2016, at 1:46 PM, Matt Foley <[email protected]> wrote:
>> >
>> > Hi all,
>> > I'm about to do a global edit of the design page at
>> https://cwiki.apache.org/confluence/display/NIFI/Extension+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions
>> > based on comments by Joe Witt and Aldrin Piri.
>> >
>> > This will include editing text that was written by the folks on the CC:
>> line.  If any of you object up front, please say so, otherwise after the
>> fact there's always Page History :-)
>> >
>> > Among other edits, I intend to unify Sections 3 (Proposed Features) and
>> 5 (Use Cases), removing contradictions and reducing the discussion to what
>> we actually intend to implement.  I will add a section on "Possible Future
>> Features", so as to not lose the other ideas.
>> >
>> > I will also break out sections for "Dependency Management and
>> Auto-loading", and "Discovery - Browsing Extensions (and their docs)
>> Without Loading Them".  These are two areas that are least well defined,
>> and have already generated the most discussion.
>> >
>> > I will start this editing tomorrow morning, unless there are '-1's.
>> > Thanks,
>> > --Matt
>> > ________________________________________
>> > From: Matt Foley
>> > Sent: Monday, July 11, 2016 4:20 PM
>> > To: [email protected]
>> > Subject: Re: External Repositories (aka Extension Registry) for
>> Dynamically-loaded Extensions
>> >
>> > Thanks, Joe.  I've responded to the issues you raised in Sections 5 and
>> 6.
>> > Sections 2 and 3 were written by others and I am reticent to edit their
>> text;
>> > I hope they will accept or respond to your comments there.
>> >
>> > Thanks everyone,
>> > --Matt
>> > ________________________________________
>> > From: Joe Witt <[email protected]>
>> > Sent: Monday, July 11, 2016 3:05 PM
>> > To: [email protected]
>> > Subject: Re: External Repositories (aka Extension Registry) for
>> Dynamically-loaded Extensions
>> >
>> > Matt, Puspendu,
>> >
>> > I put some thoughts on the wiki today and I think it looks like it is
>> > coming along nicely.  I believe the slow response cycle right now is
>> > because there are a few fairly big efforts underway at once including
>> > the first release of minifi, apache nifi 0.7.0 voting, and closing
>> > down for an apache nifi 1.0 vote.  Good to keep the discussion going
>> > and it is great you're pushing this.  It is much needed.
>> >
>> > Joe
>> >
>> >
>> > On Mon, Jul 11, 2016 at 3:28 PM, Matt Foley <[email protected]>
>> wrote:
>> >> Hi all,
>> >> Looks like this didn't get to the top of anyone's priority list over
>> the holiday week, since the Jira<
>> https://issues.apache.org/jira/browse/NIFI-2168>, the Wiki page<
>> https://cwiki.apache.org/confluence/display/NIFI/External+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions>
>> and this Mail thread have all been quiet.
>> >>
>> >> If you don't have time to look at the code, that's absolutely okay, but
>> Sections 5 and 6 of the Wiki page?<
>> https://cwiki.apache.org/confluence/display/NIFI/External+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions#ExternalRepositories(akaExtensionRegistry)forDynamically-loadedExtensions-5.UseCases>
>> are only about one page of reading total, and we would really appreciate a
>> couple +1's to say it's okay to proceed with this basic approach. Please?
>> :-)
>> >>
>> >> Thanks,
>> >> --Matt and Puspendu
>> >> ________________________________________
>> >> From: Matt Foley <[email protected]>
>> >> Sent: Sunday, July 03, 2016 3:27 PM
>> >> To: [email protected]
>> >> Subject: Re: External Repositories (aka Extension Registry) for
>> Dynamically-loaded Extensions
>> >>
>> >> That would be great. Even though the prototype impl is incomplete, it's
>> actually about 30%-50% done, if the approach is acceptable to you, the
>> community. We could easily finish it in a reasonable timeframe for the
>> release after 1.0, and we're interested in doing so.
>> >>
>> >> Thanks,
>> >> --Matt
>> >>
>> >>> On Jul 3, 2016, at 3:15 PM, Joe Witt <[email protected]> wrote:
>> >>>
>> >>> Thanks Matt.  Really great to keep having this evolve.  Once we get on
>> >>> the other side of the 1.0 release we should kick off another roadmap
>> >>> discussion to recap what has been done in the past six or so months
>> >>> and also to identify what are some good focus areas for the next 6+
>> >>> months.
>> >>>
>> >>>> On Sun, Jul 3, 2016 at 9:12 AM, Matt Foley <[email protected]>
>> wrote:
>> >>>> Hi all,
>> >>>>
>> >>>> Puspendu Banerjee and I have been exchanging ideas about how to
>> design the "Extension Registry" in the wiki page discussion at
>> >>>>
>> >>>> *
>> https://cwiki.apache.org/confluence/display/NIFI/External+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions
>> >>>>
>> >>>> We've now posted some Use Cases and a Design Proposal to that page
>> (new sections 5 and 6), as well as the beginnings of a prototype
>> implementation, enough to see the basic framework, at
>> >>>>
>> >>>> *   https://github.com/PuspenduBanerjee/nifi/tree/NIFI-ExtRegistry
>> >>>>
>> >>>> I've also opened https://issues.apache.org/jira/browse/NIFI-2168?
>> for the work.
>> >>>>
>> >>>> I'm sorry the current state of the prototype code isn't entirely up
>> to date with Master (it's from June 9), but I've been interrupted by a
>> family medical emergency, that will likely tie me up for the next week or
>> so.  But I hope those of you who are interested will look at the Design
>> Proposal and the proto implementation, and give us the benefit of your
>> comments.
>> >>>>
>> >>>> Thanks!
>> >>>> --Matt
>> >>>
>> >>
>> >
>>
>>

Reply via email to