Re: (Unofficial) wireguard packages for Debian Stretch (testing)

[Daniel Kahn Gillmor <dkg@fifthhorseman.net>]

[-- Attachment #1: Type: text/plain, Size: 2229 bytes --]

On Fri 2017-02-10 19:23:50 -0500, David Anderson wrote:
> In case it's of use to anyone, I've built wireguard packages for Debian
> testing. I wanted to play with wireguard on my Debian Stretch systems, but
> wireguard is currently locked to Sid only until 1.0 brings API stability
> guarantees.
>
> So, I set up a cronjob that rebuilds the Sid source package on a Stretch
> system, and the result is wireguard packages that track the latest release,
> but don't pull in unstable versions of libc and whatnot when you try to
> install them, as would happen if you tried to install via package pinning.
>
> Naturally, you have only my word that the packages are unmodified rebuilds
> of Debian's original package, and you're trusting packagecloud to not
> tamper with the packages (it's their signing keys, not mine) so caveat
> emptor. It works for me, it might work for you as well.
>
> With the warnings and disclaimers out of the way, here's the repo:
> https://packagecloud.io/danderson/wireguard?filter=debs

I appreciate your interest in getting wider distribution for wireguard,
David, but i'm not convinced this approach makes much sense.

It seems like a lot of extra work compared to just putting wireguard
into stretch-backports once stretch is released.

Until stretch releases, people running testing should be able to just
add the unstable repository and pin it to be lower priority than testing
(see apt_preferences(5)).

Using this standard approach, users won't need to:

 a) add a new key to their apt configuration, which increases the attack
    surface for all installed packages (btw, the proposed shell pipe
    into "apt-key add -" is deprecated, see for example commentary at
    https://bugs.debian.org/853858)
 
 b) be dependent on some alternate suite of build daemons -- if debian
    supports your build environment, the buildds will have the wireguard
    packages.

So I don't see much to recommend the proposed approach by comparison,
and i don't think that it should be documented as a recommended approach
upstream, unless there are clearer benefits that i'm missing here.  In
that case, i'd like to know what those benefits are :)

         --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]