On 06/06/2019 00:34, Giorgio Zoppi wrote:
> Ok, well done.  Just a question. does anyone how enable Sonar on our github.
> https://blog.sonarsource.com/reviewing-the-apache-sling-code-quality-using-sonar
> .

That is a 10 years old blog...

Try to look to
https://cwiki.apache.org/confluence/display/INFRA/SonarQube+Analysis

> Could we ask to Sling People?

Ask infra I guess ;-)

> Best Regards,
> Giorgio
> 
> 
> El mié., 5 jun. 2019 a las 13:24, Brian Spector (<[email protected]>)
> escribió:
> 
>> NOTE: This also exists as a post here:
>> https://cwiki.apache.org/confluence/display/MILAGRO/2019/06/04/Product+Direction+and+Release+Schedule
>>
>> Please comment on this thread though, as with the Apache Way, “if it
>> doesn’t happen on email, it doesn’t happen.”
>>
>> Milagro (the project) needs a general purpose Milagro Server that can
>> encapsulate all the required components to bring up and distributed /
>> decentralized core security services. As an example, in the current Python
>> versioned M-Pin server there does not exist any flag on whether to run this
>> as a D-TA (serving shares of secrets) or as an M-Pin Server. This means
>> someone building a fully fledged M-Pin protocol based implementation needs
>> to construct their own D-TA services, which is causing implementation drag.
>> Thankfully, Giorgio has been working on this.
>>
>> I propose that we fix this going forward by having an install script that
>> can pull down various components and complete installation according to
>> config/install scripts. So, going forward, we just have something called
>> 'Milagro Server'.
>>
>> Second, in order for Milagro to stay relevant, Milagro should address use
>> cases within the digital asset space that deliver on the security
>> requirements for decentralized networks, in addition to the enterprise and
>> IoT spaces. There is much interest from these communities for open source
>> platforms that can secure escrow of private keys used to store value and
>> transact cryptocurrencies (custody) but operate in a decentralized manner -
>> capability that is native to Milagro.
>>
>> Qredo has been working on such a platform using the Milagro crypto
>> libraries, which has authentication based on M-Pin (using Milagro) and will
>> grant the software to Apache in the next few weeks. This will enable
>> Milagro to finally get a release out the door of a product, not just a
>> release of the crypto libraries.
>>
>> The list of capabilities for this product as it continues its development
>> trajectory incorporates decentralized storage and backup. It is envisioned
>> that M-Pin protocol authentication and D-TA's will also be a part of this
>> mix.
>>
>> Decentralized Milagro
>>
>> Qredo has incorporated into its custody server product (based on Milagro)
>> a distributed, immutable file system called IPFS, an immutable,
>> operation-based conflict-free replicated data structure (CRDT) for
>> distributed systems with MIT license. On top of IPFS, we have built a
>> decentralized public key infrastructure that does away with certificates
>> and certificate authorities. This decentralized public key infrastructure
>> enables an encrypted messaging over IPFS pubsub. We propose to call this
>> the 'Milagro encrypted envelope' format.
>>
>> This functionality is required to enable Milagro Servers to distribute
>> secrets over a decentralized infrastructure - imagine a D-TA operating in
>> this manner and distributing shares of M-Pin secrets to clients.
>>
>> The custody server that Qredo has created uses the encrypted envelope
>> format to distribute Elliptic Curve keys between operators of the Milagro
>> Server. This EC keys are ultimately used to create wallet addresses, or
>> create private keys used to control digital assets inside a cryptocurrency
>> wallet. This capability is also critical for D-TAs, so that decentralized
>> D-TA services can distributed shares of M-Pin protocol based private/server
>> keys to authenticated endpoints/clients.
>>
>> I will create another blogpost describing the functional overview of the
>> Milagro Server configured for decentralized custody services and a separate
>> blogpost for decentralized backup of key stores.
>>
>> PKCS#11
>> Qredo has also created a PKCS#11 implementation that enables secrets
>> generated by a Milagro Server to be protected by AWS HSM-Clusters. We will
>> contribute this code as part of the Milagro Server.
>>
>> Docker Container
>> Apache has its own Docker registry now, so Milagro should take full use of
>> this. I propose that we implement a Milagro Server in a docker container
>> and this be part of the initial release schedule.
>>
>> Release Schedule
>> July 1 - Milagro Crypto Library Release (milagro-crypto-c)
>>
>> The C library is in good shape and will have additional fixes made by the
>> end of the month. At the moment, all tests are passing.
>>
>> Releasing the Milagro Crypto Library first will enable the contributors to
>> Milagro to familiarize themselves with the processes for getting releases
>> out the door under the 'Apache Way'. This experience is essential for the
>> success of the project. We have some tasks outstanding on
>> Milagro-JavaScript. Depending on resource availability, we may or may not
>> be able to
>>
>> August 1 - Milagro Server Release Candidate 1 of v0.1 (RC1)
>>
>> First release candidate
>>
>> September 1 - Milagro Server Release Candidate 2 of v0.1 (RC2)
>>
>> Second release candidate
>>
>> October 1 - Milagro Server v 0.1 GA
>>
>> Incorporating Current Functional Code
>> Qredo has specifics in mind with regards to functionality available in
>> each RC and GA releases in regards to decentralized custody and backup but
>> an equal priority will be given to contributor's work done so far on ZKP
>> MFA services, particularly with regards to Giorgio's work and the current
>> working implementations of the M-Pin Server. Going forward, I propose we
>> stop referring to the underlying protocol and be explicit about what the
>> functionality is, as an example, this is the zero-knowledge proof
>> multi-factor authentication (ZKP MFA) server.
>>
>> Figuring out what is going into these releases should be our next
>> immediate priority.
>>
> 
> 


-- 
Cheers

Jean-Frederic

Reply via email to