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 . Could we ask to Sling People? 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. > -- Life is a chess game - Anonymous.
