port "cask" -- installing prebuilt binaries

[Ruben Di Battista]

Ehi, sorry I was not clear enough. Sometimes I’m very bad at expressing
what I have in mind, I’m sorry.

Hmm, I hadn't heard about that, but I don't run 10.14+ other than for
testing.

https://github.com/osxfuse/osxfuse/issues/590

Huh? Are you suggesting *disallowing* the use of precompiled binaries?
That would be crazy.

No, no. What I meant was to limit “cask behavior”, that for what I
understand is “binary-only” distribution, to only the ports that really
really are needed (like, for my use case, osxfuse).

The current approach seems reasonable and philosophically closer to the
FOSS movement (i.e. shipping default variants distributable ports as
binaries…). Maybe expanding the matrix of builds to more variants would be
also cool, but I imagine that this would require an insane amount of space
on the servers...

          _
-.     .´  |∞∞∞∞
  ',  ;    |∞∞∞∞∞∞
    ˜˜     |∞∞∞∞∞∞∞∞∞ RdB
    ,.,    |∞∞∞∞∞∞
  .'   '.  |∞∞∞∞
-'       `’
https://rdb.is


On 4 August 2020 at 22:35:47, Fred Wright (fw at fwright.net) wrote:


On Wed, 29 Jul 2020, Daniel J. Luke wrote:
> On Jul 29, 2020, at 9:30 PM, Fred Wright <fw at fwright.net> wrote:
[...]
>> Personally, I'd prefer the MacPorts approach if it were less stingy
>> with the binary archives. Ideally, one should be *able* to build from
>> source, but not be *required* to do so.
>
> How is it stingy? We have binary archives for everything that the
> buildbots can build that the licenses allow us to distribute, right?

Aside from the usual issues with non-default variants and certain old OS
versions, the main problem seems to be what appears to be an overly strict
interpretation of "distributable".

As a random example, consider ffmpeg. The license for ffmpeg shows as
GPL-2+. Although GPL prohibits binary-only distributions at the "meta
level", it does *not* demand that sources be bundled with the binaries.
It simply says that if they're not, there has to be clear information
available to the user on how to obtain the sources. It doesn't even
demand a working build procedure, just the sources. It might get a bit
fuzzy in cases where the sources are patched, in which case it's not 100%
clear that providing the original source plus the patches is adequate, or
whether it's necessary to provide the actual patched sources (though the
two are certainly morally equivalent), but in any case, MacPorts clearly
does both. Anyone can get the upstream source archive(s) via "port
fetch", get the sources in tree form via "port extract", and get the
patched sources via "port patch". I don't see how this fails to meet the
GPL requirements for any MacPorts user.

Now if one were to be really paranoid, one might consider that providing
binaries on servers that are accessible by means other than MacPorts could
constitute a GPL violation, due to not having the "clear path to sources"
that MacPorts provides. But if that's a concern, it could be easily
addressed by including a README.sources file in every directory on the
archive servers, either pointing to the corresponding source on a distfile
mirror (or directly upstream if necessary), or perhaps just pointing to
the MacPorts homepage.

And to pick a random sub-example, Debian offers ffmpeg as a binary
package.

> port, by default, will use the binary archives unless you tell it to
> build from source instead.

BTW, on an only mildly related note, I've seen a number of cases lately
where it successfully fetches a binary archive and than fails to fetch the
corresponding checksum file. It seems that it gets only one chance to do
this, and only from the same mirror where it fetched the archive. It's
become common for me to need a "cleanup pass" after doing "upgrade
outdated" across my VMs, where I manually retry the failed upgrades.

On Tue, 4 Aug 2020, Ruben Di Battista wrote:

> There's is one compelling need for having "binary only" install, and that
> is for the port "osxfuse", that is currently broken for 10.14+.
>
> There was a discussion about it on the Github project about the choice of
> making it close closed source... Nonetheless it would be useful to have
it
> in order to provide things like fuse file systems and so on.

Hmm, I hadn't heard about that, but I don't run 10.14+ other than for
testing.

I was involved in fixing some osxfuse bugs right around the time that
10.10 came out, making kext signature checking mandatory. On 10.9, it
warns you about an unsigned kext, but you can tell it to proceed. The fix
at the time (for the relevant OS versions) was to have MacPorts fetch the
binary distribution and extract the signed prebuilt kext from it, while
building the rest from sources. This is done starting with 10.9, to avoid
the dialog box, even though it's not strictly necessary until 10.10+.

It sounds like some more tightening of the security noose has caused
additional problems for osxfuse.

On Tue, 4 Aug 2020, Ruben Di Battista wrote:

> So my take here is to not provide pre-built binaries packages if not
> strictly unavoidable, like for the osxfuse project (since it was open
> source before).

Huh? Are you suggesting *disallowing* the use of precompiled binaries?
That would be crazy.

The amount of both human and computer time that's wasted rebuilding the
same binaries from the same sources with the same options is humongous.

Another thing that's often overlooked is that installing precompiled
binaries, especially when signed, is more secure than building from
sources. This is because the attack surface of the tools required to
install binaries is far smaller than the attack surface of the toolchains
needed to build them. If you think this is purely hypothetical, consider
the early Unix hack that implemented a backdoor that didn't appear in any
source code.

> One of the reasons I chose Macports for is the fact it builds its own
tree
> from source and it ships basically open source only software.

Anyone is free to configure it to do that. I suppose there could be a
strict source-only option that flatly refuses to install any port that
can't be completely built from source, but I doubt that many people would
use it.

Fred Wright
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200804/24da5e22/attachment.htm>