You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@milagro.apache.org by Alessandro Budroni <bu...@gmail.com> on 2016/08/08 11:13:06 UTC
[Milagro-TLS repository]
To whom I may concern,
I’m a developer who should take care of this repository https://github.com/apache/incubator-milagro-tls <https://github.com/apache/incubator-milagro-tls>.
Milagro-TLS is a project consisting in expanding the existing library https://github.com/ARMmbed/mbedtls <https://github.com/ARMmbed/mbedtls> in order to support two new pairing-based key-exchange algorithm as explained here https://datatracker.ietf.org/doc/draft-budronimccusker-milagrotls/ <https://datatracker.ietf.org/doc/draft-budronimccusker-milagrotls/>.
From my point of view, instead of having an own repository as it is now, it would be better to have a fork to ARMmbed/mbedtls, so that it would be easier to maintain and it will allow us to make a pull request when the right time will come.
It would be possible to achieve this?
Regards,
Alessandro Budroni
Re: [Milagro-TLS repository]
Posted by Angelo Centanni <an...@becktechsupport.com>.
how can i remove my email address from this list?
On Wed, Aug 10, 2016 at 4:20 AM, Alessandro Budroni <
budroni.alessandro@gmail.com> wrote:
> Hi Nick,
>
> Actually yes, we made a relatively small expansion of the very big library
> ARM/mbedtls.
>
> I’m not active in this community and probably they don’t know about
> Milagro-tls.
>
> The plan, according with my understanding, is to reach a good level of our
> code so that anyone can safely use it and then make a pull request to
> mbedtls.
> I think the chances of acceptance are very low since the new cipher suites
> that we have implemented aren’t still a standard and
> since our changes are relatively big in terms of a single contribution.
>
> Anyway making a pull request will let us known by the community there,
> will give us visibility and we can get comments and
> see what to do to have a full acceptance. If the pull request will not
> accepted anyway, the plan was to to re-brand mbedtls as milagro-tls
> and keep it synced with the upstream mbedtls.
>
> Regards,
>
> Alessandro
>
> >>> To whom I may concern,
> >>>
> >>> I’m a developer who should take care of this repository
> >>> https://github.com/apache/incubator-milagro-tls <
> https://github.com/apache/incubator-milagro-tls>
> >>> <https://github.com/apache/incubator-milagro-tls>.
> >>>
> >>> Milagro-TLS is a project consisting in expanding the existing library
> >>> https://github.com/ARMmbed/mbedtls
> >>> <https://github.com/ARMmbed/mbedtls> in order to support two new
> >>> pairing-based key-exchange algorithm as explained here
> >>> https://datatracker.ietf.org/doc/draft-budronimccusker-milagrotls/
> >>> <https://datatracker.ietf.org/doc/draft-budronimccusker-milagrotls/>.
> >>>
> >>> From my point of view, instead of having an own repository as it is
> >>> now, it would be better to have a fork to ARMmbed/mbedtls, so that it
> >>> would be easier to maintain and it will allow us to make a pull
> >>> request when the right time will come.
> >>
> >> Are you saying the milagro-tls library is a fork of mbedtls
> >> with relatively little change?
> >>
> >> A quick look at mbedtls tells me it has what looks like a healthy
> >> community quite separate from milagro. Are you active in, or at
> >> least known within, that community?
> >>
> >> If you're saying what I think you are, it might make more sense
> >> for you and anyone else concerned with the library to work with
> >> them there, to contribute and maintain whatever enhancements are
> >> needed by Milagro. The TLS lib then becomes a prerequisite
> >> rather than a component of Milagro.
> >>
> >> Otherwise you'd presumably need to sync regularly, and it'll
> >> make the job harder if you're not working with them.
> >>
> >> Unless milagro's needs could be implemented in a modular
> >> fashion to complement rather than replace mbedtls?
> >> If that works then it matters much less how to proceed.
> >>
> >>> It would be possible to achieve this?
> >>
> >> The first question has to be, what exactly are we trying to achieve
> >> in having a separate library in the first place? Then we move on
> >> to the question of how best to make it work.
> >>
> >> --
> >> Nick Kew
> >
>
>
--
*Angelo Centanni*
*Director, BTS Cyber Security*
Linux System Administrator
*504 579 2113*
angelocentanni@becktechsupport.com
https://btscybersecurity.com
Prepare for Disaster and Recover Faster With BTS Cyber Security
Our Motto:
"When Life Gives You Lemons say "No Thank You!""
Re: [Milagro-TLS repository]
Posted by Alessandro Budroni <bu...@gmail.com>.
Hi Nick,
Actually yes, we made a relatively small expansion of the very big library ARM/mbedtls.
I’m not active in this community and probably they don’t know about Milagro-tls.
The plan, according with my understanding, is to reach a good level of our code so that anyone can safely use it and then make a pull request to mbedtls.
I think the chances of acceptance are very low since the new cipher suites that we have implemented aren’t still a standard and
since our changes are relatively big in terms of a single contribution.
Anyway making a pull request will let us known by the community there, will give us visibility and we can get comments and
see what to do to have a full acceptance. If the pull request will not accepted anyway, the plan was to to re-brand mbedtls as milagro-tls
and keep it synced with the upstream mbedtls.
Regards,
Alessandro
>>> To whom I may concern,
>>>
>>> I’m a developer who should take care of this repository
>>> https://github.com/apache/incubator-milagro-tls <https://github.com/apache/incubator-milagro-tls>
>>> <https://github.com/apache/incubator-milagro-tls>.
>>>
>>> Milagro-TLS is a project consisting in expanding the existing library
>>> https://github.com/ARMmbed/mbedtls
>>> <https://github.com/ARMmbed/mbedtls> in order to support two new
>>> pairing-based key-exchange algorithm as explained here
>>> https://datatracker.ietf.org/doc/draft-budronimccusker-milagrotls/
>>> <https://datatracker.ietf.org/doc/draft-budronimccusker-milagrotls/>.
>>>
>>> From my point of view, instead of having an own repository as it is
>>> now, it would be better to have a fork to ARMmbed/mbedtls, so that it
>>> would be easier to maintain and it will allow us to make a pull
>>> request when the right time will come.
>>
>> Are you saying the milagro-tls library is a fork of mbedtls
>> with relatively little change?
>>
>> A quick look at mbedtls tells me it has what looks like a healthy
>> community quite separate from milagro. Are you active in, or at
>> least known within, that community?
>>
>> If you're saying what I think you are, it might make more sense
>> for you and anyone else concerned with the library to work with
>> them there, to contribute and maintain whatever enhancements are
>> needed by Milagro. The TLS lib then becomes a prerequisite
>> rather than a component of Milagro.
>>
>> Otherwise you'd presumably need to sync regularly, and it'll
>> make the job harder if you're not working with them.
>>
>> Unless milagro's needs could be implemented in a modular
>> fashion to complement rather than replace mbedtls?
>> If that works then it matters much less how to proceed.
>>
>>> It would be possible to achieve this?
>>
>> The first question has to be, what exactly are we trying to achieve
>> in having a separate library in the first place? Then we move on
>> to the question of how best to make it work.
>>
>> --
>> Nick Kew
>
Re: [Milagro-TLS repository]
Posted by Nick Kew <ni...@apache.org>.
On Mon, 8 Aug 2016 13:13:06 +0200
Alessandro Budroni <bu...@gmail.com> wrote:
> To whom I may concern,
>
> I’m a developer who should take care of this repository
> https://github.com/apache/incubator-milagro-tls
> <https://github.com/apache/incubator-milagro-tls>.
>
> Milagro-TLS is a project consisting in expanding the existing library
> https://github.com/ARMmbed/mbedtls
> <https://github.com/ARMmbed/mbedtls> in order to support two new
> pairing-based key-exchange algorithm as explained here
> https://datatracker.ietf.org/doc/draft-budronimccusker-milagrotls/
> <https://datatracker.ietf.org/doc/draft-budronimccusker-milagrotls/>.
>
> From my point of view, instead of having an own repository as it is
> now, it would be better to have a fork to ARMmbed/mbedtls, so that it
> would be easier to maintain and it will allow us to make a pull
> request when the right time will come.
Are you saying the milagro-tls library is a fork of mbedtls
with relatively little change?
A quick look at mbedtls tells me it has what looks like a healthy
community quite separate from milagro. Are you active in, or at
least known within, that community?
If you're saying what I think you are, it might make more sense
for you and anyone else concerned with the library to work with
them there, to contribute and maintain whatever enhancements are
needed by Milagro. The TLS lib then becomes a prerequisite
rather than a component of Milagro.
Otherwise you'd presumably need to sync regularly, and it'll
make the job harder if you're not working with them.
Unless milagro's needs could be implemented in a modular
fashion to complement rather than replace mbedtls?
If that works then it matters much less how to proceed.
> It would be possible to achieve this?
The first question has to be, what exactly are we trying to achieve
in having a separate library in the first place? Then we move on
to the question of how best to make it work.
--
Nick Kew