CLI (bearcli) can't be turned off

Bear feedback Bear Bug Report
1
  • Bear Version: 2.8.1

I do software development. It’s trivial occurence for us, devs, to use non-sandboxed apps and scripts.

Very important security feature of macOS is sandboxing aka System Integrity Protection. There is absolutely no way for a script or a third party app to read specific directories and containers:


ls ~/Library/Group\ Containers/group.com.apple.notes
Operation not permitted

ls -la ~/Library/Containers/net.shinyfrog.bear/Data
Operation not permitted

sudo ls -la ~/Library/Containers/net.shinyfrog.bear/Data
Operation not permitted

cat ~/Library/Group\ Containers/9K33E3U3T4.net.shinyfrog.bear/Application\ Data/database.sqlite
Operation not permitted

CLI privacy failure

With recent Bear update, a CLI helper got added. There is no way to disable it.

Previously, all bear notes were protected from a 3rd party script (see last ls above). Now they’re not. It’s trivial to fetch all notes using a simple script:

import { execSync } from 'node:child_process';
const ecmd = (cmd) => execSync(`/Applications/Bear.app/Contents/MacOS/bearcli ${cmd}`).toString('utf-8').trim();
const ids = ecmd('list').split('\n').map(line => line.split('\t')[0]);
const notes = ids.map(id => {
  try { return ecmd(`cat ${id}`); } catch (error) { return null; }
});
console.log(notes);

I’ve used nodejs for the example above, to showcase that any app (not just bash commands) can easily access it.

We need a way to disable it

I applaud LLM integrations, but if Bear markets itself as security-concious note tool, we can’t be expected to have privacy degradations like this, without a way to disable the new feature. A simple checkbox would be more than enough.

We need more docs about privacy trade-offs

If the checkbox gets added in the future, I think it’s important to document the behavior for users, in very explicit terms (can be accessed via terminal by random scripts vs can’t be accessed).

2 Likes
2

+1, also see a similar discussion in the Bear 2.8 release topic. We definitely need at least a way to turn this off for those who don’t need it, for example using a checkbox in settings.

3

I don’t want to fully disable it. Instead I want to generate a unique key for access. This key would need to be passed to the CLI to gain access to the data. Maybe I want the CLI for my script that regularly exports my .md files to an external encrypted folder. But, I agree with you, any other .sh or .js files would have no access to the CLI because they won’t have an access key.

4

The problem happens when passing the key to bearcli. Any process that can run ps can see the command-line options of every other process running on the system. And any process of the same user that can run ps can also see the environment passed on process creation. Which means they can see the key while bearcli runs if it’s passed in using one of those methods. Passing the key to bearcli on standard input doesn’t have that problem, but it complicates both bearcli and any app running it.

I think what we ultimately want is to be able to allow access to Bear notes through bearcli for certain apps only. However, I’m not aware of how to do that in an easy or standard way. So I’d express my wish and leave the implementation details to Bear developers.

An on/off switch in settings is definitely easier to implement and would solve the problem in the short run. In the longer run, it may be extended with a finer-grained control mechanism.

1 Like