Ms Graph Calendar
v1.0.2Find available meeting times and free/busy slots for company employees using Microsoft Graph API. Use when user asks to schedule a meeting, find a free slot,...
⭐ 0· 307·1 current·1 all-time
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
medium confidencePurpose & Capability
The name/description (Microsoft Graph calendar free/busy lookup) matches the required env vars (AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET) and the included Node.js scripts which call Microsoft Graph. Required binaries include node (used by scripts); curl is listed but not used by the shipped scripts (minor mismatch).
Instruction Scope
SKILL.md instructs the agent and operator to collect Azure credentials and run the included scripts; the instructions are concrete and limited to resolving names and calling Graph endpoints. However the docs state "Credentials are read from env vars only — never log or echo them", while get-token.js both prints the access token to stdout and writes it to /tmp/openclaw-graph-token.json. That contradicts the stated 'never log' guidance and creates an accidental disclosure risk if console output is captured.
Install Mechanism
This is an instruction-only skill with Node.js scripts included; there is no external download or installer. No risky install URLs or extracted archives are present. The only runtime requirement is Node (and curl is listed but unused).
Credentials
Requested environment variables are appropriate for an app-only Microsoft Graph integration. However: (1) the skill caches and reuses an app access token by writing it to a temp file in the system temp directory without setting secure file permissions, which can expose the token to other local users; (2) get-token.js prints the access token to stdout (contradicting the README). These behaviours are not justified by the stated purpose and increase the blast radius of leaked credentials.
Persistence & Privilege
The skill writes persistent credentials to ~/.openclaw/ms-graph-calendar.json (setup sets file mode 600) and writes the access token to the system temp directory (no explicit mode). It does not request always: true and does not attempt to modify other skills. Persisting the client secret in the home config is expected for convenience, but the unsecured token in /tmp is a risk and should be hardened or removed after use.
Scan Findings in Context
[prints-access-token-to-stdout] unexpected: get-token.js calls console.log(json.access_token) and therefore prints the access token. Printing tokens to stdout contradicts the SKILL.md security note and increases chance of accidental leakage (logs, CI capture, screen scraping). Not expected for this purpose.
[writes-token-to-tempdir-without-permissions] unexpected: get-token.js writes the token file to os.tmpdir()/openclaw-graph-token.json without explicitly setting restrictive file permissions. While caching tokens is reasonable, writing them to a world-readable tmp file is not necessary for the described functionality and increases exposure to other local users or processes.
[stores-client-secret-in-home-config] expected: setup.js stores AZURE_CLIENT_SECRET in ~/.openclaw/ms-graph-calendar.json with file mode 600. Storing the client secret locally for convenience is expected; the file mode used mitigates some risk. This is expected given the skill's design.
What to consider before installing
This skill appears to implement what it claims (find free/busy via Microsoft Graph) but contains a few security inconsistencies you should address before use:
- Do not run this on a shared machine without changes: get-token.js prints the raw access token to stdout and writes it to a temp file in the system temp directory. That token could be captured by logs or read by other local users/processes. Consider editing get-token.js to remove the console.log of the access token and to write the token file with restrictive permissions (e.g., fs.writeFileSync(path, data, { mode: 0o600 })).
- If you prefer not to store credentials on disk, set AZURE_* env vars in a secure runtime (CI secret store, environment with restricted access) and avoid running setup.js.
- Ensure the Azure App has least privilege: only grant Calendars.Read and User.Read.All as needed, and follow the README's recommendation to apply an App Access Policy in Exchange Online so the app cannot read all mailboxes unless required. Have an admin grant consent rather than using broader rights.
- After testing, rotate the client secret if you accidentally exposed it (e.g., pasted it into chat or console logs). Remove the token file from /tmp if it exists.
- Minor doc/code mismatches: curl is listed as required but not used by the scripts; SKILL.md mentions a device code flow though the code uses client credentials flow. If you do not control the registry/source, prefer reviewing the code and running it in an isolated environment (container or VM) before giving it production credentials.
If you cannot or will not make these changes, treat the skill as risky and avoid installing it on multi-user systems or where console output is logged/collected.Like a lobster shell, security has layers — review code before you run it.
latestvk979r6wk7awwnk2w07fht916p582306g
License
MIT-0
Free to use, modify, and redistribute. No attribution required.
Runtime requirements
📅 Clawdis
Binsnode, curl
EnvAZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET
Primary envAZURE_CLIENT_SECRET
