<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Feb 12, 2017 at 3:01 PM, Daniel Kahn Gillmor <span dir="ltr"><<a href="mailto:dkg@fifthhorseman.net" target="_blank">dkg@fifthhorseman.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri 2017-02-10 19:23:50 -0500, David Anderson wrote:<br>
> In case it's of use to anyone, I've built wireguard packages for Debian<br>
> testing. I wanted to play with wireguard on my Debian Stretch systems, but<br>
> wireguard is currently locked to Sid only until 1.0 brings API stability<br>
> guarantees.<br>
><br>
> So, I set up a cronjob that rebuilds the Sid source package on a Stretch<br>
> system, and the result is wireguard packages that track the latest release,<br>
> but don't pull in unstable versions of libc and whatnot when you try to<br>
> install them, as would happen if you tried to install via package pinning.<br>
><br>
> Naturally, you have only my word that the packages are unmodified rebuilds<br>
> of Debian's original package, and you're trusting packagecloud to not<br>
> tamper with the packages (it's their signing keys, not mine) so caveat<br>
> emptor. It works for me, it might work for you as well.<br>
><br>
> With the warnings and disclaimers out of the way, here's the repo:<br>
> <a href="https://packagecloud.io/danderson/wireguard?filter=debs" rel="noreferrer" target="_blank">https://packagecloud.io/<wbr>danderson/wireguard?filter=<wbr>debs</a><br>
<br>
</span>I appreciate your interest in getting wider distribution for wireguard,<br>
David, but i'm not convinced this approach makes much sense.<br>
<br>
It seems like a lot of extra work compared to just putting wireguard<br>
into stretch-backports once stretch is released.<br></blockquote><div><br></div><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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Until stretch releases, people running testing should be able to just<br>
add the unstable repository and pin it to be lower priority than testing<br>
(see apt_preferences(5)).<br></blockquote><div><br></div><div>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 :).</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Using this standard approach, users won't need to:<br>
<br>
 a) add a new key to their apt configuration, which increases the attack<br>
    surface for all installed packages (btw, the proposed shell pipe<br>
    into "apt-key add -" is deprecated, see for example commentary at<br>
    <a href="https://bugs.debian.org/853858" rel="noreferrer" target="_blank">https://bugs.debian.org/853858</a><wbr>)<br>
<br>
 b) be dependent on some alternate suite of build daemons -- if debian<br>
    supports your build environment, the buildds will have the wireguard<br>
    packages.<br>
<br>
So I don't see much to recommend the proposed approach by comparison,<br>
and i don't think that it should be documented as a recommended approach<br>
upstream, unless there are clearer benefits that i'm missing here.  In<br>
that case, i'd like to know what those benefits are :)<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>- Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
         --dkg<br>
</font></span></blockquote></div><br></div></div>