Bug#954209: Do we want to add a fork of utls (ITP #954209)?
Hi Ana!
On 03.04.20 15:36, Ana Custura wrote:
> On 16/03/2020 18:12, Ulrike Uhlig wrote:
>
>> If I understand correctly from a quick look, Yawning distributes his
>> changes under GNU GPL, while uTLS upstream has a BSD 3-Clause license
>> [https://github.com/refraction-networking/utls/blob/master/LICENSE].
>>
>> The BSD 3-Clause is in line with the Debian Free Software Guidelines
>> (DFSG)[https://wiki.debian.org/DFSGLicenses#The_BSD-3-clause_License].
>>
>> From my understanding, in Debian packaging, licenses generally apply to
>> files but it also seems possible (I never encountered such a case) to
>> have several licenses for one file
>> [https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-syntax].
>> Maybe someone could confirm that this is accepted.
>>
>> I'm now unsure to what we referred to previously when saying that there
>> might be licensing issues with Yawning's fork. It does not look like
>> there are. Or am I missing something crucial here? If I don't, then to move forward, one would need to open an RFP or ITP
>> (Intent to Package) bug on the Debian bugtracker and then package this
>> fork of uTLS.
> To sum up the concerns that came from looking at it last time:
>
> golang-yawning-utls-dev is a fork of utls, which is itself a fork of the
> golang tls library. This is a hard fork, any improvements cannot be
> shipped upstream due to the difference in licensing that you've
> identified. The upstream is very active - go has >1500 contributors,
> uTLS has >50 contributors. The fork we want to package is maintained by
> very few people, if I'm not mistaken, Yawning is the only core contributor.
While this is not ideal, there are other packages in Debian that suffer,
or have suffered, from a similar setup, like torbrowser-launcher, or
onionshare.
> I think there is a security implication here - if there is a security
> advisory for the golang library, the Debian Security team needs to work
> with the upstreams to apply security patches to it and all of its forks
> in Debian, meaning this one too. If the delta from upstream increases
> with every fork this could mean a lot of pain.
On https://wiki.debian.org/Teams/Security I read:
For stable: "The preferred situation is that the regular maintainer of
an affected package (who is most familiar with its ins and outs)
prepares updated packages or a ready to use patch which, after approval,
will be uploaded to security-master. If the regular maintainer can't or
won't provide updates (in time), the security team will take the task of
creating the updated packages.
Security for testing and unstable is not officially guaranteed, but the
team tracks those distributions as well in the security tracker. "
However, I think it would be useful that the person maintaining that
package also has an eye on the golang TLS library, to be informed early
on about potential security issues. (I could not find that package in
the Debian archive, and as I'm totally unfamiliar with Go, I wouldn't
know how to monitor that situation.)
It would be helpful if the Debian package maintainer could create pull
requests, or at least open issues, on yawning's repository, when a
security issue is reported.
My understanding is that this does not prevent us from uploading the
package to the Debian archive, as long as Yawning's code is actively
maintained.
Correct me if I'm wrong.
> However, my understanding of the dynamics could be entirely wrong, so
> let me know if I'm off the mark.
> Sending this to the Debian Security team, to ask if they see any
> problems here. Including the source link:
> https://gitlab.com/yawning/utls and ITP:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954209
Good idea.
> If we're all good, I'd be very happy to help with packaging or even
> sponsoring this (I've recently completed the process to become DD, now
> under review!).
I'm very happy to read this. Congratulations! :)
>> → actually that package was uploaded to mentors.debian.org and could go
>> to experimental.
> Happy to update this to the latest policy and reupload if this is
> something we want to do.
Yay from me. Let's see if anyone else, besides the security team, has a
comment on this.
>>> Hey, I'm new to the debian packaging space but am happy to help out here.
> Awesome, thank you for helping with this :)
Cheers!
ulrike
PS: Ana, are you subscribed to
pkg-privacy-maintainers@alioth-lists.debian.net or do you prefer to be
Cc:ed?
Reply to: