From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: dave@natulte.net Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 32893f63 for ; Tue, 14 Feb 2017 04:41:58 +0000 (UTC) Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 0b364e54 for ; Tue, 14 Feb 2017 04:41:58 +0000 (UTC) Received: by mail-vk0-f44.google.com with SMTP id k127so73718565vke.0 for ; Mon, 13 Feb 2017 20:56:07 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <874lzzqai9.fsf@alice.fifthhorseman.net> References: <874lzzqai9.fsf@alice.fifthhorseman.net> From: David Anderson Date: Mon, 13 Feb 2017 20:55:45 -0800 Message-ID: Subject: Re: (Unofficial) wireguard packages for Debian Stretch (testing) To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=001a11415e88b491660548766155 Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --001a11415e88b491660548766155 Content-Type: text/plain; charset=UTF-8 On Sun, Feb 12, 2017 at 3:01 PM, Daniel Kahn Gillmor 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 > --001a11415e88b491660548766155 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Feb 12, 2017 at 3:01 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.ne= t> 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 f= or 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 stabili= ty
> guarantees.
>
> So, I set up a cronjob that rebuilds the Sid source package on a Stret= ch
> system, and the result is wireguard packages that track the latest rel= ease,
> but don't pull in unstable versions of libc and whatnot when you t= ry to
> install them, as would happen if you tried to install via package pinn= ing.
>
> Naturally, you have only my word that the packages are unmodified rebu= ilds
> of Debian's original package, and you're trusting packagecloud= to not
> tamper with the packages (it's their signing keys, not mine) so ca= veat
> 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=3Ddebs

I appreciate your interest in getting wider distribution for wiregua= rd,
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.

<= /div>
"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.
=C2=A0
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 i= nitially tried doing this, by adding the unstable repository at a negative = priority. What turned me off is that even with that low preference, attempt= ing to install the wireguard packages seemed to pull in some core system li= braries (libc and such) from unstable as well. And while I'm excited ab= out wireguard, I'm not "install unstable base libraries" exci= ted :).

That said, it's quite possible I was j= ust not using the preference system correctly. If it's possible to expr= ess "Install *only* wireguard-* from unstable, never anything else&quo= t;, then I agree, that's definitely the way to go.
=C2=A0

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

=C2=A0a) add a new key to their apt configuration, which increases the atta= ck
=C2=A0 =C2=A0 surface for all installed packages (btw, the proposed shell p= ipe
=C2=A0 =C2=A0 into "apt-key add -" is deprecated, see for example= commentary at
=C2=A0 =C2=A0 https://bugs.debian.org/853858)

=C2=A0b) be dependent on some alternate suite of build daemons -- if debian=
=C2=A0 =C2=A0 supports your build environment, the buildds will have the wi= reguard
=C2=A0 =C2=A0 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 approac= h
upstream, unless there are clearer benefits that i'm missing here.=C2= =A0 In
that case, i'd like to know what those benefits are :)
=

Fair enough, I defer to your greater experience with De= bian packaging. Fortunately, packagecloud's stats say that there were n= o installs from my repository, so assuming I can get pinning to work proper= ly, the only systems that need cleanup are my own.

Cheers,
- Dave
=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--dkg

--001a11415e88b491660548766155--