[TxMt] Re: Bundle Management improvements?

[Claudia Pellegrino]

Hi,


> Homebrew wants to own /usr/local as if nothing else is there. 

That’s what Homebrew _used_ to do. These times are long gone.

(FULL DISCLOSURE for anyone who’s late to the party: Caskroom member here, with a few ties to the Homebrew project.)

I have also used MacPorts, and I see how you prefer the `/opt` approach. Homebrew has come a long way to play as nice with everyone as MacPorts does today. Homebrew now lives exclusively in `/usr/local/Homebrew`. It installs packages into `../Cellar` and `../Caskroom`, and occasionally into `/opt` if it makes more sense. Anything else in `/usr/local` is free for anyone. I believe that for a package manager, this behavior is adequately modest.

If you’re unsatisfied with the fact that Homebrew puts individual things into `/usr/local/bin` and under `/usr/local/lib`, then you might want to consider that the FHS has made them for exactly that purpose. Package managers on most Unix-ish OSes keep some stuff inside `/usr/local/bin` and `/usr/local/lib` because that’s what those directories were made for.

With `brew link`, Homebrew invites all and any software to make use of its infrastructure, such as creating and maintaining symlinks for you so your software won’t have to. That’s purely optional though; anyone is free to completely ignore Homebrew, and have their software do its thing anywhere at their own discretion, and that includes `/usr/local`.


> Many package managers do not really have strong vetting
> or security policies. Homebrew is one of those.

This is actually a quite important point you’ve made; I wish more people were aware of this!

You are mostly correct, The Homebrew project is one of those package managers for a reason. Homebrew doesn’t want to be a software discovery service. Instead, it wants Homebrew users to make their own informed decisions as to whether they want to install a particular package or not.

If `foobinator` is a known spyware, but at the same time notable and popular enough that users want a `foobinator` formula to be in Homebrew, then in Homebrew that formula be.

The bottom line for users is: Do your homework before you decide to trust a particular software, with or without Homebrew. Homebrew wants that decision to be up to you, and only you.

That said, Homebrew does have vetting processes in places. Not only does it support GnuPG signatures, it also enforces SHA256 hash verification for all formulas who include such a hash, which most formulas do. Whenever a formula needs to be updated, the tap maintainer double-checks that it still points to the same trusted upstream domain. The maintainer also downloads the payload from that trusted source, and verifies the updated SHA256 matches the downloaded file. This is not to make any guarantees that the software is safe to use. It is for you to be sure that you’re installing the exact same thing the tap maintainer has personally downloaded from an official source of the upstream package.

Speaking of trust, my impression so far is that contributors are vetted quite carefully before they are granted commit access. Even when such access is granted, the project’s GitHub repos enforce reviews before anything gets merged into master branches, which are also the branches that get released to the public. Recently, the Caskroom organization has introduced a policy that requires every maintainer to use 2FA for their GitHub account.

Of course, none of all those measures will guarantee 100 % security. Nor will any of it withstand any sufficiently sophisticated attack. But it’s enough to make me personally feel very safe using Homebrew and all its official taps. (CAUTION: as I have already stressed a number of times, the `claui/textmate` tap is NOT an official Homebrew tap, and will probably never be.)


> I am just not sure unmanaged homebrew github repos is the thing.

I can’t think of a reason for anyone to use an unmanaged tap. It absolutely needs to be properly maintained.

Until some individual or organization is going to step up and adopt the tap, or we as a community figure out that a Homebrew tap might not fit our bill at all, I’ll gladly continue to help maintain it in the meantime as my time allows. Needless to say, I’m committed to the same standards and degree of diligence as I’d expect from any maintainer of a source from which I download and install executable software.

What the repo needs most right now is more contributors and more maintainers. It needs people to add content so it becomes actually useful, and make people try it out. More maintainers means that we’d have forced reviews enabled for the entire master branch similar to the official taps, including veto rights for every maintainer. This is very important for security; as of right now, the repo is not safe to use because it requires users to trust me personally. Being a sole maintainer means nobody can guarantee that every commit, including my own, gets actually reviewed.


> I would like to hear more before people just jump on the convenience.

I fully agree, and I’m looking forward to discuss this further.


Regards,
Claudia



> ------------------------------
>  
> Message: 2
> Date: Fri, 7 Jul 2017 16:19:42 -1000
> From: ???????  
> To: TextMate users  
> Subject: [TxMt] Re: Bundle Management improvements?
> Message-ID: <7CC8A118-F7C5-4318-A814-54636955B8B2 at gmail.com>
> Content-Type: text/plain; charset="utf-8"
>  
> I am actually trying to avoid using homebrew.
> There are lots of great things in homebrew but a few flaws are definitely the assumptions  
> about the path and also the total lack of vetting.
> Homebrew wants to own /usr/local as if nothing else is there.
> Mac Ports on the other hand is a bit more careful to use an uncommon path in /opt and that  
> is pretty valuable to me.
>  
> Many package managers do not really have strong vetting or security policies. Homebrew  
> is one of those.
> Mac Ports is also not great at that.
>  
> It would be great if there were more guarantees than just whatever is on github and visible  
> to homebrew.
>  
> A directory of sorts to work with would be great but I feel like this is clearly a modern  
> and missing feature, I am just not sure unmanaged homebrew github repos is the thing.  
> I would like to hear more before people just jump on the convenience.
>  
>  
> > On Jul 7, 2017, at 12:02, Lewis Overton >  
> wrote:
> >
> > I use Textmate and Brew. Linking them sounds good.
> >
> > On Tue, Jul 4, 2017 at 11:03 AM, Ryan Fitzer >  
> wrote:
> > > To install a tmbundle, you?d run:
> > >
> > > $ brew tm install arduino
> > > If more than three people find this useful, I?ll be happy to piece together a small PoC.  
> >
> > This would extremely useful. I use Homebrew for so much already. Having it for bundles  
> would a huge benefit.
> >
> > Ryan
> >
> > On Jul 4, 2017, at 1:51 AM, Claudia Pellegrino >  
> wrote:
> >
> > Hi,
> >
> > The features that stand out to me immediately are: [?] CLI searching and installing.  
> > Caskroom member here. With our recent integration into Homebrew last year, I think  
> Homebrew now brings to the table a big part of what would be needed to manage TM bundles  
> via CLI today.
> >
> > In fact, anyone is free to create an (unofficial) Homebrew tap for TextMate bundles.  
> A tap is just a GitHub repo, e. g. github.com/textmate/homebrew-bundles .  
> It would contain a number of package files, which essentially point to the individual  
> download URLs of the tmbundles.
> >
> > This is what the user would do once to tap into the repo:
> >
> > $ brew tap textmate/bundles
> > To search for plugins, you?d run:
> >
> > $ brew tm search arduino
> > ==> Exact Match
> > tm-arduino
> > To install a tmbundle, you?d run:
> >
> > $ brew tm install arduino
> > If more than three people find this useful, I?ll be happy to piece together a small PoC.  
> >
> > Regards,
> > Claudia
> >
> > _______________________________________________
> > textmate mailing list
> > textmate at lists.macromates.com  
> > http://lists.macromates.com/listinfo/textmate  
> >
> > _______________________________________________
> > textmate mailing list
> > textmate at lists.macromates.com  
> > http://lists.macromates.com/listinfo/textmate  
> >
> > _______________________________________________
> > textmate mailing list
> > textmate at lists.macromates.com  
> > http://lists.macromates.com/listinfo/textmate  
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:  
>  
> ------------------------------