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

[David Anderson <dave@natulte.net>]

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

On Sun, Feb 12, 2017 at 3:01 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:

> 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.
>

"Once stretch is released" could be a few months still, right? It's only
just gone into final freeze. I agree that once it's released, backports is
definitely the right way to distribute.


> 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)).
>

So, I'd initially tried doing this, by adding the unstable repository at a
negative priority. What turned me off is that even with that low
preference, attempting to install the wireguard packages seemed to pull in
some core system libraries (libc and such) from unstable as well. And while
I'm excited about wireguard, I'm not "install unstable base libraries"
excited :).

That said, it's quite possible I was just not using the preference system
correctly. If it's possible to express "Install *only* wireguard-* from
unstable, never anything else", then I agree, that's definitely the way to
go.


>
> 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 :)
>

Fair enough, I defer to your greater experience with Debian packaging.
Fortunately, packagecloud's stats say that there were no installs from my
repository, so assuming I can get pinning to work properly, the only
systems that need cleanup are my own.

Cheers,
- Dave


>
>          --dkg
>

[-- Attachment #2: Type: text/html, Size: 4828 bytes --]