Thanks, I'll check it out. El jue., 6 jun. 2019 a las 10:40, jean-frederic clere (<[email protected]>) escribió:
> 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 > -- Life is a chess game - Anonymous.
