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

Firewalling your code

lackofimagination.org

Post reply on HN
Print view View original

31–40 of 82 posts

Re: Firewalling your code

#31

Post by xnorswap »

jonathanlydall wrote: post #10

This seems pretty neat for when your layer separation is merely by folders in JavaScript. It's unfortunate that this doesn't highlight any problems until the code is run as I feel it's always best to find out as soon as possible you're making a mistake, your IDE instantly telling you of a problem as you try write the code is the most ideal time, with the next being compilation. In this case probably even a simple int…

You can even do something akin to this package with the "InternalsVisibleTo" property on the assembly, so you can expose your internal classes to other specified assemblies. For non-C# folks, Internal classes are normally visible only to other classes within the same assembly. This is very useful for building a tightly controlled public API while maintaining a testable code-base.

This option is typically used for exposing your internal classes to a unit test project, but can also be useful for exposing to LINQPad, and could be used like the above to hand out control to other assemblies.

Re: Firewalling your code

#32

Post by samstave »

actionfromafar wrote: post #24
wokwokwok wrote: post #15

It’s probably over the top, although I respect the intent. The quickest way to destroy “velocity” is by introducing dependencies between implementation details with no barriers in code. The more constraints you have to satisfy when you make changes, the more effort it is to make the changes (provably); and thus, the more time it takes, destroying velocity. That said, doing this as described is probably overly dramati…

Do you mean that if the constraints are visible when you change the code, it's better? But "hidden" constraints which will manifest only under specific conditions under runtime are bad.

I dont know if thats what he is saying, but what you are saying sounds logical.

Re: Firewalling your code

#33

Post by yas_hmaheshwari »

matsemann wrote: post #26

This is basically what java modules do, right? From java 9 and onwards. You have public stuff within your module, that other packages in the module can use. But another module cannot use it without you declaring it as part of your actual public facing API. I don't see people use it much in application code, though. Often just a single module where people can call everything.

Yup, same experience here.

Java modules took a long time to land, but now, it looks like the whole exercise for making the JDK more modular. Haven't seen any use in the application code

Even things like Spring Modulith don't use Java modules

Re: Firewalling your code

#34

Post by [deleted] »

actionfromafar wrote: post #24
wokwokwok wrote: post #15

It’s probably over the top, although I respect the intent. The quickest way to destroy “velocity” is by introducing dependencies between implementation details with no barriers in code. The more constraints you have to satisfy when you make changes, the more effort it is to make the changes (provably); and thus, the more time it takes, destroying velocity. That said, doing this as described is probably overly dramati…

Do you mean that if the constraints are visible when you change the code, it's better? But "hidden" constraints which will manifest only under specific conditions under runtime are bad.

[deleted]

Re: Firewalling your code

#35

Post by bluGill »

tpetry wrote: post #23
eithed wrote: post #13

We're using similar approach in PHP application by facilitating https://github.com/spaze/phpstan-disallowed-calls In essence we have defined within each domain: a) Public folder with code that other domains can use b) domain folders (src and infra) with code that only given domain can use. This way developers know not to change public contracts for a (or if they do change them they do understand they're changing publ…

Letting a static analyzer do these checks is a sane approach! The runtime detection of code files is really weird and would fail with bundling etc.

Runtime is important if security matters. Assume an attacker has already compromised your program - how much damage can they do? If you check at runtime you can prevent the compromised code from calling your functions. Well maybe, we don't know what code was compromised or how it was, but many compromises are a buffer overflow that only runs a few hundred bytes of code (overflow more than that and you clobber something else important to the attack and so the whole fails) and so the attacker needs to quickly call some sensitive function so if that sensitive function is checking the attack can't do anything.

I've been thinking about the above for a while, but I have no yet figured out how to put it into practice. I'm also not sure how much value it would have against a real world attack. It seems like it should work but security is often weird.

Re: Firewalling your code

#36

Post by lmeyerov »

quectophoton wrote: post #29

Sounds similar to capabilities: https://en.wikipedia.org/wiki/Capability-based_security

Yep!

And more specifically, 'membranes', which JavaScript was extended with the 'proxy' construct to support: https://tvcutsem.github.io/js-membranes . The types world came into these ideas as scheme's higher-order contracts (dynamically enforced), such as runtime checking gradient types.

Playing those primitives & ideas out, we made library-level access control policies here that we called object views (at Google, part of caja), and more natively via browser extensions as aspect policies (conscript, at MSR, sort of like hooks for CSPs)

JS is very dynamic, so writing unhijackable policies was quite hard. Imagine being careful about every getter, having to pre-freeze every util/stlib, and trusting no libraries.

What's old is new again: LLM OS's want to give AI's access to everything in an app as tools, so either very little gets exposed, or we walk back into problems like these.

Re: Firewalling your code

#37

Post by bluGill »

ChrisMarshallNY wrote: post #21
ooterness wrote: post #20

Earlier quoted context omitted.

AFAIK, the only C++ access specifiers are private, protected, and public. Hardly an "insane number".

What about "friend"? Do they still have that? But you have a point. It's a bit overblown, and I'll tamp down the rhetoric.

The problem is these all assume you are not under attack. If you are an attacker you can ignore all that.

The C++ ABI is known (not to be confused with defined!) on my systems, so if you have a pointer you can add an offset to find any private member and then modify it (even if const you can change it - though the code may not read the change). You can also call any private function from anywhere because how the function is name mangled can be figured out. These tricks are undefined behavior in the C++ standard, but they will work in any implementation if you know how your implementation works under the hood - they will not work on a different implementation, but you can make a different version for different implementations.

The above tricks work for most languages, though the details are different for each.

Re: Firewalling your code

#38

Post by acc4everypici »

wokwokwok wrote: post #15

It’s probably over the top, although I respect the intent. The quickest way to destroy “velocity” is by introducing dependencies between implementation details with no barriers in code. The more constraints you have to satisfy when you make changes, the more effort it is to make the changes (provably); and thus, the more time it takes, destroying velocity. That said, doing this as described is probably overly dramati…

modules? crates??? uhmm... namespaces???

I think you're conflating the language design stuff with the tooling (packaging, and calling that 'modules') ....to be fair, you're conflating but I'm fanboying python

in any case, the point being there's a distinction between an linker and a compiler but not in interpreted languages. so comparing rust's crates with JS, python (even java) is an instance of apples-to-oranges comparisons

Re: Firewalling your code

#39

Post by bluGill »

tommica wrote: post #2

What an curious approach - seems like it would be a mess to maintain in a larger project, but the concept of controlling who/what can call the public functions is an interesting idea.

I have a somewhat different approach, using a multi-repo system and some packaging rules I can make some interfaces not available outside of my repository, and still others only available to a subset of the repositories.

there are pros and cons of multirepo vs monorepo. This is one interesting side effect of the multirepo approach.

Post reply on HN