poudriere, Go and networking

[Peter Pentchev]

On Fri, Dec 11, 2015 at 03:55:22PM +0000, Malcolm Matalka wrote:
> Piotr Florczyk <piotr.florczyk at gemius.com> writes:
> 
> > W dniu 11.12.2015 o 15:36, Kurt Jaeger pisze:
> >> Hi!
> >>
> >>> Recently I had to package couple of programs written in Go and godep is
> >>> becoming the standard for dependency tracking in Go projects.
> >>> For example I currently had to package telegraf. Here is the thing. Poudriere
> >>> disables networking after fetch phase and I don't know before extract
> >>> phase what dependencies are inside.
> >>
> >> We recently upgraded maven, the java-world 'make and godep' and all
> >> the ports that need maven to build have the same problem, see:
> >>
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188110#c37
> >>
> >>> So here is the question: would it be possible to have networking
> >>> enabled during extract phase ?
> >>> Or maybe there is another solution (some flag in ports maybe that
> >>> I'm missing ?)
> >>
> >> I think we need some fancy fetch target per distfile which basically
> >> uses technology-dependend (maven, godep, etc) ways to trigger
> >> the 'fetch' during the fetch-phase. Probably some sort
> >> of base-fetch vrs. dep-fetch ?
> >>
> > New target might not be needed but I think this is good idea. Altough it does not solve my problem with poudriere. In my case, the soonest I
> > can fetch dependencies is in post-extract target. So if poudriere didn't cut off networking at this stage we wouldn't need any changes and
> > every one would be happy.
> 
> This sounds like it would be a security hole to let a package download
> extra things that the FreeBSD package system does not know about and
> cannot validate.

FWIW, this is my personal opinion, too.  The FreeBSD Ports Collection is
supposed to be self-sufficient:
- anything a port needs should be available as, well, another port
- any changes to what a port needs should be vetted by the maintainer at
  the time of updating the port
- anybody should, at any time, be able to find out what a port depends
  on and what other ports depend on it using only "static" information
  from the ports tree

That last point is pretty important for people who maintain ports of
libraries or other widely-used software: sometimes, when preparing an
update to a new upstream version with important changes, it is very nice
to be able to test by yourself if these changes will break other ports
that depend on yours (or, of course, drop an e-mail to the maintainers
of these other ports saying "hey, here's a proposed update to my port,
could you check if it'll break yours?").

> > Even if we come up with proper solution it will require cutting off network at some later stage than post-extract. In my opinion we might
> > aswell move it to that point right now.
> 
> Perhaps you should make a tool which takes a go project as input and a
> FreeBSD package as output?

This sounds like the way to go.  The Debian Perl group has a tool that
goes by many names, but in at least one of its incarnations, cpan2deb,
it does exactly that - downloads a package from the CPAN archive,
examines its metadata files to find out what it needs, looks for these
dependencies in the Debian package archive, and outputs a skeleton of
a package that has these dependencies listed in the proper fields.
Of course, it may also do this later, after the package has been updated
and its dependencies have changed.

G'luck,
Peter

-- 
Peter Pentchev  roam at ringlet.net roam at FreeBSD.org pp at storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20151212/ada723e5/attachment.sig>