TLS renegotiations (was Re: Please update your Go version to this version)

[David Cheney]

+1 STGM.


On Mon, Jul 22, 2013 at 11:43 AM, Julian Edwards
<julian.edwards at canonical.com> wrote:
> On Saturday 20 Jul 2013 19:56:42 David Cheney wrote:
>> > The person who contributed this patch is a core Go developer and also said
>> > that "it's probably not something suitable for upstreaming."
>>
>> Don't read too much into that, Adam may have been trying to say "This
>> quick has is not suitable in its current form".
>>
>> However, this would not make it into the 1.1.2 release next month, so
>> the best time this would see the light of day is Go 1.2 at the start
>> of December at which point Saucy will be shipping and we'll have to
>> backport 1.2 to 4 series.
>
> You'd only be SRUing (not backporting, SRUing) when versions lower than 1.2
> become unsupported.
>
> In this case, we'd have the patch we needed in the next LTS of 14.04 which is
> perfect.  Older releases would either get the SRU, or we maintain the forked
> packages ourselves for 9 months (and who is going to be using non-LTS releases
> for production?).
>
> In other words, the 1.2 version will have to get SRUed anyway, so the burden
> on us maintaining the forked packages is quite limited.  We can also limit the
> fork to be inside gwacl so the rest of the core is not affected.
>
>>
>> > What do you Juju core guys want to do about this?  These options come to
> mind:
>> >  1. Fix go-curl to work with 1.1
>>
>> I think the is the most work, but the best option.
>>
>> >  2. Carry a patched Go in Ubuntu (but obviously other platforms would be
>> >
>> > broken)
>>
>> This is the easiest, and if we stick to binary releases for other
>> platforms, the least work.
>>
>> >  3. Fork crypto/tls into a separate package (or put it inside gwacl) with
>> >  the>
>> > patch.
>>
>> You'll also need to fork the net/http package, and probably a half
>> dozen other packages. This is almost as much work as 1, and carries
>> higher technical debt
>
> As jtv said, he only forked 3 packages.
>
> This is increasingly looking the best option to me (especially given that we
> don't know exactly where go-curl is going wrong?).
>
> Can I get a vote on this from the rest of the devs please?