[WireGuard] The Distro Package Maintainers Thread

[WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

Hey guys,

So it looks like we're the distro people downstream of WireGuard:

Zorun: OpenWRT (perhaps a little Arch too?)
Daniel: Debian (which will then travel downstream to Ubuntu?)
Christian: Arch
Christophe: Fedora (which will then travel downstream to RHEL?) He
doesn't have time for this now, but including him in the thread
anyway, and hopefully he'll kindly forward this email onto someone
else he knows at Redhat
Jason: Gentoo

We have a couple topics to discuss and decide on:


=== 1. Package Names ===

Right now Daniel is doing the most clean and sensible thing and
dividing the package into two: wireguard-tools and wireguard (or is it
wireguard-module?). On the other end, in Gentoo I'm just keeping it in
one package called "wireguard" (maybe with USE flags down the line).
Christian is doing something a bit confusing and calling it
"wireguard-dkms" (for the module) and "wireguard" (for the tools),
when I think I'd rather prefer the latter be wireguard-tools if it's
always split.

Also, keep in mind that down the road there will also be
"wireguard-go" and "wireguard-rust", which will be administered with
the same "wireguard-tools". See https://www.wireguard.io/xplatform/
for details on that. (And, eventually, "wireguard-tools" will go away
when the functionality is merged into iproute2.)

Probably for the purposes of consistency and ease of use, we should
standardize our package names. So what about restricting naming to
either of these two naming options:

Option a) monolithic:
    Package name: wireguard

Option b) split:
    Tools package name: wireguard-tools
    Module package name: wireguard _or_ wireguard-${SUFFIX},
       where SUFFIX is modules, or dkms, or whatever the convention in
your OS is


=== 2. Experimental Status ===

WireGuard isn't meant for prime time. It's still under development,
and there won't be CVEs or responsible announcements made for various
issues. The purpose of this phase now is to get it out to interested
testers and experimenters for working out various issues. Debian is
very well suited for this configuration, with its experimental tree,
which is where the package will live until we release the first "0.1"
or "1.0" version that we stand behind. Arch has a similar place. I
think OpenWRT has a good slot for this too? And Fedora Rawhide is
always an unstable mess, so I think we'll be fine there. Gentoo has ~
and package.mask.

It's generally important we stay communicative about packaging status,
so that as the WireGuard project progresses, we can bump the package
along through the various tiers of repositories.

The issue of packaging naturally leads me to this next important point...


=== 3. Versioning ===

As mentioned prior, we're not at 1.0 or even 0.1. Many packagers can
deal with building straight from the git master with a live checkout.
But other packagers can't, and this isn't very nice for testing users
anyway, since they don't get version bumps for updating. So, it seems
wise for us to formalize a snapshot versioning scheme. First, there
are two ways of doing this:

a) I can tag snapshot releases.
b) You can select snapshot commit IDs.

I think between these two options (a) is clearly superior, since then
I can be sure to tag commits that at least build. Then the usual
distro infra can monitor the cgit atom feed (or whatever the methods
are) for generating version bumped packages. I won't be "announcing"
snapshot bumps on the mailing list, since there's nothing to announce
at this point, but it should be reasonable to monitor the cgit page,
or if you want I can send individual emails out; let me know what you
think about this.

With the actual version numbers itself, I think at least it should be
based on the big endian date stamp:

    0.0.20160701

Zero dot zero. But it'd be nice to further specify that these are
pre-release or experimental:

    0.0.20160701_pre
    0.0.20160701_experimental
    0.0.20160701_killskittens

Any preference on pre vs experimental vs killskittens vs something
else? I'm open to anything here.

The _suffix notation works well with how Gentoo does package versions.
What about the rest of you? For example, I think this might pose
problems:

    0.0.20160701.pre
    0.0.20160701.experimental
    0.0.20160701.killskittens

Or, if anyone has another idea for injecting a label like this into
the snapshot revision, speak up.

Overall, at the moment I'm leaning toward  0.0.20160701_experimental.
But I'll wait for responses before deciding anything.


=== 4. Dependencies ===

The `wg` program in tools only requires libmnl. I could probably get
rid of that dependency if it becomes an issue. Zorun and I worked a
while ago on getting it to run with musl and places where libresolv
doesn't have base64 routines, so i think it should be sufficiently
portable now, but let me know if it's an issue.

The kernel module itself requires a few options, which are most likely
already selected in your distros. I just added the menuconfig
locations of these for people who like to build their own kernels on
https://www.wireguard.io/install/#kernel-requirements . The options
CONFIG_NET_UDP_TUNNEL, CONFIG_IPV6, and
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT are required right now. I'll make
CONFIG_IPV6 optional sometime soon (and will let you know when I do
that). The option CONFIG_PADATA is not required, but it is very much
necessary to achieve good multi-core performance with WireGuard. For
OpenWRT builds that are running on single-core machines, you could do
without it, but for desktop/server distros, I _highly_ recommend it's
enabled, in whatever infrastructure that does this.

Regarding the topic of building infrastructure, it seems like with the
exception of OpenWRT and Gentoo, everyone else is converging on DKMS?
Is this right? If so, it appears that Christian's dkms.conf file is a
good start for this, and I'll consider putting it directly in the repo
at some point. Is anybody here well versed with DKMS? Does it have a
way of expressing and warning about dependencies?


=== 5. Current Status ===

In public repositories there are currently these:
  https://aur.archlinux.org/cgit/aur.git/tree/?h=wireguard-git
  https://gitweb.gentoo.org/repo/gentoo.git/tree/net-misc/wireguard/

I've seen some other package files shared privately. I think generally
speaking we're off to a good start.



Have I left anything out? How does that all sound to you guys?

Awaiting your feedback,
Jason

Re: [WireGuard] The Distro Package Maintainers Thread

[Christian Hesse]

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

"Jason A. Donenfeld" <Jason@zx2c4.com> on Thu, 2016/06/30 14:52:
> Christian is doing something a bit confusing and calling it
> "wireguard-dkms" (for the module) and "wireguard" (for the tools),
> when I think I'd rather prefer the latter be wireguard-tools if it's
> always split.

The package base name is "wireguard", not sure what happens when no split
package name matches the package base name. I will give it a try...

> Option b) split:
>     Tools package name: wireguard-tools
>     Module package name: wireguard _or_ wireguard-${SUFFIX},
>        where SUFFIX is modules, or dkms, or whatever the convention in
> your OS is

For AUR I will prepare dkms package only, that is named wireguard-dkms.
If this ever goes to an official repository we will have wireguard-arch (for
linux), wireguard-zen (for linux-zen), ...

> === 3. Versioning ===

I uploaded a git package to AUR, that will build from git HEAD and set the
version string accordingly. Currently we have "0.r9.g0624787-1" (no tag, 9
commits, most recent commit 0624787).

If you tag "0.0.20160701_experimental" the string changes to
"0.0.20160701_experimental.r0.g0624787-1" or similar. I can define what
happens in pkgver function.

I can upload a non-cvs version when first tag appears.
-- 
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Best regards             my address:    */=0;b=c[a++];)
putchar(b-1/(/*    Chris            cc -ox -xc - && ./x    */b/42*2-3)*42);}

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [WireGuard] The Distro Package Maintainers Thread

[Bruno Wolff III]

On Thu, Jun 30, 2016 at 14:52:04 +0200,
  "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
>Christophe: Fedora (which will then travel downstream to RHEL?) He
>doesn't have time for this now, but including him in the thread
>anyway, and hopefully he'll kindly forward this email onto someone
>else he knows at Redhat

Fedora people can publish EPEL packages, but I'm don't know Red Hat's 
stance on kernel module packages.

For Fedora, not having it in the upstream kernel will make it very difficult 
to get in Fedora proper, and doing COPRs may be a pain since kernel builds 
happen a lot for Fedora.

When it is actually in Fedora there won't be a package for the kernel module 
(as it will be part of the kernel-modules or kernel-modules-extra packages).

If it does get accepted for say 4.8, then getting a backported version into 
previously released Fedora's that may be running older kernels may be 
possible.

>=== 3. Versioning ===
>
>    0.0.20160701

Fedora splits the version into two pieces. The first part is the version 
and would be something like 0.0. As a prerelease the release should be 
0.x.dateandorcommit, where x is an integer that gets bumped every release 
and the rest can be a mix of date, tag or commit ID.
So the final version might look like 0.0-0.1.20160701 .

Re: [WireGuard] The Distro Package Maintainers Thread

[Daniel Kahn Gillmor]

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

On Thu 2016-06-30 08:52:04 -0400, Jason A. Donenfeld wrote:
> So it looks like we're the distro people downstream of WireGuard:

hi all!

> Option a) monolithic:
>     Package name: wireguard
>
> Option b) split:
>     Tools package name: wireguard-tools
>     Module package name: wireguard _or_ wireguard-${SUFFIX},
>        where SUFFIX is modules, or dkms, or whatever the convention in
> your OS is

I prefer option (b)

> Zero dot zero. But it'd be nice to further specify that these are
> pre-release or experimental:
>
>     0.0.20160701_pre
>     0.0.20160701_experimental
>     0.0.20160701_killskittens
>
> Any preference on pre vs experimental vs killskittens vs something
> else? I'm open to anything here.
>
> The _suffix notation works well with how Gentoo does package versions.
> What about the rest of you? For example, I think this might pose
> problems:
>
>     0.0.20160701.pre
>     0.0.20160701.experimental
>     0.0.20160701.killskittens
>
> Or, if anyone has another idea for injecting a label like this into
> the snapshot revision, speak up.
>
> Overall, at the moment I'm leaning toward  0.0.20160701_experimental.
> But I'll wait for responses before deciding anything.

debian can't include an underscore (_) in the version number:

 https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

and while debian policy suggests that in some circumstances hyphen (-)
and colon (:) are OK, they really shouldn't be used either, so i'd
prefer the dot (.) or plus (+) as a delimiter.

For release candidates: on debian, we can use the ~ character to mean
"just before" -- so if you want a pre-release version (say "release
candidate 1 for 0.1") i'd normally declare the upstream version as
0.1~rc1, which will sort as "earlier" than 0.1 itself.

anyway, i won't lose much sleep over it -- i can translate whatever you
decide makes sense as an upstream version to whatever fits in debian,
with as minimal a change as possible.

One question though: how will the release version relate to
PACKAGE_VERSION in src/dkms.conf?  do we expect those to track each
other or are they separable?

> Regarding the topic of building infrastructure, it seems like with the
> exception of OpenWRT and Gentoo, everyone else is converging on DKMS?
> Is this right? If so, it appears that Christian's dkms.conf file is a
> good start for this, and I'll consider putting it directly in the repo
> at some point. Is anybody here well versed with DKMS? Does it have a
> way of expressing and warning about dependencies?

DKMS works fine for me; i'm sorting out some minimalist debian
packaging, and will start with Christian's dkms.conf, though i'm curious
how other folks would approach the module versioning, as i mentioned
above.

> === 5. Current Status ===
>
> In public repositories there are currently these:
>   https://aur.archlinux.org/cgit/aur.git/tree/?h=wireguard-git
>   https://gitweb.gentoo.org/repo/gentoo.git/tree/net-misc/wireguard/

I'm going to be publishing debian packaging at:

  https://anonscm.debian.org/git/collab-maint/wireguard.git

I don't have anything to show there yet, but hopefully later today i'll
have something.

     --dkg

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

[WireGuard] debian packaging [was: Re: The Distro Package Maintainers Thread]

[Daniel Kahn Gillmor]

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

On Thu 2016-06-30 11:03:12 -0400, Daniel Kahn Gillmor wrote:
> I'm going to be publishing debian packaging at:
>
>   https://anonscm.debian.org/git/collab-maint/wireguard.git

OK, the master branch on the above repo contains debian packaging,
including a dkms configuration:

   https://anonscm.debian.org/git/collab-maint/wireguard.git/tree/debian/wireguard-dkms.dkms

Of which the following two lines at least might be useful if you want to
include dkms config upstream:

-----
# requires kernel 4.1 or greater:
BUILD_EXCLUSIVE_KERNEL="^(4\.[^0]|[5-9])"
-----

I've tested the package and it works.  The package should make its way
to the debian NEW queue shortly:

  https://ftp-master.debian.org/new.html

and after it is vetted by debian's ftp-masters, it should propagate to
experimental.

The debian bug report tracking this package is:

   https://bugs.debian.org/829107

Regards,

        --dkg

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

Re: [WireGuard] debian packaging [was: Re: The Distro Package Maintainers Thread]

[Jason A. Donenfeld]

Hey Daniel,

Amazing! Super pumped for this. Thanks for making this happened. It's
always a pleasure watching the Debian distro mechanics in action --
the neat bug reporting email system, the git repos, the ftp-master
requests, etc.

Very much looking forward.

Jason

Re: [WireGuard] debian packaging [was: Re: The Distro Package Maintainers Thread]

[Jason A. Donenfeld]

> drwxr-xr-x root/root         0 2016-07-01 16:32 ./usr/share/doc/wireguard-tools/examples/client-server-example/
> -rwxr-xr-x root/root      1015 2016-07-01 16:32 ./usr/share/doc/wireguard-tools/examples/client-server-example/client.sh
> -rwxr-xr-x root/root       779 2016-06-28 16:32 ./usr/share/doc/wireguard-tools/examples/client-server-example/server.sh
> drwxr-xr-x root/root         0 2016-07-01 16:32 ./usr/share/doc/wireguard-tools/examples/stress-testing/
> -rw-r--r-- root/root       580 2016-06-28 16:32 ./usr/share/doc/wireguard-tools/examples/stress-testing/badpacket.c
> -rw-r--r-- root/root      1296 2016-06-28 16:32 ./usr/share/doc/wireguard-tools/examples/stress-testing/peg.c
> -rwxr-xr-x root/root      1013 2016-07-01 16:32 ./usr/share/doc/wireguard-tools/examples/stress-testing/self-send.sh
> -rwxr-xr-x root/root       909 2016-06-28 16:32 ./usr/share/doc/wireguard-tools/examples/stress-testing/threewayiperf.sh
> -rw-r--r-- root/root       541 2016-06-28 16:32 ./usr/share/doc/wireguard-tools/examples/wgserver.service



These are not examples that are worth distributing. wgserver.service
is somewhat useful, but stress-testing/* is definitely NOT
APPROPRIATE, and I probably should remove those from the public repo.
client-server is a parlor trick, but if anybody actually uses them or
anything like them in production, they'll completely undermine the
security of wireguard, so these scripts shouldn't be used either.
They've been nice for my own development, but I definitely don't want
these on people's machines. If you want one example, maybe the
.service file is okay. But please ditch the others.

Re: [WireGuard] debian packaging [was: Re: The Distro Package Maintainers Thread]

[Daniel Kahn Gillmor]

On Fri 2016-07-01 17:11:26 -0400, Jason A. Donenfeld wrote:
>> drwxr-xr-x root/root         0 2016-07-01 16:32 ./usr/share/doc/wireguard-tools/examples/client-server-example/
>> -rwxr-xr-x root/root      1015 2016-07-01 16:32 ./usr/share/doc/wireguard-tools/examples/client-server-example/client.sh
>> -rwxr-xr-x root/root       779 2016-06-28 16:32 ./usr/share/doc/wireguard-tools/examples/client-server-example/server.sh
>> drwxr-xr-x root/root         0 2016-07-01 16:32 ./usr/share/doc/wireguard-tools/examples/stress-testing/
>> -rw-r--r-- root/root       580 2016-06-28 16:32 ./usr/share/doc/wireguard-tools/examples/stress-testing/badpacket.c
>> -rw-r--r-- root/root      1296 2016-06-28 16:32 ./usr/share/doc/wireguard-tools/examples/stress-testing/peg.c
>> -rwxr-xr-x root/root      1013 2016-07-01 16:32 ./usr/share/doc/wireguard-tools/examples/stress-testing/self-send.sh
>> -rwxr-xr-x root/root       909 2016-06-28 16:32 ./usr/share/doc/wireguard-tools/examples/stress-testing/threewayiperf.sh
>> -rw-r--r-- root/root       541 2016-06-28 16:32 ./usr/share/doc/wireguard-tools/examples/wgserver.service
>
> These are not examples that are worth distributing. wgserver.service
> is somewhat useful, but stress-testing/* is definitely NOT
> APPROPRIATE, and I probably should remove those from the public repo.
> client-server is a parlor trick, but if anybody actually uses them or
> anything like them in production, they'll completely undermine the
> security of wireguard, so these scripts shouldn't be used either.
> They've been nice for my own development, but I definitely don't want
> these on people's machines. If you want one example, maybe the
> .service file is okay. But please ditch the others.

I was distributing them as part of the experimental package to encourage
people to experiment with the tool.  I thought maybe it'd be useful to
get stress-testing reports from (for example) people running powerpc64
platforms or whatever.  The "parlor trick" is quite neat: clearly not
secure, but a nice quick way for people to be able to say "hey, this
things works on my platform" without needing to set up two ends of a
tunnel themselves.

i'm fine with removing them though, if you don't want them distributed.
They'll be gone in the next revision.

        --dkg

Re: [WireGuard] debian packaging [was: Re: The Distro Package Maintainers Thread]

[Jason A. Donenfeld]

There's this page here:
https://www.wireguard.io/install/#option-b-compiling-from-source

In the "Option B)" section, what command line would you like me to
specify for Debian?

Re: [WireGuard] debian packaging [was: Re: The Distro Package Maintainers Thread]

[Daniel Kahn Gillmor]

On Thu 2016-07-07 00:34:50 +0200, "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
> There's this page here:
> https://www.wireguard.io/install/#option-b-compiling-from-source
>
> In the "Option B)" section, what command line would you like me to
> specify for Debian?

something like this should work fine:

    # apt install pkg-config libmnl-dev build-essential linux-headers-$(uname -r)

Or, if they have the experimental apt repo installed they should just be
able to do:

    # apt-get build-dep wireguard


hth,

        --dkg

Re: [WireGuard] The Distro Package Maintainers Thread

[Baptiste Jonglez]

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

On Thu, Jun 30, 2016 at 02:52:04PM +0200, Jason A. Donenfeld wrote:
> === 1. Package Names ===
> Probably for the purposes of consistency and ease of use, we should
> standardize our package names. So what about restricting naming to
> either of these two naming options:
> 
> Option a) monolithic:
>     Package name: wireguard
> 
> Option b) split:
>     Tools package name: wireguard-tools
>     Module package name: wireguard _or_ wireguard-${SUFFIX},
>        where SUFFIX is modules, or dkms, or whatever the convention in
> your OS is

On OpenWRT, the packages are necessarily split, and the kernel package is
called kmod-wireguard.  For now I have named the tools package "wireguard",
but there's no problem changing that to "wireguard-tools".

> === 2. Experimental Status ===
> 
> WireGuard isn't meant for prime time. It's still under development,
> and there won't be CVEs or responsible announcements made for various
> issues. The purpose of this phase now is to get it out to interested
> testers and experimenters for working out various issues. Debian is
> very well suited for this configuration, with its experimental tree,
> which is where the package will live until we release the first "0.1"
> or "1.0" version that we stand behind. Arch has a similar place. I
> think OpenWRT has a good slot for this too?

All third-party OpenWRT packages go to https://github.com/openwrt/packages.
There is no notion of "experimental" repositories as this is third-party
anyway.  There are also special branches for stable releases, where
package versions are mostly "frozen":

  https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md#release-branches

> === 3. Versioning ===
> 
> As mentioned prior, we're not at 1.0 or even 0.1. Many packagers can
> deal with building straight from the git master with a live checkout.
> But other packagers can't, and this isn't very nice for testing users
> anyway, since they don't get version bumps for updating. So, it seems
> wise for us to formalize a snapshot versioning scheme. First, there
> are two ways of doing this:
> 
> a) I can tag snapshot releases.
> b) You can select snapshot commit IDs.
> 
> I think between these two options (a) is clearly superior, since then
> I can be sure to tag commits that at least build.

Agreed, you are the most suited person.  It's tedious to have to guess
when upstream changes are either significant or likely to break things.

> With the actual version numbers itself, I think at least it should be
> based on the big endian date stamp:
> 
>     0.0.20160701
> 
> Zero dot zero. But it'd be nice to further specify that these are
> pre-release or experimental:
> 
>     0.0.20160701_pre
>     0.0.20160701_experimental
>     0.0.20160701_killskittens
> 
> Any preference on pre vs experimental vs killskittens vs something
> else? I'm open to anything here.
> 
> The _suffix notation works well with how Gentoo does package versions.
> What about the rest of you? For example, I think this might pose
> problems:
> 
>     0.0.20160701.pre
>     0.0.20160701.experimental
>     0.0.20160701.killskittens
> 
> Or, if anyone has another idea for injecting a label like this into
> the snapshot revision, speak up.
> 
> Overall, at the moment I'm leaning toward  0.0.20160701_experimental.
> But I'll wait for responses before deciding anything.

There does not seem to be any restriction for OpenWRT regarding allowed
characters.  Personally, I'd like to keep the label short for readability
("exp", "pre", "alpha"...).

> Have I left anything out? How does that all sound to you guys?

How often do you plan to tag new snapshot releases?  For OpenWRT, I don't
plan to update the package more often than once every few weeks anyway.

Also, do you plan to have an infrastructure producing a tarball every time
you tag a release?

Baptiste

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

Re: [WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

Hi folks,

Thanks for the super helpful responses.

For versioning of tags, I'll go with "experimental/0.0.$(date
+%Y%d%m)". You can then do whatever you'd like with regard to version
numbers, so long as it contains the 0.0.YYYYMMDD somewhere. I've
already tagged the first one for testing:

https://git.zx2c4.com/WireGuard/snapshot/experimental/0.0.20160630.tar.xz

Zorun -- to answer your question: cgit turns snapshots into tarballs
automatically. (It also evidently imposes that directory scheme on the
tarball; Christian -- we'll discuss this oddness on the cgit list.)

I'll be signing the git tags with the public key on wireguard.io.

It seems like we've converged on the split packages wireguard-tools
and wireguard-dkms/kmod-wireguard. Sounds good to me.

I'll get a Gentoo ebuild cooking with the new snapshot. Looking
forward to seeing the other packages!

Yay!

Jason

Re: [WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

Et voila:

https://gitweb.gentoo.org/repo/gentoo.git/tree/net-misc/wireguard/wireguard-0.0.20160630.ebuild

Re: [WireGuard] The Distro Package Maintainers Thread

[Christian Hesse]

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

"Jason A. Donenfeld" <zx2c4@gentoo.org> on Thu, 2016/06/30 20:32:
> Hi folks,
> 
> Thanks for the super helpful responses.
> 
> For versioning of tags, I'll go with "experimental/0.0.$(date
> +%Y%d%m)". You can then do whatever you'd like with regard to version
> numbers, so long as it contains the 0.0.YYYYMMDD somewhere. I've
> already tagged the first one for testing:
> 
> https://git.zx2c4.com/WireGuard/snapshot/experimental/0.0.20160630.tar.xz

https://aur.archlinux.org/pkgbase/wireguard/

Resulting packages are:

wireguard-dkms 0.0.20160630-1
wireguard-tools 0.0.20160630-1
-- 
Schoene Gruesse
Chris

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

On Thu, Jun 30, 2016 at 9:27 PM, Christian Hesse <mail@eworm.de> wrote:
> https://aur.archlinux.org/pkgbase/wireguard/
>
> Resulting packages are:
>
> wireguard-dkms 0.0.20160630-1
> wireguard-tools 0.0.20160630-1

Beautiful!

Re: [WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

Investigating the / in the tag name a bit more, it seems git has all
sorts of problems with that. I'll get to addressing those in their
respective projects in due time, but for WireGuard, the experimental
snapshots will have a simpler naming scheme. Here's the new URL:

https://git.zx2c4.com/WireGuard/snapshot/WireGuard-experimental-0.0.20160630.tar.xz

Sorry for the churn. This should now be solid.

Re: [WireGuard] The Distro Package Maintainers Thread

[Daniel Kahn Gillmor]

On Thu 2016-06-30 22:41:46 -0400, Jason A. Donenfeld wrote:
> Investigating the / in the tag name a bit more, it seems git has all
> sorts of problems with that. I'll get to addressing those in their
> respective projects in due time, but for WireGuard, the experimental
> snapshots will have a simpler naming scheme. Here's the new URL:
>
> https://git.zx2c4.com/WireGuard/snapshot/WireGuard-experimental-0.0.20160630.tar.xz
>
> Sorry for the churn. This should now be solid.

Thanks.  This is the right choice :)

         --dkg

Re: [WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

Are these instructions correct?

Arch [AUR]:
    yaourt -S wireguard-dkms wireguard-tools

Debian [experimental]:
     apt-get install wireguard-dkms wireguard-tools

OpenWRT [trunk? 15.05?]:
    opkg install kmod-wireguard wireguard-tools

Gentoo [~arch]
    emerge wireguard

Re: [WireGuard] The Distro Package Maintainers Thread

[Christian Hesse]

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

"Jason A. Donenfeld" <zx2c4@gentoo.org> on Fri, 2016/07/01 23:28:
> Are these instructions correct?
> 
> Arch [AUR]:
>     yaourt -S wireguard-dkms wireguard-tools

Using yaourt is not the only but one of the possible ways to go...

Looks like this is sufficient, though:

yaourt -S wireguard-tools

This will find package base 'wireguard' and install all split packages.
-- 
Schoene Gruesse
Chris

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [WireGuard] The Distro Package Maintainers Thread

[Daniel Kahn Gillmor]

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

On Fri 2016-07-01 17:28:28 -0400, Jason A. Donenfeld wrote:
> Are these instructions correct?
 [...]
> Debian [experimental]:
>      apt-get install wireguard-dkms wireguard-tools

I'd just use:

      apt install wireguard-dkms wireguard-tools

thanks,

      --dkg

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

Re: [WireGuard] The Distro Package Maintainers Thread

[Daniel Kahn Gillmor]

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

On Sat 2016-07-02 08:39:44 -0400, Daniel Kahn Gillmor wrote:
> On Fri 2016-07-01 17:28:28 -0400, Jason A. Donenfeld wrote:
>> Are these instructions correct?
>  [...]
>> Debian [experimental]:
>>      apt-get install wireguard-dkms wireguard-tools
>
> I'd just use:
>
>       apt install wireguard-dkms wireguard-tools

on second thought, it's possible that people running with

   APT::Install-Recommends "0";

Or who are running a kernel which doesn't match the locally-installed
headers won't end up with the kernel module installed, because they
might not have the headers available for their running kernel.  On a
normal system where the admin hasn't done anything unusual, the headers
would be automatically installed because of the chain of
Depends/Recommends:

  wireguard-dkms Depends: dkms
  dkms Recommends: linux-headers-686-pae | linux-headers-amd64 | linux-headers-generic | linux-headers

If you want to be certain that they end up with a functional
wireguard.ko for their current kernel, it should be:

  apt install linux-headers-$(uname -r) wireguard-dkms wireguard-tools

I've updated /usr/share/doc/wireguard-tools/README.Debian to suggest
pulling in the headers as well.

hope this is useful,

     --dkg

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

Re: [WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

Hey guys,

We're all set now!

Updated the instructions on: https://www.wireguard.io/install/

Debian, OpenWRT, Arch, and Gentoo seem to be solid.

Regards,
Jason

Re: [WireGuard] The Distro Package Maintainers Thread

[Phillip Smith]

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

> Arch [AUR – module, tools]
> $ yaourt -S wireguard-dkms wireguard-tools

yaourt is not a standard part of Arch, and it's often frowned upon to use
it.
That section should read something like:

> Use the AUR to install the `wireguard-dkms` and `wireguard-tools`
packages.


On 5 July 2016 at 01:50, Jason A. Donenfeld <zx2c4@gentoo.org> wrote:

> Hey guys,
>
> We're all set now!
>
> Updated the instructions on: https://www.wireguard.io/install/
>
> Debian, OpenWRT, Arch, and Gentoo seem to be solid.
>
> Regards,
> Jason
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/wireguard
>

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

Re: [WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

On Tue, Jul 5, 2016 at 12:57 AM, Phillip Smith <fukawi2@gmail.com> wrote:
> yaourt is not a standard part of Arch, and it's often frowned upon to use
> it.
> That section should read something like:
>
>> Use the AUR to install the `wireguard-dkms` and `wireguard-tools`
>> packages.

Have you got a better suggestion for a "command"? What do you prefer
to yaourt for installing AUR packages?

Re: [WireGuard] The Distro Package Maintainers Thread

[Phillip Smith]

> Have you got a better suggestion for a "command"? What do you prefer
> to yaourt for installing AUR packages?

There isn't really a single official command for installing from the
AUR. It is assumed the user has an understanding of the AUR process,
and tools like yaourt are unofficial third-party utilities.
A bare minimum of commands to do it manually would be something like:
    git clone https://aur.archlinux.org/wireguard-dkms.git && cd wireguard-dkms
    makepkg -is
    cd ..
    git clone https://aur.archlinux.org/wireguard-tools.git && cd wireguard-dkms
    makepkg -is

Re: [WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

Six lines seems worse than one line. If users are expected to have "an
understanding of the AUR process", surely they'll be able to translate
yaourt into which ever tool they're using.

Re: [WireGuard] The Distro Package Maintainers Thread

[Christian Hesse]

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

Phillip Smith <fukawi2@gmail.com> on Tue, 2016/07/05 11:15:
> > Have you got a better suggestion for a "command"? What do you prefer
> > to yaourt for installing AUR packages?  
> 
> There isn't really a single official command for installing from the
> AUR. It is assumed the user has an understanding of the AUR process,
> and tools like yaourt are unofficial third-party utilities.
> A bare minimum of commands to do it manually would be something like:
>     git clone https://aur.archlinux.org/wireguard-dkms.git && cd
> wireguard-dkms makepkg -is
>     cd ..
>     git clone https://aur.archlinux.org/wireguard-tools.git && cd
> wireguard-dkms makepkg -is

This is a split package, so you should be fine with:

git clone https://aur.archlinux.org/wireguard.git
cd wireguard
makepkg -is

This requires pacman to be granted permissions by su or sudo, though.
How about splitting the install?

git clone https://aur.archlinux.org/wireguard.git
cd wireguard
makepkg

And with root privileges:

pacman -U wireguard-dkms-*.pkg.tar.xz wireguard-tools-*.pkg.tar.xz 

-- 
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Best regards             my address:    */=0;b=c[a++];)
putchar(b-1/(/*    Chris            cc -ox -xc - && ./x    */b/42*2-3)*42);}

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

Quick question -- how often is too often for you guys for publishing
snapshots? Once a week okay? Twice a week okay? Twice a month okay? It
doesn't matter because package bumping is all automated anyway?

Re: [WireGuard] The Distro Package Maintainers Thread

[Baptiste Jonglez]

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

On Mon, Jul 11, 2016 at 07:51:12PM +0200, Jason A. Donenfeld wrote:
> Quick question -- how often is too often for you guys for publishing
> snapshots? Once a week okay? Twice a week okay? Twice a month okay? It
> doesn't matter because package bumping is all automated anyway?

As I said before, once every ~two weeks is the minimum for me, as I like
to at least compile-test a new release before publishing it...

You can release more often, but then I would probably skip releases
(which is not a big deal).

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

Re: [WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

On Mon, Jul 11, 2016 at 11:20 PM, Baptiste Jonglez
<baptiste@bitsofnetworks.org> wrote:
> As I said before, once every ~two weeks is the minimum for me, as I like
> to at least compile-test a new release before publishing it...
>
> You can release more often, but then I would probably skip releases
> (which is not a big deal).

Okay, thanks. Well, let's get this latest snapshot with the NAT fixes
packaged so folks stop complaining. Then I'll focus more on
development than release for two or three weeks or so.

Re: [WireGuard] The Distro Package Maintainers Thread

[Daniel Kahn Gillmor]

On Mon 2016-07-11 19:51:12 +0200, Jason A. Donenfeld wrote:
> How often is too often for you guys for publishing snapshots? Once a
> week okay? Twice a week okay? Twice a month okay? It doesn't matter
> because package bumping is all automated anyway?

I also prefer to at least build and test manually before i upload.
weekly is probably fine.

If there's something critical, of course, please don't delay the release
of a fix due to my scheduling.  It's possible that i won't get a new
revision packaged the day of the release (or maybe even longer), but
that's no reason for you to not to publish an important fix as upstream.

i'll be more comfortable with a more automated package/release workflow
when i sort out better automated testing and continuous integration for
the package as a whole.

     --dkg

Re: [WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

On Tue, Jul 12, 2016 at 12:59 PM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:
> On Mon 2016-07-11 19:51:12 +0200, Jason A. Donenfeld wrote:
>> How often is too often for you guys for publishing snapshots? Once a
>> week okay? Twice a week okay? Twice a month okay? It doesn't matter
>> because package bumping is all automated anyway?
>
> I also prefer to at least build and test manually before i upload.
> weekly is probably fine.
>
> If there's something critical, of course, please don't delay the release
> of a fix due to my scheduling.  It's possible that i won't get a new
> revision packaged the day of the release (or maybe even longer), but
> that's no reason for you to not to publish an important fix as upstream.

Okay, noted.

>
> i'll be more comfortable with a more automated package/release workflow
> when i sort out better automated testing and continuous integration for
> the package as a whole.

That's a good point. Alright, that seems sufficient motivation for me
to construct a good automated test harness.

Last week Jonathan and I got the Go external test pinging. Maybe I'll
expand this and make a general framework for automated testing.

Re: [WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

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

On Jul 12, 2016 5:27 PM, "Jason A. Donenfeld" <zx2c4@gentoo.org> wrote:
> That's a good point. Alright, that seems sufficient motivation for me
> to construct a good automated test harness.

So I briefly thought about this and made some infrastructure changes. The
demo.wireguard.io box is now infrastructure stable enough for use in
automated test suites. So, as a first run at an automated test, these
things could happen:

1. dpkg -i path/to/pkgs
2. Set up a wireguard tunnel to the demo box.
3. ping -c 1 the demo box through the tunnel and see if it reports success.
4. remove the wireguard tunnel.

If these succeed, it passes.

Now (2) is a subtle point. It's not a good idea to use the private key in
the contrib/external-tests/ because it's possible somebody else will be
using it. (As a general rule, private keys should never be shared or leave
the box on which they were generated.) Alternatively, the ncat client.sh
can be used to provision things dynamically. Or, you could generate a
private key that remains private on debian infrastructure, and send me the
public key. I'm okay with either.

However, it might be easiest to simply use network namespaces and run all
this locally. I'm about to take an airplane; I'll create a 'make test' that
does this. Then you could just incorporate calling that into your build
system; would that work for you?

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

Re: [WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

On Wed, Jul 13, 2016 at 4:29 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> However, it might be easiest to simply use network namespaces and run all
> this locally. I'm about to take an airplane; I'll create a 'make test' that
> does this. Then you could just incorporate calling that into your build
> system; would that work for you?

I did it!

$ make test

Will now execute src/test.sh.

This script tries several things:

- Module insertion, which, in debug mode, does internal kernel tests
of algorithms.
- ICMP in v4 over v4
- ICMP in v4 over v6
- ICMP in v6 over v4
- ICMP in v6 over v6
- TCP in v4 over v4
- TCP in v4 over v6
- TCP in v6 over v4
- TCP in v6 over v6
- UDP in v4 over v4
- UDP in v4 over v6
- UDP in v6 over v4
- UDP in v6 over v6

It uses network namespaces and seems to work quite well. If the exit
status is 0, tests were successful. It is still quite basic, but will
be gradually expanded over time. I welcome patches for it.

https://git.zx2c4.com/WireGuard/tree/src/test.sh

Re: [WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

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

On Jul 13, 2016 6:35 PM, "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
> I did it!
>
> $ make test
>
> Will now execute src/test.sh.

If it turns out the test phase of the debian package build process isn't
permitted to do these things, we can always experiment with running this in
qemu or UML... the tests are entirely self-contained.

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

Re: [WireGuard] The Distro Package Maintainers Thread

[Baptiste Jonglez]

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

On Wed, Jul 13, 2016 at 06:42:57PM +0200, Jason A. Donenfeld wrote:
> On Jul 13, 2016 6:35 PM, "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
> > I did it!
> >
> > $ make test
> >
> > Will now execute src/test.sh.

Nice!

> If it turns out the test phase of the debian package build process isn't
> permitted to do these things, we can always experiment with running this in
> qemu or UML... the tests are entirely self-contained.

Good point: since the test must be run as root, I anticipate this will be
annoying for packagers: builds are performed as simple user, with no sudo
access (and obviously no *passwordless* sudo access).  At least that's how
it works for Arch and OpenWRT.

Anyway, it's probably a bad idea to muck with the kernel of the building
host, and it's not even possible when cross-compiling.

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

Re: [WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

On Wed, Jul 13, 2016 at 6:49 PM, Baptiste Jonglez
<baptiste@bitsofnetworks.org> wrote:
>
> Good point: since the test must be run as root, I anticipate this will be
> annoying for packagers: builds are performed as simple user, with no sudo
> access (and obviously no *passwordless* sudo access).  At least that's how
> it works for Arch and OpenWRT.

Right, this won't work for Arch and OpenWRT. I have a suspicion it'll
be fine in Debian, though... But waiting on Daniel to say whether or
not.

Once we get this working reliably there, I'll see if I can cobble
together some UML or qemu automation for the other platforms.

Re: [WireGuard] The Distro Package Maintainers Thread

[Martin Hauke]

Am 13.07.2016 um 19:58 schrieb Jason A. Donenfeld:
> On Wed, Jul 13, 2016 at 6:49 PM, Baptiste Jonglez
> <baptiste@bitsofnetworks.org> wrote:
>>
>> Good point: since the test must be run as root, I anticipate this will be
>> annoying for packagers: builds are performed as simple user, with no sudo
>> access (and obviously no *passwordless* sudo access).  At least that's how
>> it works for Arch and OpenWRT.
> 
> Right, this won't work for Arch and OpenWRT. I have a suspicion it'll
> be fine in Debian, though... But waiting on Daniel to say whether or
> not.
> 
> Once we get this working reliably there, I'll see if I can cobble
> together some UML or qemu automation for the other platforms.

It also won't work on the openSUSE Build Service.
All packages on OBS are built with a simple and restricted user.

Re: [WireGuard] The Distro Package Maintainers Thread

[Daniel Kahn Gillmor]

On Wed 2016-07-13 18:42:57 +0200, Jason A. Donenfeld wrote:
> On Jul 13, 2016 6:35 PM, "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
>> I did it!
>>
>> $ make test
>>
>> Will now execute src/test.sh.
>
> If it turns out the test phase of the debian package build process isn't
> permitted to do these things, we can always experiment with running this in
> qemu or UML... the tests are entirely self-contained.

this won't be done during the build phase of the package -- the build
phase of the package doesn't even build the kernel module, it just
sets up the dkms package.

However, debian has autopkgtest and https://ci.debian.net/

 https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst

Which i think will allow me to run these tests against all CI-supported
architectures (currently just amd64 and arm64 afaik, but future
expansion of CI would then automatically pull in wireguard).

I'll see if i can get something like this sorted out over the next few
days, and i'll post here if i have any results.

          --dkg

Re: [WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

Hey,

So I made a disgusting harness that uses QEMU and doesn't require
root. It compiles a kernel and then makes a little testing filesystem
for the VM, pulling down tarballs from random places and compiling
them.

It is arguably one of the grossest scripts I've ever made. But it
works very well. And I'm hoping the mere existence of it will
encourage you guys to send [PATCH]es that make it not as awful.

Here's a video of it in action: https://data.zx2c4.com/wireguard-qemu-test.mp4
And here's the script:
https://git.zx2c4.com/WireGuard/tree/src/tests/qemu.sh and
https://git.zx2c4.com/WireGuard/tree/src/tests/guest-init.sh

Interested to see what becomes of this...

Jason

Re: [WireGuard] The Distro Package Maintainers Thread

[Jason A. Donenfeld]

On Thu, Jul 14, 2016 at 4:27 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Here's a video of it in action: https://data.zx2c4.com/wireguard-qemu-test.mp4

If you want to skip many minutes of compiling, don't hesitate to skip
to the 6:40 mark...