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

[Ryan Schmidt]

On Feb 7, 2021, at 09:59, Ken Cunningham wrote:

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

To clarify a couple things... The managers (Josh, Rainer and myself) are here to guide the project. We've been here longer than most so we can provide historical context about why things are done the way they're done and recommend consistency in how we do things. But our opinions are not meant to be directives that can never be broken. We've granted commit access to you and many others who have demonstrated competency and understanding of MacPorts traditions and we trust you to make sound judgements when it comes to making changes in MacPorts.

I did not mean to convey that I "feel there's really no issue to worry about here" or that "the current system is fine and there is nothing of significance that needs fixing". What I meant to convey was that *based on the concerns you had raised so far* in this thread, which I addressed in turn, I did not understand why you feel that the current situation is an "unworkable disaster". You declined to elaborate, saying "without ever trying it, you couldn't know". I've already spent hours on this thread that I didn't plan on spending, and I don't want to spend more time trying your portfile. If you believe your portfile exposes a flaw in MacPorts base or some other need for changes to base, please describe it.


>>> 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 thought that binary ports were exactly for what Clemens says above: "cases where Apple's limitations made [compiling from source] impossible" (or at least sufficiently difficult). I've said many times that I don't have a problem with that, and we've long had such ports in MacPorts already (e.g. for closed-source software like oracle-instantclient and libxl; osxfuse should be one too). But if we're proposing a more general acceptance of precompiled software, even if we could build it from source, then I think it's reasonable to ask why we would want to allow that.


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

It's not going to be me or the other managers who comes down from high with an edict telling everyone else how to handle this. I for one have demonstrated that I don't yet understand what the concerns are, so I'm not yet equipped to advise what to do. I recommend interested parties have a discussion, as in this mailing list thread, to come to an agreement about what the issues are and how each of them should be addressed. I will warn you that I may not personally be participating in this discussion, which does not mean the issues are not important, just that we all have to decide what we have time to work on, and I may not have time for this.