4 ms·

I remember a few months ago there was a discussion[1] here about how fossil, the VCS for sqlite, should bring in a dependency on mermaid charts already. Nothin

by jddj 3y ago

I remember a few months ago there was a discussion[1] here about how fossil, the VCS for sqlite, should bring in a dependency on mermaid charts already. Nothing against mermaid, but I guess supply chain attacks are hard to conceptualise until they happen. When we're shortsighted we risk our mitigations against vague but serious threat models losing out against convenience. [1]https://news.ycombinator.com/item?id=38886344 https://news.ycombinator.com/item?id=38886344

datascienced 3y ago
Could a plugin architecture accommodate this?
- samatman 3y ago
  Many moons ago, I was active on the fossil list (right before it became a forum, one of the many things fossil has built-in), hoping to achieve the opposite of this: a libfossil containing the core technology for a fossil repo, without all the other stuff that comes along with it. Someone had started work on this, but was unable to complete it. The maintainers were willing to consider the idea, but not do it themselves, which is (always, for any request, on any open source project, at any time) completely understandable. I still think it would be great if someone with the ability/interest/time made it happen. Version control is useful for many things other than software, and fossil's architecture is well-suited for a linkable all-purpose revision control library.
roenxi 3y ago
Well... supply chain attacks are trivial to anticipate. A lot of modern programming (I'm thinking JavaScript especially when I say this) involves what seems to be 100s of dependencies. If there is a 1% chance of a random repo having a backdoor, the project will be compromised. That is clear and obvious. The problem is that the people who act on this and minimise dependencies are at a significant economic disadvantage to those who don't. A project with high risk tolerance has to write a fraction of the code and solve a fraction of the problems as someone who carefully writes secure software. The trade off isn't just "convenience", we're talking massive differentials in productivity that favour insecure models. It is much cheaper to accept that data will leak sooner or later, to the point where we can assume that if something is economically developed that is evidence it can't possibly be secure. That isn't an argument for more security though; if possible it is better to just design systems where leaks don't matter (eg, here in HN it isn't clear why I'd care about a leak - everything is already public except for the IP address in the server log).
- akira2501 3y ago
  > The problem is that the people who act on this and minimise dependencies are at a significant economic disadvantage to those who don't People say this, but it my experience, it simply isn't true. You're at a _slight_ economic disadvantage, and if you anticipate it, and correctly staff and plan for it, it's entirely manageable. The huge win is that in the long run you are massively more productive and you're not held back by framework incompatibilities, version updates, or web standards changing faster than you can keep up. Many shops don't have the mentality or the expertise to actually do this, partly I feel because this canard as taken as rank truth and no one ever dares to challenge it. Web standards have gotten much better in the past 10 years, they're actually pleasant and useful now. > we're talking massive differentials in productivity You have an ability to get something that feels "fully featured" off the ground more quickly. I'd wait for the actual user reviews before I make a decision on the quality of the output.
- francescovv 3y ago
  > 100s of dependencies. If there is a 1% chance of a random repo having a backdoor, the project will be compromised Apologies for nit-picking, but that's not quite how sum-of-probabilities work. Total probability across 200 tries of 1% chance each, is ~87%: p=0 for _ in range(200): p=p+(1-p)*.01 print(p) 0.8660203251420382 Your "sooner or later, to the point where we can assume" conclusion, still stands, of course.
  - roenxi 3y ago
    Eh. I suppose 3 points, all minor: 1) Best of luck in an audit explaining that there is almost a 14% chance that your project is free of backdoors given reasonable assumptions. I recommend taking a photo of the auditor's expression and reporting back. 2) There are quibbles to be had about the IID assumption here; dependencies tend aren't selected randomly and attackers aren't targeting them randomly. 3) You don't need a for loop for that, you can calculate directly with `1-(0.99*200)`.
    - h4x0rr 3y ago

by jddj 3y ago

datascienced 3y ago

Could a plugin architecture accommodate this?

samatman 3y ago
Many moons ago, I was active on the fossil list (right before it became a forum, one of the many things fossil has built-in), hoping to achieve the opposite of this: a libfossil containing the core technology for a fossil repo, without all the other stuff that comes along with it. Someone had started work on this, but was unable to complete it. The maintainers were willing to consider the idea, but not do it themselves, which is (always, for any request, on any open source project, at any time) completely understandable. I still think it would be great if someone with the ability/interest/time made it happen. Version control is useful for many things other than software, and fossil's architecture is well-suited for a linkable all-purpose revision control library.

roenxi 3y ago

Well... supply chain attacks are trivial to anticipate. A lot of modern programming (I'm thinking JavaScript especially when I say this) involves what seems to be 100s of dependencies. If there is a 1% chance of a random repo having a backdoor, the project will be compromised. That is clear and obvious. The problem is that the people who act on this and minimise dependencies are at a significant economic disadvantage to those who don't. A project with high risk tolerance has to write a fraction of the code and solve a fraction of the problems as someone who carefully writes secure software. The trade off isn't just "convenience", we're talking massive differentials in productivity that favour insecure models. It is much cheaper to accept that data will leak sooner or later, to the point where we can assume that if something is economically developed that is evidence it can't possibly be secure. That isn't an argument for more security though; if possible it is better to just design systems where leaks don't matter (eg, here in HN it isn't clear why I'd care about a leak - everything is already public except for the IP address in the server log).

akira2501 3y ago
> The problem is that the people who act on this and minimise dependencies are at a significant economic disadvantage to those who don't People say this, but it my experience, it simply isn't true. You're at a _slight_ economic disadvantage, and if you anticipate it, and correctly staff and plan for it, it's entirely manageable. The huge win is that in the long run you are massively more productive and you're not held back by framework incompatibilities, version updates, or web standards changing faster than you can keep up. Many shops don't have the mentality or the expertise to actually do this, partly I feel because this canard as taken as rank truth and no one ever dares to challenge it. Web standards have gotten much better in the past 10 years, they're actually pleasant and useful now. > we're talking massive differentials in productivity You have an ability to get something that feels "fully featured" off the ground more quickly. I'd wait for the actual user reviews before I make a decision on the quality of the output.
francescovv 3y ago
> 100s of dependencies. If there is a 1% chance of a random repo having a backdoor, the project will be compromised Apologies for nit-picking, but that's not quite how sum-of-probabilities work. Total probability across 200 tries of 1% chance each, is ~87%: p=0 for _ in range(200): p=p+(1-p)*.01 print(p) 0.8660203251420382 Your "sooner or later, to the point where we can assume" conclusion, still stands, of course.
- roenxi 3y ago
  Eh. I suppose 3 points, all minor: 1) Best of luck in an audit explaining that there is almost a 14% chance that your project is free of backdoors given reasonable assumptions. I recommend taking a photo of the auditor's expression and reporting back. 2) There are quibbles to be had about the IID assumption here; dependencies tend aren't selected randomly and attackers aren't targeting them randomly. 3) You don't need a for loop for that, you can calculate directly with `1-(0.99*200)`.
  - h4x0rr 3y ago