"cask" ports just keep on rolling in...

[Ruben Di Battista]

If I can express my opinion, I agree with Clemens.

In my opinion binary only ports should be allowed only for a very
restricted subset, where the effort is justified by the extreme complexity
of the build (and I'm also I'm not sure about that even, if someone managed
to build it, we should be able too ☺) or the port bering binary only (e.g.
osxfuse).



On Sun, 7 Feb 2021, 12:17 Clemens Lang, <cal at macports.org> wrote:

> Hi Ken,
>
> On Sat, Feb 06, 2021 at 11:35:58PM -0800, Ken Cunningham wrote:
> > although I was concerned about getting this pattern right before we
> > had too many of these to fix, it does seem the admins feel there's
> > really no issue to worry about here.
>
> I don't like this tone, Ken. "The admins" have as much obligation to
> provide infrastructure as anybody else in this project, which is none.
>
> If you feel repackaging binary archives is a thing MacPorts should
> support better, please invest the time to come up with patches that do
> this, or find somebody that will.
>
>
> > So I guess we just open the gate and let them in. There is no
> > recommendation for a requirement for a naming convention or other
> > identifier.
>
> Personally, I don't like this trend at all. It always used to be
> MacPorts' policy to compile from source except in cases where Apple's
> limitations made this impossible (e.g. because valid signatures with a
> developer certificate were required and an ad-hoc signature would not
> work).
>
> Now, we're apparently shipping binaries compiled by other people with
> other people's toolchains. When I previously installed things from
> MacPorts, I knew that I'd either compile those with my own toolchain
> locally, or that they had been compiled on MacPorts' buildbots.
> Repackaging binaries breaks that assumption and adds additional trusted
> third parties. If such parties were infiltrated by supply chain attacks
> such as Xcode Ghost, we'd now ship malware via 'port install'.
>
> I do know that we have recently started making more and more exceptions
> to this rule, e.g. for Java and Haskell, and I'm guilty of preferring
> these approaches to a broken build of a very outdated version, but I'd
> like to argue that we should keep asking ourselves the question "should
> we really trust this person's toolchain" before merging such ports and
> keep pushing for builds from source where those are feasible.
>
> Also, keep in mind that some licenses (GPL, LGPL) require us to ship the
> source code that was used to compile a certain binary. Our distfiles
> server does that automatically for everything that's compiled from
> source, but repackaging a binary that contains compiled GPL or LGPL code
> puts us in legal muddy water very quickly.
>
> --
> Clemens
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20210207/101cd7a7/attachment-0001.htm>