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

[Ken Cunningham]

> On Feb 7, 2021, at 03: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.

It wasn't meant to be a tone. Just stating the exact facts. 

> 
> 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.
> 

I did wonder about that, started some thought about how that might proceed, but the clear message was the current system is fine and there is nothing of significance that needs fixing.

> 
>> 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'.

Now that the reality of what this really means comes to the fore, people are starting the be more vocal about their thoughts on it. This is good. These ports have been coming in, with no plan so far.


> 
> 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



All true.

So new policy coming then?

As I stated at the very beginning months ago, with no plan or guidance, these just keep coming in. I am not championing this, but raising the flag here that there is a potential problem.

If it took a slightly more obvious message about what this really meant to get everyone to notice, I guess I accept that.

K