TextMate July 2017

textmate@lists.macromates.com

15 participants
19 discussions

4.8.0

by Bernd

Hi there, I upload generally the new versions of lftp with ‘brew'. But it is able to install this morning only the version 4.7.7 (Command in a the terminal of a Mac : 'brew install lftp’ - with link problems but it is easy to fix it) Do you know of this new version is now included in ‘brew' and how I can find it?  Tkx -- Bernd J.

8 years, 1 month

HTML output window not scrolling down when output appended

by Stefan Daschek

I recently started to notice that the HTML output window often (not always) no longer automatically scrolls down when new output is appended (eg. from a build task thats running for several seconds). Anyone else noticing this? Stefan

8 years, 1 month

tm_query --setting fontName

by じょいすじょん

Hello all, I'm looking to fix up the old TextMate Python Jedi completion bundle. The docstring viewer command returns this error. Setting or variable 'fontName' not found Traceback (most recent call last): File "Docstrings for word", line 10, in <module> completion.show_docstrings() File "/Users/myaccount/Library/Application Support/TextMate/Pristine Copy/Bundles/python-jedi.tmbundle/Support/completion.py", line 132, in show_docstrings font_name = subprocess.check_output([tm_query, '--setting', 'fontName']).rstrip() or "Menlo-Regular" File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 573, in check_output raise CalledProcessError(retcode, cmd, output=output) subprocess.CalledProcessError: Command '['/Applications/TextMate.app/Contents/Resources/tm_query', '--setting', 'fontName']' returned non-zero exit status 69 This is because the CLI command says no such key exists. /Applications/TextMate.app/Contents/Resources/tm_query --setting fontName Setting or variable 'fontName' not found Is there a modern alternative to fontName? Or, even better, a reference for that and other keys? thanks! JJ

8 years, 1 month

Vetting and security policies (was: Bundle Management improvements?)

by Claudia Pellegrino

Hi Josh, (I apologize for my replies to be attached to the wrong places in the thread. I have just figured out how to turn off the digest format. Please bear with me until the changes take effect.) > Thanks for pointing this out! I agree that in 2017 we should > be taking security seriously. I'd love to learn though, what > are some good ways to set up vetting and security policies? Off the top of my head: 1. Create an organization on GitHub, and move the repo there. Or maybe get another GitHub organization (TextMate?) to adopt it. This ensures that in the long run, more than one single person has the power to grant or revoke _Owner_ and _Maintainer_ privileges. 2. You have already mentioned a very effective measure: make it a policy to not allow `sha256 :no_check` without good reason. For TextMate bundles, this means in practice: always pin your Cask to a release; in cases where upstream does not issue releases or tags, pin the Cask to the latest commit instead; do not point to nightlies, or to upstream `head`; in case users really want it, create a separate tap for nightlies within the same GitHub organization. 3. On GitHub, enable forced reviews for any commit on the master branch; also, tick the box that says this actually covers anyone’s commits, including the owner’s. Configure the GitHub repo so any single maintainer has veto rights against merging. Make regular audits to ensure these setting are still in place. 4. Have two maintainers at the very least, and grant them the _Maintainer_ privilege to make #3 technically possible. 5. In the `url` stanza, do not allow domains where the maintainer can’t reliably determine who has control over the domain. For example, if the author of `Foomatic.tmbundle` offers their releases only via a Dropbox link, maintainers will not be able to keep track of authenticity as updates get released. 6. Do not be afraid to refuse a Cask if it fails to meet those standards for whatever reason. 7. On the GitHub organization level, grant the _Owner_ privilege to at least one more maintainer. Not only does this help keep the organization alive in case the original owner fails to be responsive, or fails to fulfill their duties, it also allows for quick reaction in case another owner’s account be ever compromised. 8. Speaking of compromised: enforce that anyone with _Maintainer_ or _Owner_ status have two-factor authentication enabled for their GitHub accounts. Make regular audits to ensure everyone continues to comply. 9. Check the contributions of anyone before you grant them _Maintainer_ status on the GitHub organization. Ensure that a person is trustworthy before you grant them _Owner_ status on the GitHub organization. 10. When creating or reviewing a Cask, make sure it contains a line that says e. g., # downloads.example.com was verified to be a canonical download # site at the time it was first introduced to this Cask On each update, double-check whether the `url` stanza still points to the same domain name as the one in the comment. 11. On each update, download the payload from the given source, and verify the updated SHA256 matches the downloaded file. (It’s OK to automate this.) When generating the hash, never use plain HTTP to download the file if it’s also available via HTTPS from the same source. 12. Use common sense before you grant anyone commit access or other privileges. Regards! Claudia

8 years, 1 month

Re: Bundle Management improvements?

by 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(a)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(a)lists.macromates.com > > http://lists.macromates.com/listinfo/textmate > > > > _______________________________________________ > > textmate mailing list > > textmate(a)lists.macromates.com > > http://lists.macromates.com/listinfo/textmate > > > > _______________________________________________ > > textmate mailing list > > textmate(a)lists.macromates.com > > http://lists.macromates.com/listinfo/textmate >

8 years, 1 month

Re: Bundle Management improvements?

by Claudia Pellegrino

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

8 years, 1 month

First PoC ready (was: Bundle Management improvements?)

by Claudia Pellegrino

Hello じょいすじょん, I have pieced together a small proof of concept and put it online for anyone to try: https://github.com/claui/homebrew-textmate Feedback and pull requests welcome. Regards! Claudia

8 years, 1 month

JSLintMate not working as advertised

by Jack Royal-Gordon

HI! I’ve installed JSLintMate and am trying to use it on the JS for my Rails project. I’ve tried to turn off complaints about “$” and “document” being undefined, but can’t seem to do so. I’ve tried with a “.jshintrc” resource file, and also with inline configuration. My inline configuration currently looks like: /* jshint undef: false, unused: false */ // global $, document … I read in the docs that single-line comments work as well as open-close comments, so I tried both formats. Not only did it not turn off all messages regarding undefined and unused variables, but it also did not turn them off for “$” and “document”. Does anyone have an idea why? In case it helps, the messages look like: JSHint found problems: ‘$’ is not defined. line 3 $(document).ready(function() { ‘document’ is not defined. line 3 $(document).ready(function() { …

8 years, 1 month

Bundle Management improvements?

by じょいすじょん

8 years, 1 month

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

TextMate July 2017