Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Less is safer: Reducing the risk of supply chain attacks

obsidian.md

Post reply on HN
Print view View original

171–180 of 274 posts

Re: Less is safer: Reducing the risk of supply chain attacks

#171

Post by formerly_proven »

schmichael wrote: post #36
0cf8612b2e1e wrote: post #19

Earlier quoted context omitted.

Don’t most plugin models work this way? Does VSCode, Vim, Emacs, and friends do anything to segregate content? Gaming is the only area where I expect plugins have limited permissions.

vim and emacs are over 30 years old and therefore living with an architecture created when most code was trusted. Encrypting network protocols was extremely rare, much less disks or secrets. I don't think anything about the security posture of vim and emacs should be emulated by modern software. I would say VSCode has no excuse. It's based on a browser which does have capabilities to limit extensions. Huge miss on th…

iirc vscode has RCE by design when you use the remote editing feature (i.e. editing files on a server, which is obviously a bad idea anyway, but still a feature) and nobody gives a fuck.

Re: Less is safer: Reducing the risk of supply chain attacks

#172

Post by huimang »

ptx wrote: post #167

An alternative for those who want a native application and/or even less supply-chain risk is Zim [1], which uses GTK and is packaged by the major Linux distributions. [1] https://zim-wiki.org/

Zim doesn't have a native phone app and syncing, though, and that's a big draw of Obsidian. It's plenty secure if you don't install plugins all willy-nilly.

Re: Less is safer: Reducing the risk of supply chain attacks

#174

Post by sunaookami »

jabbany wrote: post #27
0cf8612b2e1e wrote: post #19

Earlier quoted context omitted.

Don’t most plugin models work this way? Does VSCode, Vim, Emacs, and friends do anything to segregate content? Gaming is the only area where I expect plugins have limited permissions.

Browser extensions also have a relatively robust permissions-based system. If they wanted to, one would guess that browser-ish local apps based on stuff like Electron/node-webkit could probably figure out some way to limit extension permissions more granularly.

>Browser extensions also have a relatively robust permissions-based system.

Yeah and they suck now. We need a better security model where it's still possible to do powerful stuff on the whole machine (it's MY computer after all) without compromises.

Re: Less is safer: Reducing the risk of supply chain attacks

#175

Post by debugnik »

tlavoie wrote: post #125
schmichael wrote: post #36

Earlier quoted context omitted.

vim and emacs are over 30 years old and therefore living with an architecture created when most code was trusted. Encrypting network protocols was extremely rare, much less disks or secrets. I don't think anything about the security posture of vim and emacs should be emulated by modern software. I would say VSCode has no excuse. It's based on a browser which does have capabilities to limit extensions. Huge miss on th…

I'd love to see software adopt strong capabilities-based models that enforce boundaries even within parts of a program. That is, with the principle of least authority (POLA), code that you call is passed only the capabilities you wish (e.g. opening a file, or a network socket), and not everything that the current process has access to. Thomas Leonard's post ( https://roscidus.com/blog/blog/2023/04/26/lambda-capabilit…

> OCaml's newer Eio effect system

Eio is an IO library out of many competing ones, not OCaml's effect system. The capabilities are an Eio thing, not an effects thing.

Re: Less is safer: Reducing the risk of supply chain attacks

#176

Post by deafpolygon »

aucisson_masque wrote: post #161
shelled wrote: post #115

Earlier quoted context omitted.

This app deals with very critical, personal, and intimate data – personal notes and professional/work-related notes, but proudly has an Electron app. This alone has seemed like a massive red flag to me.

Until there is a better alternative you’re left with electron. Nothing come close to obsidian.

There are better alternatives. It's just that people have convinced themselves they need the features Obsidian offers - because it makes them feel smart and important.

At the end of the day, you're just taking notes. If you write a journal, don't put it in something like Obsidian. Even Apple Notes is better (in security, privacy, etc) in this regards.

Re: Less is safer: Reducing the risk of supply chain attacks

#177

Post by CMay »

On the other hand, their actual dependency list looks closer to this, and this is definitely not comprehensive:

https://github.com/ionic-team/capacitor

https://github.com/Microsoft/tslib

https://github.com/codemirror

https://github.com/codemirror/autocomplete

https://github.com/codemirror/language

https://github.com/marijnh/style-mod

https://github.com/marijnh/crelt

https://github.com/marijnh/find-cluster-break

https://github.com/marijnh/w3c-keyname

https://github.com/cure53/DOMPurify

https://github.com/electron/electron

https://github.com/electron/get

https://github.com/debug-js/debug

https://github.com/vercel/ms

https://github.com/sindresorhus/env-paths

https://github.com/sindresorhus/got

https://github.com/sindresorhus/is

https://github.com/visionmedia/node-progress

https://github.com/npm/node-semver

https://github.com/malept/sumchecker

https://github.com/szmarczak/http-timer

https://github.com/szmarczak/defer-to-connect

https://github.com/szmarczak/cacheable-lookup

https://github.com/jaredwray/cacheable

https://github.com/biomejs/biome

https://github.com/sindresorhus/decompress-response

https://github.com/sindresorhus/mimic-response

https://github.com/octet-stream/form-data-encoder

https://github.com/szmarczak/http2-wrapper

https://github.com/szmarczak/resolve-alpn

https://github.com/sindresorhus/lowercase-keys

https://github.com/sindresorhus/p-cancelable

https://github.com/sindresorhus/responselike

https://github.com/sindresorhus/type-fest

https://github.com/sindresorhus/tagged-tag

https://github.com/max-mapper/extract-zip

https://github.com/sindresorhus/get-stream

https://github.com/Sec-ant/readable-stream

https://github.com/sindresorhus/is-stream

https://github.com/thejoshwolfe/yauzl

https://github.com/brianloveswords/buffer-crc32

https://github.com/andrewrk/node-pend

https://github.com/i18next/i18next

https://github.com/babel/babel

https://github.com/microsoft/TypeScript

https://github.com/lezer-parser

https://github.com/lucide-icons/lucide

https://github.com/mathjax/MathJax

https://github.com/mermaid-js/mermaid

https://github.com/moment/moment

https://github.com/mozilla/pdf.js

https://github.com/pixijs/pixijs

https://github.com/mapbox/earcut

https://github.com/primus/eventemitter3

https://github.com/matt-way/gifuct-js

https://github.com/matt-way/jsBinarySchemaParser

https://github.com/kaimallea/isMobile

https://github.com/browserslist/caniuse-lite

https://github.com/jkroso/parse-svg-path

https://github.com/avoidwork/tiny-lru

https://github.com/PrismJS/prism/

https://github.com/mourner/rbush

https://github.com/mourner/quickselect

https://github.com/remarkjs/remark

https://github.com/hakimel/reveal.js

https://github.com/barrysteyn/node-scrypt

https://github.com/nodejs/nan

https://github.com/mixmark-io/turndown

https://github.com/mixmark-io/domino

https://github.com/webpack/webpack

https://github.com/acornjs/acorn

https://github.com/nicolo-ribaudo/acorn-import-phases

https://github.com/browserslist/browserslist

https://github.com/web-platform-dx/baseline-browser-mapping

https://github.com/kilian/electron-to-chromium

https://github.com/chicoxyzzy/node-releases

https://github.com/browserslist/update-db

https://github.com/lukeed/escalade

https://github.com/alexeyraspopov/picocolors

https://github.com/samccone/chrome-trace-event

https://github.com/webpack/enhanced-resolve

https://github.com/isaacs/node-graceful-fs

https://github.com/webpack/tapable

https://github.com/guybedford/es-module-lexer

https://github.com/eslint/js

https://github.com/browserify/events

https://github.com/fitzgen/glob-to-regexp

https://github.com/isaacs/node-graceful-fs

https://github.com/npm/json-parse-even-better-errors

https://github.com/webpack/loader-runner

https://github.com/jshttp/mime-types

https://github.com/jshttp/mime-db

https://github.com/suguru03/neo-async

https://github.com/webpack/schema-utils

https://github.com/ajv-validator/ajv

https://github.com/epoberezkin/fast-deep-equal

https://github.com/fastify/fast-uri

https://github.com/epoberezkin/json-schema-traverse

https://github.com/floatdrop/require-from-string

https://github.com/ajv-validator/ajv-formats

https://github.com/ajv-validator/ajv-keywords

https://github.com/DefinitelyTyped/DefinitelyTyped

https://github.com/webpack-contrib/terser-webpack-plugin

https://github.com/jridgewell/sourcemaps

https://github.com/jestjs/jest

https://github.com/yahoo/serialize-javascript

https://github.com/browserify/randombytes

https://github.com/terser/terser

https://github.com/tj/commander.js

https://github.com/evanw/node-source-map-support

https://github.com/LinusU/buffer-from

https://github.com/mozilla/source-map

https://github.com/webpack/watchpack

https://github.com/webpack/webpack-sources

https://github.com/eemeli/yaml

Re: Less is safer: Reducing the risk of supply chain attacks

#178

Post by deafpolygon »

nylonstrung wrote: post #165

How much supply chain vulnerability can be mitigated just by pinning known safe versions of dependencies Did anyone need the newest xz version in the first place? What negative tradeoffs would have come from pinning a 2022 release for example

Depends on the pinned version. The pinned version might even have vulnerabilities themselves. The problem is trusting the ecosystem.

Re: Less is safer: Reducing the risk of supply chain attacks

#179

Post by debugnik »

raincole wrote: post #102
0cf8612b2e1e wrote: post #19

Earlier quoted context omitted.

Don’t most plugin models work this way? Does VSCode, Vim, Emacs, and friends do anything to segregate content? Gaming is the only area where I expect plugins have limited permissions.

> Gaming is the only area where I expect plugins have limited permissions. It's pretty much the opposite. A lot of modding communities' security model is literally just to "trust the community." Example: https://skylines.paradoxwikis.com/Modding_API > The code in Mods for Cities: Skylines is not executed in a sandbox. > While we trust the gaming community to know how to behave and not upload malicious mods that will…

I think they meant games that specifically come with a sandboxed scripting layer. Otherwise, I agree that most mods are indeed just untrusted patches for a native executable or .NET assembly.

I guess the intent behind Cities Skylines's support for mods is just removing the need for a mod manager and enabling Steam Workshop support.

Re: Less is safer: Reducing the risk of supply chain attacks

#180

Post by deafpolygon »

photon_garden wrote: post #81
brentm wrote: post #77

I've been using Roam Research since about 2020. Is Obsidian better?

Haven’t used Roam, but what I like about Obsidian: - All your data is just plain files on your file system. Automation and interop are great, including with tools like Claude Code. - It’s local-first, so performance is good. - It’s extensible. Write extensions in HTML, CSS, and JS. - It’s free. - Syncing files is straightforward. Use git, Syncthing, Google Drive, or pay for their cheap sync service which is quite goo…

The plain text thing is more of a feel-good argument than a practical one. If there’s a solid export path, the format isn’t really the issue... what matters is whether the app actually works the way you need it to. At the end of the day, your workflow lives or dies on how the software behaves... not on the file extension.
Post reply on HN