This might be a better post for the homebrew repo, and I'll open up a ticket there as well, but wanted to see if anyone here who uses homebrew on their mac along with LS4? If so, do you install (not compile, but bottled) any formulae that are 'internet-facing'? For example-python, git, curl ,etc. (something that, when used, would trigger a LS connection alert).

If so, does anyone else's LS complain about the formula (git, curl, etc.) lacking a valid code signature? GIven this new security feature it seems counter-productive to ignore the warning issued by LS, but at the same time, I get the warning for every single program i download that faces the internet.

It would be nice if LS would at least do a SHA/md5 hash of the binaries and store those and use that to validate the binaries haven't changed since rule creation...and if it does change prompt the user so that they can approve/reject the rule being updated with the new hash. Path and file name matching is not secure by any means, and there will always be some code that goes unsigned (unless Apple wholly blocks unsigned binaries from executing in the future).

It would be nice if LS would at least do a SHA/md5 hash of the binaries and store those and use that to validate the binaries haven't changed since rule creation...

Yes please! Although I would recommend a hashing method that is not officially declared "insecure".

I love Little Snitch, but version 4 is so annoying for all developers who use a lot of command line binaries. Also the UX is quite bad if it allows to create "Allow always" rules for binaries without a valid code signature, because I as a user think I created that rule. But the next time the binary attempts to connect to some server the alert shows up again and my created rule won't even be considered by Little Snitch, because of the missing code signature... In this case I think it would be better to clarify to the user, that those rules have no effect.

First, verifying the integrity of unsigned code is something Little Snitch currently simply does not do. We have a couple of ideas floating around, but we’re not sure if or how we want to do this.This is a problem that other parts of macOS have too, by the way. For example, if you use an app that accesses Contacts, Calendar, Reminders, Location Services, etc. and that app is not signed at all, macOS simply creates an ad-hoc signature for it and remembers a hash in a database. It does this so it can know if someone modifies the executable and creates a new ad-hoc signature (this will result in another hash).Little Snitch could use this mechanism in the future to support what you’re asking for, but there’s a lot of research, implementation and testing to be done before this will be available – and we haven’t even decided if we want to do this yet.

Second, it sounds to me like there’s more friction going on than intended. If you’re using a command line tool that has no code signature and for which no rule exists, Little Snitch should show a connection alert like any other connection alert, just with the added warning triangle and line that the executable has no code signature. For example, with a copy of ping that I modified to have no code signature (I created a rule for “Forever”, not “Once” as in the screenshot …):

If you create a rule, that rule should ignore any code signature, i.e. the “Require valid code signature” should be unchecked (and even disabled) when you double-click the rule in Little Snitch Configuration:

The next time that command line tool establishes the same connection, the rule should match and you shouldn’t be bothered again. Does Little Snitch behave differently for you?

Please correct me if I am wrong but it seems that the situation is made worse by the fact that every time Homebrew formulae are updated, the Littlesnitch config needs manually renewing.

Some of us want to run unsigned, regularly updated software without Littlesnitch making life overly complicated. I've recently had issues updating Homebrew via SSH which appeared to break the previously configured Littlesnitch configuration. Having no access to the GUI to re-enter the Littlesnitch rules brought everything to a grinding halt.

@nudge: Could you please clarify what exactly needs manual tweaking after updates by Homebrew? As I wrote in my previous message, if you’re using executables that have no code signature, Little Snitch is intended to work exactly the same way as if they were signed, with only these two exceptions:

The connection alert shows a warning triangle and message that the executable has no code signature (see first screenshot in my previous message).

Any factory rules require a valid code signature and therefore will not match. Instead, a connection alert is shown (with the warning from the first point). Note that this may not apply for connections to/from the local network if Preferences > Security > “Ignore code signature for local network connections” is checked.

If there’s anything else, it could very well be that you’re seeing something that does not work as intended.

I was blaming code signatures when probably the problem is elsewhere. What I'm looking for are rules that don't need renewing after homebrew updates. As you'll know, when a utility installed via homebrew is updated, the link that points to the software changes to a new folder name corresponding to the new version. As Littlesnitch sees this as being something new, it isn't covered by existing rules. If that's right, how can a sysadmin work around this ? Is there a rule format that can handle that or someway of creating a subset of rules on one system and importing them via CLI on another ?

@nudge: Currently, Little Snitch rules require executables to be located at a specific path. We’re planning to add a new kind of rule that would only require a specific code signature. That wouldn’t help in this case, though, because the executables in question are not signed at all.

We do not plan to support wildcards in paths for security reasons. For the same reason, we also do not support any CLI or scriptability functionality. Little Snitch also prevents GUI scripting access, although this can be disabled in Little Snitch Configuration’s security preferences.

Only two possibilities come to my mind for what you ask for:

Enable GUI scripting access in Little Snitch and write a script that uses GUI scripting to paste rules in Little Snitch Configuration. (You can copy rules in plain text form in LSC, too).

Create rules in advance by guessing version numbers.

I understand that both of these suggestions are not exactly satisfactory. If you have any suggestions about what we could improve in this area, I’d be happy to hear them.

I understand the reasons for the choices Obdev have made in the past to maximise security, but I think now's a good time to review some aspects of Littlesnitch administration. As you say, gui scripting is disabled by default but users have the possibility to enable it, if they deem the risk worthwhile. You could have similar safety first defaults with regards to the importing of rules sets via GUI & CLI. This would be my preferred solution and I believe you'd be allowing a lot more people to benefit from Littlesnitch. Please correct me if I'm wrong, but currently there's a backup/restore option which is gui only and it's all or nothing. More flexibility with options that enable system administrators to handle user configs in typical business/education environments would help grow your user base quite quickly IMHO.

There's one other thing that I've noticed recently. It seems that non-admin users have the forever option greyed out and disabled when prompted by an alert. However, if they open the configuration menu and edit the temporary rule, they are allowed to make it permanent. Of course, non techies probably wont find that and will get repeat alerts. Which is unfortunate and can give them an unnecessarily negative experience of your product.

Thank you for time, I hope you'll be able to keep improving Littlesnitch rapidly and continue to help users better protect their data and privacy.

There will be improvements in this area in the future, but we’re not yet ready to share details.

nudge wrote:There's one other thing that I've noticed recently. It seems that non-admin users have the forever option greyed out and disabled when prompted by an alert. However, if they open the configuration menu and edit the temporary rule, they are allowed to make it permanent

The “Forever” option should only be disabled in some special circumstances where it would be problematic to create such a rule. These are:

If the Connection Alert is shown for a process running by another user with a UID >= 500 who is not logged in. In this case, you can only create a rule for “Anyone”. If it were for the other UID, you wouldn’t see the rule in Little Snitch Configuration and therefore couldn't edit or delete it anymore unless you logged in as that other user. To prevent surprises for that other user, you also can’t create a “Forever” rule.

@marco it's great to hear that you are working on these things, even if it's too early to talk about them. It's also very reassuring to know I can get quick feedback from you on this forum.

I believe your explanation about the Forever option has answered my question. I haven't checked but it sounds very likely this was related to processes running under another user UID as we have some background jobs running like this. In which case, this is not as big an issue as I imagined.

BTW: These forums are not an official support channel and we don’t monitor them very closely most of the time. If there’s an issue that requires an answer from us specifically (as opposed to from other users on this forum), please contact us directly via our tech support or on Twitter:

Especially with virtualenv of python, each project is initialized with a python copy (kind of -- with some soft links). When python or relevant is updated, little snitch starts to warn from scratch per project. If you have 20-sth projects it starts to be life consuming... virtualenv is sometimes recreated in our case for the tests.

I tried to give exception rules for the executables, taking the risk but couldnot manage it somehow.

Little Snitch in our case makes a big issue for us. MD5/signature/anything; we need sth. for this problem for a long time.