Unexpected dependencies of graphics/libGL

[Michael B. Eichorn]

On Wed, 2016-01-20 at 18:42 +0000, Luís Fernando Schultz Xavier da
Silveira wrote:
> Indeed. As I have said, it is the proper tool to build package
> repositories.
> 
> Maybe I should have rephrased myself as in
>   "If the extra dependencies compromise the jail, the output packages
>   can be compromised and, when installed, compromise the host
> system."
> 
> We can not live in a dreamland and expect that when a software
> malfunctions, it will be kind enough to output an error message and
> end with a non-zero exit code. It may also signal success but affect
> the binaries and files contained in the resulting package. However,
> as someone pointed out, I am repeating myself.

Ok, I think I see what your concern is now. I accept that you are
correct that building only what is necessary is safer.

I think the disconnect was that avoiding installing B-deps also
improves security and using poudriere to do this is relatively easy.
Your responses while correct that it did not solve your problem, were
somewhat over broad in ignoring this similar, but admittedly
incomplete, solution. This is probably why the thread 'blew up' in my
estimation.

Building only what you need is hard. It does take time and effort to
provide the configure options in the ports tree. As such it is
reasonable that porters might not choose to include every possible
case. However if you think an important one has been missed it is
reasonable to get in touch with the port owner and see if they will add
a configure option.

I think the list assumed that if your concern was not addressed by a
configure option it probably was either an oversight or not worth the
effort to have the option. And that if it was an oversight the port
owner would have fixed it on request. As such we incorrectly jumped to
the next best solution, not installing the B-deps.

> 
> Just because we find a trick to not install crapware like autoconf,
> it does not mean the integrity of the system is not affected by our
> use of it. 

> On Wed, 20 Jan 2016 11:16:42 -0600
> Brandon J. Wandersee <brandon.wandersee at gmail.com> wrote:
> 
> > 
> > Luís Fernando Schultz Xavier da Silveira writes:
> > 
> > > If the extra dependencies break the jail, the output packages can
> > > be
> > > malformed and, when installed, break the host system.
> > 
> > Nope. Leaving aside the fact that no package should even (ideally)
> > affect the base system (and so shouldn't break a jail), if a
> > Poudriere
> > jail does break, the build fails. Not the *port build*, but the
> > *Poudriere bulk build process.* The whole thing will crash out with
> > an
> > error message. And while Poudirere doesn't require ZFS, it was
> > crafted
> > with ZFS in mind, and if it is installed and run in a zpool then
> > any
> > time a jail is updated or a bulk build process executed, a snapshot
> > is
> > created beforehand. Should things become completely borken, the
> > jail
> > and/or repository can simply be rolled back.
> > 
> > Moreover, the package repository index is not updated until the
> > bulk
> > build for all packages is complete. If a particular package fails
> > to
> > build or pass a test then all packages upon which it depends are
> > skipped, and all builds for packages which depend up the failed
> > package
> > are ignored. Only successfully built packages are made available
> > for
> > installation/upgrades.
> > 
> > This can easily be resolved: Poudriere is the official build system
> > for
> > the FreeBSD ports team. All official packages you install via
> > pkg(8) are
> > built with it, and have been for a couple years now. Chances are
> > you're
> > not the first person to think about these things. If you don't
> > trust
> > Poudriere, you shouldn't trust packages. Since the ports system and
> > package manager are now bound to one another (with all ports being
> > built
> > into packages and installed/tracked with pkg(8)), if you don't
> > trust
> > packages, you probably shouldn't place too much trust in the ports
> > system, either.
> > 
> > If a particular port/package can be successfully built and
> > installed,
> > yet is causing problems on its host system then it's entirely
> > possible
> > that the port itself is faulty, or (perhaps more likely) that the
> > issue
> > stems from a bug or malicious code within the compiled software
> > itself. Poudriere can't account for such a circumstance, but then
> > it
> > doesn't have to. It's a build system designed to expedite the
> > building
> > of customized ports, while simulatneously preventing malicious code
> > from
> > being executed on the build system during that build process and
> > avoiding a port/package upgrade from failing on a host system part-
> > way
> > through and breaking things in the process. If a port successfully
> > builds in Poudriere, and its package is successfully added to the
> > repository, and then successfully installed on the receiving
> > system,
> > then Poudriere has successfully done its job.
> > 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5729 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20160120/6b40f8fd/attachment.bin>