* Package name : golang-yawning-utls-dev Version : 0.0.11-1 Upstream Author : Yawning Angel <yawning@schwanenlied.me> * URL : https://gitlab.com/yawning/utls * License : GNU GPLv3, 3-clause BSD Programming Lang: Go Description : fork of utls for obfs4proxy's meek_lite transport . uTLS is a fork of "crypto/tls", which provides ClientHello fingerprinting resistance, low-level access to handshake, fake session tickets and some other features. Handshake is still performed by "crypto/tls", this library merely changes ClientHello part of it and provides low-level access. Note: this package is required to update the package obfs4proxy to the latest version.
Hi Ulrike and Cecylia, Thank you for looking at this! 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. 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. 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 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!). Happy to update this to the latest policy and reupload if this is something we want to do. Awesome, thank you for helping with this :) Thank you all, Ana
Hi Ana! 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. 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. Good idea. I'm very happy to read this. Congratulations! :) Yay from me. Let's see if anyone else, besides the security team, has a comment on this. ulrike PS: Ana, are you subscribed to pkg-privacy-maintainers@alioth-lists.debian.net or do you prefer to be Cc:ed?
Hi there, I see this ticket after I packaged and uploaded an intermediate upstream of this package: * https://github.com/refraction-networking/utls * https://bugs.debian.org/959534 This case is different from dual license. I ever experienced single license to dual license transition for a few files in Linux kernel [1]. So I know this need ACK from original author. [2] [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e2f2db [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/400740.html I guess Yawning didn't ask upstream for re-license, so license for this project is suspicious. Personally I think if it's the case, the project should be considered using the same license as upstream. Since I already packaged the refraction-networking/utls, maybe you can simply use this one? It's still in NEW queue, but you can find the repo in salsa [3] [3] https://salsa.debian.org/go-team/packages/golang-refraction-networking-utls I tried to compare both git repos, but I can only git fetch master branch from yawning/utls. Is this problem of my local git tool? Can you git fetch all branches / tags from yawning/utls? Hope it helps. Cheers,
queue, and now hit testing. [4] https://tracker.debian.org/pkg/golang-refraction-networking-utls Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1